Category: 法則
Type: プロジェクト管理
Origin: ソフトウェア工学、1975年、フレッド・ブルックス
Also known as: 神話の人月
Type: プロジェクト管理
Origin: ソフトウェア工学、1975年、フレッド・ブルックス
Also known as: 神話の人月
先に答えると —
ブルックスの法則は、遅れたソフトウェアプロジェクトに人員を追加するとさらに遅くなると述べています。IBMのOS/360プロジェクトを率いた経験に基づきフレッド・ブルックスが定式化したこの原則は、複雑なプロジェクトのスケジュール遅延が単により多くのリソースを投入することで解決できない理由——新しいチームメンバーはトレーニングと調整のオーバーヘッドを必要とし、それが短期的な貢献を上回る——を明らかにします。
ブルックスの法則（Brooks’s Law）とは
ブルックスの法則は、チームサイズとプロジェクトスケジュールの直感に反する関係を記述するソフトウェアプロジェクト管理の基本原理です。この法則は、新しい人が無能だからではなく、オンボーディング、コミュニケーション、調整の本質的なコストのために、遅れたプロジェクトに更多的人を追加するとさらに遅延すると述べています。「遅れたソフトウェアプロジェクトに人員を追加すると、さらに遅くなる」——フレッド・ブルックス核心的な洞察は、ソフトウェア開発は製造業とは異なるということです。工場では、労働者を追加すると通常比例して出力が増加します。しかし、複雑な知識作業では、コミュニケーションのオーバーヘッドはチームサイズとともに非線形に増加します。新しい人はそれぞれトレーニングを受け、ワークフローに統合され、既存のチームメンバーと調整される必要があります——これが実際の進行から注意を逸らす作業を生み出します。
ブルックスの法則を3つの深さで理解する
- 初心者: 苦戦しているプロジェクトに人を追加すると、多くの場合状況は良くなるのではなく悪化することを理解しましょう。新人の最初の熱意は、トレーニングと調整のコストによって相殺されます。
- 実践者: 遅延プロジェクトにリソースを追加する前に、新メンバーの「立ち上がり時間」と調整オーバーヘッドを計算しましょう。多くの場合、スコープの削減やプロセスの改善の方が効果的です。
- 上級者: ブルックスの法則が相互依存性の高いプロジェクトに最も強く適用されることを認識しましょう。高度にモジュール化されたプロジェクトは新しいメンバーをより簡単に吸収できます。また、法則を回避できる場合も理解しましょう——結合度の低い「機能ファーム」に人を追加するなど。
起源
フレッド・ブルックス（1931年生まれ）は、1960年代にIBMのOS/360オペレーティングシステムプロジェクトを管理したアメリカのソフトウェアエンジニア、計算機科学者です。OS/360プロジェクトは当時最大のソフトウェアプロジェクトの一つであり、技術的には成功したものの、スケジュールと予算を大幅に超過しました。 1975年、ブルックスは経験と洞察を「神話の人月——ソフトウェア工学のエッセイ」として発表しました。この本はソフトウェア工学文献の礎石となり、ブルックスの法則はそれ以来、無数のプロジェクトの事後分析と管理の議論で引用されてきました。 タイトルの「人月」は、1人が1か月で働く努力を表す作業単位を指します。ブルックスは、この単位が相互依存タスクに適用されるとき危険な神話であると主張しました——人と月は交換可能ではないからです。要点
コミュニケーションのオーバーヘッドはチームサイズとともに増加する
新しいチームメンバーはそれぞれ、既存のメンバー全員とのコミュニケーションチャネルを追加します。n人の場合、n(n-1)/2の可能なコミュニケーションパスがあります。10人のチームには45のチャネルがあり、20人のチームには190のチャネルがあります。
応用場面
プロジェクト計画
調整オーバーヘッドを考慮して現実的なスケジュールを構築しましょう。チームを2倍にしてもタイムラインが半分になるとは限らないことを認識しましょう。
採用決定
「問題に人を投げつける」誘惑に抵抗しましょう。新メンバーが十分に早くオンボーディングできるかどうかを評価しましょう。
危機管理
プロジェクトが遅れている場合、まず根本原因を調査しましょう。根本的な問題を修正せずにリソースを追加すると、問題が悪化します。
チーム構造
自律性と最小限の相互依存のためにチームを設計しましょう。コンウェイの法則は、システムアーキテクチャがチームのコミュニケーションパターンを反映することを示唆しています。
事例
OS/360プロジェクト
1960年代半ばのIBMのOS/360オペレーティングシステムプロジェクトは、数百万行のコード、数百人の開発者、IBMのコンピューターライン全体での互換性に関する野心的な目標——規模において画期的なものでした。 プロジェクトがスケジュールに遅れたとき、IBMの経営陣は慣例的に反応しました。より多くのプログラマーを追加したのです。ブルックスは、これが状況を悪化させるだけであることを観察しました。新しいプログラマーは巨大なコードベースでトレーニングを受ける必要があり、既存のチームメンバーはコーディングではなくメンタリングに時間を費やし、増加した調整の負担が全員を遅くしました。 プロジェクトは最終的にリリースされましたが、数年遅れで予算を大幅に超過しました。ブルックスは後に、OS/360から学んだ最も価値のあることは「子供を産むのは、何人の女性を割り当てても9か月かかる」ということだったと書いています。限界と失敗パターン
原則が適用されない場合:- 高度にモジュール化されたプロジェクト: 作業がクリーンに独立したモジュールに分割できる場合、人を追加すると役立ちます。重要なのは、タスクが真の依存関係を持つかどうかです。
- プロジェクトの初期フェーズ: 始まったばかりのプロジェクトに人を追加するコストは、学ぶべきコンテキストが少ないため低くなる可能性があります。
- 純粋に逐次的なタスク: 作業が純粋に加算的（データ入力など）である場合、更多的人は確かにスループットを増加させます。
- 人員不足を正当化するためにブルックスの法則を使う: この法則は人を決して追加すべきだと言っているわけではありません——遅れたプロジェクトに人を追加するのは非生産的だと言っているのです。最初からの適切な人員配置は依然として重要です。
- 緊急時に法則を無視する: 一部のマネージャーはパニックになってとにかく人を追加し、繰り返しこの教訓を学びます。
- すべてのドメインに適用する: ブルックスの法則は特化してソフトウェアについてのものでした。他の分野への適用性は様々です。
よくある誤解
ブルックスの法則はプロジェクトに決して人を追加すべきでないという意味だ
ブルックスの法則はプロジェクトに決して人を追加すべきでないという意味だ
違います。
この法則は特化して遅れたプロジェクトに対処しています。スケジュール通りだが加速が必要なプロジェクトに人を追加することは、作業が分解可能であれば機能します。
法則はソフトウェア開発者が特別であることを証明している
法則はソフトウェア開発者が特別であることを証明している
違います。
この原則は、ソフトウェアだけでなく、複雑で相互依存する知識作業すべてに適用されます。創造的なプロジェクト、研究チーム、複雑な組織イニシアチブも同様のダイナミクスを示します。
より良いツールができたのでブルックスの法則は時代遅れだ
より良いツールができたのでブルックスの法則は時代遅れだ
違います。
ツールは改善されましたが、コミュニケーションのオーバーヘッドと立ち上がり時間の根本的な課題は持続しています。モダンなアジャイル手法は実際により多くのコミュニケーションを強調しており、法則をさらに適切にしています。
関連概念
神話の人月（The Mythical Man-Month）
この法則を紹介したブルックスのソフトウェアプロジェクト管理に関する記念碑的な本。
コンウェイの法則（Conway's Law）
システムデザインが組織のコミュニケーション構造を反映するという観察。
パーキンソンの法則（Parkinson's Law）
仕事は完成に利用できる時間を満たすまで膨張するという観察。
クリティカルパス分析（Critical Path Analysis）
プロジェクトの期間を決定するタスクのシーケンスを特定するプロジェクト管理手法。
アジャイル手法（Agile Methodology）
反復的な進行とチームコラボレーションを強調する開発アプローチ。
スコープクリープ（Scope Creep）
プロジェクト要件が元の目標を超えて制御不能に拡大すること。