新しいお客様とのシステム開発の難易度

日経XTECHを読んでいると、「金は払わないけどやって、理不尽な追加要求でプロジェクトが炎上」という記事が公開されていました。

発注側と受注側の立場の違いと、不確定な状態で見積もり提示や予算措置が行われるという我が国の商慣習から、IT業界では受発注者間でトラブルが起こりがち。システムは目に見えず、値ごろ感もないため、理不尽な主張が起こり、結果的にプロジェクトが炎上し...

今まで、一緒にシステムを開発してきたお客様であれば、どういう時に追加費用がかかって、どういう場合はシステム構築業者側で頑張れるかといった阿吽の呼吸が出来上がっていくのですが、初めてお付き合いするお客様だと、まだ文化の共有ができていないので、「金は払わないけどやって」というような話しが起こりがちです。

特に基本設計工程あたりからサービス開始まで一括で請け負って開発するような開発だと、そんな小さなボタンのかけ違いが、あとで大変なことに繋がるパターンが良くあります。

お客様が準備した仕様書、要件が曖昧な場合は、一旦、基本設計でお客様がやりたいことをきちんと整理し、両者できちんと合意（仕様凍結）した上で開発をスタートさせるのが順当な方法でしょう。

ただ、官公庁のお客様だと年度の予算が決められていたり、業者と複数年度契約ができる国家債務負担行為で予算を確保する形になります。まだ、お客様側が準備した調達仕様書を元に基本設計からサービス開始までの一括請負となるパターンがほとんどです。基本設計等で仕様が膨らんだとしても、天変地異など外的な理由が無い限りは予算の増額が難しい場合が多く、「金は払わないけど、やって」とか、緩く書かれている仕様書を元に、「ここに書いてあるでしょ」のようなことになります。

近年はIT調達制度が見直されたことにより、大きなシステム開発をサブシステムや機能ごとに複数の業者へ分割して発注することも増えています。この場合、業者間の仕様調整等に官庁のお客様があたらなくてはいけないことも多く、いわばお客様側がシステム開発のプロジェクトマネージャーを担った形になります。

業者間で齟齬等が発生した場合は、どちらの業者の責任かと一律に決めることも出来ず、またお客様が修正のための追加の予算を確保することもままなりません。通常はプロジェクトマネージャーにはリスク予備費がありますが、官公庁のお客様は手元に予備費を持っているわけでは無いので、調整が硬直的になってしまいます。

このように大きな開発で複数の業者に分割発注されるようなまのには、お客様側には工程管理会社等と呼ばれるコンサル会社が付くことが普通ですが、やはりコンサル会社が予備費分を負担するわけにもいきません。