ブルックスの法則とは？意味・なぜ増員で遅れるのか・対策を解説

ブルックスの法則とは、遅れているソフトウェア開発に人を増やすと、かえって完了が遠のくことがある、という経験則です。新しく加わる人が戦力になるまで時間がかかり、説明やすり合わせも増えるためです。

• 要点：遅れた案件への増員は、教育とすり合わせの負担で逆効果になりやすい
• 当てはまりやすい場面：終盤で、担当どうしのつながりが強く、レビュー待ちも詰まっているとき
• 増員前に見る点：作業量の不足なのか、仕様の未決や調整の詰まりなのかを先に切り分ける

以下では、ブルックスの法則の意味、背景、起きやすい場面、現場で取りやすい対策の順に整理します。

ブルックスの法則とは

ブルックスの法則とは、遅れているソフトウェア開発に人を足すと、かえって完了が遅れることがあるという経験則です。この考え方は、Fred Brooks（フレデリック・P・ブルックス）が著書『The Mythical Man-Month』で示したものとして広く知られています。

ブルックスの法則の定義

ブルックスの法則は、次のように表されます。

遅れているソフトウェアプロジェクトに人員を追加すると、プロジェクトの完了がさらに遅れる。

この法則が示しているのは、人数を増やしても、そのぶん進みが速くなるとは限らないということです。新しく入る人への説明や、チーム内のすり合わせが増えるため、全体の速度が一時的に落ちることがあります。

大事なのは、ブルックスの法則が「人を増やすな」と言っているわけではない点です。遅れた場面で人を足すときは、教育や調整の負担まで見込まないと、かえって遅れが広がりやすい、という注意として読む必要があります。

ブルックスの法則が生まれた背景

この考え方の土台には、ブルックスが IBM の OS/360 開発で得た経験があります。予定から遅れた案件に人を足しても、すぐには立て直せず、むしろ完了が遠のく場面があったためです。

ブルックスは、この現象の主な要因として、たとえば次の点を挙げています。

1. 新しく加わる人が仕事を覚えるまで時間がかかる
2. 連絡とすり合わせが増える
3. 作業の切り分けと組み合わせが難しくなる
4. 今いるメンバーの手が教育に取られる

ソフトウェア開発は、単に仕事量を人数で割れば終わるものではありません。仕様の前提、コードの癖、テストの進め方など、文書だけでは伝わりにくい知識が多く、これを共有する時間がどうしても必要になります。

ブルックスの法則が示す問題

ブルックスの法則が示しているのは、次のような点です。

1. 増員がそのまま解決策になるとは限らない
2. 見積りと計画の甘さが遅れとして表に出やすい
3. 連絡のしかたが悪いと、遅れが広がりやすい
4. 作業の分け方が甘いと、あとで直す量が増えやすい

こうした点を先に見ておくと、遅れた場面での判断を誤りにくくなります。

どこまで当てはまるか

ブルックスの法則がもともと想定しているのは、ソフトウェア開発のように作業の切り分けと共有が難しい仕事です。他分野でも似た現象が起きることはありますが、それは「調整の負担が大きい場面では同じような遅れが起きやすい」という意味で捉える必要があります。以下は、その例です。

ただし、分野が違えば事情も違います。建設や製造のように役割を分けやすい仕事では、人を増やすことがそのまま効く場面もあります。逆に、設計の見直しや工程どうしの待ち時間が大きい場面では、ソフトウェア開発と似た形で遅れが広がりやすくなります。

ブルックスの法則が示す開発の課題

ブルックスの法則が示しているのは、「人を足したのに、なぜ進みが速くならないのか」という現場の難しさです。ここでは、起きやすい問題を順に整理します。

連絡コストが増える

新しいメンバーが加わると、チーム内の連絡はそれだけ増えます。情報を渡す時間、認識をそろえる時間、相談に答える時間が増えるため、もともと作業していた人の手が止まりやすくなります。

具体的には、次のような「見えにくい仕事」が増えます。

• 仕様の前提を説明する時間
• 誰がどこまで受け持つかを引き直す時間
• レビュー待ちが増えることによる停滞
• 相談が増え、集中しにくくなること

連絡そのものは必要ですが、遅れた場面では、その負担を吸収する余裕が小さくなっています。そのため、進みの鈍さが表に出やすくなります。

新しく入る人の立ち上がりに時間がかかる

新しく入る人が案件の背景や仕組みを理解するまでには時間がかかります。その間は、教える側の時間も必要です。新しく入る人がまだ十分に動けず、今いる人の手も教育で削られるため、しばらくは全体の速度が落ちやすくなります。

立ち上がりに時間がかかるのは、文書が足りないからだけではありません。なぜその設計にしたのか、どこで不具合が出やすいのか、運用では何を守るのか、といった知識は、紙だけでは伝わりにくいからです。

作業の切り分けが難しくなる

人数が増えるほど、役割の分け方と、あとでつなぎ直す手間は重くなります。新しく入る人の役目を決め、今ある作業とのつながりを保つ必要があるためです。

とくにソフトウェア開発では、並行で進められそうに見えても、実際には前後のつながりが強いことが少なくありません。仕様がまだ固まっていない段階で人を増やすと、あとで仕様が変わったときの直しが広がりやすくなります。

終盤ほど遅れが広がりやすい

人を増やしたときの負担は、案件の終盤ほど重くなりがちです。終盤は、新しく作ることより、つなぎ合わせること、テストすること、壊れていないか確かめることが中心になるからです。

この段階で人を増やすと、変更点が増え、テストする範囲も広がり、レビューと確認が詰まりやすくなります。その結果、遅れを縮めるつもりの増員が、かえって遅れを広げることがあります。

ブルックスの法則が当てはまりやすい条件

ブルックスの法則は万能ではありませんが、次の条件が重なると起きやすくなります。

• 仕様が変わることが多く、口頭で共有している前提も多い
• 担当どうしのつながりが強く、きれいに分けにくい
• レビューや承認がすでに詰まっている
• 終盤で、結合テストやリリース準備に入っている
• 追加で入る人が、その分野や業務にまだ慣れていない

逆に言えば、作業を切り出しやすく、教える時間も短く、別の詰まりが主因なら、増員が効く余地はあります。次章では、その見方と対策を整理します。

ブルックスの法則への対策

ブルックスの法則が示す問題を抑えるには、増員するかどうかだけでなく、遅れの原因をどう見るかが重要です。ここでは、現場で取りやすい対策を順に整理します。

まず遅れの原因を分けて見る

人を足す前に、まず遅れた理由を分けて見る必要があります。初期の見積りが甘かったのか、仕様がまだ決まっていないのか、テストやレビューが詰まっているのかで、打ち手が変わるからです。

たとえば、次のように整理します。

• 見積りが甘く、作業量が想定より多かった
• 仕様がまだ決まっておらず、手戻りが出ている
• 不具合が多く、直しの作業が増えている
• レビュー待ちや環境待ちが詰まっている
• 割り込みやあとからの要望が多く、手が散っている

原因がレビュー待ちなら、人を増やしても解決しません。仕様が固まっていないなら、増員は直しを増やすだけになりやすいです。まず原因を見分けることが先です。

作業を切り分け、責任を明らかにする

案件を進めやすくするには、作業を分け、その範囲ごとの責任をはっきりさせることが有効です。人を増やす場合も、どこまでを任せるのかが曖昧だと、連絡の回数だけが増えます。

ここでいうモジュール化は、ファイルを分けることではありません。直しが出たときに、影響が広がる範囲を小さくする考え方です。たとえば、次のような進め方が役に立ちます。

• 役割ごとに境界を引く
• API や入出力の約束を早めに固める
• 部品ごとに責任者を決める
• 誰が決めるかを先に決める

こうしておくと、新しく入る人も、自分が受け持つ範囲に集中しやすくなります。

連絡を増やすより往復を減らす

遅れた場面で会議や報告を増やしすぎると、かえって手が止まります。必要なのは、連絡の量を増やすことではなく、迷いと行き違いを減らすことです。

たとえば、次のように整えます。

• 仕様、決まったこと、まだ決まっていない点を一か所に集める
• レビューの窓口と、見る基準をそろえる
• 質問の書き方を決め、往復を減らす
• 短い定例で詰まりだけを見つけ、全員での会議で長引かせない

後ろの工程を軽くする

遅れた場面では、後ろの工程を軽くする改善も効きます。あとで確かめる手間を下げられれば、手戻りを減らしやすくなるからです。

たとえば、次のような取り組みが考えられます。

• 自動テストを増やし、確認の手間を下げる
• ビルドとデプロイを自動化し、環境待ちを減らす
• リリース手順をそろえ、属人化を減らす
• 同じ不具合を出す手順やログの見方をそろえる

こうした改善は、その場では手間に見えても、あとで直す量を減らしやすく、結果として遅れの圧縮につながります。

増員するなら入れ方を設計する

遅れた案件でも、増員が必要になることはあります。その場合は、ただ人数を足すのではなく、どう入るかを先に決める必要があります。

• 任せる範囲を、ほかと強くぶつからない単位で切り出す
• 初週に何を理解し、何を出すかを決める
• 教える役を一人に寄せる
• レビューできる人の数を増やす
• 完了の条件を文書でそろえる

終盤に人を入れるなら、新しい機能を広く任せるより、テストの追加、ログの整え、文書の整え、リリース準備のように、切り出しやすい仕事へ寄せるほうが失敗しにくくなります。

ブルックスの法則から学ぶ教訓

人月で単純に割れない

ブルックスの法則が示しているのは、人数を足せば、そのぶん納期を短くできるとは限らないということです。この考え方は『The Mythical Man-Month』の中心にある主張として知られています。

人月の神話とは、人数と月数の掛け算で期間を素直に見積もれるという見方です。しかし、ソフトウェア開発では、順番にしか進められない仕事や、つなぎ合わせにかかる手間があるため、単純な割り算は通用しません。

難しさは作業量だけではない

ソフトウェア開発の難しさは、仕事量の多さだけではありません。設計の意図をそろえること、前提を共有すること、でき上がったものをつなぐことにも、かなりの時間がかかります。

そのため、新しいメンバーが入ると、いま進んでいる作業の説明や、認識合わせの時間も必要になります。案件を率いる立場の人は、この負担を見込んだうえで人の入れ方を考える必要があります。

進め方の管理が結果を左右する

ブルックスの法則は、管理のしかたが結果を大きく左右することも示しています。全体像を見て、優先する順や前後のつながりを整理し、人の配置を決めることが欠かせません。

情報をどこに集めるか、誰が判断するか、レビューをどう流すかが曖昧だと、遅れた場面で詰まりが増えやすくなります。増員そのものより、進め方の整え方が問われます。

同じ遅れを繰り返さない

対策は一度で終わりません。見積りの振り返り、要件の詰め方、レビューの基準、テストの進め方、リリース手順など、遅れの原因になった点を次の案件に持ち越さないことが大切です。

ブルックスの法則の教訓は、増員そのものを否定することではありません。人を足す前に何が詰まっているかを見きわめ、必要なら入れ方まで設計することが重要だ、という点にあります。

まとめ

ブルックスの法則は、遅れているソフトウェア開発に人を増やしても、教育の手間や、連絡と調整の増加によって、かえって完了が遠のくことがあるという教訓です。遅れた場面では、まず原因を切り分け、どこが詰まっているのかを見きわめる必要があります。

増員が必要な場合でも、任せる範囲を切り出し、立ち上がりの計画とレビュー体制を整えなければ効果は出にくくなります。ブルックスの法則は「増員は悪い」と言うためのものではなく、増員が効く条件と、効きにくい条件を見分けるための考え方です。