ブルックスの法則とは何か？妊婦の例と対策を紹介
ブルックスの法則とは
ブルックスの法則とは、遅延しているソフトウェアプロジェクトに新規に要員を追加しても、想定通りには改善されず、むしろますますスケジュールを遅延させてしまうというものです。
このブルックスの法則はソフトウェアエンジニアリングの名著『人月の神話』の中で紹介されているアイデアであり、著者であるフレデリック・フィリップス・ブルックス・ジュニア（Frederick Phillips Brooks, Jr.）の名前から「ブルックスの法則」と呼ばれています。
ブルックスの法則によりプロジェクト遅延は容易に解消できない
「人月」という単位
ブルックスの法則は「人月」という単位の不確かさから始まっています。
「人月」というのは、建築業やソフトウェア開発などの仕事で使われる単位で、開発規模を表す単位として使用され、ひいてはプロジェクトの見積りに使われます。
たとえば予約システムの開発をITシステムの開発業者に依頼すると、以下のような項目の見積書が送られてくるかもしれません。
- 仕様策定（0.5人月）：60万円
- 開発（１人月）：120万円
- テスト （0.5人月）：60万円
「開発」に１人月と記載されていますが、これはその項目の作業を担当する開発業者のスタッフが１ヶ月分対応するほどの規模・作業量であることを指しています。
より具体的には、開発を行うプログラマーがコーディングを１ヶ月（とはいえだいたい１ヶ月の営業日数の20日程度）続けて、ようやく完成する作業であるということを表しています。
多くの場合、開発業者は独自に人月に対する単価を決めています。上の例の業者であれば、１人月当たり120万円の料金を見積もっています。
３人月の仕事は３人で対応すれば１ヶ月で完了するのか？
これまでは「人月」についての説明をしてきました。
ここで問題なのは、作業させる人を増やせば、その分作業は短縮できるのかということです。
たとえば、３人月の仕事は３人で対応すれば１ヶ月で完了させられるのでしょうか。
「人月」というのは作業員１人が１ヶ月で対応する作業量を表しているので、３人月の作業であれば３人で対応すれば１ヶ月で完了するように思われます。
しかし、多くの場合、３人月の作業を３人で対応しても１ヶ月で終わるということはなく、1.5ヶ月くらいで完了すればよいところ、最悪の場合は３ヶ月以上かかってしまうかもしれません。
これがブルックスの法則であり、ITプロジェクトで使われる「人月」という単位を信じて要員を追加したとしても、思ったような効果は挙げられず、むしろスケジュールに遅れをきたしてしまいます。
要員の追加が遅延の解決にならない理由
10人の妊婦がいても１ヶ月で子供は生まれない
ここからは遅延しているプロジェクトに新規で要員を追加しても、遅延の解決にはならない理由を考えていきます。
要員の追加がスケジュール遅延の解決にならない１つ目の理由は、人月で表現されていても、必ずしも複数人で分担できる作業ではないことです。
この問題については、『人月の神話』内で著者が例として挙げている妊婦の例が有名です[1]フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、富澤昇 (訳)『人月の神話 【新装版】』、丸善出版社、2014年、14頁。。
一般的に言われるように、妊婦は妊娠してから10月10日後に子供を出産するとしましょう。
つまり出産というのは、約10人月の一大プロジェクトです。
しかし、この出産をするために、２人の妊婦を集めたとしても、５ヶ月で子供を産むことはできません。
できることは、２人で約10ヶ月後に２人の子供を産むことです。
このように、作業量を「人月」で表していたとしても、分担して作業できるようなものでなければ要員を追加しても意味はありません。
教育やコミュニケーションの時間の増加
要員の追加がスケジュール遅延の解決にならない２つ目の理由は、人数が増えると教育やコミュニケーションの時間も増えることです。
たとえば、とあるITプロジェクトで、もともとAさん１人が担当していたソフトウェア開発の進捗が悪く、完了予定日まで残り２ヶ月なのに、まだ８人月分の作業が残っていたとします。
この残り８人月の作業に３人の新規メンバーを追加し、４人体制で対応しようとするとします。
８人月の作業を４人で対応するので、計算上は２ヶ月で対応できそうです。
しかし、いざ４人体制でスタートしても、はじめはAさんから新規メンバーに対して状況説明をしたり、そのプロジェクトでのコーディングルールを共有したりと、新規メンバーの教育を行う時間が必要になります。
また、人数が増えたために、作業を割り振ったり、お互いの進捗を確認しあうコミュニケーションの時間も増加してしまいます。
その結果、開発以外の時間が増えてしまい、４人体制を敷いて２ヶ月で完了させる予定のものが、結局は３ヶ月も４ヶ月もかかってしまいます。
ブルックスの法則への対策
銀の弾（魔法のような解決策）はない
スケジュール遅延が発生し、要員を追加したらブルックスの法則が働き、ますますスケジュールは乱れていきます。
ではこの問題にどのように対処していけばよいのでしょうか。
ブルックスの法則が記されている『人月の神話』にはソフトウェア開発のプロジェクトで起こる様々な問題が論じられていますが、総じて結論としては狼人間から襲われる悪夢を終わらせる「銀の弾」のような方法はないというものです。
今回のようなスケジュール遅延に対しては、あらかじめ作業の生産性やバグ発生率の数量化を行い、見積り基準を開発し、それを公にして共有して予防をすること[2]前掲『人月の神話』、19頁。としています。また、スケジュールの見直しが必要になったら、作り直したスケジュールはたっぷり時間をとって慎重に、そして完全に作業を終わらせるようにすることとしています [3]前掲『人月の神話』、20頁。 。
遅れたスケジュールにのみブルックスの法則は有効？
ブルックスの法則の対策ではありませんが、ブルックスの法則はスケジュール遅延が発生しているプロジェクトに要員が追加された時に発生するため、実際に作業が始まる前に要員が追加される場合は、状況が変わるかもしれません。
たとえばプログラマーが実際に開発に着手した後で要員を追加しても、スケジュールは思ったように早まらないですが、仕様設計などの前段階で要員の不足が発見され、増員した体制がしっかりと敷かれた後で開発が始まれば、人数の増加のメリットを享受することができそうです。
また、教育コストのかからないような腕の立つ要員を用意するということでも、ある程度は解消されるかもしれません。
とはいえ、いずれにしても付け焼き刃の対応ではあるため、『人月の神話』で論じられているように、あらかじめ生産性やバグ発生率を正確に把握し、無理のないスケジュールをたてていくことに越したことはないでしょう。
ブルックスの法則の言い換え
ワインバーグによるブルックスの法則の言い換え
ここまではブルックスの法則の内容を見てきました。
ここからはブルックスと同じくソフトウェアエンジニアリングに多大な影響を及ぼしたジェラルド・ワインバーグの著書『ワインバーグのシステム思考法』で紹介されている「ブルックスの法則の言い換え」を紹介していきます。
ブルックスの法則の言い換えとは、「他のすべての原因よりもカレンダー時間の切迫が、ソフトウェアプロジェクトにその失敗の現実を直視させる」というものです[4]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、328頁。。
これはどういうことかというと、スケジュールの切迫自体がプロジェクトの失敗の原因ではなく、他の要因によってスケジュール遅延が発生していることこそが問題なのですが、プロジェクトの失敗という現実をプロジェクト・チームにつきつけるのはスケジュールだということです。
言い換えたブルックスの法則の言い換え
つまり、言い換えたブルックスの法則はさらにこのように言い換えることができます。
他のすべての原因よりもカレンダー時間の切迫が、彼らのモデルの誤りを直視させる[5]G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年、328頁。。
繰り返しになってしまいますが、スケジュールの遅延というのはあくまで結果であって、プロジェクトが失敗した原因ではありません。
しかし、スケジュールの切迫以上にプロジェクトのメンバーに「プロジェクトが失敗した」という現実をつきつけるものはなく、反省を促すものもないでしょう。
参考
Webサイト
書籍
- フレデリック・P・ブルックス Jr.、滝沢徹 (訳) 、牧野祐子 (訳) 、富澤昇 (訳)『人月の神話 【新装版】』、丸善出版社、2014年。
- G.M.ワインバーグ (著)、大野 徇郎 (訳)『ワインバーグのシステム思考法 ソフトウェア文化を創る〈1〉』共立出版 、1994年。