はじめに
Frederick P. Brooks Jr. の『The Mythical Man-Month（人月の神話）』を読みました。
初版は1975年、今回読んだのは1995年の20周年記念版（第2版）です。元になっている経験はIBM System/360とOS/360の開発、つまり1960年代前半の話です。にもかかわらず、この本は今も読まれ続けています。
正直に言うと、読む前は「有名だが古い本」という印象を持っていました。実際に通読してみると、印象がかなり変わりました。本書が扱っているのは、コンパイラでもメインフレームでもなく、「多人数で一つのものを作る」ときに必ず起きる構造的な問題です。技術が変わってもこの問題は消えません。だから残っているのだと納得しました。
この記事では、本書全体の要旨と章立てを整理したうえで、現在の開発現場にどう読み替えられるかを書きます。
本書は「エッセイ集」です。各章が独立した論考になっているため、順番に読まなくても成立します。ただし第4章〜第7章は一続きの議論なので、まとめて読むことをおすすめします。
書誌情報
| 項目 | 内容 |
|---|---|
| 原題 | The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) |
| 著者 | Frederick P. Brooks Jr. |
| 出版社 | Addison-Wesley |
| 初版 | 1975年 |
| 記念版 | 1995年 |
| 構成 | 第1章〜第15章（1975年版）＋ 第16章〜第19章（記念版で追加） |
著者はIBMでSystem/360のプロジェクトマネージャーを務め、その後OS/360ソフトウェアプロジェクトのマネージャーを担当した人物です。つまり本書は、当時世界最大級のソフトウェア開発を率いて苦しんだ当事者による回顧録でもあります。
記念版の構成が独特で、著者は初版を改訂していません。1975年版をほぼそのまま再録したうえで、20年後の視点から書いた4章を追加するという形をとっています。おかげで「当時こう考えていた／今はこう考えている」という差分がそのまま読めます。この構成自体が本書の価値を高めていると感じました。
本書の中心にある5つの主張
まず、通読して見えてきた柱を5つに整理します。
1. 人月は交換可能ではない
本書のタイトルの由来です。
見積もりで使われる「人月」という単位は、人数と月数を掛け算した値です。コストは確かにこの積に比例します。しかし進捗は比例しません。それにもかかわらず、この単位を使うと「人を増やせば月を減らせる」という誤解が生まれます。
著者は、人と月が交換可能になる条件を明示しています。それは、作業が分割可能で、かつ作業者間のコミュニケーションが一切不要な場合だけです。小麦の収穫や綿花の摘み取りはこれに当たります。システムプログラミングはまず当たりません。
分割できないタスクでは、人を増やしても期間は縮まりません。著者が挙げている例が印象的でした。
出産には、何人の女性を割り当てても9ヶ月かかる
さらに、分割可能でもサブタスク間の調整が必要なら、コミュニケーションのコストが上乗せされます。このコストは2種類あります。
- 教育・訓練: 新メンバーへの技術、目標、戦略、計画の共有。分割できないので人数に比例して増える
- 相互コミュニケーション: 各パートを他のパートと個別に調整する必要がある場合、n(n-1)/2 で増える
つまり人を増やすと、成果は線形にしか増えないのに、調整コストは二次で増えます。
2. ブルックスの法則
上の帰結が、本書で最も有名な一文です。
遅れているソフトウェアプロジェクトに人員を追加すると、プロジェクトはさらに遅れる
著者は、遅れたプロジェクトに人を足すと総労力が3つの形で増えると説明しています。
- 作業を再分割すること自体の手間と混乱
- 新メンバーの教育コスト（教える側の時間を奪う）
- 相互コミュニケーション経路の増加
「火にガソリンを撒くようなもの」という表現が使われていました。追加投入が新たな遅延を生み、その遅延がさらに追加投入を呼ぶという再生産サイクルに入る、という指摘です。
現場でこれを何度も見ている人は多いと思います。50年前に既に明文化されていた、という事実のほうが衝撃でした。
3. 概念的整合性（Conceptual Integrity）
個人的に、本書の本当の主題はこちらだと感じました。
著者はシステム設計における最も重要な考慮事項として、概念的整合性を挙げています。そして、かなり強い主張をします。
優れたアイデアが多数含まれているシステムよりも、一部の機能や改良を省いてでも、一貫した設計思想を反映したシステムのほうが優れている
判断基準として提示されているのが「機能と概念の複雑さの比率」です。機能の豊富さだけでも、単純さだけでも、優れた設計にはなりません。与えられた機能水準に対して、最も単純かつ直接的に物事を表現できるシステムが最良という基準です。
この節では、ヨーロッパの大聖堂が比喩に使われています。多くの大聖堂は世代交代のたびに様式が変わり、ノルマン様式の翼廊とゴシック様式の身廊が隣り合うような不統一を抱えています。一方でランス大聖堂は8世代の建築家が自分のアイデアを犠牲にすることで統一性を保った、と紹介されます。
そして著者は、プログラミングシステムのほうが大聖堂よりひどい不統一を抱えていると書きます。理由は世代交代ではなく、設計が多数の作業に分割され、多くの人が同時に行うからです。
ここで大事なのは、「単純さ」だけでは足りないという但し書きです。基本概念の数が少なくても、やりたいことを表現するのに基本機能の予期しない組み合わせが必要になるなら、それは直接的ではない、と著者は言います。要素と規則を覚えるだけでなく、慣用的な使い方まで学ばないと使えない設計は失敗している、というわけです。
APIやDSLの設計をしたことがある人には刺さる指摘だと思います。
4. アーキテクチャと実装の分離
「概念的整合性は少数の頭脳から生まれるべき」と「大規模システムは多人数を必要とする」は正面から衝突します。このジレンマの解決策として本書が提示するのが、アーキテクチャと実装の分離です。
ここでの「アーキテクチャ」は、ユーザーから見える製品の完全かつ詳細な仕様を指します。コンピュータならプログラミングマニュアル、コンパイラなら言語マニュアルに相当するものです。内部構造の設計ではありません。この定義は現代の「アーキテクチャ」より狭く、注意して読む必要がありました。
著者は、この分離をStretchやSystem/360で成功させ、OS/360では適用不足のために失敗した、と自ら書いています。
分離は「貴族制ではないか」という批判に対しても正面から答えています。著者の回答は、実装者にも十分な創造性の余地がある、というものです。アーキテクトは何をするかを決め、実装者はどうするかを決める。実装の発明的・創造的責任は実装者にある、という線引きです。
第5章では、アーキテクトが実装者と対立したときの振る舞いまで具体的に書かれていて、ここが妙に実務的でした。
- 実装の責任は実装者にあると忘れない。指示ではなく提案する
- 自分が指定したことの実現方法を常に提案できるようにしておく
- ただし、他の実現方法も受け入れる用意をしておく
- 提案は静かに、内々に行う
- 採用された改善の手柄は放棄する覚悟をする
最後の1行が効いています。技術的に正しいだけでは組織は動かない、という現実を踏まえた助言だと思いました。
5. 銀の弾丸はない
記念版で追加された第16章、本書でもっとも引用される論文です。
主張はシンプルです。技術・管理手法のいずれにも、10年以内に生産性・信頼性・簡潔性を1桁向上させる単一の発明は存在しない。
論の立て方が明快でした。著者はアリストテレスに倣い、ソフトウェア開発の困難を2つに分けます。
| 分類 | 内容 |
|---|---|
| 本質的困難（essence） | 複雑な概念構造を作り上げること自体に内在する困難 |
| 偶有的困難（accident） | 現在の表現手段や環境に付随するが、本質ではない困難 |
そして単純な算術を持ち出します。偶有的作業が全体の9/10を超えていない限り、それをゼロにしても1桁の改善は得られない、と。高水準言語もタイムシェアリングも統合環境も、偶有的困難を取り除く形で貢献してきました。だからこそ、次の1桁は同じ方向からは来ない、という論理です。
本質的困難として挙げられるのは4つです。
- 複雑性（complexity）: 同じ部分があればサブルーチンにまとめてしまうため、規模に対して部分がすべて異なる。建物や自動車のような繰り返し要素がない
- 同調性（conformity）: ソフトウェアは既存の制度・人間・他システムに合わせざるを得ない。その複雑さは恣意的で、単純化できない
- 可変性（changeability）: ソフトウェアは変更しやすいと思われているため、変更要求が集中する
- 不可視性（invisibility）: 本質的に空間的でないため、図で表現しきれない
そのうえで著者が提案するのは、魔法ではなく地道な方向です。
- 買えるものは作らない（マスマーケットの活用）
- 要件確立のための計画的な反復としてのラピッドプロトタイピング
- ソフトウェアを有機的に成長させる（動かしながら機能を足していく）
- 優れた概念設計者を発掘し、育てる
病気の管理が悪魔説から細菌説に移った瞬間、魔法の解決策への希望は絶たれたが、地道な進歩の道が開けた ── という比喩が使われていました。懐疑主義は悲観主義ではない、王道はないが道はある、というのが結論です。
章別ダイジェスト
各章の要点を短くまとめます。
第1章 タールピット
大規模システム開発を、太古の獣がタールに沈む姿になぞらえた導入です。もがくほど深く沈む、という比喩がそのまま本書の通奏低音になります。
技術的に重要なのは「プログラム」と「プログラミングシステム製品」の区別です。
| 段階 | 内容 | コスト倍率 |
|---|---|---|
| プログラム | 作者の環境で動く、それ自体で完結したもの | 1x |
| プログラミング製品 | 誰もが実行・テスト・修正・拡張できる。汎用化・テスト・ドキュメントが必要 | 3x |
| プログラミングシステムのコンポーネント | インターフェース準拠、リソース予算内、他コンポーネントとの結合テスト済み | 3x |
| プログラミングシステム製品 | 上記の両方を満たす | 9x |
「ガレージの2人が大規模チームを凌駕した」という話が成り立つのは、比較対象が違うからだ、という指摘です。見積もりの議論が噛み合わないとき、この表を思い出すと整理しやすいと思いました。
後半は「プログラミングの喜び」と「プログラミングの苦悩」を対で論じています。喜びとして挙げられるのは、ものを作る喜び、他人の役に立つものを作る喜び、パズルのような仕掛けを組み上げる魅力、常に学び続けられること、そして極めて扱いやすい媒体（純粋な思考）を扱えることの5つです。
最後の点が伏線になっています。媒体が扱いやすいからこそ実装は簡単だと錯覚し、それが第2章の楽観主義につながります。
第2章 人月神話
プロジェクトが失敗する原因として、カレンダー時間の不足が他のすべての原因の合計より多い、という宣言から始まります。
原因は5つに整理されます。
- 見積もり技法が未発達で、「すべてうまくいく」という誤った暗黙の前提を反映している
- 見積もり手法が労力と進捗を混同している（人月）
- 見積もりが不確かなため、圧力に対して頑固さを保てない
- スケジュールの進捗が適切に監視されていない
- 遅延が認識されたときの反応が「人員追加」になる
楽観主義の分析が面白かったです。プログラマは純粋な思考から構築するため媒体が扱いやすく、実装に困難はほとんど生じないと予想する。しかしバグが出るのは媒体のせいではなくアイデア自体に欠陥があるからであり、だから楽観は根拠を持たない、という論です。
また、単一タスクなら「すべてうまくいく」確率は有限だが、大規模作業は多数のタスクが連鎖するため、全体がうまくいく確率は無視できるほど小さくなる、という指摘もありました。
スケジュール配分の経験則も示されています。
- 設計: 1/3
- コーディング: 1/6
- コンポーネントテスト: 1/4
- システムテスト: 1/4
コーディングは全体の1/6に過ぎない、という主張です。コーディング部分だけを見積もって比率で全体を推定するのは危険だ、と釘を刺しています。
第3章 外科チーム
プログラマ間の生産性格差の話です。Sackman, Erikson, Grant の研究が引かれ、最高と最低の比率が生産性で約10:1、実行速度とメモリ使用量で5:1だったと紹介されます。しかも経験年数とパフォーマンスの相関は見られなかった、と（著者自身も普遍性には疑問を呈しています）。
ここから「小規模精鋭が最適」という結論が出ますが、著者はすぐに反論します。OS/360はピーク時1,000人以上、1963〜1966年で約5,000人年が投じられました。10人チームが仮に7倍の生産性を持ち、コミュニケーション削減でさらに7倍だとしても、5000/(10×7×7) ≒ 10年かかります。10年後に意味のある製品でしょうか。
このジレンマへの回答が、Harlan Mills の提案する外科チームです。豚の解体チームのように全員が肉を切り分けるのではなく、1人が執刀し、他の全員がその人の生産性を最大化するために支援する構造です。
役割は「執刀医（チーフプログラマ）」「副執刀医」「管理者」「編集者」「秘書」「プログラム事務員」「道具係」「テスター」「言語弁護士」の10人。設計と構築に関わる人数を絞りつつ、多くの人手を投入できます。
役職名は時代を感じますが、チームを「同質な人の集合」ではなく「役割の構造」として設計するという発想は今も有効だと思いました。
第4章 貴族制、民主主義、そしてシステム設計
前述の概念的整合性とアーキテクチャ／実装分離の章です。本書の理論的な中核です。
著者はここで4つの問いを立てます。
- 概念的整合性はどう達成するか
- それはアーキテクトの貴族制と実装者の平民層を意味しないか
- アーキテクトが実装不可能・高コストな仕様に迷走するのをどう防ぐか
- 仕様の細部を実装者にどう正確に伝達するか
第4章がこの問いの提示と1つ目の回答、第5章が3つ目、第6章が4つ目への回答という構成です。
第5章 第2システム効果
本書でもっとも実感を伴って読める章かもしれません。
最初のシステムを設計するとき、設計者は自分が何をしているか分かっていないと自覚しているため、慎重で抑制的になります。そのため成果物は簡素になります。その過程で思いついた装飾は「次回のために」取っておかれます。
そして最初のシステムが完成し、自信と熟達を得た設計者が2つ目に取りかかると──取っておいた装飾をすべて投入して過剰設計してしまう。これが第二システム効果です。
3つ目以降は、過去の経験が互いに一般的な特徴を裏付け、差異が一般化できない部分を明らかにするため、この罠は弱まる、とされています。危険なのは2番目だけ、という指摘が鋭いです。
例としてIBM 709（操作セットが豊富すぎて実際に使われたのは半分程度）、Stretch、そしてOS/360が挙げられます。著者は自分の担当したOS/360を第二システム効果の典型例として名指ししています。
さらに、第二システム効果は機能の追加という形だけをとらないとも指摘されます。前提が変わって陳腐化した技術を、それでも洗練させようとする傾向としても現れる、と。例として挙げられるのがOS/360のリンケージエディタです。静的オーバーレイ機能として史上最高峰の完成度でしたが、マルチプログラミングと動的コア割り当てが前提のシステムに属していました。「恐竜の最後にして最良の個体」という表現がされています。
技術的に立派であることと、その労力が正しい場所に注がれていることは別だ、という話として読みました。リライトの現場でよく起きることだと思います。
第6章 言葉を伝える
10人のアーキテクトが決めたことを、1,000人の実装者にどう正確に伝えるか。System/360で使われた手法が紹介されます。
- 書面による仕様（マニュアル）: 外部仕様書。何を書かないかを慎重に決める必要がある
- 形式的定義: 精密だが読みにくい。散文的定義と併用し、どちらが正本かを明示する
- 直接的な体現: 仕様を実行可能な形（シミュレータなど）で持つ
- 会議と裁判所: 週次の実務会議と、年2回程度の上位審級。決定は必ず文書化する
- 複数の実装: 同じ仕様に対する独立実装が仕様の曖昧さをあぶり出す
- 電話ログ: アーキテクトへの質問と回答をすべて記録し、定期的に配布する
- 製品テスト: 独立したテスト部隊を早期から置く
「決定を必ず文書化する」「質問と回答を記録して共有する」あたりは、現在のADR（Architecture Decision Record）やFAQ運用そのものです。ツールが変わっただけで、やっていることは変わっていません。
第7章 バベルの塔はなぜ崩壊したのか?
創世記のバベルの塔を、エンジニアリングプロジェクトとして経営監査するという構成の章です。
著者はプロジェクト成功の前提条件をチェックしていきます。明確な使命、十分な人材、十分な材料、十分な時間、適切な技術──すべて揃っていました。では何が欠けていたのか。
答えはコミュニケーションと、それに伴う組織化です。互いに話せなかったので調整できず、調整できないので作業が止まった。そして著者は行間を読み、コミュニケーション不全が争いと嫉妬を生み、離散に至ったと書いています。
大規模開発でも同じことが起きます。スケジュール破綻、機能の不整合、システムバグ。そのほとんどは、左手が右手のしていることを知らないから発生します。
対策として挙げられるのが、非公式なコミュニケーション、定期的な会議、そしてプロジェクトワークブックです。
ワークブックは独立した文書ではなく、プロジェクトで作られるすべての文書に課される構造だと定義されます。目標、外部仕様、インターフェース仕様、技術標準、内部仕様、管理覚書がすべてこの構造の一部になります。
目的は情報の制限ではなく、必要な情報が必要な人全員に確実に届くようにすることです。最初のステップは全メモへの採番。規模が大きくなればツリー構造にし、サブツリー単位で配布リストを管理します。
規模が大きくなるほど問題が非線形に悪化する、という指摘が繰り返されます。10人なら採番だけでよく、100人なら複数の線形シーケンス、1,000人なら構造化されたワークブックが要る、と。
なお本章の終盤ではコンウェイの法則も紹介されます。設計する組織の構造は、その組織のコミュニケーション構造を写したシステムを生むという法則です。1968年の指摘が、マイクロサービスやチームトポロジーの文脈で再発見されているのは周知の通りです。
第8章 指揮命令
見積もりの実証データを扱う章です。
重要なのは、コーディング部分だけを見積もって比率で全体を推定してはならないという警告です。コーディングは問題の1/6程度に過ぎず、その部分の見積もり誤差が全体に増幅されます。
そして、プログラミングの労力は規模に対して線形ではなく、指数的に増える（べき乗則的に増える）という各種データが紹介されます。
第9章 5ポンドの袋に10ポンド
メモリ容量という制約の下での設計の話です。
当時のIBM APLシステムが月額400ドルでレンタルされ、最低160KBを消費し、モデル165ではメモリ賃料が1KBあたり月12ドル──といった具体例が出てきます。数字は完全に時代物です。
しかし空間コストを設計上の管理対象として明示的に扱うという発想は生きています。マネージャは規模の予算を配分し、規模を管理し、規模削減の技術を育てなければならない、という主張です。
現代なら、コンテナイメージのサイズ、バンドルサイズ、クラウドのメモリ課金あたりに読み替えられます。空間と時間のトレードオフが必ず存在し、それを表現するにはデータ構造の設計こそが本丸である、という指摘も変わっていません。
第10章 文書仮説
「大量の書類の中で、少数の文書があらゆるプロジェクト管理の重要な軸となる」という仮説です。
職人からマネージャーになった人間には、書類は不要な邪魔に見える。実際そのほとんどはそうだ。しかし特定の一群だけは、経営業務の大部分を体現している──という論の運びが率直でした。
ソフトウェアプロジェクトで必要とされる中核文書として挙げられるのは、目標、製品仕様、スケジュール、予算、組織図、作業空間の割り当て、そして見積もり・予測・価格の対応表です。
文書化の効用として強調されるのが、書くこと自体が意思決定を強制するという点です。決定の断片が明確になり、曖昧なままにしておけなくなります。
第11章 捨てる計画
化学工学のパイロットプラントの比喩から始まります。実験室で動くプロセスを、一足飛びに工場に導入することはできない。中間段階が要る、と。
ソフトウェアも同じで、最初に構築したシステムはたいてい使い物にならない。遅すぎるか、大きすぎるか、使いにくいか、そのすべてか。捨てて作り直すことは、するかしないかではなく、必ずする。唯一の問いは、それを計画するか、それとも捨てるべきものを顧客に納品してしまうか、である──という論理です。
初版でもっとも有名なアドバイスの一つがここです。
1つは捨てる計画を立てよ。どのみち捨てることになる
ただしこの主張は第19章で著者自身が撤回します。詳しくは後述します。
章の後半は変化への対応です。「唯一の不変は変化そのもの」として、変化を例外ではなく生き方として受け入れよ、と説きます。設計面ではモジュール化、サブルーチン化、インターフェースの正確な定義、高水準言語の使用、そして変更の量子化（バージョン番号を振り、フリーズ日を設ける）が挙げられます。
組織面での指摘が鋭かったので引いておきます。設計者が文書化を嫌がるのは怠惰や時間不足のためだけではない、と著者はCosgroveを引いて述べます。暫定的だと自覚している決定を、公然と弁護する立場に置かれたくないからだ、と。組織構造が脅威として機能している場合、完全に弁護可能になるまで何も文書化されなくなります。
心理的安全性の話が1975年に出ていた、と読める箇所です。
第12章 鋭利な道具
「良い職人は道具でわかる」から始まる、開発環境の章です。
多くのプロジェクトが機械工場のように運営されている、と著者は指摘します。熟練工がそれぞれ自分の道具を持ち、鍵をかけて保管している状態です。プログラマも小さなエディタやダンプツールを個人のファイルに溜め込んでいる、と。
これが愚かである理由が2つ挙げられます。第一に、根本問題はコミュニケーションであり、個別化された道具はそれを阻害する。第二に、技術が変わったとき、個人の道具は陳腐化する。
そこで共通ツールを整備し、ツールメーカーの役割を明示的に置くべきだと主張されます。加えて、ターゲットマシン、シミュレータ、デバッグ環境、性能監視ツール、そして高水準言語の使用が推奨されます。
現在で言えば、内部開発者プラットフォーム（IDP）やプラットフォームエンジニアリングの議論に直結します。「各チームが勝手にツールを作る」状態のコストは、50年経っても変わっていません。
第13章 全体と部分
バグをどう減らし、どう見つけるかの章です。
議論の順序が明快でした。まずバグを設計しないこと。仕様を注意深く定義し、テスト可能な形にすること。次にコンポーネントデバッグ。最後にシステム統合。
システムデバッグについて、いくつか具体的な助言が並びます。
- デバッグ済みのコンポーネントのみを使う（各パーツが単体で動くまで統合しない）
- 十分な足場（scaffolding）を用意する。ダミーコンポーネント、テストドライバ、ロギングなど
- 一度に一つずつ変更する（複数を同時に変えると原因が特定できない）
- 変更を量子化する（変更を定期的にまとめ、その間はベースを固定する）
「一度に一つずつ変更する」は、そのままGitの小さいコミット、Feature Flagの単位、カナリアリリースの発想です。
第14章 大惨事の企て
スケジュール遅延を扱う章で、冒頭の一文が有名です。
プロジェクトが1年遅れるのはどうしてか。……1日ずつです
大きな災害は対処しやすい、と著者は言います。強力な力、抜本的な組織再編、新しいアプローチで対応でき、チーム全体が立ち向かうからです。厄介なのは日々の遅延で、認識しにくく、防ぎにくく、取り戻しにくい。竜巻ではなくシロアリだ、という表現がされています。
対策として提示されるのが、マイルストーンを鋭利に定義することです。「90%完了」のような曖昧な状態を許さず、達成したか否かが客観的に判定できる形にする。曖昧なマイルストーンは、遅延を隠す装置として機能してしまいます。
もう一つが「PERTチャート／クリティカルパス」の活用、そして下位から上位への報告における情報の歪みへの注意です。部下は「まだ挽回できる」と思って報告を遅らせます。マネージャは、報告を待つのではなく、レビューの場を設計しなければなりません。
第15章 もう一つの顔
ドキュメントの章です。
プログラムには2つの顔がある、と著者は言います。機械に対するメッセージという顔と、人間のユーザーに物語を伝えるという顔です。最もプライベートなプログラムでさえ、作者は記憶を失うので後者は不可欠だ、と。
文書化の指針として、必要な文書の種類が列挙されます。使用目的、実行環境、入力と出力、実行例、選択肢、実行時間、精度と検証方法。
そして自己文書化プログラム（self-documenting program）の概念が提示されます。ドキュメントをソースコードとは別に管理すると必ず乖離するので、ソースコード自体に文書を統合するという発想です。当時の具体例（アセンブラのコメント欄の使い方）はさすがに古いですが、思想としてはJavadocやKDoc、Doc Commentそのものです。
第16章 銀の弾丸はない ― ソフトウェア工学における本質と偶然
前述の通りです。1986年のIFIP会議での招待論文が原型で、本書で最も独立性が高く、単体で読める章です。
第17章 「銀の弾丸はない」の改良
第16章に寄せられた反論への応答です。
面白いのは、著者が「9/10論法」への批判に丁寧に答えている点です。また、オブジェクト指向への評価が更新されています。1986年時点では「不当に低い評価をした」と自ら認めつつ、オブジェクト指向は本質的困難の一部（複雑性の管理）には効くが、銀の弾丸ではないという立場は維持しています。
再利用（reuse）についての議論も充実しています。再利用が難しいのは技術ではなく、部品を探し、理解し、信頼するコストが高いからだ、という指摘です。ライブラリ数が増えるほど、その語彙を学ぶコストが増えます。これは現在のnpm/PyPIエコシステムの状況をかなり正確に予言していると感じました。
第18章 人月の神話の命題: 真実か嘘か?
記念版の中でも実用性が高い章です。
1975年版の主張を、著者が命題として抜き出して番号を振り、箇条書きにしています。目的は「読者の思考・評価・コメントを集中させる」ためで、命題の多くは操作的に検証可能な形になっています。
たとえば第2章からはこう抜き出されています。
- 2.6 原価計算を軸とした見積もり手法は労力と進捗を混同している。人月は誤った危険な神話である
- 2.11 ブルックスの法則: 遅れているソフトウェアプロジェクトに人材を追加すると、プロジェクトはさらに遅れる
- 2.12 人を追加すると、再分割の作業と混乱、新人の訓練、相互コミュニケーションの増加の3点で総労力が増える
この章だけで初版の要約になっており、通読前に目を通しておくと本文の理解が早くなります。時間がない人はここから読むのが効率的だと思いました。
第19章 20年後の神話的な人月
著者自身による20年越しの自己採点です。個人的には本書で一番おもしろい章でした。
維持された主張として、概念的整合性とアーキテクトの重要性が真っ先に挙げられます。むしろ著者は「小規模プロジェクトでも同様に有効だ」と適用範囲を広げています。アーキテクトは映画監督、マネージャはプロデューサーという比喩も提示されます。
撤回された主張が第11章の「1つは捨てる計画を立てよ」です。著者はこれを明確に誤りだったと認めています。理由は、この助言が暗黙にウォーターフォールモデルを前提にしているからです。「捨てる版」と「本番版」という2段階の発想自体が古い、と。
代わりに著者が支持するのがインクリメンタルな構築、漸進的成長です。動くスケルトンを最初に作り、機能を足していく。この方法なら、常に動くシステムがあり、チームの士気も保たれ、大きな捨て直しが不要になります。第16章で提案していた「有機的な成長」の延長線上にあります。
1975年から1995年の間に本当に新しくなったものとして、著者はマイクロコンピュータによるパワーの民主化、シュリンクラップ・ソフトウェア（パッケージソフト）市場の成立、オブジェクト指向、そして再利用の実用化を挙げています。
ここも率直で、**「人月の神話が生き残っている理由は、ソフトウェアの本ではなく、チームで人がものを作る本だからだ」**と著者自身が書いています。人類の歴史はドラマであり、筋書きは変わらず、脚本は文化とともにゆっくり変わり、舞台装置だけが常に変わる、と。
エピローグ
50年を振り返る短い文章です。1944年のハーバードMark Iの落成、Vannevar Bushの論文への驚きから始まり、この分野に関わってきたことへの感謝で締められます。技術書としてではなく、一人の技術者の回顧として読める部分でした。
現代の開発への読み替え
読みながら、現在の実務にどう対応するかをメモしていました。整理します。
| 本書の概念 | 現代の対応物 |
|---|---|
| 概念的整合性 | 設計原則の統一、API設計ガイドライン、デザインシステム |
| アーキテクチャと実装の分離 | API-first、スキーマ駆動開発、コントラクトの明示 |
| プロジェクトワークブック | ADR、内部Wiki、Design Doc文化 |
| 会議と裁判所 | アーキテクチャレビュー、RFCプロセス |
| コンウェイの法則 | チームトポロジー、逆コンウェイ戦略 |
| 外科チーム | テックリード＋支援ロールという構造化されたチーム編成 |
| 鋭利な道具 | 内部開発者プラットフォーム、プラットフォームエンジニアリング |
| 変更の量子化 | バージョニング、リリーストレイン、Feature Flag |
| 一度に一つずつ変更 | 小さいコミット、カナリアリリース、段階的ロールアウト |
| 捨てる計画（撤回後） | インクリメンタル開発、Walking Skeleton、MVP |
| 自己文書化 | Javadoc/KDoc、OpenAPI、型による仕様表現 |
| 本質的困難と偶有的困難 | 生成AI時代の生産性議論のフレーム |
最後の行は個人的に重要だと思っています。コード生成の支援ツールが取り除いているのは、主に偶有的困難です。定型コードを書く、APIの使い方を調べる、構文を思い出す──これらは表現に関わる作業です。
一方、何を作るべきかを決め、概念構造を設計し、それが正しいか検証するという本質的困難は残ります。第16章の枠組みは、ツールの効果を冷静に見積もるための道具として、今こそ使いどころだと感じました。
同時に、本質的困難の1つである「複雑性」に対して生成された大量のコードがどう作用するかは、本書だけでは答えが出ません。ここは読者が考えるべき部分だと思います。
読んでいて気になった点
良かった点ばかり書いてきたので、公平に留保も書いておきます。
具体例が古いのは避けられません。OS/360、Stretch、PL/I、パンチカード、メモリ賃料。技術的な細部をそのまま持ち帰ることはできません。抽象度を上げて読む作業が常に必要です。
エッセイ集ゆえの重複もあります。概念的整合性の話は第4章から第7章、第19章まで繰り返し出てきます。通読すると同じ主張を何度も読むことになります。
測定データの薄さは著者自身が認めています（命題2.9）。多くの主張は著者の経験と観察に基づくもので、統計的な裏付けを持つものではありません。Sackman らの10:1についても、著者自身が普遍性を疑っています。この本を「科学的知見」としてではなく「経験知の体系化」として読むのが妥当だと思います。
訳語の揺れにも注意が必要でした。本書の「アーキテクチャ」はユーザーから見える仕様を指し、現代の一般的な用法（内部構造の設計）とは異なります。ここを取り違えると議論が噛み合わなくなります。
こんな人におすすめ
- 複数人でのソフトウェア開発に関わっているすべてのエンジニア
- 設計判断の「なぜ」を言語化したい人
- テックリードやアーキテクトのロールに就いた／就こうとしている人
- 見積もりや工数の議論で消耗している人
- ソフトウェア工学の議論の出発点を知りたい人
逆に、具体的な実装テクニックを求めている人には向きません。コード例はほぼありません。
読み方の提案
分量はありますが、読む順序を工夫すると負担が減ります。
- 第18章（命題一覧）で全体像を把握する
- 第2章（人月神話）で中心的な議論を読む
- 第16章（銀の弾丸はない）を単体で読む
- 第4章〜第7章をまとめて読む（概念的整合性とその実現手段）
- 第19章で著者の自己採点を確認する
- 残りを興味のある順に
時間がない場合は 1 → 3 → 5 だけでも、本書の骨格は掴めると思います。
まとめ
読み終えて残ったのは、次の3点です。
1. 人を増やすことは、選択肢ではあっても解決策ではない
コミュニケーションコストが二次で増えるという構造は、リモートワークでもSlackでも変わりません。むしろ非同期コミュニケーションが増えた分、調整コストの見えにくさは増しているとも言えます。
2. 設計の一貫性は、放っておくと必ず失われる
概念的整合性は、意図的で、時に英雄的なマネジメント行為によってしか維持されない、と著者は書いています。誰が概念を統括するのかを明示しない限り、システムは必ず不統一に向かいます。マイクロサービス化やチーム分割を進めるときほど、この視点が要ると感じました。
3. 銀の弾丸はないが、道はある
魔法の解決策への期待を捨てることが、地道な進歩の出発点になる。この構えは、新しい技術が出るたびに揺さぶられる現在の状況において、むしろ実用的な態度だと思います。
50年前の本ですが、開発現場で起きている問題の多くは、既に1975年に記述されているという事実そのものが、本書を読む最大の理由かもしれません。
まだ読んでいない方には、一度通読することをおすすめします。
参考
- Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), Addison-Wesley, 1995
- 第16章の原型: "No Silver Bullet — Essence and Accident in Software Engineering", IFIP '86 会議録（1986）