「ブルックスの法則」の検証

システム開発

先日、紹介した「人月の神話」に書かれている「ブルックスの法則」について、初めて読んだ際にグッと来たので、この法則を掘っていきたいと思います。

名著を読む「人月の神話」
システム開発にまつわる著書を読み込んでいた時期がありました。その中で、名著と思われるもの、名著と呼ばれているものを紹介していきたいと思います。まずは、第1段として、この分野の名著といえば、これでは?という本を紹介します。人月の神話...

「ブルックスの法則」とは

「人月の神話」の「第2章 人月の神話」という本の題名と同じ題名の章に書かれている法則です。

遅れているソフトウエアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ

フレデリック・ブルックス著「人月の神話」「第2章 人月の神話」より

本文中では、12人月の仕事量を3人が4ヶ月をかけて行うプロジェクトが例としてあげられていて、このプロジェクトが2ヶ月を経過した時点で、1ヶ月の遅れで9人月が残っている。という想定となっています。

これをEVMSを用いて確認をして行くと、以下の状況になります。
(ACなど本来は金額で計算する項目は、工数に置き換えて計算しています。)

  • BAC(完了までの当初予算):12人月
  • PV(出来高計画値):6人月
  • EV(出来高実績値):3人月
  • AC(実際のコスト):6人月
  • SPI(スケジュール効率指数):0.5 ( EV / PV )
  • CPI(コスト効率指数):0.5 ( EV / AC )
  • ETC(残作業コスト見積):18人月 ( ( BAC – EV ) / CPI )
  • EAC(完了時コスト見積):24人月 ( AC + ETC )

EVMSは、こちらで解説しています。

EVMS(アーンドバリューマネジメントシステム)
IT業界で、プロジェクトのマネジメントに関わったことがある方であれば、聞いたことがあると思います。「EVMS」は「Earned Value Management System」の略称です。EVMSとは「Earned Val...

自分がこのプロジェクトのマネージャなら逃げたいところです。規模が小さいのまだ良いですが、単位が100人月を超えるようなプロジェクトで、この状況だと、部署予算は大赤字になるでしょうし、小さな会社だと倒産の危機になるでしょう。

このような状況に陥った際に、実際のプロジェクトで取られる対応は、「納期を遵守せよ。かつ、要員の追加は最小限にせよ。」といったものではないでしょうか。自社製品や自社サービスであれば、完成を遅らせる。といった対応をとることもできるかと思います。実際に、身近な例だと、人気大作ゲームなどで販売延期をしたりして品質を高めたり最新の機能を取り込んだりすることが多い印象です。しかしながら、IT業界でよくある一括請負の場合、大抵は、顧客から工数増加に対応する予算の獲得はできず、手弁当で予算を追加するため、最小限の人員追加になると思います。稀に、明らかな顧客起因による要件変更に伴い追加予算を獲得できる場合は、前述のEVMSを用いて計算したETC分の費用を獲得することができると思いますが、これは、なかなかできないと思います。

ブルックスの法則は、新規要員が、プロジェクトの運営ルールや開発技法、ツールなどを理解するまで時間がかかり、その新規要員に教える既存要員の工数もかかる。というところにあります。
例えば、2名の新規要員追加で、前述の内容を覚える期間が1ヶ月程度かかるとします。教える人が1人だったとしても3人の1月分の工数はゼロとまではいかなくてもかなりCPIが悪化することになります。そもそも、既存要員のCPIが0.5の状態で新規要員に教えた場合、新規要員のCPIも0.5が最大となります。ETCの18人月では確実に終わりません。さらに追加の対応が必要です。

ブルックスの法則に対する対応

ブルックスの法則は、避けては通れないものと考えています。

避けては通れないと思いますが、リスク対応でいう、「軽減」「受容」ということはできます。

まずは、「念密な計画を建てる」ということが重要かと思います。アサイン予定のメンバの生産性を把握し、WBSを詳細化して見積もりのブレを減らすようにする。といったような対応が取られるかと思います。

次に重要なのは、プロジェクトを開始してから早期の段階で、EVMSを利用して、CPIを算出してETCとEACを確認することです。同じメンバーであってもプロジェクトの特性によって、生産性は変わるものです。また、メンバーの生産性は変わらない。と仮定しても、詳細化されたWBSに対して見積をした人によって、相対的な生産性が変わるものです。このことから、例えば、プロジェクトを開始してから10%程度の期間を経過したら、CPI、ETC及びEACを確認することにより、様々な対策をとることができます。少なくとも「プロジェクト完了予定日の1ヶ月前に絶望的な状況を把握する」という事態にくらべたら取りうるオプションは多いです。

そして、リクスを小さくするため、一つのプロジェクトを小さくする。という対策があります。
例えば1,000人月という壮大な工数がかかるシステムの開発があったとして、それを一つのウォーターフォール開発モデルでやるのではなく、スクラム開発モデルにし、複数のスプリントに分割して行う。という方法があります。複数のスプリントに分割することにより、一つ一つのスプリントの規模を小さくすることができます。このようにすることで、リスクが顕在化しても、プロジェクト全体の予備費で対処できる範囲にしておけば、リスクが顕在化した原因を見極めて、残りのスプリントで調整するといった対応ができます。

基本を忠実に実行するのが最善の対策

上記に対策を3つに分けて記載しましたが、これは「当たり前だ」という内容で、アジャイル手法も今となってはPMBOKやISOにも取り入れられており、目新しいものではないと思います。

ただ、この当たり前のことが、顧客から予算を抑えられたり納期を縮められたりする要求があったり、ITベンダー内でも上層部から原価削減や複数プロジェクトへのアサイン要求があったり、ということからできない。となることがあり得ます。

「ブルックスの法則」を体感する事態に陥いると、自分たちプロジェクトチームだけではなく、顧客も自社の上層部も巻き込みます。顧客や上層部だけが都合よく「ブルックスの法則」の影響から逃れることはできません。

根拠があるWBSやそれに対応した合理的な見積をもとに、計画時に必要な工数(予算)を確保し、早期にプロジェクトの生産性を見極めて対策を行う。というのが最大の最善の対策となります。

コメント

タイトルとURLをコピーしました