You are currently viewing 「ブルックスの法則」はソフトウェア以外のプロジェクトにも当てはまるか?

「ブルックスの法則」はソフトウェア以外のプロジェクトにも当てはまるか?

  • 投稿カテゴリー:Project Management
  • 投稿の最終変更日:2020年12月15日
  • Reading time:6 mins read

「ブルックスの法則:遅れているソフトウェアプロジェクトに要員を追加しても、さらに遅れるだけ」を他の業種で成り立つか考察しましたが、「ブルックスの法則」は様々な議論を喚起する奥深い法則です。

~ ~ ~ ~ ~

ソフトウエア開発の名著、フレデリック・ブルックスの「人月の神話」(原題:「The Mythical Man : Month – Essays on Software Engineering」)の中に、「ブルックスの法則」として知られる「遅れているソフトウェアプロジェクトに要員を追加しても、プロジェクトをさらに遅らせるだけ:”adding manpower to a late software project makes it later”」という記述があります。

ブルックスは、その理由として、次の3点を挙げています。
・新規メンバーの教育に時間が取られる
・コミュニケーションラインが増加し時間が取られる 
・タスクを新たなメンバーに配分する際の分解に限界がある

~ ~ ~ ~ ~

「ブルックスの法則」は建設や製造といった他のジャンルのプロジェクトにも当てはまるのでしょうか?建設プロジェクトで検証してみました。

建設プロジェクトで、工事が遅れるのは、①工事会社側の責任で遅れた場合、②施主側の責任で遅れた場合、③その両方、そして④天災等そのどちらでもない場合の4パターンがあります。
遅れた理由によって対応の仕方も異なるのですがそれはともかく、スコープを小さくする等の変更する事なく、純粋に遅れたプロジェクトを人を増やす事で短くする事ができるかに焦点を当てて考えます。

まず工程(期間)を短縮するには2つの方法があります。この2つの方法のいずれかが可能であれば、期間を短縮できます。

1.クラッシング(Crashing:突貫工事)
2.ファスト・トラッキング(Fast-Tracking)

~ ~ ~ ~ ~

1.クラッシング(突貫工事)

人を増やしたり作業時間を増やしたりすることで期間を圧縮する方法です。
1日の作業員が1日(8時間)でできる仕事を1人工(にんく)と言います。例えば、1,000人工の作業を50人で行う場合20日かかりますが、100人に増やせば10日で終わります。
(注:実際は人数によって作業効率も変化するため、単純な比例関係にはなりません)
下図の例では、作業A・B・Cにそれぞれ6日・4日・8日かかる当初の予定を、作業員を増やす事でそれぞれ3日・3日・5日に圧縮し、トータルでは18日から11日に短縮しています。

クラッシング(Crashing)クラッシング(Crashing)

早く終わらせる事はできますが、人数を計画より増やせばお金がかかりますし、増えた作業員が使う機械や設備も追加となれば更にお金はかかります。
作業員が増えれば管理上の負担・経費も増えます。ブルックスの指摘のように、追加した作業員に対する指導、コミュニケーション、元々の作業員と新しい作業員の連携は問題ないでしょうか?
スピードアップした作業対応に監督者(エンジニア)の追加が必要になる可能性もあります。

~ ~ ~ ~ ~

2.ファスト・トラッキング

A ⇒ B ⇒ Cという順番でやる予定だった作業の一部又は全部を、並行して行います。
この場合、A,B,Cの作業をそれぞれ別の作業員が行う予定であったなら、作業員を増やす事なく全体工程を圧縮できますが、A ⇒ B ⇒ Cの順番で同じ作業員が同じ設備を使って場所を変えて行う作業であった場合には、作業チームと設備を増やさなければ並行して行う事はできません。
下図の例では、作業A・B・Cにそれぞれに掛かる時間は変化ありませんが、作業A・Bを2日同時作業とし、更に作業B・Cも2日同時作業とする事で、トータルでは18日から14日に4日間短縮しています。

ファスト・トラッキング(Fast-Traking)

ファスト・トラッキングもクラッシングと同様に、同時作業が増えますので管理上の負担・リスクが増えます。A,B,Cの作業管理を一人の監督者(エンジニア)でもともと計画した場合、同時作業を一人で管理できず、監督者も増やす必要がある可能性もあります。

~ ~ ~ ~ ~

以上、お金やリスクが増える可能性はありますが、クラッシング、ファスト・トラッキングで工程を短くする事はできます(厳密に言うと、クリティカルパス上にある作業に対して有効ですが、その説明は割愛します)。

人を増やす事の効果がない場合というのは、逆にクラッシング、ファスト・トラッキングで工程短縮が出来ない場合です。

人を増やしても短くならない作業は多くあります。
例えば、田んぼの稲刈り作業は、稲を刈る人を増やせば(稲刈り機を増やせばというべきでしょうか)、刈り終わるまでの時間は短くて済みます。
しかし、4月の田植えから10月の稲刈りまでの期間はいくら人や機械を増やしても短くなりません。稲の生育を並行作業で進めて早くする事も出来ません。
建設分野で言えば、コンクリートが固まるまでの時間も、お金をかけて特別な促進技術を使えばある程度短くできますが、限界があります。当然コンクリートが固まるまで眺めている人を増やしても固まる時間は短くなりません(笑)。

基本的に工程短縮の方法はクラッシング、ファスト・トラッキングの2つの方法に限られるため、これらを使っても工程短縮ができない場合は、仕様変更やスコープを小さくする等の変更をする事なく、工程短縮はできないという事になります。
ただし逆に言うと、客先にお願いして仕様変更やスコープを小さくする了解をもらえれば短縮はできます。
さらには業務改善の積み上げで業務効率を上げれば圧縮できる可能性はありますが、業務改善で短期的に大幅な工程短縮は難しいですし、遅れを取り戻すためというよりは日々の業務に組み込まれているべきものでしょう。

~ ~ ~ ~ ~

ところで、遅れているプロジェクトでやっていけないのは「なぜ遅延が発生しているか原因が分からず、増員の効果も分からないが、取り合えず人を増やす」事です。
なぜ遅延が発生しているか明確な原因が分からないのであれば、まずその原因を突き止める必要があります。
原因を突き止めている間にも短縮対応が必要なほど緊急な場合で、クラッシング、ファスト・トラッキングが効果的なら、それを実施しつつ、原因を追究するという事も有り得ます。
しかし、2つともリスクを伴う方法なので、本質的な問題が水面下にくすぶっている場合、これらの方法が逆に働き、期待した効果が得られない可能性や、プロジェクトが余計に混乱する可能性もあります。

プロジェクトマネージャー(PM)が原因を突き止められれば良いのですが、突き止められない場合、PMO(プロジェクト・マネジメント・オフィス)や工事統括部、他の管理組織等、プロジェクトを監督する一段上位の組織の介入が必要になります。
上位組織がその原因を突き止める能力のある人間を派遣するなどして、原因を突き止めます。
その結果、原因に見合った対応をする。
もし実施体制や管理方法に問題があるなら、それ以上の遅延を防ぐため実施体制、管理方法を見直すとか、上位組織からサポートやチェックを強化するとか、プロジェクトマネージャーの能力不足の場合、最悪はPMを交替させなければならないケースもあるかもしれません。

~ ~ ~ ~ ~

通常原因は複数の要因が複雑に絡まり合っており、遅れは根本的な原因の一部が結果として表面に現れたものなので、上位組織でも根本的な原因究明ができない場合があります。または原因はある程度分かるが社内で利用可能なリソースではどうしようもない。
この場合どうするかというと、取り合えず人間を増員しよう、「取り合えず行ってきてくれ!」に陥りがちです。

しかも客先から「早く対応して下さい!」「何してるんですか!」とプレッシャーがある場合、問題を解決できない上位組織が出来る事は、人を追加するか交換するか謝ること(笑)位しかないので「何とか追加の人間を確保しました!」と精一杯の対応のアピールとして取り合えず人を増やす事もあります。
しかしこのようにして派遣された要員では、現地で手持ちぶたさになる可能性があります。

更には上位組織が官僚的、政治的な組織の場合、つまり権力闘争や社内の駆け引きが合理的判断より優先される場合、往々にして「何が原因か?」に加え「誰が原因か?」が追及されがちです。
遅れの原因によっては、現場のプロジェクトマネージャーは何をしていたんだ?更には上位組織は今まで何を管理してたんだ?そもそも誰がこんな問題だらけのプロジェクトを受注したんだ?と責任追及、指の差し合いが始まります。
そのためパワーバランスが合理的判断に優先され、「どうせ上層部はプロジェクトの詳細は分からない」と原因はグレーのままにしておいて、社内的には外的要因のためという説明にしておく。そして、プロジェクトは崩れるなりに崩れていく。。。という事もあるのです。
政治的な組織でなくても、「失敗=減点」色が強い組織では、原因追究に対する心理的安全性が確保されなかったり、PDCAが回らなかったり、原因の追究を避ける傾向があります。

ちょっと話が拡散してきました。。(汗)

~ ~ ~ ~ ~

最初の話に戻すと、「ブルックスの法則:遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」が建設等の他のジャンルのプロジェクトにも当てはまるか?ですが、答えは「ケース・バイ・ケース」です。
ソフトウエア開発以外の建設等のプロジェクトでも、追加費用やリスクが高まる可能性はあるもののクラッシング、ファスト・トラッキングで工程(期間)を圧縮できる場合は可能になります。
クラッシング、ファスト・トラッキングが適用できない場合は、仕様変更やスコープを小さくする等の変更をする事なく、期間を圧縮する事はできない事になります。この場合、要員追加しても期間を圧縮できないどころか、管理上の手間や非効率が生じて更に遅れる可能性はあります。

一方で「ブルックスの法則」は色々な考察への展開や、その他の課題を喚起しうる奥深い法則でもあります。

コメントを残す

CAPTCHA