unnamed
2022年10月、東京高等裁判所はある判決を確定させた(東京地判令4.2.24・東京高判令4.10.5〔令4ネ2390〕) 。学習塾大手のZ会が、基幹システムの開発を委託した日立ソリューションズを訴えた裁判だ。原因は夜間バッチ処理(夜間にまとめてデータの自動処理を行うこと)が終わらないというシステム障害。

Z会は、すでに支払った開発費用の返還(原状回復)として約20億円、これとは別に損害賠償として約7億円、合わせて約27億円を求め、そして勝訴した。ただし、実際に支払われたのは約11億円(Z会公式発表) 。既払金の返還請求だけで見ても、その半分近くが、契約書のある一文によって消えた(東京高判令4.10.5〔令4ネ2390〕、伊藤雅浩弁護士「IT・システム判例メモ」より)。

世間はこれを「Z会が勝訴した裁判」として見ている。だが私は、この裁判の本当の教訓は勝敗にはないと考えている。既払金20億円を請求して11億円しか取れなかったことより、そもそも訴訟にまで発展したこと自体が、このプロジェクトの失敗を何より雄弁に物語っている。

私は、成功報酬のみでシステム開発を手がける会社を経営して約20年、エンジニアとしてのキャリアは30年になる。この立場から言わせてもらうと、システム開発の世界で「訴訟になる」というのは、勝ち負け以前の話だ。すでに詰んでいる。なぜそう言えるのか? また、そうならないために契約前に打てる手立てについて考えてみたい。

■そもそも、何を買っているのか
多くの発注担当者は、システム開発を「モノを買う」感覚でとらえている。仕様書に書いた通りのものが、決めた金額で、決めた期日に納品される。そう思って契約書にハンコを押す。

しかし請負契約が発注者に保証しているのは、突き詰めれば「完成したものを引き渡す義務」であって、途中経過の質までは保証していない。仕事は仕事として進み、対価は発生する。仕様と食い違っていても、遅れていても、開発会社側には「やるべきことはやった」という言い分が常に残る。だからこそ揉める。

そしてこの揉め方は、契約書を隅々まで読んでいても防げない。仕様書を交わした時点では、双方とも「合意していた」つもりでいるからだ。

Z会のケースがまさにそれだった。契約は交わされ、開発は進み、そして障害が起きてから初めて、双方の認識のズレが表面化した。契約書にあった責任制限条項――損害賠償の上限を契約金額までとする一文――は、契約時点では誰も本気で意識していなかったはずだ。それが、いざ訴訟になった瞬間、既払金の返還請求20億円を11億円まで削る力を持った。

■800万円の案件で起きていたこと
これは大企業だけに関係する話ではない。むしろ深刻なのは中小企業のほうだ。

私が相談を受けたある会社は、あるシステムの開発を約800万円で発注した。納品されたものは仕様通りに動かず、開発会社に何度掛け合っても改善されない。最終手段として弁護士経由で内容証明を送った。それでも相手は無視した。

訴訟という選択肢も検討したという。だが弁護士費用と時間を考えると、回収できる見込み額と釣り合わない。結局その会社は、泣き寝入りするしかなかった。

Z会は既払金20億円を請求して11億円を取り返せた。 800万円の案件では、それすら選べなかった。この差は「相手が悪質かどうか」の差ではない。訴訟という手段そのものが、案件の規模によっては最初から機能していないという、身も蓋もない現実の差だ。

■「訴訟になった時点で負け」の意味
ここまでの2つの事例に共通するのは、揉めごとが表面化した時点――システム障害が起きた時点、あるいは納品物が仕様と違うと分かった時点――で、すでに手遅れになっていたという点だ。

訴訟というのは、揉めた後にどちらがより多く取り返せるかを争う場でしかない。プロジェクトを成功させる手段では、そもそもない。Z会が11億円しか取れなかったのも、800万円の案件が泣き寝入りに終わったのも、原因は同じところにある。契約から開発の途中まで、発注側とベンダー側の間に、どちらの利害からも独立した第三者の目が一度も入っていなかったことだ。

医療の世界でセカンドオピニオンが当たり前になったのは、当事者である患者と主治医の間だけでは判断が偏りうると分かっているからだ。システム開発でも構造は同じはずなのに、この発想はまだほとんど浸透していない。

「そうは言っても、契約書さえきちんと確認すれば防げるのでは」と思う人もいるだろう。だが実際には、Z会ほどの規模の会社でさえ、契約書の責任制限条項の重みを訴訟が起きるまで正しく認識できていなかった。契約書を読むという行為そのものが、トラブルを防ぐ決め手にはならない。読んでも気づけない危険信号があるからだ。

■事後に取り返す発想を捨てる
私が中小企業の経営者に伝えたいのは、訴訟に強くなる方法ではない。訴訟という選択肢に頼らずに済む状態を、契約前・契約中につくっておくという発想の転換だ。

要件定義の段階、あるいは開発の途中の節目で、発注側にもベンダー側にも属さない専門家の目が一度入るだけで、認識のズレは早い段階で表面化する。表面化すれば、訴訟という最終手段まで行き着く前に軌道修正ができる。

Z会の11億円も、800万円の泣き寝入りも、起きてから対処しようとした結果だ。起きる前に第三者の目を入れるという、たったそれだけのことができていれば、どちらの結末も違っていたはずだ。


久保田一 株式会社VERVE代表取締役


【関連記事】
■システム開発の契約内容、ちゃんと理解できていますか?認識違いで追加費用1200万も、防ぐ簡単な方法は (久保田一 エンジニア)
https://sharescafe.net/63378932-20260730.html
■大企業でも頻発するシステム開発の「爆死」―背景にあるIT業界の無責任な構造とは? (久保田一 経営者)
https://sharescafe.net/63338517-20260713.html
■ 「科研費倍増」で日本の研究力は本当に戻るのか?(九条丈二 社会制度・政策研究者)
https://sharescafe.net/63455692-20260902.html
■110万円の家賃を払う板野友美さんとヤクルト高橋奎二さんの判断が正しい理由。(中嶋よしふみ ファイナンシャルプランナー)
https://sharescafe.net/62674731-20250930.html
■世帯年収1560万円の共働き夫婦は、9540万円の湾岸タワーマンションを買えるのか? その1・生活費は800万? (中嶋よしふみ ファイナンシャルプランナー)
https://sharescafe.net/61186482-20240125.html


■プロフィール 久保田一 株式会社VERVE代表取締役
kubota
エンジニア歴約30年。GMOメディア株式会社で開発部長を務めた後、独立して約20年。成功報酬のみで業務改善・システム開発を行う株式会社VERVEを経営し、中小企業・スタートアップ向けに要件定義から実装・運用まで一気通貫で支援している。2026年6月に「中小企業はなぜDXできないのか?」を出版。

公式サイト https://verve-inc.jp/
X https://x.com/vervekubo @vervekubo
note https://note.com/innovations_hk @innovations_hk

この執筆者の記事一覧

このエントリーをはてなブックマークに追加
シェアーズカフェ・オンラインからのお知らせ
■シェアーズカフェ・オンラインは2014年から国内最大のポータルサイト・Yahoo!ニュースに掲載記事を配信しています
■シェアーズカフェ・オンラインは士業・専門家の書き手を募集しています。
■シェアーズカフェ・オンラインは士業・専門家向けに執筆指導を行っています。
■シェアーズカフェ・オンラインを運営するシェアーズカフェは住宅・保険・投資・家計管理・年金など、個人向けの相談・レッスンを提供しています。編集長で「保険を売らないFP」の中嶋が対応します。