人月の神話を読んで、やはりわが社のシステムは寿命が近いと感じた

かの有名な、「人月の神話」を購入して読んだので感想。

IBM/360という、プログラムを交換可能な画期的な汎用機の、OS開発のプロジェクトを率いた人が著者

IBM/360は1960年代に発売され、この本の初版は1974年に発行された

すべて1974年に書かれたわけではなく、有名な「銀の弾丸などない」は1986年に書かれた文書で、後の版で追加された。さらに1995年に追加された部分もあり、この本一冊でプログラミングの歴史を知ることができる

構造化プログラミングや、オブジェクト指向が、どういう経緯で広まっていったかがわかり興味深い

この本を読むときは、最初の版と後の版を分けて考えるべきだ

学術的には最初の版のほうが価値があるだろうが、実務的には後の版に書かれている内容に価値がある

コンピュータの入出力にテープやプリンタを使ったり、一日に数時間、決められた時間だけコンピュータを占有してつかったりと、どこかで聞いた伝説のような話が繰り広げられる

しかし、本質はかわっていない、どころか、今も続いている風習の起源はもしかして、ここにあるのかもな、と考えさせられる部分がいくつもある

例えば、フローチャートをノイマン博士が導入し、根付いていったが、筆者は必要ないと思っているくだり、などその通りだと思う

そのほか、なるほどと思った点

・システムのリリースまでにかかる工数は、プログラム単体を作る工数の9倍

・人と月は交換できない、なぜならコミュニケーションコストと教育コストがかかるから

（ブルックスの法則：遅延しているソフトウェアプロジェクトに要員を追加するとさらに遅れる）

・アーキテクトが仕様を定めすぎると、開発者が創造性を発揮できない、ということはない。むしろ逆。制限があるほうが創造性を発揮できる

・プログラムのサイズが大きくなると開発工数は指数関数であがる（1.5乗）

・エントロピーが増大したシステムはやがて、修正を加えても改善につながらなくなる。一歩進んで一歩下がる

これは弊社のシステムの現状を適切に表現している

・銀の弾などない。ソフトウェア技術は進歩するが、システムの本質的な複雑さは変化しない

20年が経過し、状況が変化した

商用パッケージソフトやコンポーネントの再利用については、著者はこれほど広まるとは思っていなかったらしい

なお実装段階の問題だが、コンポーネントは使いこなすためには学習コストが高い

パッケージを使うことで本質的な概念のレベルを上げることができると言っているが、パッケージソフトはある意味、銀の弾丸になっている気もする

要件決める段階で、いかにフルスクラッチで作らず、既存のものを使いまわすかという、フレームワークやオープンソースに精通しているかが勝負になっているということか

ブルックスは、メタプログラミングが本質を攻略する鍵であると述べているし、パッケージの中を隠ぺいするのが正しいとか、開発チームは執刀医を中心とした外科手術チームみたいなものが理想だと述べている

これが後のSOA（サービス志向アーキテクチャ）やマイクロサービスアーキテクチャにつながっていくのだろう

そして一番大事だと思ったのがここ

・プロジェクトにかかる月数は投入人月の立方根に比例する

月数 = 2.5 x （人月）^ 1/3

自分が不勉強なだけかもしれないが、初めて聞く話だ

今後の仕事に生かしていきたい

・コスト曲線は最適なスケジュールより長くなると上昇する

・コスト曲線は最適なスケジュールより短くなると急上昇する

長すぎも短すぎもよくない