こんにちは、阿久梨絵です！
今回は開発現場でよく聞く悩み、
「納期がヤバい、じゃあ人を増やそう」という選択に本当に意味があるのか？
——そんな疑問に答えてくれる ブルックスの法則 をご紹介します。
ブルックスの法則とは？
「遅れているソフトウェアプロジェクトに人を追加しても、完成は早まらず、むしろさらに遅れる」
この法則は、1975年に出版されたフレデリック・ブル Brooks の著書『人月の神話（The Mythical Man-Month）』の中で提唱されました。
当時も今も、プロジェクトの遅れに対して“人員追加”という解決策が安易に選ばれがち。
しかし、ブルックス氏はそれが逆効果になる理由を、こう指摘しています。
なぜ人を増やすと遅れるのか？
1. オンボーディングコスト
新しく加わった人に対して、既存メンバーが状況説明・教育を行う時間が必要になります。
その結果、既存の作業がさらに遅延します。
2. コミュニケーション負荷の増加
関わる人が増えることで、情報共有や意思決定にかかる時間が指数関数的に増えます。
たとえば2人→3人で必要なコミュニケーションのラインは3本→6本と倍増。
3. 作業の分割が難しい
ソフトウェア開発のような複雑なタスクは、簡単に分割・並列化できるとは限りません。
分けられない作業に無理に人を当てても、かえって混乱の元になります。
活用法：「足す」よりも「整理する」
遅延対策は「人を増やす」より「今あるタスクを見直す」ことが重要です。
優先順位の再整理
「すべてを完璧に」よりも、「最も重要なことを確実に」進める。
スコープの見直し（スコープクリープの防止）
初期の要件に立ち返り、本当に必要な機能に集中。
ボトルネックの明確化
遅れの原因が「人手不足」ではなく、「意思決定の遅延」「仕様のあいまいさ」であることも多々あります。
コミュニケーション設計の最適化
会議頻度、ドキュメント形式、レビュー体制の見直しが、スムーズな進行を助けます。
応用：現代開発でも通用する考え方
ブルックスの法則は40年以上前に提唱された理論ですが、アジャイル開発・リモートワーク・グローバルチームといった現代の開発体制においても、強い示唆を持っています。
・スクラムやカンバンなど、スモールチーム×タスクの見える化を前提とした手法
・少人数でも自律的に動けるチーム設計の重視
・ドキュメント・ナレッジ共有の仕組み（Notion、GitHub Projectsなど）の整備
これらの潮流も、ブルックスの法則と親和性が高いのです。
まとめ
「人を増やせば、なんとかなる」——その発想が危ういことを、ブルックスの法則は明快に教えてくれます。
真の対策は、いまあるリソースの中で何が最も効果的かを見極める視点にあります。
プロジェクトが遅れたときこそ、“数”よりも“仕組み”に目を向けることが、実は最短ルートなのです。
阿久梨絵でした！
