一括請負契約の場合、見積もり精度が低いと、開発側が大きな打撃を受けます。発注側は、コスト面の損害はありませんが、スケジュール、機能、品質面での打撃は計り知れません。発注側が、「ソフトウェアの開発が予定通りに終了するだろう」との前提で将来のビジネス計画を立てていた場合、その計画は大幅な見直しが必要になります。
このように、見積もりミスは、発注側と開発側の双方に大きな影響を与えます。最悪の場合、共倒れになります。そのため、見積もりミスがあっても、双方の被害を最小限にする工夫が必要です。
見積もりミスが起きる大きな原因は、「見積もり技術が稚拙である」と、「実装機能が確定していない」の2つです。
「見積もり技術が稚拙である」という問題は、見積もり技術や見積もりのプロセスに関するものであり、これまでお届けしてきた「見積もり・シリーズ」のメインテーマとして取り上げました。具体的には、FP試算法、SLIM、(過去の類似プロジェクトからの)類推法を採用することで、高精度での規模見積もりや、見積もりの習慣付けが可能となります。
もう一方の「実装機能が確定していない」の解決は簡単ではありません。ソフトウェア開発で、通常、最も時間がかかるのが「要求仕様フェーズ」です。要求仕様フェーズで実装機能が決まらないと、正確な規模予測ができません(それを無理やり予測するのがFP試算法なのですが)。この対策として、通常は要求仕様の定義からテストまでの「ソフトウェア開発一式」を一括請負で契約するのですが、要求仕様フェーズだけを業務支援契約とし、残りの作業を一括請負にする方法があります。
まず、通常の開発フェーズを図2に示します。この方式では、発注側は、システム化計画を立て、実現可能性を分析して、以降の開発フェーズをソフトウェア開発会社(開発側)に依頼します。開発側は、発注側と協議しながら要求仕様を凍結させるのですが、そう簡単には決まりません。
「その処理方式ではなく、この方式にせよ」との発注側の要望を受け、翌週、変更したものを持っていくと、「うーん。やっぱり、元のままがいいな」と言われ、モチベーションがガクッと下がった……。そんな経験をしたことありませんか? 優柔不断な発注側のせいで、仕様は一向に決まらず時間だけが過ぎていきます。当然、納入日をシフトしてくれるはずもありません。
プロジェクトが途中で打ち切りになる原因のおよそ50%が、この「なかなか仕様を凍結できない」で、残りが「見積もりミス」です。プロジェクトが失敗する主な原因は、この2つにあるといえます。
そもそも、このプロジェクト失敗の2大要因を、開発側が責任を持って解決するというところに無理があります。それなら、「この2つを発注側に担当してもらえばいいのでは?」というのが、図3の契約方式です。この方式の骨子は、以下の2つです。
要求仕様フェーズを業務支援契約とすると、仕様を凍結できないことや、それにより生じるスケジュール遅延のリスクは、発注側が負うことになります。当然、発注側は早く凍結させようとするでしょう。
契約の形態は大きく異なりますが、実際の作業内容(図2の「要求仕様」と図3の「要求仕様」)は、何も変わりません。これにより、開発側のリスクは大きく下がり、また、正確な規模見積もりが可能になるのです。
今回は、見積もりミス対策を正攻法ではなく、“契約条件”から検討してみました。
引き続き、契約の側面から、見積もりミス対策を考えていきます。次は、「実費償還契約」を取り上げる予定です。これは、ある程度のコスト超過分を発注側に負担してもらう代わりに、実費が想定コストを下回った場合は、安くなった分を発注側と開発側で折半するというものです。建設業界などで実績のある契約形態ですね。
見積もり技法や、見積もりプロセスの活用だけでなく、契約条件を含めた多角的な対策により、デスマーチ・プロジェクトが1つでも少なくなることを祈っています。(次回に続く)
Copyright © ITmedia, Inc. All Rights Reserved.