「動かないシステムに費用を払えと請求が来た」「逆に、納品物を検収しないまま使われていて支払いを拒否されている」——システム開発の訴訟トラブルでは、双方が「相手が悪い」と主張する構図が典型です。本記事では実際に紛争に発展した4つの典型パターンと、契約書の4項目を最初に整えておけば防げたという視点を経営者向けに整理します。
この記事の結論（3行）
- 訴訟トラブルの大半は「検収条項」「成果物責任」「遅延損害金」「知財帰属」の4項目の曖昧さが原因
- 訴訟に進むと解決まで1〜2年、弁護士費用だけで200〜500万円が乗る
- 多くのケースは契約書を整え直しておくだけで、訴訟前の和解で済む
なぜシステム開発で訴訟トラブルが起きやすいのか
システム開発はソフトウェアという「目に見えない成果物」を扱うため、契約段階での合意形成が難しい特徴があります。物理的な製品なら「届いた・届かない」「動く・動かない」が明確ですが、システムは「何をもって完成とするか」の定義が曖昧になりがちです。訴訟トラブルが起きやすい背景は3つあります。
- 「完成」の定義が契約書に書かれていない
- 追加要求の扱いが不明確で「言った・言わない」になる
- 成果物の品質責任の範囲が定義されていない
この3つを契約段階で整えるだけで、トラブル発生率を大きく下げられます。逆に整えずに発注すると、紛争になった瞬間に弁護士同士の解釈論争に発展します。中小企業の経営者は法務部を持たないケースが多く、ベンダーが提示した契約書のひな形に署名するだけで終わってしまう傾向があります。この習慣を改め、最低でも検収・成果物責任・遅延損害金・知財の4項目だけは経営者自身がチェックする運用に切り替えてください。
「完成」の定義が契約書に書かれていない
「動くシステムを納品する」とだけ書かれた契約書では、何をもって完成かが分かりません。発注者は「業務で使える状態」を想定し、ベンダーは「契約書記載の機能が動作する状態」を想定する——この認識ギャップが、検収を巡るトラブルの根本原因です。検収条件を「テストケースの何%が合格すれば完成」のような形で明文化していないと、必ず揉めます。
追加要求の扱いが不明確
開発中に発注者から「この機能も追加したい」「ここはこう変えたい」という要望が出るのは自然なことですが、その扱いが契約書に書かれていないと「サービスでお願いします」「いえ、別途見積もりです」の押し付け合いになります。後から訴訟になると、追加要求のメール・議事録を1つずつ証拠として整理する作業に膨大な時間がかかります。
成果物の品質責任の範囲が不明確
リリース後にバグが見つかった場合、無償で対応する範囲・期間・対象がどこまでかを定義していないと、揉めます。「契約不適合責任」の規定だけで対応しようとすると、解釈論争になります。瑕疵担保期間・対象範囲・対応方法を契約書で明示しておく必要があります。
システム開発訴訟の典型4パターン
実際に訴訟まで発展したシステム開発トラブルを、典型4パターンに整理します。
| パターン | 主な原因 | 双方の主張 | 解決までの期間 | |---|---|---|---| | 検収拒否型 | 完成定義の曖昧さ | 発注者「動かない」vs ベンダー「契約範囲は完了」 | 1〜2年 | | 追加費用型 | 追加要求の扱い不明確 | 発注者「契約範囲内」vs ベンダー「追加費用が必要」 | 6か月〜1年 | | 遅延損害型 | 遅延損害金の規定なし | 発注者「業務遅延の損害賠償」vs ベンダー「発注者起因」 | 1〜2年 | | 知財帰属型 | 著作権帰属の曖昧さ | 発注者「成果物の権利は当社」vs ベンダー「再利用権あり」 | 6か月〜1年 |
4パターンとも、契約書の該当条項を最初に整えておけば、訴訟前に解決できた論点ばかりです。発注前に契約書を点検したい経営者の方は、業務改善・システム見積もりAI適正診断で論点整理から始める流れがお勧めです。
パターン1：検収拒否型（完成定義の曖昧さ）
最も件数の多いパターンです。ベンダーは「契約書記載の機能は全て実装した」と主張し、発注者は「業務で使える状態になっていない」と主張する構図です。検収条件が「テストケースの90%以上合格」「主要業務シナリオが完遂可能」のような数値・行動ベースで定義されていれば、判定が明確になります。逆に「業務で使える状態」という抽象表現だけが書かれている契約書では、判決まで進んでも双方納得できる結論が出にくくなります。
パターン2：追加費用型（追加要求の扱い不明確）
開発中の追加要求が積み上がり、ベンダーから請求された追加費用を発注者が拒否するパターンです。「軽微な変更は契約範囲内、月20時間を超える変更要望は別途見積もり」のような線引きが契約書にあれば、判定が容易です。線引きが書かれていない場合は、メール・議事録に残っている「追加要求」のやり取りを1件ずつ証拠として整理する必要が生じ、解決まで半年以上を要するのが一般的です。
パターン3：遅延損害型（業務遅延に対する損害賠償）
ベンダーの納期遅延により発注者の業務に損害が出た場合、損害賠償の請求を巡って紛争になります。遅延損害金の規定（例：契約額の0.1%/日、上限契約額の10%）が契約書にあれば、賠償額の算定が明確になります。規定がない場合は、業務遅延による逸失利益を1つずつ立証する必要があり、立証コストが賠償金額を上回ってしまうケースも珍しくありません。
パターン4：知財帰属型（成果物の著作権帰属）
納品されたコードや設計書の著作権がどちらに帰属するか、明示されていないことで起きるトラブルです。発注者は「自社の業務のために作らせたものだから自社帰属」と主張し、ベンダーは「再利用権を留保する」と主張するパターンが典型です。知財帰属が曖昧なまま納品されたシステムは、他ベンダーへの保守委託・機能追加を行う段階で改めて紛争化することもあり、長期的な経営リスクになります。
契約書で押さえるべき4項目
訴訟トラブルを防ぐために、契約書で必ず押さえるべき4項目を整理します。
項目1：検収条項
「何をもって検収完了とするか」を数値・行動ベースで定義してください。具体的には「テストケースの90%以上が合格していること」「主要業務シナリオ5件が連続して完遂可能であること」「検収期間内に発注者から書面での不合格通知がなければ検収完了とみなす」の3点をセットで書きます。検収期間は通常2〜4週間で設定します。
項目2：成果物責任（瑕疵担保・契約不適合責任）
リリース後の品質責任を、対象範囲・期間・対応方法の3点で定義してください。「リリース後6か月間、契約書記載の機能の不具合に対し、無償で修正対応する」のような書き方です。対象範囲には「発注者の運用方法に起因する不具合は除く」のような除外規定も明記しておきます。
項目3：遅延損害金
納期遅延に対する損害賠償の算定式を明記してください。「ベンダー起因の遅延に対し、契約額の0.1%/日を遅延損害金として支払う。ただし上限は契約額の10%」のような書き方です。発注者起因の遅延（要件追加・回答遅延など）は対象外であることも明示しておきます。
項目4：知財帰属
成果物の著作権帰属を明確にしてください。「本契約に基づき作成された成果物の著作権は発注者に帰属する。ただしベンダーが従前から保有する汎用ライブラリ・フレームワーク等の著作権はベンダーに帰属する」のような書き方が一般的です。さらにソースコードの開示義務と引き渡し方法も明記しておくと、保守ベンダーの切り替え時にも揉めません。発注前に契約書条項を項目別に整理してから締結に進む流れをお勧めします。
なおこの4項目以外にも、業務委託契約か請負契約かの選定、再委託に関する事前承諾条項、秘密保持条項の範囲・期間など、押さえるべき項目は多数あります。中小企業の発注では、ベンダーが提示する契約書のひな形をそのまま使うケースが多いですが、最低でもこの4項目だけは自社視点で点検してから締結する習慣を作ってください。
経営者目線で考える「訴訟になる前にやれること」
ここからは経営の話です。訴訟は時間・費用ともに大きな負担ですが、訴訟直前の段階で和解できるケースは少なくありません。経営者が訴訟前に取れる選択肢は3つあります。
第一に、第三者を入れた事実関係の整理です。発注者・ベンダーの双方が冷静さを失っている状態では、感情論で議論が進みません。第三者（コンサルタント・ITに詳しい弁護士・業界団体）を入れて事実関係を客観的に整理するだけで、和解の余地が見えてくることがあります。
第二に、「金銭的損失の最小化」を共通目標にする提案です。「双方が訴訟まで進んだ場合のコスト合計」を試算し、それを下回る和解額で着地させる方向に持ち込みます。弁護士費用200〜500万円、解決まで1〜2年という現実を双方が認識すれば、和解条件が見えやすくなります。
第三に、ADR（裁判外紛争解決手続）の活用です。日本商事仲裁協会・各地の弁護士会の仲裁センターなどを使えば、訴訟より短期間・低コストで解決できる可能性があります。費用は数十万円〜100万円台で、3〜6か月で結論が出るケースが多いです。
訴訟を回避するには、トラブル初期段階での「事実関係の文書化」が決定的に重要です。メール・議事録・進捗報告書を時系列で整理し、第三者にも分かる形で残しておいてください。文書が散逸している状態で訴訟に進むと、立証の段階で大きく不利になります。
また、トラブル発生初期に「感情的なメールを送らない」ことも重要です。怒りに任せた文面のメールは、後日訴訟証拠として相手側に有利に使われる可能性があります。事実関係を淡々と整理した文面でのやり取りに徹してください。
ぷらすわん実例：ある製造業A社の検収トラブル和解
ぷらすわんが相談を受けたある製造業A社の事例をお伝えします。A社は受発注システムの納品を巡って、ベンダーと検収可否で対立していました。ベンダー側は「契約書記載の機能は全て実装済み」として残金500万円を請求し、A社側は「業務で使える状態ではない」として支払いを拒否、訴訟を視野に弁護士に相談していた段階でした。
ぷらすわんが第三者として入り、3ステップで整理しました。第一に、契約書の機能一覧とシステムの動作状況を1項目ずつ突合し、「実装済み・実装済みだが不具合あり・未実装」の3区分に分類しました。結果として、機能の70%は実装済み、20%は不具合あり、10%は未実装と判明しました。第二に、不具合と未実装部分の修正に必要な工数を見積もり、ベンダー側に追加負担を求めず無償対応を依頼しました。第三に、修正完了後に検収・残金支払いという和解条件を双方で合意しました。
結果として、訴訟に進まず3か月で和解が成立し、A社は受発注システムを業務で使える状態で受け取りました。ベンダー側も残金回収が遅れたものの訴訟費用を回避できました。検収トラブルが見えてきた段階で、第三者に診断する流れに乗せておくと、訴訟前の和解選択肢が広がります。
まとめ
システム開発の訴訟トラブルは、「検収条項」「成果物責任」「遅延損害金」「知財帰属」の4項目の曖昧さが原因で起きるケースが大半です。訴訟に進むと弁護士費用200〜500万円、解決まで1〜2年という大きな負担になりますが、契約書を最初に整えておくだけで多くの紛争は予防できます。発注金額1,000万円規模のプロジェクトでも、契約書のリーガルチェック費用は10〜30万円程度に収まることが多く、訴訟リスクを大きく下げる投資としてはコストパフォーマンスが高い領域です。
既にトラブルが起きている場合も、訴訟直前で和解できる選択肢は残っています。第三者を入れた事実関係の整理、損失最小化を共通目標にする提案、ADRの活用——この3つの手を打つことで、訴訟回避の可能性は大きく高まります。発注前・トラブル発生時のいずれの段階でも、契約条項を比較を依頼する流れで点検してから次の手を打ってください。