１．経緯
2023年1月に日本通運（NXグループ）が進めていた
「新・国際航空貨物基幹システム」の開発は中止となり、
約１５４億円の減損損失を計上する
開発ベンダーの アクセンチュアに約１２４億円の損害賠償を求める
プロジェクトの規模は約１２３億円、アクセンチュアの受託規模は約３５億
当初は開発期間は2017年4月～2020年7月
契約形態は受託契約を前提としたいわゆるSI契約
２．SI契約の問題点
SIerにとって極めてリスクが高い契約形態
SIerは成果物をスケジュール通りに完成させる義務、
契約で定められた通りに成果物が機能することを保証する
SIerは要件定義が詳細化する前に概算見積を出す
プロジェクトの事実上の上限額となる場合が多い
もし、超過した場合はSIerとユーザー企業の間で厳しい交渉を行う
要件定義が詳細化する前に正しい見積を作成するのは難しいが
ユーザー企業の予算を確保のため、このような商慣習となっている
米国では委任形態の契約が主流
「準委任の工数型」に近い
工数が増加すれば、ユーザーが負担する
３．開発規模による難易度
中小規模プロジェクト
約２億円～３億円の規模、最大で約２０人体制
サブシステム単位で構築されることが多い
PMは、要件定義からテストを実施して内容を把握し、チームを率いる
統合テスト（ＩＴ）の終了が納品に相当し、検収を経てリリースとなる
大規模プロジェクト
約２０億円～３０億円規模、最大で１００人体制
PMをチームリーダーとする複数チームから構成される
チームリーダーには中小規模プロジェクトを統括するスキルが求められる
５～１０以上のサブシステムから構成される
ユーザー企業の部門全体で利用するITシステムが対象となる
サブシステム間で共通のデータベース制御、は障害対応など
ITシステムの運用の共通化、
ITシステムを動かすために必要な機能の設計・開発が必要となる
「非機能要件」を整理して、実現可能な設計をし、開発する
方式設計とシステム基盤開発を実施することも求められる
総合テスト（ＳＴ）の実施で一定の品質に達したと判断した上で
ユーザー受け入れテスト（UAT）を実施し検収する
超大規模プロジェクト
約１００億円規模、最大で千人超の体制
難易度は大規模プロジェクトよりもさらに増す
一括してリリースするのは難しいため、
機能システム単位で順次リリースする
新旧の機能システムを併存させながら徐々に移行する
機能システム間の整合性確認のため、
STの次に機能システム間テストを実施する
部門間をまたがるため、CEOの参加が必須となる
４．現行機能の保証
既存の機能が開発の影響を受けずに正常に動作することを保証する
自社の業務内容を正確に把握しておらず、業務要件を定義できない
現行機能を保証することは、言葉以上に難しい
既存システムの機能を整理する場合
新たなベンダーにシステム開発を依頼する場合は、
ユーザー企業が既存機能を整理し、最適な設計になっているかどうかを
ユーザー企業がレビューする
そのためには既存のSIerの協力を得る必要があるが、
SIerを変更する場合は何らかの不満が大きくなったというケースが多い
ユーザー企業と既存SIerとの関係は良く無く、協力が得られない
ユーザー企業の従業員は自社で実施している業務を「知らない」
SIerはユーザー企業の従業員よりも業務に詳しくなっていく
必要最低限の修正ドキュメントが断片的に残されるだけ
上書きされた修正ドキュメントから現在の業務要件は読み取れない
現行プログラムを分析すると、「何をしているか」の情報は見付けられる
「何のために動いているのか」に関する情報はない
プログラムの分析によって判明する業務仕様は要件の一部にすぎない
「現行機能保証」を求められたケースがトラブルの主要な原因になる
５．「ITb」の位置付け
日本通運の訴状
「アプリケーション開発業務」など4件の個別契約が債務不履行
システムは完成せず「システムの完成義務」に違反する
アクセンチュアの反論
請負契約において求められるのは「仕事の完成」
検収は「仕事の完成」とは独立した手続きであり、
検査の合否は債務の履行・不履行とは関係しない
請負で締結された上記4件の個別契約について、
債務を履行している
ITbの契約における「完成すべき仕事」とは、
「合意された『シナリオ』及び『コンディション』に基づく検証作業
シナリオとは業務フローに沿って策定されるシステムの確認単位、
コンディションとはシナリオに従ってシステムを動作させることで
検証される細かな画面や帳票の動きのことを指す
全てのシナリオ及びコンディションに基づく検証、バグの修補も完了した
ITbの成果物を提出した
打鍵チェックと検収は別プロセス
アクセンチュアの主張
ITbの成果物を納入したこと自体を否認
日本通運の主張
ITbと並行して実施した「打鍵チェック」における指摘事項は
請負契約上対応すべき「不具合」であり、
一定対応を行うまでは検収を開始しない
ITbへの取り組み
アクセンチュアは
ITbの成果物は当初、「ユーザ向けデモ」を実施し
日本通運が確認・検収することを提案する
日本通運は
上記提案を拒否
日本通運の社員が開発中のアプリケーションを直接動作させ
「打鍵チェック」を実施したいと強く主張する
打鍵チェックの目的
アクセンチュアの主張
開発途中の品質チェック及び日本通運からのフィードバックを
受けて両者間のイメージが乖離しないようにすることであり、
日本通運が並行して進めていたITbとは無関係
打鍵チェックはITbの成果物の完成基準でもなければ、
日本通運が検収を実施するための前提条件でもない
打鍵チェックのスコープやシナリオは日本通運が決定し、
ユーザー受け入れテストに近い態様だった
第三者としての見解
遅れが生じていたと思われるので
ユーザー側は早めにバグ出しを行いたいので、
ITb期間中に並行して打鍵テストと称して実施した
内容は検収に近い形となる
ITb期間中に検収を行えば不具合いが出るのは当たり前
ITaが終了してるとはいえ、打鍵テストは時期尚早の感がする
相互のコミュニケーションが悪かったのではないか
開発側の不手際を一気に洗い出すには打鍵テストしかない
シナリオテストの用意は進捗遅れには関係なくできていたと思われる
打鍵テストではなく仕様レベルでのレビューしかない
双方とも手戻り感もあり、工数も必要になるので実施は困難
この壁を乗り越える「力」が欠けていたのではないか
６．プロジェクト失敗の原因
テスト工程について
一般的に超大規模に準じる大規模プロジェクトならば
STを終了した時点で、作り手は品質を保証する
今回のプロジェクトの場合、「ITb」を最終テスト工程としている
結合テストの終了がSTの終了として位置付けられている
プロジェクトの遅れを一気に取り戻そうとしたと思われ
ITbとSTを並行実施する苦肉の策を取ったのではないか
SIerとユーザー企業がどのような責任分担で契約したかによって、
アクセンチュアに対して責任を問えるかどうかが決まるだろう
７．今回のテストについて
ITbだけが実施され、STはアクセンチュアの責任としては実施されなかった
この場合、ユーザーの指摘のみに対応することになる
自ら開発していないサブシステム間の整合性を確認することは、
ベンダーにとって極めて困難であり、失敗する可能性が高い
「ITb」のテスト内容
日本通運が「打鍵テスト」を実施し、
「1487件の不具合を検出した」とされている
「1487件」（アクセンチュア資料では「2031件」と記載）の内容
全体で少なくとも1400件以上のバグが検出されたと推測される
開発規模が100万stepsだとSTでのバグ総数は200～300件程度
ST相当のテストとした場合、品質は「極めて悪い」
IT相当のテストとした場合、ITとしての品質も不十分
『ユーザー受入テスト』ではなく、ITbから顧客が参加するのは過剰だ
完成のためには、早く問題を把握し対応することが必須だが
ITaの完了基準をどこに設定したかにもよるが
設定基準をクリアしていれば顧客が参加しても良いのでは
要件定義が固まっていないまま早い段階で
ユーザーがテストに参加すると、テスト後に要件変更が多発する
基盤SEが業務仕様から必要な仕組みを洗い上げ、
過去の経験を踏まえて必要な処理方式を設計する必要がある
基盤SEは大規模プロジェクトには必須の人材
また、方式設計の工程と基盤技術者もやはり必須
８．まとめ
受注側に十分なケイパビリティが備わっていたかどうかは疑問が残るところ
発注側は受注側の諸条件をどこまで認識していたかも問われる
「丸投げ」を前提としていたら、致命的な条件を受け入れていたことになる