システム開発過程におけるシステム開発費の追加。
今回は、『システムテスト／検収時に発生する追加費用』 を取り上げてみたいと思います。
この段階で追加費用が出てくるというのは、明らかに
『要件漏れ』 『考慮漏れ』 『設計ミス』
が原因の大半を占めることでしょう。
基本的には、ユーザ企業またはベンダー企業のどちらの 『落ち度』 で発生したかによって、追加費用の負担先が決ることでしょう。
ただ、どの様な経緯でこの工程まで進んできたのか、その間にどの様な合意がなされたのかなど、設計書や議事録などに証拠を残しておかなければ 『落ち度』 を判定することは非常に難しいでしょう。
ただ、判定する材料がないとベンダー企業が圧倒的に不利になるでしょうが、ユーザ企業もその事を逆手に取らず、真摯に協議する姿勢が望まれます。
通常であれば、システム設計工程終了時に、ベンダーから
仕様凍結／仕様確定
という話しが出るはずです。
要するに、ユーザ企業がシステム設計を承認（合意）する手続きの事です。
もっと突っ込んだ言い方をすると、
この手続き以降、設計変更が生じた場合は別途費用がかかる、
ということをユーザ企業が認めるという事です。
それじゃ、この手続きを踏まなければ、ユーザ企業はいつでも自由に設計変更できるのでは？
と思われるかもしれませんが、そうなるといつまで経っても仕様が決らず、ベンダー側も作業が進まないと言う事になります。要は、納期遅延の原因となるのです。
そうなると、ユーザ企業側に遅延責任があるので、遅延期間に発生したベンダー側のコスト（主に技術者の人件費）を要求されても止む無し、となるのでご注意を。
その際は、要件がどの様にシステム設計に反映してあるのかを十分に確認することが肝要です。
システム設計に対するチェック機能が働かないと 『要件漏れ』 『考慮漏れ』 が後工程で露見する事になるのです。
仮にベンダーから承認印を急いで押してくれといわれても、安易に承認印を押すべきではありません。
安易に承認印を押すと『落ち度』がベンダー企業側にあったとしても、
『それは仕様変更です！』
と言われたら従わざるを得なくなりますので、要注意です。
慎重に事を運んだとしても、システムテスト工程になると
『設計段階でのイメージ』 ☞ 『動くシステム』 となっており、
ユーザ企業も実際のシステムを『見て』『操作』するようになります。
そうなると
やっぱりこうしたい！
え！ 違うんじゃない？
など 『要望』 や 『意見』 が出てくるものです。
この段階に来ると、どちらが負担すべきはその状況に依るとしかいい様がなく、ユーザ企業／ベンダー企業が協議して決めざるを得ません。
