物流大手の日本通運が、航空輸送事業におけるグローバル共通基盤の構築を目的に進めていた「新・国際航空貨物基幹システム」の開発失敗を巡り、開発ベンダーであるアクセンチュアを訴えていたことが日経クロステックの取材で分かった。以下ではアクセンチュアが提出した第1準備書面を基に、日本通運の主張に対する同社の反論を読み解く。
アクセンチュアが最重要争点として挙げるのは、結合テストの後半フェーズ「ITb」に関する債務の履行を完了したことだ。日本通運は訴状で「アプリケーション開発業務」など4件の個別契約が債務不履行になった結果、システムは完成せず基本契約書で締結した「システムの完成義務」に違反すると主張していた。
アクセンチュアは請負で締結された上記4件の個別契約について、債務を履行していると反論する。同社の主張によれば、請負契約において求められるのは「仕事の完成」だ。検収は「仕事の完成」とは独立した手続きであり、検査の合否は債務の履行・不履行とは関係しないとする。
アクセンチュアの主張によると、ITbの契約における「完成すべき仕事」とは、「合意された『シナリオ』及び『コンディション』に基づく検証作業であった」。シナリオとは業務フローに沿って策定されるシステムの確認単位、コンディションとはシナリオに従ってシステムを動作させることで検証される細かな画面や帳票の動きのことを指す。
同社は全てのシナリオ及びコンディションに基づく検証、バグの修補も完了した上で、ITbの成果物を提出したと主張する。
打鍵チェックと検収は別プロセス
「納品」後も両者間で応酬が続いた。アクセンチュアの主張によると、日本通運はアクセンチュアがITbの成果物を納入したこと自体を否認。ITbと並行して実施した「打鍵チェック」における指摘事項は請負契約上対応すべき「不具合」であり、一定対応を行うまでは検収を開始しないと強硬に主張した。
アクセンチュアは日本通運が「ITbと打鍵チェックを混同」していると指摘する。アクセンチュアによれば、ITbの成果物は当初、同社が「ユーザ向けデモ」を実施して日本通運が確認・検収することを提案していた。しかし、日本通運はこれを拒否。同社の社員が実際に開発中のアプリケーションを直接動作させる「打鍵チェック」を実施したいと強く主張した。
打鍵チェックの目的は、開発途中の品質チェック及び日本通運からのフィードバックを受けて両者間のイメージが乖離（かいり）しないようにすることであり、日本通運が並行して進めていたITbとは無関係とアクセンチュアは主張する。すなわち、打鍵チェックはITbの成果物の完成基準でもなければ、日本通運が検収を実施するための前提条件でもないとする。
打鍵チェックの対象となったシステムはITb完了前のものになる。しかも打鍵チェックのスコープやシナリオは日本通運が決定し、ユーザー受け入れテストに近い態様だったという。アクセンチュアは「ユーザたる原告（日本通運）の視点からは、『大量の障害』が『検知された』ように映ったようである」とする。
