リスクを緩和する上手な予算の立て方・使い方：企業システム戦略の基礎知識（5）（1/2 ページ）

仕様変更、追加開発が爆発的に増加し、予算オーバーでプロジェクトが中止──とはよく聞く話だ。今回は、そうした失敗をしないための上手な予算の配分について考えていこう

　さて、要件定義も固まり、仕様書もできたら、いよいよシステム開発である。これを社内でやるか、外注するかは別にして、できた仕様書は決して完ぺきではないということを忘れてはならない。いざ、システムができてきて、実際にリハーサルなどを繰り返すうちに、当初に残した2割の要求のほかにもあれこれ仕様が漏れていることが発覚するものだ。ときには、致命的な漏れを発見することもある。

　そのときに「予算がありません」では、必然的に予算オーバーとなる。期間についても同様、ギリギリのスケジュールを敷いていると、途端に期間延長、予定遅れとなってしまう。そんなことにならないように、予算・期間に余裕を持たせておくことが必要である。また、運用段階での保守費用もあらかじめ予算の一部として考慮しておかなければならない。

2：4：2：3の法則

　仕様追加による予算オーバーに関して、俗に「2：4：2：3の法則」といわれているものがある。当初の予算に対して、仕様追加が発生して開発費用が2倍に膨れ上がる。ところが、開発費用は相変わらず当初のままである。そこで、仕方がないので、追加予算を申請し最終的に当初予算の1.5倍で手を打つことになるというものである。

　予算を有効活用するには、これを逆手に利用する。

　まず当初予算の半額分だけをまず開発する。当然、要求仕様は、ビジョンや要件定義に照らし合わせて優先順位を付け、上位のものから予算半額で可能なところまでを開発する。これで、システムの必要最低限の部分は利用可能となる。

　そして、リハーサルなどを行い仕様の漏れや実際に使ってみた結果で、仕様変更や追加仕様を洗い出す。そして、当初の残り半分と合わせて優先順位を付け、効果が明確な仕様追加に対してのみ追加予算を申請・審議する。

　このようにすると、1/2：1：1/2：3/4となり、結果的に当初、予算の1/4が余る。さらに、もう1度、リハーサルを繰り返して、重要な追加仕様に1/4の予算を使うこともできる。このようにすると、当初の予算内で、都合3回の繰り返し開発が可能である。基本部分から小さく始めて、実際のシステムを確認しながら順次、仕様を見直して繰り返し開発するので、最終的に要求事項をかなり満足したシステムを構築することができる。これも、前述した「守・破・離」の考え方に通じる。

　同様に、開発期間についても、これに合わせて、最大3回程度の繰り返し開発を想定し、最初の1/2開発は、全体の開発期間の1/2程度をメドに完了し、初期リリースをする。次の仕様追加は、3/4時点でのリリースとする。そして、最悪、3回目の繰り返しが必要であったとしても、当初の最終完成予定をクリアすることができる。

仕様変更対策

　システム構築において、仕様変更は必ずあると考えた方がよい。特に、既存の業務プロセスを自動化するレベルではなく、新たに業務設計から始めた、いわゆる業務改革型や創造型のシステム構築では、実際の仕事に沿ってシステムを動かすリハーサルをやるまでは、想像の域を出ない。これは、どんなモデル化手法を用いても、業務プロセスという目に見えないものを扱う以上仕方のないことである。

　従って、仕様変更を避けるのではなく、仕様変更をうまくかわすことを考えた方がよい。

　うまくかわすには、仕様変更から逃げずに、前に一歩出て相手の懐に飛び込んでみればよい。そして、その仕様変更要求が、なぜ出てきたのかをしっかりと聞いてみることだ。その結果、ビジョンや要件を実現するために必須の要求事項が漏れていたものか、それとも、あったらいいな程度の改善要望か、はたまた、単なる思い付き・勘違いのたぐいか──。

　さて、仕様変更を識別し優先順位を付けたならば、いつの段階で盛り込むかというのが問題になる。

　できれば、第1次開発が完了し、運用試験を一巡した後に盛り込むのがよい。開発途中の仕様変更は、開発チームの士気やモラルの低下を招き、コスト・納期・品質、すべてに悪影響が出る。あいまいな仕様書で開発を始めておいて、途中から変更を好き放題に詰め込めば、プロジェクトがどのような状態になるか、システムの専門家でなくても想像に難くない。ただでさえ、ソフトウェア開発は超労働集約産業であるから、人のメンタルな面が、製品の品質や納期・コストに表れやすい。

　ただし、変更がマスタ・データベースの重要項目に及ぶような場合は、必ずしも後回しにすることが得策とならないこともある。多くのプログラムで共通的に参照されるマスタ・データベースの重要項目に変更や追加があると、これを後から改修するのは非常に費用が掛かる。そのような致命的な仕様変更は極力避けたいが、万一発生した場合は、その重要度や影響範囲、コスト・納期・品質に対する影響などを判断し、途中で盛り込むことも必要である。

　家の建築でも、基礎工事が終わってしまってから、大幅な間取り変更は困難であるが、内装や壁のクロスなどは、後からでも変更が可能だ。システム構築において、データベースは建築の場合の基礎に当たり、画面のレイアウトや色使いなどは、内装やカベのクロスに当たる。