プロジェクトが予定より遅れている。納期を守るため、急いで人を追加する。ところが、教える人と確認する人が増えて、かえって仕事が進まなくなる。こうした状況を考える手掛かりがブルックスの法則（Brooks’s Law）です。
ただしこれは「人を増やすと必ず失敗する」という自然法則ではありません。増員によって救える仕事もあれば、作業を分けられず逆効果になる仕事もあります。何が違うのかを『人月の神話』の議論と、現代のプロジェクト運営から読み解きます。
ブルックスの法則とは
計算機科学者フレデリック・P・ブルックス・ジュニア（Frederick P. Brooks Jr.）は、1975年の著書『The Mythical Man-Month（人月の神話）』で、遅延しているソフトウェア開発へ人員を追加すると、かえって完了が遅くなることがあると論じました。
この警句の対象は、すでに遅れが生じたソフトウェア開発です。マーケティングの人数、すべての事務作業、すべての会社に機械的に当てはめてよいわけではありません。大切なのは、なぜそうなるのかという条件を分解することです。
原典は『人月の神話』――人数と期間を単純交換できない
ブルックスはIBMのSystem/360およびOS/360開発に携わった経験をもとに、ソフトウェア開発に固有の計画・設計・連携の難しさを書きました。出版社Pearsonの書誌によれば、初版は1975年、改訂を含む20周年記念版は1995年に刊行され、同版には元の議論を振り返る章も収録されています。
「人月」は、一人が一か月働く量を表す工数の単位です。しかし、二人で二か月かかる作業を四人なら一か月で終えられる、と単純には言えません。単純な並列作業なら近づく場合はありますが、設計の合意、実装の統合、承認、テストなどには人数を増やしても短縮しにくい時間が存在します。
原著の主題は、単なる人数の多寡ではなく、分業の限界と設計の一貫性です。2026年の技術者Martin Fowlerによる回顧も、この点と概念的な一貫性（conceptual integrity）の重要性を指摘しています。
遅れが悪化する理由は三つある
- 教育・立ち上がり：新メンバーは目的、設計、仕様、ツール、判断基準を理解する必要があります。その支援に既存メンバーの時間を使うため、追加直後の純増戦力は人数ほど大きくありません。
- 相互連携・統合：複数の担当が同じ仕様やコードを扱うほど、変更の衝突や相談が増えます。理論上の二者間の組合せは人数nに対してn(n−1)/2ですが、実務上すべての組合せで通信するわけではありません。これはあくまで調整の複雑さを考える目安です。
- 順番を変えられない工程：要件確定、重要な設計判断、外部審査、公開前テストなどは、担当者を増やしただけでは並列化できません。
例えば、同じ資料を三人が別々に改善しても、統合方針が未確定なら、最後の確認作業はむしろ増えます。人手不足ではなく、決めるべきことが未決定なのかもしれません。
増員が有効になる条件もある
一方、ブルックスの法則を「途中の増員は絶対にするな」と読むのは誤りです。仕事を独立した単位へ切り分けられ、成果物の受け渡し方法が明確で、必要な教育時間が小さければ、増員は有効になり得ます。
- 分割可能性：追加メンバーが独立して進められる作業は何か。既存作業との依存関係はいくつあるか。
- 教育コスト：誰が何日程度を使って支援するのか。期限までにその投資を回収できるか。
- 統合責任：成果物を誰が受け取り、判断し、最終品質を担保するのか。
- ボトルネック：詰まっている場所は本当に実作業の処理能力なのか。それとも承認や情報待ちなのか。
増員後に完了までの期間が延びるとは限りません。しかも長期的な運用能力を高める採用と、差し迫った納期を短縮する増員は、別々の意思決定です。
BtoBマーケティングでは「施策担当」より前提の共有を点検する
記事制作、広告、展示会、MA、営業連携の担当者を増やしても、ターゲット企業、提供価値、MQL・SQLの定義、顧客へ届けるメッセージが食い違っていたら、活動量だけが増えます。これはブルックスの法則をBtoB業務へ応用した編集上の仮説であり、同書がマーケティング施策の効果を実証したという意味ではありません。
例として、架空のBtoB SaaS企業が四人で月十本のコンテンツを出しているとします。二人を追加する前に、記事の企画承認に毎回一週間かかるなら、最初に解決すべきは企画承認の遅さです。判断基準を明文化し、レビューの窓口を絞れば、増員せずに進捗が改善する可能性があります。
市場・顧客・営業・KPIの関係をまとめて確認するにはBtoBのGTM戦略も役立ちます。
AIエージェントも数より受け渡しの設計
調査AI、執筆AI、校正AI、公開AIを増やせば必ず作業が速くなるわけではありません。それぞれの前提が違えば、矛盾の検出と統合に人手が必要です。並行実行によってWordPressで古い本文を上書きするなど、品質やデータの事故が起こり得ます。
AIの分業を進めるときは、入力の正本、最終判断者、状態の確認方法、更新競合時の停止条件を先に定義します。これは原著をAIへそのまま当てはめた「新しい法則」ではなく、分業コストの構造に注目した実務上の応用です。
増員判断に使う、四つの質問
- 現在の遅延は、作業量・判断待ち・品質不足・仕様変更のどれから生じたか。
- 追加する人が、他の作業を止めずに進められる独立した仕事は何か。
- 教育・連携・統合作業は誰が担い、その時間をどこから捻出するか。
- 短期納期の改善が目的か、長期的な組織能力の増強が目的か。
これらに答えられない状態では、増員の費用対効果を判断できません。「人数を増やすべきか」より先に、仕事の構造を見えるようにする方が、手戻りを減らせる場合があります。
まとめ――人を足す前に、何が進捗を止めているかを確認する
ブルックスの法則は、複雑なソフトウェア開発で人数と納期を単純交換できないことへの警告です。しかし、人が増えること自体を否定する教えではありません。
必要な作業が独立していれば増員は力になります。意思決定、設計、受け渡しが詰まっているなら、その詰まりを解く方が先かもしれません。組織や仕事の仕組みを見直す関連概念として、コブラ効果も合わせて考えられます。
参考資料と確認範囲
- Pearson / Addison-Wesley, The Mythical Man-Month 20周年記念版：初版・新版の刊行情報、収録章・原著の対象を確認。書籍全頁を通読したという意味ではありません。
- Martin Fowler, Mythical Man Month (2026)：原著を読み直した現代の技術者による解説。原著とは区別する二次資料。
- Google Books『The Mythical Man-Month』書誌：出版・内容紹介の照合。