「ドンブリ勘定」「つじつま合わせ」ができなくなる
仕様をしっかり確定して契約することが求められる
まず契約時点で発注側の要求や仕様が正確にきまっていることはまずありません。おおざっぱにきまっている範囲で、ITベンダーは手戻りなどの作業を予想しながら工数を見積もります。
開発が長期にわたると法律改正があったり想定していた競争構造が変わり、仕様変更や発注側が想定していなかった追加作業が発生する場合があります。これによって、収益や原価が見積もりからどんどん離れていきます。いままでは発注側、受注側ともにドンブリ勘定でやって最後につじつまをあわせていましたが、今後は、こういったことができなくなります。
営業段階から要件定義にかかるコスト、開発にかかるコストなど工程別により正確な見積もりが行われなければなりません。契約習慣や内容も整備しなければなりません。方向性しか決まっていないのに、とりあえず先行着手するような契約習慣ではだめです。
進捗把握も悩ましい問題です。ダムのようにできあがったモノを目視で確認できませんので、基本的にはメンバーからの進捗報告になります。半分入った酒の瓶を見て、もう半分になった、まだ半分あると同じものを見ても人によって受け取り方は様々です。進捗報告だけでなく、作成したプログラム行数やテスト完了件数など、計量できるもので把握できる体制を整えなければなりません。厳格なプロジェクト管理が要求されます。
ITベンダーだけの問題ではなく、発注側も対応が求められます。いままでのように途中で仕様を追加したり、仕様変更を求めても拒否されます。仕様をしっかり固めて発注しなければ、契約そのものが認められなくなります。またサブシステムに分解して短期契約にできないか検討することも求められます。
工事進行基準は絶対か？
工事完成基準ではシステム開発が終わらないと財務諸表に反映されませんが、工事進行基準は進行しているシステム開発の状況も含めて財務諸表に反映され、より企業実態にあっています。ただ懸念もあります。進捗状況で売上や原価を配分しますので、進捗状況に手心を加えるだけで売上や利益の数字操作が可能です。エンロン事件で不正経理が行われ、サブプライムローンの本質を見抜けなかったこともあり、アメリカでは国際会計基準（IFRS）に工事完成基準を採用すべきという意見もでています。
懸念もありますが、より企業実態にあった工事進行基準は時代の流れです。発注側、受注側双方が厳密にプロジェクト管理し、緊張感をもって契約していく業界に変えていかなければなりません。
