本書によって人口に膾炙したのが、｢ブルックスの法則｣である。遅れているソフトウェア開発プロジェクトでは、開発要員の増加はかえって遅れをひどくする、というもの。プロジェクトに必要な開発期間は、それぞれ分割された作業同志の順序性によって決まるし、要員数の上限は独立した作業の数による。
ソフトウェア開発プロジェクトの失敗原因は、大部分が開発期間の不足である。次のように分類できるという。
(1)見積り技術の未熟さ。その未熟さゆえに、プロジェクトの進捗上の問題点に気づくことが遅れ、｢すべて順調｣といったまったく誤った認識を持っていることさえ多い。
(2)｢人数と時間には互換性がある｣という誤った定理を信じていること。工程が遅れた時にさらに人間を投入し、結果としてかえってプロジェクトを混乱させてしまう。仕事に順序性があって分割できないならば、労力の投入は何の効果も期待できない。何人の女性を動員しても子供を産むには10カ月が必要なのである。
(3)見積り技術に自信がないことから、プロジェクト･リーダーは確固とした工程を確保する頑固さに欠けてしまうこと。あまりにも発注者の意向に合わせて、予定を立てることがないだろうか。
著者は、かつてＩＢＭの収益の大黒柱であったシステム/360、さらにはオペレーティング･システムであるＯＳ/360の開発責任者であった。ＯＳ/360の開発には1963年から1966年まで、約5000人・年が投入された。ピーク時にはプログラマ、ドキュメント作成者、マシン・オペレータ、事務員もろもろ支援グループを含めて1,000人以上が働いていたという。
本書は、ＯＳ/360という超大型システムの開発経験を集約したものであり、プロジェクト・リーダ、特にプログラマ管理担当者向けに書いたものだという。ソフトウェア開発論というだけでなく、組織論としても経営論としても読めるだろう。原著発行から数えても既に30年は過ぎている。しかし本質的な内容の陳腐化はまったくない。今日の読者の役割は、懐旧談として楽しむのではなく、本書で随所に提案されている種々の施策を現代版にアレンジして日常の開発作業に適用することであろう。
例えば、ソフトウェア開発には変更がつきものである。本書でも、唯一不変なのは変更があるということ自体である、と言っている。要求の変更はまぬがれないから、変更がないと仮定してすすめるより、変更のために準備しておいたほうがよいと。そして、プログラム・メインテナンスの基本的な問題は、欠陥をなおすということが他の欠陥を引き起こすことという点にあるという。二歩進んで一歩後退しているわけだ。
副次的影響が出ない、あるいは少なくともすぐわかるようなプログラム設計を行えば、メインテナンス・コストは著しく下がるだろう。｢オブジェクト指向｣は、この解答になっているだろうか。
◆『ソフトウェア開発の神話』フレデリック･Ｐ･ブルックスJr著、山内正彌訳、企画センター、昭和52(1977)/３
(本書は絶版であるが、原著発行20周年記念増補版として、下記の書名で再刊されている)
◆『人月の神話――狼人間を撃つ銀の弾はない』滝沢徹ほか訳、ピアソン･エデュケーション発行、星雲社発売、1996/２
◆フレデリック･Ｐ･ブルックスJr ｢ＩＢＭのシステム/360の父｣として知られている。開発マネージャーとして、またデザイン段階のオペレーティングシステム(ＯＳ)/360ソフトウェアプロジェクトのマネージャーでもあった。