システム開発過程におけるシステム開発費の追加。
今回は、『業務要件漏れ』 を発生要因として取り上げてみたいと思います。
ベンダーは、そのシステム化要件を元に見積りを提示していることでしょう。
ただ、その見積書が 『正式見積り』 なのか 『概算見積り』 なのかにより、システム開発費に与えるインパクトは変わってくるはずです。
何故なら、システム開発費が確定してスタートしたのか、それとも確定していないでスタートしたのか、と言葉を変えれば一目瞭然です。
システム規模が大きくなればなるほど不確定要素が多くなり、ベンダーもリスクを回避するために 『概算見積り』 として提示せざるを得ません。
そして、要件定義を終えた後に正式見積りを出すので、当初概算見積りより大幅に費用が膨れる事がありえます。
結局は、ユーザ企業が発注前にどれだけシッカリと検討を重ね、ベンダーに十分な情報を提供したかに依るのです。
ユーザ企業が伝えるべき要件を漏らしてしまった場合はどうでしょう。
これは、明らかにユーザ企業のミスであり、追加となった要件に対するシステム開発費用を負担しなければならないのではないでしょうか。
システム化要件を検討もせず、システム開発の全てをベンダーに丸投げした場合は、議論の余地はないでしょうね。
それでは、十分な情報を提供しても、ベンダー側が要件を読み落としていたり、要件を誤解釈していたりと、ベンダー側の落ち度により見積額を大幅に変更しなければならない場合はどうでしょう。
これは、難しいですね。
何故なら、ベンダーから提示された提案書を読みきれないユーザ企業にも問題があったりしますので、単純にベンダーの落ち度と言い切れないからです。
そうは言っても、ベンダーの落ち度なのだから、それはベンダーが負担すべきだ、との声がユーザ企業から聞こえてきそうです。
反面、だから見積り精度を上げるために要件定義工程を行い、要件確定した後に正式（正確）な見積りを提示したのだとの声がベンダーから聞こえてきそうです。
双方言い分はあるでしょうが、話し合いで決着せざるを得ないところでしょう。
ベンダーとの打合せを重ねると、 『あれもしたい』 『これもしたい』 との ”おねだり病” が顔を覗かせるからです。
ところが、いざシステム開発してみると、 『使わない無駄な機能』 があちこちに・・・
『正式』 『概算』 どちらの見積りであっても、その金額を上限としてシステム化要件を調整しないから起こるのではないでしょうか。
