ブルックスの法則とは何か——「人を増やせば早くなる」という幻想を打ち破る50年前の真実

「人を増やせば早くなる」は本当か

プロジェクトの納期が近づいてきた。テストでバグが続出し、リリースまでに終わりそうにない。そんなとき、マネージャーや上司からこう言われた経験はないでしょうか。「じゃあ、人を増やそう」と。

直感的には正しそうに聞こえます。人が増えれば作業が分担でき、スピードが上がる。工場のラインなら確かにそうかもしれません。しかしソフトウェア開発においては、この判断が逆効果になることが多いのです。これを約50年前に喝破したのが、フレデリック・ブルックスが1975年に著した名著『人月の神話』であり、そこから導かれる「ブルックスの法則」です。

フレデリック・ブルックスとは何者か

ブルックスの法則を理解する前に、その提唱者について少し触れておきます。フレデリック・P・ブルックスは、IBMで世界初のメインフレーム向け商用オペレーティングシステムである「IBM OS/360」の開発プロジェクトマネージャーを務めたコンピュータ科学者です。このプロジェクトは、当時最大規模のソフトウェア開発のひとつであり、ブルックスはそこで多くの失敗と教訓を経験しました。

その経験をもとに執筆した『人月の神話』（原題：The Mythical Man-Month）は、ソフトウェア工学の古典として今なお読み継がれています。出版から50年近くが経った今でも「現場の真実を語っている」と感じるエンジニアが後を絶たないのは、ソフトウェア開発の本質的な難しさが変わっていないからです。

ブルックスの法則とは何か

ブルックスの法則は、一文で表すとこうなります。

「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」

「人を増やせばスケジュールが縮まる」という考え方を根底から否定するこの言葉は、初めて聞いたとき多くの人が「本当に？」と思うはずです。しかし現場経験を積むにつれ、「そうだ、これは本当のことだ」と確信に変わっていく。それがこの法則の奥深さです。

なぜ人員追加がかえって遅延を招くのか

ブルックスは、この法則が成り立つ主な理由として次の3つを挙げています。

理由1：新メンバーの立ち上がりコスト

プロジェクトに新しく参加したメンバーは、すぐに戦力になれるわけではありません。まずコードベースの構造を把握し、設計の意図を理解し、チームのルールや慣習を覚え、開発環境を整える必要があります。これらが揃って初めて、実際の作業に取り掛かれます。

この立ち上がり期間（オンボーディング）は、プロジェクトの規模や複雑さによっては数週間から数ヶ月に及ぶことがあります。しかも、その間は既存メンバーが教育や質問対応に時間を取られるため、チーム全体の生産性が一時的に低下します。

理由2：コミュニケーションコストの爆発的増加

これがブルックスの法則の核心です。チームの人数が増えると、メンバー同士のコミュニケーション経路の数が急激に増加します。数式で表すと、n人のチームで必要なコミュニケーション経路の数は n × (n-1) ÷ 2 本になります。

以下の表で具体的な数字を見てみましょう。

3人のチームが5人になると、コミュニケーション経路は3本から10本へと3倍以上に増えます。さらに8人になると28本と、5人のときの約3倍です。人数の増加に対してコミュニケーションコストはほぼ2乗のオーダーで増加していくため、一定の規模を超えると「話し合い・調整・情報共有」だけで膨大な時間が消費されるようになります。

理由3：作業の分割不可能性

ソフトウェア開発の多くのタスクは、単純に人数で割り算できるものではありません。たとえば、複雑な認証機能の設計は、10人がかりにしてもひとりが考える場合の10分の1の時間では終わりません。むしろ、10人が一斉に関わると議論が錯綜して、余計に時間がかかることすらあります。

ブルックスはこれを「9人の母親がいても、赤ちゃんは1ヶ月では生まれない」という印象的な比喩で表現しました。本質的に順序が決まっていたり、緊密な連携が求められたりするタスクは、人員を増やしても並列化できないのです。

「人月」という誤った単位

ブルックスが『人月の神話』で強調したもうひとつの重要な概念が、「人月（man-month）」という見積もり単位の欺瞞です。

「この仕事は6人月かかる」というとき、多くのマネージャーは「6人いれば1ヶ月で終わる」と解釈しがちです。しかしこの計算が成り立つのは、作業が完全に分割可能で、メンバー間のコミュニケーションが一切不要な場合だけです。現実のソフトウェア開発でそんな状況はほとんどありません。

人月という単位は、人数と時間を掛け算すれば同じ成果が得られるという前提を暗黙に含んでいます。しかしブルックスは、この前提が虚偽であることを実体験から指摘しました。ソフトウェア開発において「人×月＝成果」の等式は成り立たない、というのが『人月の神話』の根本的なメッセージです。

現場での「あるある」シナリオ

ここで、エンジニアなら身に覚えがあるかもしれないシナリオを整理してみます。

このサイクルに入ると、増員するたびに状況が悪化するという悪循環に陥ります。「火に油を注ぐ」とブルックスが表現したとおりです。

ではどうすればよいのか——現場で使える対策

ブルックスの法則は「人を絶対に増やすな」という主張ではありません。「遅れているプロジェクトへの安易な人員追加は逆効果になりやすい」という警告であり、正しく対処するための知見として活かすことが重要です。

対策1：スコープを削る

最も効果的かつ正直な手段は、やることを減らすことです。「リリース時点でこの機能は本当に必要か」を再検討し、優先度の低い要件をバックログに積み直す。スケジュールを守るために品質を下げるよりも、機能を絞って品質を維持する方が、長期的には正しい判断になることが多いです。

対策2：増員するなら早期に、かつ担当範囲を切り出して

どうしても人員を追加するなら、できるだけ早い段階で行うことが重要です。プロジェクトの終盤では学習コストの回収が間に合わないからです。また、新しいメンバーには既存の複雑な部分に触れさせず、新規機能や独立したモジュールなど、他への影響が少ない担当範囲を割り当てることが有効です。

対策3：モジュール化とドキュメント整備

コードが適切にモジュール化され、設計思想がドキュメントとして整備されていると、新メンバーの立ち上がり時間が大幅に短縮されます。「後から人を入れる可能性がある」と最初から想定した設計・記録の習慣が、いざというときのリスクを下げます。

対策4：コミュニケーションの「量」ではなく「質」を上げる

チームが大きくなった場合は、会議や連絡を増やすのではなく、仕様・決定事項・未解決事項を一箇所に集約し、誰でも参照できる状態を作ることが重要です。情報の非対称性をなくすことで、不必要な往復コミュニケーションを減らせます。

対策5：根本原因を特定してから手を打つ

「遅延の原因は何か」を正確に診断することが先決です。要件の変更なのか、技術的な難易度の過小評価なのか、それとも特定のボトルネックなのか。原因によって打ち手は全く変わります。人員追加が有効なケースもあるため、ブルックスの法則を「増員禁止のルール」として機械的に適用するのは誤りです。

ブルックスの法則は今も有効か

1975年に提唱されたこの法則は、アジャイルやスクラムが普及した現代でも本質的に有効です。スクラムがチームサイズを「5〜9人」という小規模に固定し、スプリントを短く区切ることでフィードバックサイクルを高速化するのは、コミュニケーションコストの爆発を防ぐというブルックスの教えと根を同じくしています。

ただし、現代の開発環境では当時より条件が変わっている部分もあります。Gitによるコード管理、Confluenceなどのドキュメントツール、SlackやNotionによる非同期コミュニケーションは、オンボーディングや情報共有のコストをある程度低減しています。AIコーディングツールの普及により、コードの読解速度も上がっています。

それでも、「人を増やしたらコミュニケーションコストが爆発的に増える」という構造的な問題は変わっていません。ツールが良くなっても、人間が情報を処理し、合意形成し、連携して動く構造が変わらない限り、ブルックスの法則は形を変えながら現場に現れ続けるでしょう。

まとめ——「人月」の幻想から抜け出す思考を

ブルックスの法則を一言で整理すると、「ソフトウェア開発は人を増やせば早くなるという線形な世界では動いていない」ということです。

この法則を知っているだけでも、現場での判断は変わります。遅延が発生したとき、「まず原因を診断する」「安易に人を入れない」「スコープを見直す」という思考の流れを自然に持てるようになります。エンジニアとして、そしていずれプロジェクトをリードする立場になったとき、50年前にブルックスが見抜いた本質を自分の経験と重ねながら活かしてください。