企業にとって基幹システムの刷新やクラウド移行は、経営を左右する大きなプロジェクトです。
しかし、計画の遅延や品質不良が深刻化すると、最終的には裁判で争われるケースも少なくありません。

本記事では、実際にあった訴訟事例をご紹介し、裁判の争点と判断ポイント、トラブルへの対策を解説していきます。

主な訴訟事例

システム開発をめぐるトラブルは珍しいことではなく、業種や規模を問わず発生しています。
場合によっては数十億円規模の損害賠償請求に発展し、判決が確定すれば企業の経営やブランド価値に大きな影響を及ぼします。

ここでは、実際に裁判に至った事例を取り上げ、トラブル発生の背景や裁判で争点となったポイントを整理します。

金融機関システム開発訴訟　（開発者側の責任）

某金融機関は、勘定系基幹システムを刷新するため、大手システム開発会社と契約を結びました。
契約額は約40億円規模で、当初は数年以内の稼働を予定していました。

しかし、要件定義が曖昧な状態で開発がすすめられたことや、進捗管理の不備などにより、遅延が続き、最終的にはプロジェクトの中止に至りました。

発注者（金融機関側）は、すでに支払った30億円超の費用と、開発中止に伴う損害賠償を求めて訴訟を起こしました。

主な争点

プロジェクトマネジメント義務

開発会社が専門家として、進捗管理やリスク把握を徹底し、中止提言を行う責任があったか

要件定義の不備

要件定義が曖昧なまま進められたことで、大幅な遅延と品質低下が起き、その責任はだれが負うか

契約形態と責任範囲

請負契約か準委任契約のどちらに当たるか

請負は成果に、準委任は作業に責任があり、この解釈によって開発会社が負う責任範囲が左右される

裁判所の判断と判決

裁判所は、開発会社が専門家としてプロジェクトを管理し、進捗やリスクの把握・是正を行う義務があるとしました。

また、発注者の要望が曖昧な場合でも、それを整理し具体的な要件へと落とし込み、現実的な設計へ結び付ける責任を負うと判断しました。

契約の性質については、成果物を完成させる責任と不具合を修補する義務を伴う「請負」に近いと解釈し、開発会社の責任は重いとしました。

これらを踏まえ、裁判所は開発会社が専門家としての義務を怠り、かつ請負契約としての成果責任を負う立場にあると認定した上で、約40億円の損害賠償を開発者側に命じました。

医療機関情報システム開発訴訟　（発注者側の協力義務違反）

ある医療機関は、電子カルテを含む病院情報システムを導入するため、大手システム開発会社と契約を結びました。
しかし、仕様を確定した後にも医療機関から多数の追加要求が出され、設計変更や追加開発が相次ぎ、開発は停滞しました。

最終的にシステムは完成に至らず、発注者側が「開発会社の遅延や不具合が原因」として訴訟を起こしました。

これ対し開発会社は、発注者が仕様確定後に大量の追加要求を行ったことが開発を妨げたとして、反訴しました。

主な争点

協力義務の是非と協力義務違反

発注者にプロジェクトへ協力する義務があるのか、そしてその義務を実際に遂行していたのか

仕様変更と変更管理

正式な手続を経ず追加要求を繰り返した点の契約上の扱いと停滞への影響

裁判所の判断と判決

まず裁判所は、発注者側にプロジェクトを円滑に進めるための協力義務があると認めました。
本来であれば「影響評価 → 承認 → 契約変更」といった正式な変更管理手続きを経るべきところ、発注者がこれを行わずに追加要求を重ねたことが、開発工程に混乱を招いたと判断しました。

こうした不適切な仕様変更は協力義務違反に当たり、開発停滞の主要な原因になると認定されました。

これらを踏まえ、裁判所は発注者側に十数億円規模の損害賠償を命じました。

裁判所が重視する判断ポイント

日常の業務で当たり前に行っていることが、裁判では大きな争点になります。

裁判所がどのような部分を重視して判断するのかを理解しておくことは、日々のプロジェクト管理にも役立ちます。

ここでは、裁判所が重視する代表的な判断ポイントについて解説していきます。

契約形態と責任範囲

システム開発の契約は大きく請負契約と準委任契約に分かれます。

裁判所は契約書の表記だけでなく、実際の開発の進め方や契約条項の内容を見て「請負か準委任か」を判断します。
準委任として始めたつもりでも、検収基準や支払い条件から「請負に近い」と認定されるケースも少なくありません。
また、工程ごとに契約形態が異なる場合には、より判断が複雑になります。

請負契約と認定されると、開発者は成果物に対しての完成責任を負うことになり、未完成や重大な不具合があった場合には、多額の賠償金額を命じられることになります。

プロジェクトマネジメント義務

プロジェクトマネジメント義務とは、開発会社が単なる作業者ではなく、専門的知識を持つ事業者＝専門家として、業務を進めるすべての工程に対して管理をする責任を指します。
これは民法上の「善管注意義務」を基盤に、判例で認められてきた「専門家責任」として位置づけられます。

そのため、開発会社は成果物だけでなく、進捗・品質・リスクを管理し、是正・再計画・中止提言までを主導する義務があり、プロジェクトを先導する必要があります。

曖昧なWBSの作成・管理や楽観的な再見積、要件・スコープ整理の怠慢、発注者へのリスク警告や改善提案を適切に行っていたかどうかが、裁判で争点となることが多いです。

発注者の協力義務

発注者には、プロジェクトを円滑に進めるために必要な協力を行う義務があると解釈されることがあります。

例えば、仕様確定後の頻繁な追加要求、必要な資料の提供遅延や不備、決裁・承認・レビューに対する応答遅延などは、協力義務違反と評価される可能性があります。

開発会社側の遅延だと主張していても、実際には発注者のこうした要求や対応の遅れが原因で停滞しているケースも少なくありません。
裁判で発注者の協力義務違反が認定されれば、過失相殺による賠償額の減額や、場合によっては発注者に対して賠償を命じられることもあります。

検収と成果物の完成基準

検収とは、発注者が成果物の仕様・品質を満たしているかを確認し、正式に受領する手続きのことです。
このとき、成果物の完成基準が契約で明確に定められているかどうかが重要になります。

完成基準が曖昧だと、後に「完成していたか否か」が訴訟の大きな争点となります。
重大な欠陥や機能の不一致がある場合には、検収自体が無効と判断されるケースもあります。

検収が有効と認められれば「完成した」と扱われるため、開発会社の賠償範囲は限定されます。
一方で、無効と判断された成果物は「未完成」とされ、開発会社の責任は重くなり、賠償範囲が広がる可能性があります。

訴訟に至る典型的な原因と対策

訴訟に発展したシステム開発に例を見ると、原因は特別なものではなく、日常のプロジェクトで小さな不備が重なった結果がトラブルに発展することが多いです。

ここでは、典型的な原因とその対策について簡単にご紹介します。

要件定義の不備と契約内容の曖昧さ

• 原因　要件が曖昧な開発を始めたことで手戻りが発生し、追加費用や納期遅延が深刻化
  　　　契約形態が不明確で、完成責任や成果基準が曖昧になる
• 対策　要件と契約形態を文書化し、双方の合意と署名を取る

プロジェクトマネジメントの不備

• 原因　進捗・品質・リスク管理が甘く、遅延や不具合のが是性されなかった
• 対策　WBSやリスク台帳を整備し、定期的なレビューや進捗確認を行う

仕様変更と変更管理の不徹底

• 原因　仕様確定後に発注者が追加要求を繰り返し、開発の遅延・中止が起こる
• 対策　正式な変更手続きを作成し、影響評価・承認・契約変更を明確化する

---

このような日常の管理業務の曖昧さが原因で、訴訟に発展するケースが多く見られます。

要件定義やプロジェクトの徹底管理を行うことが最大の予防策となります。

まとめ

システム開発の訴訟は、経営やブランド価値を揺るがす大きなリスクであり、数十億円規模の賠償に発展することもあります。

裁判の主な争点は、契約形態やプロジェクトのマネジメント義務、発注者の協力義務などがあり、裁判所もこれらの点を重視して判断を下しています。

訴訟を起こさないためには、要件定義を明確にし、マネジメント業務を徹底することが最大の対策になります。
日々の業務を丁寧に行い、基本を確実に積み重ねることで、訴訟リスクを最小限に抑えていきましょう。

SELECTOでは、開発だけでなく要件定義からのご相談や、要件定義のみの依頼も承っております。
要件定義についてお困りの方は、お気軽にご相談ください。