日本通運が基幹システムの開発を委託していた外資系コンサルティング会社・アクセンチュアに対し、開発が失敗・中止となり債務不履行が生じているとして約125億円の損害賠償を求めて提訴している事案。10月1日付「日経クロステック」記事『日本通運・アクセンチュアのシステム開発訴訟、裁判資料を読んで胃がキリキリした』は、結合テストにおける納品と検収をめぐって両者が対立しながらやりとりする過程を報道。SNS上では、プロジェクトの結合テストの段階から当事者が訴訟に発展した際のことを念頭にやりとりを行っていた様子がみられるとして、
<見えていたから用意してたんだろうな アクセンチュア流石>
<この辺のリーガルの強さや先を見越した対応力は企業としてのガバナンスの強さを感じますね>
<チュアすげぇ>
<議事録と銘打たないでも、自分に非がない書き方でさらっと事実だけ並べておきたい。相手が特段異議を唱えないギリギリを狙う訓練は必要>
<議事録大事、深く同意します…>
といった声が相次いでいる。結合テストにおいて納入物が納入されたのか、されていないのかで揉めるケースというのは多いのか。また、開発プロジェクトが頓挫する背景には何があるのか。専門家の見解を交えて追ってみたい。
前出「日経クロステック」記事によれば、結合テストの終了は当初の予定より1年も後ろ倒しとなったというが、ここまで大幅にシステム開発プロジェクトの進捗が遅れるというのは、どのような原因が考えられるのか。データアナリストで鶴見教育工学研究所の田中健太氏はいう。
「みずほ銀行の新勘定系システムのように、大規模な開発プロジェクトにおいて年単位で遅延が生じるという事態は、しばしば起こります。発注者側が『ベンダが開発したものが、ウチが要求したとおりになっていないので修正せよ』と注文し、ベンダ側は『ちゃんと要求されたとおりにつくっている』と主張し、認識の齟齬(そご)がどんどん積み重なることで遅延が生じるというケースが多いように思います。
このようなボタンの掛け違いが生じる原因としては、発注者側が自社のシステムの内容や業務をきちんと把握していないがために、要件定義が不十分だったということが多いです。何年も前につくられたシステムの更改の場合、どのような中身になっていて、どのような機能があるのか、また、各部門の現場がどのような使い方をしているのかを発注者側がしっかりと認識・整理できていないままに要件定義が完了し、開発を進めていく中で次から次に把握していなかった機能が見つかるというかたちです。発注者側がそのような機能も実装するようベンダに要求し、ベンダ側は想定していない機能なので追加で工数・費用が必要ですよと主張し、両者の溝が深まっていきます」
システム開発の失敗をめぐる裁判としては、NTT東日本が旭川医科大学に契約を解除されたため開発費用を受け取れなかったとして旭川医大に損害賠償を求めて提訴し、2017年、札幌高裁が旭川医大に100%の責任があるとして約14億1500万円を支払うように命じた事例がある(旭川医大は判決を不服として最高裁に上告したが、受理されず)。旭川医大がNTT東日本に対して再三にわたり追加開発を要求したことがプロジェクトの遅延と頓挫の原因となったとされる。
「2000年前後につくられたシステムが老朽化して一斉に更新のタイミングを迎える『2025年の崖』が注目されていますが、20年以上前につくられて誰も中身がわからずブラックボックスと化したシステムは一定数存在するとみられ、今回の日通のような事例は今後、増えていくと予想されます」(田中氏)