Loading article…
ブルックスの法則は、ソフトウェアプロジェクト管理に関する観察であり、「遅れているソフトウェアプロジェクトに人員を追加すると、プロジェクトはさらに遅れる」というものです。 [1] [2]この法則は、フレッド・ブルックスが1975 年の著書「人月の神話」で提唱したものです。ブルックスによれば、特定の条件下では、プロジェクトに人員を追加すると、時間が短縮されるのではなく、長くなります。
説明
ブルックス自身によれば、この法則は「とんでもないほど単純化されている」[1]が、一般的なルールを捉えている。ブルックスは、なぜこの法則がこのように機能するのかを説明する主な要因を指摘している。
- プロジェクトに加わった人々が生産的になるには、ある程度の時間がかかります。ブルックスはこれを「立ち上げ」時間と呼びます。ソフトウェア プロジェクトは複雑なエンジニアリング作業であり、プロジェクトの新しい作業者はまず、それまでに行われた作業について教育を受ける必要があります。この教育には、プロジェクトですでに作業しているリソースを転用する必要があり、新しい作業者がまだ有意義な貢献をしていない間は、一時的に生産性が低下します。また、新しい作業者はそれぞれ、数人のエンジニアで構成されたチームに統合する必要があり、そのチームは新しい作業者に、コード ベースの専門分野について日々教育する必要があります。経験豊富な作業者の貢献度が下がることに加えて (トレーニングが必要なため)、新しい作業者は、たとえばバグを持ち込んでプロジェクトの完了を遅らせるなど、マイナスの貢献をすることさえあります。
- 人数が増えると、コミュニケーションのオーバーヘッドが増加します。組み合わせ爆発により、異なるコミュニケーションチャネルの数は人数とともに急速に増加します。[3]同じタスクに取り組んでいる全員が同期を保つ必要があるため、人が増えると、他の人が何をしているのかを知るために多くの時間を費やすことになります。
- ホテルの部屋の清掃など、非常に分割しやすいタスクに人員を追加すると、タスク全体の所要時間は短縮されます (追加した作業員がお互いの邪魔になる程度まで)。ただし、ソフトウェア プロジェクトの多くの専門分野を含む他のタスクは、分割しにくいです。Brooks 氏は、別の例を挙げてこの分割可能性の限界を指摘しています。1 人の女性が 1 人の赤ちゃんを産むのに 9 か月かかりますが、「9 人の女性が 1 か月で赤ちゃんを産むことはできません」。
例外と可能な解決策
ブルックスの法則には例外を認め、解決策の可能性を開く重要なポイントがいくつかあります。[4] [5]
まず、ブルックスの法則は遅れているプロジェクトにのみ適用されることに注意する必要があります。[6]プロセスの早い段階で人員を追加すれば、プロジェクトを再び管理下に置くことができます。[7]プロジェクトが本当に遅れているのか、スケジュールが当初から過度に楽観的だったのかを判断することも重要です。多くのプロジェクトが遅れているのは、スケジュールのミスが原因です。スケジュールを修正することが、プロジェクト完了のための意味のある信頼できる時間枠を設定するための最善の方法です。[8]
プロジェクトに追加される人々の量、質、役割も考慮する必要があります。超過プロジェクトに関する法律を回避する簡単な方法の 1 つは、必要以上に人員を追加し、トレーニングとコミュニケーションのオーバーヘッドを余分に補うことです。[9]優れたプログラマーやスペシャリストは、トレーニングのオーバーヘッドを少なくして追加できます。[10]プロジェクトに関連する他のタスク、たとえば品質保証やドキュメント作成を行うために人員を追加できます。タスクが明確であれば、立ち上げ時間は最小限に抑えられます。[11]
適切なセグメンテーションは、チーム メンバー間のコミュニケーション オーバーヘッドを最小限に抑えるのに役立ちます。小さなサブ問題は小さなチームで解決し、トップレベルのチームはシステム統合を担当します。この方法が機能するには、まず問題のセグメンテーションを正しく行う必要があります。正しく行わないと、プロジェクト計画では密接に関連していないと定められていても、実際には密接に関連している問題の部分に取り組むプログラマー間のコミュニケーションが 妨げられ、問題が改善されるどころか悪化する可能性があります。
セグメンテーションの例としては、作業の分配を簡素化するデザイン パターンが挙げられます。これは、そのパターンによって提供されるフレームワーク内でチーム全体がそれぞれの役割を果たすことができるためです。デザイン パターンは、プログラマーが従うルールを定義し、標準言語の使用によってコミュニケーションを簡素化し、一貫性とスケーラビリティを実現します。
プロジェクトの開発者のほとんどを排除し（「バミューダに送る」）、残りの開発者にソフトウェアの完成を任せるというバミューダ計画は、ブルックスの法則を回避する方法として提案されている。[12] [13]
参照
注記
- ^ ab Frederick P. Brooks, Jr. The Mythical Man-Month 1995 [1975]. Addison-Wesley.
- ^ Maggie Fox NBC News、2013 年 10 月 21 日、「電話を使う方がよい: オバマケアの Web サイトがなぜ失敗なのか」。2013 年 10 月 21 日にアクセス。ソフトウェアの専門家は、「最も優秀で聡明な人材」を多く送り込むのも、正しい解決策ではないかもしれないと指摘しています。彼らは、プロジェクトに人を追加するとプロジェクトが遅くなるというブルックスの法則をよく引用しています。
- ^ James Taylor、「プロジェクトマネージャのためのサバイバルガイド」、第2版、AMACOM [明確化が必要]、2006年、ISBN 978-0814408773、p. 21。
- ^ 「ブルックスの法則にもかかわらず、遅れたプロジェクトに人を追加することは依然として一般的です」...「私自身、この使い古されたソフトウェア エンジニアリングの決まり文句を何度も説いてきましたが、もはやそれが真実だとは思いません」。(McConnell、1999)
- ^ 「問題は、ブルックスの法則を使って何かを正当化するときに、多くの人が時間をかけて考慮しない重要な例外があることです。」(Berkun、2006)
- ^ 「これらのプロジェクトでは、それがプロジェクトの最終段階にのみ適用されることが暗黙的に示されています。問題は、プロジェクトの最終段階にあるかどうかをどうやって知るかということです。」(McConnell、1999)
- ^ 「遅れているプロジェクトに人員を追加すると、必ずコストが増加するが、十分なスケジュールがあり、プロジェクトに最大人員が配置されていない可能性があるため、プロジェクトが遅れるとは限りません。プロジェクト タスク間に一定の順序上の制約がある場合のみ、プロジェクトは遅れます。」(Hsia、Hsu、Kung、1999)
- ^ 遅れて混乱するプロジェクトは、プロジェクト マネージャーが考えているよりもずっと遅れる傾向があります。プロジェクトの完了は 3 週間先ではなく、6 か月先です。スタッフを追加してください。彼らが生産的になる時間はあります。プロジェクトは計画よりも遅れますが、それはブルックスの法則によるものではありません。そもそもプロジェクトを過小評価した結果です。" (McConnell、1999)
- ^ 「ゴードンとラムはブルックスの法則を研究し、遅れたスケジュールを回復する最善の方法は、必要と思われる人員よりも多く、しかも早期に人員を追加することであると示唆した。」(シア、スー、クン、1999)
- ^ 「法則は、追加された労働力はすべて等しいと仮定していますが、これは真実ではありません。コードベースを熟知し、チームの半分と友人関係にある優秀なプログラマーを追加するという選択肢があれば、私はそれを検討します。」(Berkun、2006)
- ^ 「残念だがよくあるやり方は、あまり説明せずに人を投入し、全員に自分で解決させるというものだ。しかし、マネージャーがサリーとルパートが参加する理由を明確にし、チームからの意見も取り入れて、彼らの適切な役割を定義すれば、彼らはスムーズに移行できるだろう。」（バークン、2006年）
- ^ Shea, Tom (1984 年 5 月 7 日). 「開発者が「Vaporware」を発表」. InfoWorld . 6 (19). InfoWorld Media Group: 48. ISSN 0199-6649 . 2010 年 4 月 13 日閲覧。
- ^ Bruno, Eric J. (2023-02-06). 「Curly Braces #9: Fred Brooks は遅れたソフトウェア プロジェクトについて間違っていたのか?」. Java Magazine . Oracle Corporation.
参考文献
- Steve McConnell。「Brooks の法則の廃止」、IEEE Software、vol. 16、no. 6、pp. 6–8、1999 年 11 月/12 月。著者の Web サイト (Brooks の法則の廃止?) でも参照できます。
- Pei Hsia、Chih-tung Hsu、David C. Kung。「ブルックスの法則の再考: システム ダイナミクス アプローチ」、compsac、p. 370、第 23 回国際コンピュータ ソフトウェアおよびアプリケーション カンファレンス、1999 年。
- RL Gordon および JC Lamb。「ブルックスの法則の詳細」、Datamation、977 年 6 月、81 ～ 86 ページ。
- バークン、スコット (2006 年 1 月 11 日)。「ブルックスの法則の例外」。2008 年 7 月 28 日閲覧。
- ブルックスの法則は多くの共同活動に当てはまる