追加費用は、どちらが負担すべきか（その３）

追加費用は、どちらが負担すべきか（その３）

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

今回は、『システム設計の考慮漏れ』 を発生要因として取り上げてみたいと思います。

◇◇◇◇◇◇◇◇◇◇

要件定義も終わり、システム設計工程へ。

ここで、『要件確定』　と　『仕様確定』　とは違うと言う事を認識しておいたほうが良いでしょう。

『何をしたいのか』　と　『どの様に実現するのか』　と言葉を置き換えれば一目瞭然です。

また、システム設計も、基本設計（外部設計） と詳細設計（内部設計） がありますが、この違いも認識しておいたほうが良いでしょう。

基本設計（外部設計）は、要件定義をもとに、システム全体をどの様に組み立てるのかを明確にするもの。

詳細設計（内部設計）は、基本設計（外部設計）をもとに、システムを組み立てる部品をどの様に作るのかを明確にするもの。

とは言っても、開発方法論 （ウォーターフォールやプロトタイピングなど） によって違いがあるので一括りにはできませんが、どんな開発方法論であっても、全体のコンセプトを明確にせずに部分（部品）を作ると、後戻りが増えるという事は明白でしょう。

◇◇◇◇◇◇◇◇◇◇

システム設計を進めると、大体システム規模が膨れ上がるものです。


システムの仕様凍結 （仕様を確定させること。以降の仕様変更は別途費用とするのが一般的です） 前であれば、システム開発費を追加したくないというのがユーザの本音でしょう。

でも、ベンダーとしては、システム設計を進める事で 『見えていなかった部分』 が見えるようになり、結果としてシステム開発規模（簡単に言えば、製造するプログラム本数）が膨れれば、その分の開発費が欲しいと言うのが本音でしょう。

ユーザ企業には 『この金額でやると言ったんだから、全てやれ！』 と、ベンダーの言い分を全く聞き入れない会社もあるようです。

確かに、本来であれば、この様な状況になるというのは 『ベンダーの甘さ』 と言わざるを得ず、当初予算内で吸収できるように努力すべきだと思います。

しかし、要件定義そのものに無理が無かったのか、必要も無い機能を作成しようとしていないか等をベンダーと協議し、ユーザ／ベンダー双方で当初予算内で吸収できるように努力したほうが、より建設的ではないでしょうか。

貴方の会社のシステムを作ってくれる 『パートナー』 であるベンダーを粗末に扱うのは如何なものでしょうか？

ただ、この様な状況を意図的に作り出すベンダーがいるのも事実です。


提案時点では低く見積もり金額を出し、コンペを勝ち抜く。

そして、システム設計終了時点で 『正式見積り』 を出す際に、提案時点の見積額を大幅に上回る金額を提示する。

ユーザ企業も後に引けず、ベンダーの言いなりに・・・・

最悪のストーリーですね。

そうならない様にとの考えから、私はシステム調達の支援をしているのです。

ただ、膨れる原因が 『要件の追加』 の場合はどうでしょう。

ユーザ企業が伝えるべき要件を漏らしてしまった事と同じでしょうから、ユーザ企業は追加となった要件に対するシステム開発費用を負担すべきではないでしょうか。

よくあるのが、業務要件は明確に要件定義してあっても 、 『例外的にこんな業務処理をしている』 ということが、後になって出てくる場合です。

システム設計全体に影響がある場合と、あまり影響がない場合とで対応は変わるでしょうが、これもユーザ／ベンダー双方で当初予算内で吸収できるように努力すべきではないでしょうか。

兎に角、この段階は費用が増加し易いと言う事を念頭に、システム設計を進めたほうが良いのです。

◇◇◇◇◇◇◇◇◇◇

ところが、システム設計の考慮漏れが発覚するのは、システム設計工程ではなく次の工程である製造工程やテスト／検収工程で発覚する事が大半です。

次回は、『システムテスト／検収時に発覚する考慮漏れ』 を取り上げてみたいと思います。

こちらもご覧ください