システム開発の契約トラブル事例5選｜裁判になる前に知っておきたい予防策
「開発費用が当初の1.5倍に膨らんだ」——このトラブル、他人事ではありません
「見積もりでは500万円だったのに、最終的に750万円を請求された」「納期を過ぎても動くものが出てこない」「納品されたシステムが、打ち合わせで伝えた要件を満たしていない」——こうしたシステム開発のトラブルは、中小企業の経営者から頻繁に寄せられる相談です。
- 追加費用の算出根拠が不明確で、言われるままに払うしかない
- 要件定義書と実装されたものが食い違っている
- ベンダーが途中でプロジェクトを投げ出した
- 納品されたシステムにバグが多発し、運用が回らない
- 解約しようとしたら、高額な精算金を請求された
こうした問題は、実際に年間数百件が裁判に発展しています。判例データベースを見ると、システム開発訴訟の件数は右肩上がりで、発注側・ベンダー側の双方が多大なコストと時間を失っています。
重要なのは、「裁判になる前に防げたケースがほとんど」だという点です。
「信頼できるベンダーだから大丈夫」——その思い込みが危険です
システム開発のトラブルは、悪質なベンダーとの取引だけで起きるわけではありません。むしろ、お互い誠実に仕事を進めていても、認識のズレが積み重なって紛争に発展するケースが多いのが実態です。
「打ち合わせでは『分かりました』と言われたので、出来上がるものは一致していると思っていた」
「見積書の範囲を超える作業だと言われたが、何が範囲外かの線引きが曖昧だった」
「途中で何度か仕様を変更したが、それが追加費用になるとは聞いていなかった」
こうした食い違いは、契約書が曖昧だったり、議事録が残っていなかったりすると、後から「言った・言わない」の泥沼に発展します。
中小企業の場合、法務部門が無く、契約書をそのままサインしてしまうケースが多いのも問題です。IT発注に不慣れな会社ほど、ベンダー提示の契約書にハンコを押し、想定外の費用や納期遅延に苦しむ状況に陥ります。
しかし、典型的なトラブルパターンを知っておけば、多くは事前に防げます。
この記事で、契約トラブルの予防策が分かります
以降では、システム開発で実際に起きているトラブル5事例を紹介し、それぞれの予防策を解説します。建築・設計事務所や中小工務店のように、IT発注の経験値が高くない会社こそ、この内容を押さえておくと安心です。
契約トラブル予防の全体像
実際に起きている契約トラブル5事例と予防策
事例1. 「見積もり額の1.5倍に膨らむ」——追加費用紛争
最も多いのが、当初見積もりから大幅に金額が増えるトラブルです。
典型的な流れ
- 要件定義を曖昧なまま進め、概算見積もりで契約
- 開発段階で「これもやってほしい」と追加要望が発生
- ベンダー側は「別作業扱い」として追加費用を請求
- 発注側は「最初から含まれていると思っていた」と反発
予防策
- 契約時にスコープ（作業範囲）を文書化する
- 追加作業が発生した場合の精算ルールを契約書に明記（時間単価・固定額など）
- 変更要望は必ず書面またはチケット化し、その都度見積もりを取る
- 検収条件を契約段階で確定しておく
特に「変更管理（チェンジマネジメント）」のルールを契約書に入れておくだけで、トラブルの7〜8割は予防できます。
事例2. 「納期通りに動くものが出てこない」——納期遅延紛争
典型的な流れ
- 契約時に「6ヶ月で納品」と約束
- 3ヶ月経過時点で、進捗率が20%以下
- 発注側が懸念を伝えても、「最後に巻き返します」と回答
- 納期を過ぎても動くものが出てこず、プロジェクトが炎上
予防策
- **マイルストーン（中間目標）**を契約書に明記し、各時点での成果物を定義
- 進捗報告を週次で書面化する義務をベンダーに課す
- 遅延が発生した場合の違約金条項を入れる
- スコープの削減や納期延長のルールも予め決めておく
契約時に納期だけを決めるのではなく、「進捗が遅れたときに何をするか」を決めておくのが重要です。
事例3. 「納品されたシステムが使えない」——品質不足紛争
典型的な流れ
- 納期通りに納品されたが、バグが多発
- ベンダーは「受入検収が完了したので、以降は保守契約で対応」と主張
- 発注側は「そもそも業務で使えないので、検収していない」と反発
- 瑕疵担保責任（契約不適合責任）の範囲で揉める
予防策
- 検収基準を契約書で定量化（エラー発生率・処理速度・主要業務シナリオの動作確認）
- テスト項目書を発注側が用意し、合意してから開発開始
- 瑕疵担保期間（通常6ヶ月〜1年）を契約書に明記
- 本番稼働後の運用サポートの範囲・料金も契約段階で確定
2020年の民法改正で、瑕疵担保責任は「契約不適合責任」に名前が変わり、追完請求・代金減額・損害賠償の選択肢が広がりました。この新ルールを踏まえた契約書かどうか、一度チェックすることを推奨します。
事例4. 「途中でベンダーが撤退」——プロジェクト頓挫紛争
典型的な流れ
- 開発途中でベンダーの主要エンジニアが退職
- 代替要員が手配されるが、品質・スピードが大幅低下
- 最終的にベンダーが「これ以上の開発は難しい」と撤退を通告
- 支払済みの金額は戻らず、成果物も使える状態ではない
予防策
- 中間成果物の所有権を契約書で発注側に確保
- ソースコードの著作権の扱いを明確化
- 継続が困難になった場合の精算ルールを予め規定
- 重要プロジェクトは複数ベンダーで分散することも検討
中間成果物とソースコードを発注側が確保しておけば、仮にベンダーが撤退しても、別のベンダーに引き継いで完成させる道が残ります。
事例5. 「解約で高額な精算金」——途中解約紛争
典型的な流れ
- プロジェクト途中で、発注側の事情で計画を変更
- ベンダーに解約を申し出る
- ベンダーから、着手済み全工程の費用請求が届く
- 発注側が想定していた金額と大きく乖離
予防策
- 解約時の精算ルール（進捗率に応じた按分など）を契約書に明記
- マイルストーンごとの支払いにして、一括払いを避ける
- 小さく始めて、フェーズごとに契約を切る（アジャイル型の契約）
- 解約金の上限額を設定しておく
特に「フェーズ分割契約」は、中小企業の発注で最も有効なリスクヘッジ手段です。3〜6ヶ月単位でフェーズを切り、フェーズごとに成果を確認してから次を発注する形にすれば、途中解約のリスクは大幅に下がります。
契約書チェックの具体的ステップ
こんな方にこの記事の予防策が役立ちます
- これから初めてシステム開発を発注する中小企業の経営者
- 過去にIT発注で苦い経験があり、次こそ成功させたい担当者
- 建築・設計事務所など、IT専門部署を持たない組織の責任者
- 社内にリーガルチェック機能が弱く、契約書の精査に不安がある総務担当者
システム開発のトラブルは、契約書の数行の不備が原因で数百万円の損失を生むことも珍しくありません。逆に、契約前の1〜2週間を投資するだけで、ほとんどのトラブルは予防できます。
契約書の精査は、プロジェクト全体の成否の8割を決めると言っても過言ではありません。ベンダー提示の契約書をそのまま受け入れるのではなく、自社の立場で必要な条項が入っているか、必ず確認してください。
まとめ
契約トラブル予防でプロジェクト成功
システム開発のトラブルは、以下の5パターンに集約されます。
- 追加費用紛争：スコープと変更管理ルールを明文化する
- 納期遅延紛争：マイルストーンと進捗報告を義務化する
- 品質不足紛争：検収基準を定量化する
- プロジェクト頓挫紛争：中間成果物・著作権を確保する
- 途中解約紛争：フェーズ分割契約で小さく始める
これらの予防策は、すべて契約書の工夫で対応可能です。法務の専門家に頼ることも重要ですが、発注側の担当者が「何を確認すべきか」を知っているだけで、守れるリスクが大きく変わります。
私たちアトリエ・バイナリ（atelier binary）では、建築・設計事務所や中小工務店のIT発注相談に応じており、契約書の精査やベンダー選定の伴走も承っています。「契約書を前にして固まってしまった」という段階でも、早めに相談いただければトラブルの芽を摘めることが多いです。
まずは、お手元のシステム開発契約書を一度取り出して、「変更管理」「マイルストーン」「検収基準」「解約時精算」の4つの項目が書かれているかを確認してみてください。書かれていなければ、それが最初に手を打つべきポイントです。
