「納品した」「されてない」日通・アクセンチュア、開発頓挫の訴訟がエグ過ぎる

　日本通運が基幹システムの開発を委託していた外資系コンサルティング会社・アクセンチュアに対し、開発が失敗・中止となり債務不履行が生じているとして約125億円の損害賠償を求めて提訴している事案。10月1日付「日経クロステック」記事『日本通運・アクセンチュアのシステム開発訴訟、裁判資料を読んで胃がキリキリした』は、結合テストにおける納品と検収をめぐって両者が対立しながらやりとりする過程を報道。SNS上では、プロジェクトの結合テストの段階から当事者が訴訟に発展した際のことを念頭にやりとりを行っていた様子がみられるとして、

＜見えていたから用意してたんだろうな　アクセンチュア流石＞

＜この辺のリーガルの強さや先を見越した対応力は企業としてのガバナンスの強さを感じますね＞

＜チュアすげぇ＞

＜議事録と銘打たないでも、自分に非がない書き方でさらっと事実だけ並べておきたい。相手が特段異議を唱えないギリギリを狙う訓練は必要＞

＜議事録大事、深く同意します…＞

といった声が相次いでいる。結合テストにおいて納入物が納入されたのか、されていないのかで揉めるケースというのは多いのか。また、開発プロジェクトが頓挫する背景には何があるのか。専門家の見解を交えて追ってみたい。

ボタンの掛け違いが生じる原因

　前出「日経クロステック」記事によれば、結合テストの終了は当初の予定より1年も後ろ倒しとなったというが、ここまで大幅にシステム開発プロジェクトの進捗が遅れるというのは、どのような原因が考えられるのか。データアナリストで鶴見教育工学研究所の田中健太氏はいう。

「みずほ銀行の新勘定系システムのように、大規模な開発プロジェクトにおいて年単位で遅延が生じるという事態は、しばしば起こります。発注者側が『ベンダが開発したものが、ウチが要求したとおりになっていないので修正せよ』と注文し、ベンダ側は『ちゃんと要求されたとおりにつくっている』と主張し、認識の齟齬（そご）がどんどん積み重なることで遅延が生じるというケースが多いように思います。

　このようなボタンの掛け違いが生じる原因としては、発注者側が自社のシステムの内容や業務をきちんと把握していないがために、要件定義が不十分だったということが多いです。何年も前につくられたシステムの更改の場合、どのような中身になっていて、どのような機能があるのか、また、各部門の現場がどのような使い方をしているのかを発注者側がしっかりと認識・整理できていないままに要件定義が完了し、開発を進めていく中で次から次に把握していなかった機能が見つかるというかたちです。発注者側がそのような機能も実装するようベンダに要求し、ベンダ側は想定していない機能なので追加で工数・費用が必要ですよと主張し、両者の溝が深まっていきます」

　システム開発の失敗をめぐる裁判としては、NTT東日本が旭川医科大学に契約を解除されたため開発費用を受け取れなかったとして旭川医大に損害賠償を求めて提訴し、2017年、札幌高裁が旭川医大に100％の責任があるとして約14億1500万円を支払うように命じた事例がある（旭川医大は判決を不服として最高裁に上告したが、受理されず）。旭川医大がNTT東日本に対して再三にわたり追加開発を要求したことがプロジェクトの遅延と頓挫の原因となったとされる。

「2000年前後につくられたシステムが老朽化して一斉に更新のタイミングを迎える『2025年の崖』が注目されていますが、20年以上前につくられて誰も中身がわからずブラックボックスと化したシステムは一定数存在するとみられ、今回の日通のような事例は今後、増えていくと予想されます」（田中氏）

要件定義が8～9割方、左右する

　結合テストフェーズにおいて「納品物を納品した」「納品されていない」という点でベンダと発注元の間で認識の齟齬が生じるというケースは、よくあるものなのか。また、前出「日経クロステック」記事によれば、結合テストでの打鍵テストで大量の不具合が見つかったと日通側は主張しているとのことだが、結合テストフェーズで発注者が開発中のシステムの打鍵チェックを行い、発注者が不具合だと認識する部分が多数みつかり、不具合が修正されるまで発注者が検収を行わないというケースは、よくあるものなのか。

「あまりないケースといえます。結合テストフェーズでは、あらかじめ発注者とベンダがどのようなテストを行うのかというテスト項目・条件を取り決め、それに沿って進めるので、ベンダにとってみれば、それとは別に発注者が行う打鍵チェックに起因する事柄については、結合テストとは関係がない話です。なので納入は行ったと主張するアクセンチュアとしては、日通側が検収を完了しようがしまいが、もしくは納品されたという認識なのかどうかは関係なく、両者で取り決めたテスト項目については作業をすべて行ったので仕事は完了したという認識なのかもしれません。

　先ほどの話とも重なりますが、発注者が実装すべき要件をきちんと洗い出せていなかったために、テストフェーズで打鍵チェックをして『あれもない、これもない』と主張しても、それはテストとは別の話ということになります。プロジェクトがうまくいくかどうかは、要件定義が8～9割方、左右するといっても過言ではありません。今回の事例は、発注者とベンダのコミュニケーションがうまくいっていなかったプロジェクトの典型例ともいえます」

発注側とベンダの間で食い違う見解

　大手SIer社員も、今回の事例は非常に珍しいものだという。

「『日経クロステック』記事を読む限り、アクセンチュアは結合テストまで完了して成果物を納品したという見解なのに対し、日本通運は納品されていないという見解で、真っ向から食い違っています。アクセンチュアの主張によれば、日本通運は当初、検収を拒否したとのことですが、考えられるケースとしては、アクセンチュアは不具合だと考えていない部分を日本通運は不具合だと主張し、その点について合意に至らないまま納期を迎え、アクセンチュアは開発は完了したと主張し、日本通運は不具合が改修されていないので完了していないと主張しているというかたちです。部分部分について『これが不具合か、そうではないのか』をめぐり発注側とベンダ側の見解が食い違うというケースは珍しくないですが、大抵はベンダが発注側から言われるままに改修したり、追加費用の契約をして改修したり、改修不要としてそのままにしたりするので、納品が完了したかどうかという点で揉めるということは、あまり聞いたことがありません。

　テストフェーズでは通常、発注側とベンダの間でテスト項目や合否の基準を予め決めておくものなので、今回の事案ではその点がどうなっていたのかが気になります。要件定義や基本設計・詳細設計のフェーズで細かい各項目について合意していても、開発が進んでいくなかで発注側とベンダの間で『これは要件になかった追加項目ですよね？』『これは設計で決めた内容と違いますよね？』などと見解の食い違いが生じるもので、生じないプロジェクトなんてないといっていいくらいです。ベンダ側の詰めや確認が甘かったり、発注側が社内の各部門の要件をきちんとまとめきれていなかったりと、さまざまな原因があげられます。発注側のプロジェクトマネージャー（PM）やプロジェクトリーダー（PL）が社内の各部署の要件をしっかりと把握して、現状からの変更も含めてシステムと業務プロセスを策定して社内の合意を得て、それを正しくベンダに伝えるというのは、かなり大変な作業なので、発注側のPMにそのようなスキルがないと、プロジェクトがうまくいかないということになりがちです。

　日本企業の場合、メーカーだと製造部門や物流部門、銀行であれば支店や営業部門、物流企業であれば物流部門など、本業の現場の声や力が強いため、システム部門は力関係的に下になりがちなので、社内に言うことを聞かせにくいという点も、システム開発プロジェクトの障害としては結構大きかったりします。システム部門が本体から外出しされてシステム子会社になっていれば、なおさらです」（9月27日付当サイト記事より）

裁判所はどのように判断するのか

　過去には大規模システムの開発中止をめぐって発注元企業とベンダが訴訟に発展するケースもあった。野村ホールディングス（HD）と証券子会社・野村證券は10年、社内業務にパッケージソフトを導入するシステム開発業務を日本IBMに委託したが、作業が大幅に遅延したことから野村は開発を中止すると判断し、13年にIBMに契約解除を伝達。そして同年には野村がIBMを相手取り損害賠償を求めて提訴した一方、IBMも野村に未払い分の報酬が存在するとして約5億6000万円を請求する訴訟を起こし、控訴審判決で野村は約1億1000万円の支払いが命じられた。

　テルモは物流管理システム刷新プロジェクトが中止となり、14年に委託先ベンダのアクセンチュアを相手取り38億円の損害賠償を求めて提訴。また、12年に基幹系システムの全面刷新を中止した特許庁は、開発委託先の東芝ソリューション（現・東芝デジタルソリューションズ）とアクセンチュアから開発費と利子あわせて約56億円の返納金の支払いを受けることで合意している。

　システム開発が頓挫する場合、原因が発注元、ベンダのどちらにあるのかは判断が難しいが、損害賠償の金額というのは、裁判所はどのように判断するのか。山岸純法律事務所代表の山岸純弁護士はいう。

「システム開発やソフトウェア開発を業とするクライアントを持つ弁護士にとっては、開発が頓挫した場合の法的紛争について、長年、苦労しています。なぜなら、このような開発は、契約『時』には、“だいたいこんな感じのものを作ろう”という合意しかなく、契約『後』に、要件定義といった“何をつくるか”を少しずつ明らかにしていく作業が行われるという性質があるからです。これに対し、裁判の世界は、あくまでも契約『時』に遡り、当事者は契約『時』において、はたして“何を作る合意があったのか”“当事者は何をしたかったのか”を確定する作業であり、なかなか開発の現場の実態と合致しないところがあるからです。

　こういった紛争が長く続いてきたため、経済産業省や（独）情報処理推進機構は『システム開発等の標準契約書』を作るなどして、法的紛争を未然に防ぐ努力をしています。しかし、上記のとおり、どんなに契約書をしっかり作っても、法務部や顧問弁護士がしっかりしている大手の会社同士の契約であっても、今回のような法的紛争が避けられないのが、システム・ソフトウェア開発業界の特徴です。そして、たいていの場合、カネを出す発注者は、なるべく自分の要望を強く押し出してきますし、時に最初に希望していたモノと違うモノを欲したりもするので、仕事をもらうという弱い立場の開発側は、苦労することになるわけです。

　今回、日本通運は125億円の損害賠償を請求したとのことですが、今後、当事者間は裁判内で、契約『時』に“何を作る合意があったのか”“当事者は何をしたかったのか”“実際には、何が完成したのか”を確定する作業をしていくこととなります。その上で損害額を確定していくのですが、おそらくですが、『委託料』に相当する金額（システム開発として支払った金額）を損害賠償としたのでしょう。

　確かに、大金を支払って、ろくでもないモノが納められたなら、カネ返せと言いたくなるのは当然です。特に、システム開発は『ある用途』のために使えないことがわかれば無用の長物となるので（ほかに転用ができない）、払ったカネを返せという訴訟が定番となるわけです」

（協力＝山岸純弁護士／山岸純法律事務所代表、田中健太／データアナリスト、鶴見教育工学研究所）

●田中健太／データアナリスト、鶴見教育工学研究所
東京工業大学大学院　博士課程単位取得退学。ITベンダー系人材育成サービス企業で、研修開発、実施に従事。クラウド、IoT、データサイエンスなどトレンド領域で多数の教材作成、登壇。リサーチ会社でデジタルマーケティング領域のデータ分析に従事。アンケート、アクセスログ、位置情報、SNS等を組み合わせた広告効果の分析を行った。現在は、フリーランスとして教育の領域で活動。
鶴見教育工学研究所