◆２：４：２：３の法則
俗に、ＩＴ業界では、仕様追加による予算オーバについて、２：４：２：３の法則と言われている。当初の予算に対して、仕様追加が発生して開発費用が、２倍に膨れ上がる。ところが、開発費用はあいかわらず当初のままである。そこで、しかたがないので、仕様追加を半分あきらめて、追加予算を申請し最終的に当初予算の１．５倍で手を打つというものである。
これを、逆手に利用して予算を有効利用するのである。それは、当初予算の半額分だけをまず開発する。当然、要求仕様は、ビジョンや要件定義に照らし合わせて優先順位を付け、上位のものから予算半額で可能なところまでを開発する。これで、システムの必要最低限の部分は利用可能となる。そして、リハーサルなどを行い、仕様の漏れや、実際に使ってみた結果で、仕様変更や追加仕様も洗い出す。そして、当初の残り半分と合わせて優先順位を付け、効果が明確な仕様追加に対してのみ追加予算を申請・審議する。
このようにすると、１／２：１：１／２：３／４となり、結果的に当初、予算の１／４が余る。さらに、もう一度、リハーサルを繰り返して、重要な追加仕様に１／４の予算を使うことも出来る。このようにすると、当初の予算内で、都合３回の繰り返し開発が可能である。基本部分から小さく始めて、実際のシステムを確認しながら順次、仕様を見直して繰り返し開発するので、最終的に要求事項をかなり満足したシステムを構築することができる。これも、前述した「守・破・離」の考え方に通じる。
また、建築に例えれば、基礎の完成時、棟上げ時、竣工時と状況に応じて、建築検査をしながら工事を進めるのにも似ている。建築業者に任せ切りにして、竣工時まで一切建築検査をしないと、手抜きや欠陥住宅のリスクが高くなる。また、途中での設計変更や要望も取り入れてもらう機会を逃すことになる。そのような場合、不満が残るものだ。同様に、最初から、完璧な仕様書を想定し、全予算をつぎ込んで一気に開発しようとすると、全てが完成するまで、システムに触れることができない。結果的には、後で仕様追加・変更が発生し、予算オーバとなり、その割りに満足できないシステムとなってしまう。
同様に、開発期間についても、これ合わせて、最大３回程度の繰り返し開発を想定し、最初の１／２開発は、全体の開発期間の１／２程度をメドに完了し、初期リリースをする。次の仕様追加は、３／４時点でのリリースとする。そして、最悪、３回目の繰り返しが必要であったとしても、当初の最終完成予定をクリアすることができる。
コメント