前回に続き、今回もシステム開発時のトラブルの責任について考察したい。

　まず、下図をご覧いただきたい。トラブルが発生した時に、システム開発（受注）側と発注側のどちらに責任があるかを、システム開発のフェーズごとに大まかに示した図である。

責任の重さは発注側から受注（開発）側へと移っていく

　システム開発は「計画・分析」フェーズから始まる。コンサルティング会社やシステムインテグレーターなどの会社が発注会社にシステム化の構想や目的などをヒアリングし、具現化していく。この工程では、発注側の方向性確立や情報開示などが求められ、ここで発注側の意向がブレると、後々になって大変な問題を引き起こす。

　次は「設計（基本・詳細）」フェーズである。ここでも、まだ発注側の責任加重が大きい。発注側に、ある程度のシステム知識のある人をリーダーとして置き、開発側の提示する各種設計資料を「承認」しなければならない。

　裁判に至るほとんどのトラブルの原因は、実はこの「設計（基本・詳細）」フェーズのものが相当数を占める。それは、発注側の「お金を払うのはこっちなんだから、ちょっとは融通を利かせてくれるだろう（後からでも変更させてくれるだろう）」という甘えがあるような気がする。

　この時期に、画面や帳票など旧システムにあったものが「必要ない」と判断されたものの、後になって「やはり必要」ということで再浮上してくることがよくある。これが、俗に言う「仕様変更」であり、追加費用請求の妥当性を巡ってよく係争になる。