システム開発・IT紛争は、要件定義・仕様変更・検収・追加費用・遅延・バグ対応など、プロジェクトの「途中経過」が争点になりやすい領域です。契約書が薄い／チャットだけで決めた／担当者が入れ替わった、といった事情が重なると、後から責任分界が曖昧になり、損害が拡大しやすくなります。
このページでは、主に非上場企業の実務を想定し、ベンダー（受託者）側の防御に加えて、発注者側の請求の組み立ても整理します。全体像を押さえたうえで、個別論点は下位記事で深掘りできるように構成しています。企業間紛争全体の入口は企業紛争・会社訴訟（企業間トラブル）の解決手段と弁護士相談のポイントをご覧ください。
- 初動は「事実の時系列化」と「証拠保全」で勝負が決まる（チャット・チケット・議事録を優先）
- 争点は大きく損害賠償／検収・契約不適合／追加費用／仕様変更に収れんしやすい
- 契約類型（請負・準委任）と、要件定義〜検収までの合意の積み上げが結論を左右する
- 交渉で終わらせるにも、訴訟を見据えた「主張の骨格」と「立証計画」を先に作る
坂尾陽弁護士
執筆者：弁護士 坂尾 陽（企業法務・M&A担当）
Contents
企業法務の無料法律相談実施中！
- 0円！完全無料の法律相談
- 弁護士による無料の電話相談も対応
- お問合せは24時間365日受付
- 土日・夜間の法律相談も実施
- 全国どこでも対応いたします
システム開発・IT紛争でよくある争点と、最初に確認すべき前提
システム開発は、成果物が目に見えにくく、工程が長く、途中で仕様が動きやすい分、紛争になると「どこまでが当初の約束で、どこからが追加なのか」「検収は完了しているのか」「誰の遅れで納期が崩れたのか」といった事実の切り分けが中心になります。
また、契約書のタイトルが「業務委託」でも、法的には請負（完成責任）と準委任（プロセス責任）のどちらに近いかで、評価が変わります。工程ごとに混在することもあります。
まずは、次の資料を「最新版＋改定履歴（差分）」で集め、プロジェクトを時系列で俯瞰してください。
- 契約書／約款、見積書、発注書・注文請書、提案書（スコープの根拠）
- 要件定義書、基本設計・詳細設計、仕様書、変更管理表（変更依頼・承認の履歴）
- 議事録、メール／チャット、チケット（Jira等）、進捗報告、課題管理表
- 検収資料（受入テスト結果、検収書、受領書）、リリース判定の記録
- 納品物（ソースコード、成果物一式）、ログ、リポジトリ履歴、環境情報
緊急度が高いときの初動対応：まず止血するチェックリスト
炎上・遅延・バグ多発などで関係が悪化している場合、早期に「証拠が散逸する」「現場が走りながら口約束を増やす」ことが最大のリスクです。とくにベンダー側は、善意で対応を続けた結果、後から「無償でやる合意だった」と評価される危険があります。
初動の具体策はシステム開発トラブルの初動対応：証拠保全・交渉・契約見直しで詳しく解説していますが、ここでは最低限の要点をまとめます。
- 窓口を一本化：現場が個別に謝罪・約束・値引きをしない（発言が合意と評価され得る）
- 時系列表を作る：誰が・いつ・何を決めたか（決裁者／会議体／合意方法も記録）
- 証拠保全：チャット・議事録・ログを優先（退職者やアカウント停止で消えやすい）
- 現状の成果物を固定：環境を複製して検証できる状態を確保（上書きで「何が壊れていたか」が不明になるのを防ぐ）
- 追加作業はルール化：合意前の追加対応は、範囲・期限・有償/無償の前提をメール等で残す
- ゴールを決める：完成優先／打切り・乗換え／支払回収／損害圧縮など、会社としての目的を明確化
損害賠償をめぐる整理：請求できる範囲と、防御のポイント
システム開発の損害は、金額が大きくなりやすい一方で、因果関係や相当性が争われやすいのが特徴です。典型的には、納期遅延や不具合を理由に「再開発費」「代替ベンダー費用」「業務停止損害」「逸失利益」などが主張されます。
損害賠償の全体像・立証の作り方はシステム開発の損害賠償：請求できる範囲と立証（遅延・瑕疵・追加費用）で詳述します。ここでは、交渉の場でまず整理したい論点を、立場別にまとめます。
発注者側：損害の「見せ方」を先に設計する
- 損害項目を分解する（例：再開発費／運用回避費／外注費／社内人件費／第三者への補償）
- 「いつから発生した損害か」を時系列で切る（遅延開始点・不具合発覚点・是正要請点）
- 代替手段をとった記録を残す（損害拡大防止の観点。放置すると減額要因になり得る）
- 責任制限条項（キャップ・間接損害除外等）の有無を確認し、交渉レンジを現実化する
ベンダー側：責任を広げない（防御は「論点の棚卸し」から）
- 因果関係：損害は本当に自社の遅延・不具合から生じたか（発注者側の運用・判断遅れの影響）
- 協力義務：発注者の素材提供・レビュー・意思決定が遅れていないか（遅延の帰責の分解）
- 範囲外要求：追加開発（仕様変更）を無償瑕疵対応として扱われていないか
- 責任制限条項：上限金額、直接損害限定、逸失利益除外、通知期限など（適用要件も確認）
- 是正機会：補修・代替措置で解消できたのに、発注者が打切った事情はないか
- 証拠の粒度：口頭合意・口頭指示を、メールや議事録で追認しているか（後追いでも重要）
検収・契約不適合（バグ／仕様不適合）の争い方
検収は、システムが「仕様どおりか」を確認し、支払条件や引渡しを確定させる工程です。検収が完了すると、発注者は支払義務が明確化し、ベンダー側は「完成・引渡し」を前提に防御を組み立てやすくなります。一方で、検収完了後に不具合が見つかるケースも多く、契約条項（検収の範囲、通知期限、保守範囲）次第で結論が動きます。
契約不適合責任の枠組みや、発注者・ベンダー双方の実務対応はシステム開発の契約不適合責任：バグ・仕様不適合への請求と防御で整理します。ここでは要点だけ押さえます。
発注者側：検収を「儀式」にしない
- 受入基準（テスト項目・合格基準）を明確化し、結果を保存する
- 不具合は「再現手順・ログ・画面キャプチャ・影響範囲」をセットで残す
- 修補依頼は期限と優先度を付け、合意形成（いつまでに何を直すか）を文書化する
ベンダー側：不具合対応を「無制限」にしない
- 不具合の定義（仕様不適合か、追加要望か、環境要因か）を切り分ける
- 補修計画（対応方針・期限・代替措置）を提示し、是正機会を確保する
- 検収・受入の範囲外の要求は、追加開発として見積・合意のルートに乗せる
- 保守契約の有無と範囲（軽微修正、運用支援、改修）を整理し、炎上拡大を防ぐ
追加費用と仕様変更：争点を「変更管理」に落とし込む
システム開発紛争で頻出なのが、仕様変更をめぐる追加費用です。発注者は「当初から当然含まれる」と主張し、ベンダーは「追加開発で別料金」と主張しがちで、ここが最も揉めやすいポイントの一つです。
実務では、次の2点を分けて整理すると、話が前に進みます。
- 当初スコープ：提案書・要件定義・見積の前提に照らし、どこまでが「本来の債務」か
- 変更の合意：変更依頼がいつ・誰から出て、見積・納期影響・検収条件がどう承認されたか
発注者側：追加費用を払う前に確認したいこと
- 変更内容が「バグ修正」なのか「追加機能」なのか（責任分界）
- 金額の算定根拠（工数・単価・前提条件）と、納期・検収条件への影響
- 承認プロセス（誰が最終承認者か）を明確にし、口頭でGOを出さない
ベンダー側：追加作業を「無償」に見せないコツ
- 変更依頼の受領時点で、まず「影響調査（有償/無償）」の位置づけを通知する
- 合意が取れるまで、追加開発を開始しない（難しい場合も、メール等で暫定合意を残す）
- 「要求→見積→承認→実装→検収」を一連で残す
- 追加対応を続けるほど、後から工数が立証しづらくなるため、週次などで累計を可視化する
交渉から訴訟まで：進め方と、準備の勘所
多くの案件は、交渉（和解）での着地を目指します。ただし、交渉を優位に進めるには、訴訟での立証を見据えて「主張の骨格」と「証拠の並べ方」を先に作ることが重要です。特にIT領域は、相手に専門性があり、言い回しの違いで誤解が生まれやすいため、文書化が効果を持ちます。
訴訟になった場合の流れや争点整理はシステム開発訴訟の流れと主な争点：要件定義・検収・仕様変更・遅延で解説します。弁護士への相談のタイミング・準備資料はIT紛争に強い弁護士の選び方：相談タイミング・費用・準備資料が参考になります。
交渉局面で、まず固めたい「共通の土台」は次のとおりです。
- 争点の棚卸し（遅延／不具合／仕様変更／追加費用／検収／支払）を一枚にまとめる
- ゴール設定（完成、打切り、清算、再発防止、守秘など）を会社方針として決める
- 譲歩できる条件と譲れない条件を整理（特に責任範囲と金額上限）
- 相手の資力・回収可能性、訴訟コスト、時間軸（社内工数）を見積もる
なお、上場企業の場合は、重要なプロジェクトの失敗が開示・内部統制・監査対応の論点になることがあります。
システム開発・IT紛争：個別論点の詳しい解説（索引）
本文で触れた論点を、状況別に深掘りできるよう、個別記事をまとめます。プロジェクトの状況に近いものから参照してください（本文の流れで触れられないテーマは、この索引で補完しています）。
- システム開発トラブルの初動対応：証拠保全・交渉・契約見直し：炎上・遅延・バグ多発時に、まず何をするか（証拠保全／交渉の土台）
- システム開発の損害賠償：請求できる範囲と立証（遅延・瑕疵・追加費用）：再開発費・遅延損害・逸失利益など、損害の範囲と立証
- システム開発の契約不適合責任：バグ・仕様不適合への請求と防御：バグ／仕様不適合への請求・防御、検収後の考え方
- システム開発訴訟の流れと主な争点：要件定義・検収・仕様変更・遅延：要件定義・検収・仕様変更が訴訟でどう争点化するか
- IT紛争に強い弁護士の選び方：相談タイミング・費用・準備資料：相談タイミング、費用の考え方、準備資料
- システム開発の失敗事例と回避策：紛争化を防ぐプロジェクト運営：失敗パターンと予防策（契約・プロジェクト運営）
まとめ：システム開発・IT紛争は「契約×経緯×証拠」で決まる
- 初動は、時系列化と証拠保全（チャット・チケット・議事録・ログ）を優先する
- 損害賠償は、因果関係・相当性・責任制限条項でレンジが決まる
- 検収・契約不適合は、受入基準と通知・是正の履歴が鍵になる
- 追加費用・仕様変更は、変更管理（要求→見積→承認→実装→検収）に落とし込む
- 交渉で終えるためにも、訴訟を見据えた主張と証拠の並べ方を先に作る
紛争が拡大するほど、現場の疲弊と機会損失が大きくなります。社内の窓口と方針を早めに定め、契約と事実経過をもとに、取り得る選択肢（完成・打切り・清算）を現実的に比較することが重要です。
坂尾陽弁護士
関連記事
企業法務の無料法律相談実施中！
- 0円！完全無料の法律相談
- 弁護士による無料の電話相談も対応
- お問合せは24時間365日受付
- 土日・夜間の法律相談も実施
- 全国どこでも対応いたします