物流大手の日本通運が「新・国際航空貨物基幹システム」の開発が失敗したことをめぐって、システム開発を進めていたアクセンチュアを訴えたという報道がありました。損害賠償額が約124億9100万円と、とても大きな金額になっていることが、とても衝撃的です。日経XTECHの報道を読んでいると、経緯は下記のようになっているようです。
- 開発プロジェクトはテスト工程から遅延
- 当初2020年12月の予定だった結合テストの後半過程「ITb」の終了は2021年11月に遅延
- アクセンチュアがITbの「成果物」を共有サーバーにアップロードしたのは2021年11月30日
- 日本通運は先立って実施した「打鍵テスト」で大量の指摘事項が挙がっていたことなどから、品質を問題視
- 成果物の検収を巡り、両者の主張は至るところで対立
両者間で成果物の検収を巡って対立しているのですが、よく判らないことがあります。
通常のシステム開発では、要件定義、基本設計、詳細設計を通じて、システムで実現する機能を具体化して発注者とのレビューを通じて仕様を凍結します。
以降の製造や試験(テスト)は、設計工程完了時に合意された仕様が実現するように製造しテストが行われます。システム(プログラム)が完成し納品する時点では、設計工程完了時点で合意した仕様のシステム(プログラム)ができていることがマストです。
もしも、ITbが終わり、発注者にプログラム等が納品されていたとしても、納品されたものが合意した仕様と違っていた場合は、業者に修正を求めることが普通だと思います。
日経XTECHの記事を読んでいても、ITbと打鍵テストの位置付けに関する両社の考えの違いに焦点があたっていて、元々の合意された仕様と納品物の差異に関する論点が取り上げられていなかったことがとても不思議でした。
- 日本通運・アクセンチュアのシステム開発訴訟、裁判資料を読んで胃がキリキリした | 日経クロステック(xTECH) (nikkei.com)
- 日本通運によるアクセンチュア提訴、コミュニケーションロスの真の原因と求められる協力姿勢 | 日経クロステック(xTECH) (nikkei.com)
システム開発ではときどき発生するのですが、要件定義や設計工程でなかなか仕様を詰め切れずに、凍結された仕様が曖昧な状況になってしまっているのでしょうか。詳しいことはもう少し開示された情報を探して勉強したいと思います。
コメント