システムの『悩み』や『困った』を一緒に解決します!

追加費用、どちらが負担(業務要件もれの場合)

シェアする

システム開発過程におけるシステム開発費の追加。

今回は、『業務要件漏れ』 を発生要因として取り上げてみたいと思います。

どういう形式(例えば、提案依頼書)であれ、ユーザ企業はシステム化の要件をベンダーに伝えてあるはずです。
ベンダーは、そのシステム化要件を元に見積りを提示していることでしょう。

ただ、その見積書が 『正式見積り』 なのか 『概算見積り』 なのかにより、システム開発費に与えるインパクトは変わってくるはずです。

何故なら、システム開発費が確定してスタートしたのか、それとも確定していないでスタートしたのか、と言葉を変えれば一目瞭然です。

システム規模が大きくなればなるほど不確定要素が多くなり、ベンダーもリスクを回避するために 『概算見積り』 として提示せざるを得ません。

そして、要件定義を終えた後に正式見積りを出すので、当初概算見積りより大幅に費用が膨れる事がありえます。

『正式』 『概算』 どちらの見積りであっても、要はユーザ企業が提示するシステム化要件と、要件定義工程との結果に差が出なければ、この段階でシステム開発費が追加される事はないでしょう。

結局は、ユーザ企業が発注前にどれだけシッカリと検討を重ね、ベンダーに十分な情報を提供したかに依るのです。

ユーザ企業が伝えるべき要件を漏らしてしまった場合はどうでしょう。

これは、明らかにユーザ企業のミスであり、追加となった要件に対するシステム開発費用を負担しなければならないのではないでしょうか。

システム化要件を検討もせず、システム開発の全てをベンダーに丸投げした場合は、議論の余地はないでしょうね。

それでは、十分な情報を提供しても、ベンダー側が要件を読み落としていたり、要件を誤解釈していたりと、ベンダー側の落ち度により見積額を大幅に変更しなければならない場合はどうでしょう。

これは、難しいですね。

何故なら、ベンダーから提示された提案書を読みきれないユーザ企業にも問題があったりしますので、単純にベンダーの落ち度と言い切れないからです。

そうは言っても、ベンダーの落ち度なのだから、それはベンダーが負担すべきだ、との声がユーザ企業から聞こえてきそうです。

反面、だから見積り精度を上げるために要件定義工程を行い、要件確定した後に正式(正確)な見積りを提示したのだとの声がベンダーから聞こえてきそうです。

双方言い分はあるでしょうが、話し合いで決着せざるを得ないところでしょう。

要件定義工程で 『必要要件』 と 『不必要要件』 をユーザ企業がシッカリと吟味しなければ、概ね要件は膨れあがってくるものです。

ベンダーとの打合せを重ねると、 『あれもしたい』 『これもしたい』 との ”おねだり病” が顔を覗かせるからです。

ところが、いざシステム開発してみると、 『使わない無駄な機能』 があちこちに・・・

『正式』 『概算』 どちらの見積りであっても、その金額を上限としてシステム化要件を調整しないから起こるのではないでしょうか。

当社は、顧客の立場に立ち、IT化・システム化戦略の企画・立案および推進、課題解決をご支援させていただいておりますので、お悩み事やお困り事をお持ちのユーザ企業様、お気軽にご相談ください。

シェアする