人月の神話 (Frederick Phillips Brooks, Jr. 著、滝沢徹 訳、牧野祐子 訳、富澤昇 訳、丸善出版 発行)を、いくつかの章は流しながら読んだ。

この本は1975年に初版がでたもので、そろそろ発売から50年になろうとしている。記事の中に書かれている個々の事象は「お、まじか」と驚くような (しかし当時としては妥当であっただろう) How Toも多数ある。50年経つことを前提に置いて、細かい事象にはあまり深入りせずに読むことにしていた。

本の中で語られる「人」と「月」の常に等価交換できないということは、2023年の私の身の回りではありがたいことに当たり前に認識されているように思う。当たり前になっていることが、この本の功績なのだろう。

本の主張の本質はそのあたりだと思うが、それ以外に本を読んだ中で気になったトピックをいくつか記す。

ソフトウェア実体は、どの2つの部分をとっても似ることが無いので (少なくとも文レベルより上では)、大きさの割にはおそらく他のどの人口構造物よりも複雑なものだ。似通っている部分があれば、2つの類似部分を1つ - 外部または内部サブルーチン - にする。この点においてソフトウェアシステムは、重複要素 (部品) が、豊富なコンピュータやビルあるいは自動車などとは全く異なっている p171

ソフトウェア実体は、どの2つの部分をとっても似ることが無いと言い切れるかはわからないが、同一では無いとは言えると思う。ソフトウェア製品やソフトウェアデータの良いところの一つに、複製のコストがほぼかからないという点があるが、これをプログラムの内部構造に置き換えると、同一の操作を繰り返す場合はforや、関数、オブジェクトなどで処理をまとめられてしまう。1

建築物や機械製品の場合は同一のパーツというのが多数含まれており、それらの組み合わせで製品が成り立つ。つまり、設計図の中に記述されるコンポーネントは重複がある。プログラムの場合は、重複がないように構造を変えてしまうことができるので、設計図の中のどれも同一のコンポーネントではない。2

悲しいかな、自由形式で生成された英語のコマンドを確実に解釈する機能は、コマンドが音声であろうと文字であろうとも、現在の技術を超えてしまっている。p254

これは初版にはなかった章で、おそらく1995年などが文章中の「現在」にあたるが、この記述はいま大きく変わろうとしているように思う。たとえばスマートスピーカーのようなものはそれを一部示していたし、LLMの台頭により、今後のユーザインタフェースは自然言語をベースにして複雑な、プロ向けの操作も実現可能になるかもしれない。

プログラマは自分の担当でないモジュールの内部については、見せられるよりも隠蔽された方が非常に効率が良いのだと言う。p265

これは、例えば一例として低級言語を使う時と高級言語を使う時の違いに近いところがあるだろう。コンピュータのなかで行われている抽象化を自分のプログラムの中でも実装せよ、ということだ。高級言語でメモリアロケーションやメモリ上のデータ配置について考える必要が減るように、OSの提供するシステムコールを使うことでハードウェアの制御を考えなくて良いように、APIを介して外部サービスを使うことで、細かな挙動を気にせずに機能を利用できるように、ということと本質的には一緒に思う。自分が書くプログラムのなかで、どうやると違和感なく理解できる、使いやすいインタフェースになるかを考え、試し、うまい抽象化の方法を見つけるしかない。

Footnotes

  1. 何をまとめて何をまとめないべきかはここでは考えないこととする

  2. ここまで書いてみて思ったが、実際のところ何が違うのかは建築物や機械製品に詳しくないのでわからないな、という気持ちになった。ソフトウェアも、サブルーチンの実体は定義が一つだが、その呼び出しは多数の箇所で記述される。非ソフトウェアのコンポーネント自体の設計図が一つで、そのコンポーネントの利用箇所が多数ある、という構造と何が違うのだろうか?わからなくなってきた。