ブルックスの法則とは何か?妊婦の例と対策を紹介

2020年3月10日

ブルックスの法則とは

ブルックスの法則とは、遅延しているソフトウェアプロジェクトに新規に要員を追加しても、想定通りには改善されず、むしろますますスケジュールを遅延させてしまうというものです。
このブルックスの法則はソフトウェアエンジニアリングの名著『人月の神話』の中で紹介されているアイデアであり、著者であるフレデリック・フィリップス・ブルックス・ジュニア(Frederick Phillips Brooks, Jr.)の名前から「ブルックスの法則」と呼ばれています。

今回の内容は動画でも解説しているので、ご覧いただければ幸いです。

ブルックスの法則によりプロジェクト遅延は容易に解消できない

「人月」という単位

ブルックスの法則は「人月」という単位の不確かさから始まっています。
「人月」というのは、建築業やソフトウェア開発などの仕事で使われる単位で、開発規模を表す単位として使用され、ひいてはプロジェクトの見積りに使われます。
例えば予約システムの開発をITシステムの開発業者に依頼すると、以下のような項目の見積書が送られてくるかもしれません。

  • 仕様策定(0.5人月):60万円
  • 開発(1人月):120万円
  • テスト (0.5人月):60万円

「開発」に1人月と記載されていますが、これはその項目の作業を担当する開発業者のスタッフが1ヶ月分対応するほどの規模・作業量であることを指しています。
より具体的には、開発を行うプログラマーがコーディングを1ヶ月(とはいえだいたい1ヶ月の営業日数の20日程度)続けて、ようやく完成する作業であるということを表しています。
多くの場合、開発業者は独自に人月に対する単価を決めています。上の例の業者であれば、1人月当たり120万円の料金を見積もっています。

3人月の仕事は3人で対応すれば1ヶ月で完了するのか?

ブルックスの法則のイメージ画像1

これまでは「人月」についての説明をしてきました。
ここで問題なのは、作業させる人を増やせば、その分作業は短縮できるのかということです。
例えば、3人月の仕事は3人で対応すれば1ヶ月で完了させられるのでしょうか。
「人月」というのは作業員1人が1カ月で対応する作業量を表しているので、3人月の作業であれば3人で対応すれば1ヶ月で完了するように思われます。

ブルックスの法則のイメージ画像2

しかし、多くの場合、3人月の作業を3人で対応しても1ヶ月で終わるということはなく、1.5ヶ月くらいで完了すればよいところ、最悪の場合は3ヶ月以上かかってしまうかもしれません。
これがブルックスの法則であり、ITプロジェクトで使われる「人月」という単位を信じて要員を追加したとしても、思ったような効果は挙げられず、むしろスケジュールに遅れをきたしてしまいます

要員の追加が遅延の解決にならない理由

10人の妊婦がいても1ヶ月で子供は生まれない

ブルックスの法則における妊婦の例

ここからは遅延しているプロジェクトに新規で要員を追加しても、遅延の解決にはならない理由を考えていきます。
要員の追加がスケジュール遅延の解決にならない1つ目の理由は、人月で表現されていても、必ずしも複数人で分担できる作業ではないことです。
この問題については、『人月の神話』内で著者が例として挙げている妊婦の例が有名です[1]フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、富澤昇 (訳)『人月の神話 【新装版】』、丸善出版社、2014年、14頁。
一般的に言われるように、妊婦は妊娠してから10月10日後に子供を出産するとしましょう。
つまり出産というのは、約10人月の一大プロジェクトです。
しかし、この出産をするために、2人の妊婦を集めたとしても、5ヶ月で子供を産むことはできません
できることは、2人で約10ヶ月後に2人の子供を産むことです。
このように、作業量を「人月」で表していたとしても、分担して作業できるようなものでなければ要員を追加しても意味はありません。

教育やコミュニケーションの時間の増加

ブルックスの法則における教育とコミュニケーションの時間

要員の追加がスケジュール遅延の解決にならない2つ目の理由は、人数が増えると教育やコミュニケーションの時間も増えることです。
例えば、とあるITプロジェクトで、もともとAさん1人が担当していたソフトウェア開発の進捗が悪く、完了予定日まで残り2ヶ月なのに、まだ8人月分の作業が残っていたとします。
この残り8人月の作業に3人の新規メンバーを追加し、4人体制で対応しようとするとします。
8人月の作業を4人で対応するので、計算上は2ヶ月で対応できそうです。
しかし、いざ4人体制でスタートしても、はじめはAさんから新規メンバーに対して状況説明をしたり、そのプロジェクトでのコーディングルールを共有したりと、新規メンバーの教育を行う時間が必要になります。
また、人数が増えたために、作業を割り振ったり、お互いの進捗を確認しあうコミュニケーションの時間も増加してしまいます。
その結果、開発以外の時間が増えてしまい、4人体制を敷いて2ヶ月で完了させる予定のものが、結局は3ヶ月も4ヶ月もかかってしまいます。

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

銀の弾(魔法のような解決策)はない

スケジュール遅延が発生し、要員を追加したらブルックスの法則が働き、ますますスケジュールは乱れていきます。
ではこの問題にどのように対処していけばよいのでしょうか。
ブルックスの法則が記されている『人月の神話』にはソフトウェア開発のプロジェクトで起こる様々な問題が論じられていますが、総じて結論としては狼人間から襲われる悪夢を終わらせる「銀の弾」のような 方法はないというものです。
今回のようなスケジュール遅延に対しては、あらかじめ作業の生産性やバグ発生率の数量化を行い、見積り基準を開発し、それを公にして共有していき予防をしていったり[2]前掲『人月の神話』、19頁。、スケジュールの見直しが必要になったら、作り直したスケジュールはたっぷり時間をとって慎重に、そして完全に作業を終わらせられるようにすることとしています [3]前掲『人月の神話』、20頁。

遅れたスケジュールにのみブルックスの法則は有効?

ブルックスの法則の対策ではありませんが、ブルックスの法則はスケジュール遅延が発生しているプロジェクトに要員が追加された時に発生するため、実際に作業が始まる前に要員が追加される場合は、状況が変わるかもしれません
例えばプログラマーが実際に開発に着手した後で要員を追加しても、スケジュールは思ったように早まらないですが、仕様設計などの前段階で要員の不足が発見され、増員した体制がしっかりと敷かれた後で開発が始まれば、人数の増加のメリットを享受することができそうです。
また、教育コストのかからないような腕の立つ要員を用意するということでも、ある程度は解消されるかもしれません。
とはいえ、いずれにしても付け焼き刃の対応ではあるため、『人月の神話』で論じられているように、あらかじめ生産性やバグ発生率を正確に把握し、無理のないスケジュールをたてていくことに越したことはないでしょう。

ブルックスの法則の言い換え

ワインバーグによるブルックスの法則の言い換え

ここまではブルックスの法則の内容を見てきました。
ここからはブルックスと同じくソフトウェアエンジニアリングに多大な影響を及ぼしたジェラルド・ワインバーグの著書『ワインバーグのシステム思考法』で紹介されている「ブルックスの法則の言い換え」を紹介していきます。
ブルックスの法則の言い換えとは、「他のすべての原因よりもカレンダー時間の切迫が、ソフトウェアプロジェクトにその失敗の現実を直視させる」というものです[4]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、328頁。
これはどういうことかというと、スケジュールの切迫自体がプロジェクトの失敗の原因ではなく、他の要因によってスケジュール遅延が発生していることこそが問題なのですが、プロジェクトの失敗という現実をプロジェクト・チームにつきつけるのはスケジュールだということです。

言い換えたブルックスの法則の言い換え

つまり、言い換えたブルックスの法則はさらにこのように言い換えることができます。

他のすべての原因よりもカレンダー時間の切迫が、彼らのモデルの誤りを直視させる[5]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、328頁。

繰り返しになってしまいますが、スケジュールの遅延というのはあくまで結果であって、プロジェクトが失敗した原因ではありません。
しかし、スケジュールの切迫以上にプロジェクトのメンバーに「プロジェクトが失敗した」という現実をつきつけるものはなく、反省を促すものもないでしょう。

参考

Webサイト

書籍

  • フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、富澤昇 (訳)『人月の神話 【新装版】』、丸善出版社、2014年。
  • G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年。

1フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、富澤昇 (訳)『人月の神話 【新装版】』、丸善出版社、2014年、14頁。
2前掲『人月の神話』、19頁。
3前掲『人月の神話』、20頁。
4,5G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、328頁。