人月の神話
セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。 The second is the most dangerous system a person ever designs; the general tendency is to over-design it.
彼は、それを「ブルックスの法則」と呼び、以下のように定義している。
ブルックスの法則:遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
そして、ブルックスは、その法則が成り立つ理由を以下のように分析している。
ソフトウェア・プロジェクトに人員を追加すると、全体として必要となる労力が、次の3つの点で増加する。すなわち、再配置そのものに費やされる労力とそれによる作業の中断、新しい人員の教育、追加の相互連絡である。
したがって、人員を追加することで、遅れているプロジェクトに対処することはできない。そこで、ブルックスは、スケジュールが遅れているときには、
スケジュールを立て直す
仕事の規模を縮小する
ことを提案している。ちなみに、ブルックスは、次のような目安で、スケジュールを運用している。
私の大まかなやり方は、スケジュールの1/3を設計に、1/6をコーディングに、1/4をコンポーネント・テストに、1/4をシステム・テストに割り当てるというものである。
全てのソフトウェアプロジェクト管理者は、形式に即した文書の小さな中核となるセットを作成するべきである。この形式に即した文書の小さなセットは次の役割を果たす。 プロジェクトの目標群に向けた道標 プロジェクトの目標群をどのようにして達成するかについての道標 目標群の達成を担当する人物を明らかにする 目標のそれぞれについて、達成することを予定している時期 目標のそれぞれについて、必要となる費用
形式に即した文書の小さなセットはまた、プロジェクトの遂行に不整合があることも明確に示す。こうした不整合は、形式に即した文書の小さなセットが無い場合は、その存在を認識することが難しい。
チームは、できるだけたくさんの方法で、お互いに連絡を取るべきである。非公式には、いつものプロジェクト会議で、技術的なブリーフィングで、共有の公式プロジェクトワークブックで(そして、電子メールで)。
プログラマは、何かを仮定するべきではない。つまり、プログラマは、自分が実装する機能について曖昧なところがあれば、自分で勝手に想像するのではなく、アーキテクトに機能の意図するところを明確にするために質問をするべきである。
多くの方面において増加する遅延が蓄積して、全体として大幅な遅延という結果になってしまう。細かい粒度でのそれぞれのマイルストーンごとに継続的に注意することが、各水準の管理 (マネジメント) では必要である。
2002年に出版された日本語訳の書籍より目次を記す。なお第16章から第19章は、二十周年記念版で新たに追加された章である (初版には無かった章である) 。
人月の神話——狼人間を撃つ銀の弾はない
二十周年記念増訂版の序文
初版の序文
訳者まえがき
第1章 タールの沼
第2章 人月の神話
第3章 外科手術チーム
第4章 貴族政治、民主政治、そしてシステムデザイン
第5章 セカンドシステム症候群
第6章 命令を伝える
第7章 バベルの塔は、なぜ失敗に終わったか
第8章 予告宣言する
第9章 五ポンド袋に詰め込んだ十ポンド
第10章 文書の前提
第11章 一つは捨石にするつもりで
第12章 切れ味のいい道具
第13章 全体と部分
第14章 破局を生み出すこと
第15章 もう一つの顔
第16章 銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項
第17章 「銀の弾などない」再発射
第18章 「人月の神話」の命題——真か偽か
第19章 「人月の神話」から二十年を経て
エピローグ 五十年間の不思議、興奮、それに喜び
注釈および参照文献
訳者あとがき
索引