LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

システム開発で起きる契約トラブルの実態

システム開発の契約トラブルとは、発注者（ユーザー企業）と受注者（開発会社）の間で、仕様・品質・納期・費用・責任範囲の認識が一致しないことに起因して生じる紛争や問題の総称を指します。

よくある契約トラブルの6つのパターン

システム開発プロジェクトで実際に生じやすいトラブルには、いくつかの典型的なパターンがあります。

①要件・仕様の齟齬：発注者が「当然含まれる」と思っていた機能が、受注者には「別途見積もり対象」として認識されているケースです。要件定義が口頭や簡単なメモのみで進んだ場合に起きやすくなります。

②仕様変更に伴う費用・納期の未合意：開発途中に発注者から仕様変更の要望が生じ、追加費用と納期延長の取り扱いが契約上明確でないまま進んだ結果、請求段階で紛争になる例です。

③納期遅延：受注者側の開発遅延により、発注者の事業計画に支障が生じるケースです。遅延損害金の取り決めが契約書にあるかどうかが対応の分かれ目になります。

④品質不良・バグの多発：引き渡されたシステムにバグや仕様との不整合が多く、本番稼働後に業務障害を引き起こすケースです。検収基準が不明確な場合、受注者は「検収合格済み」と主張し、発注者は「まだ直っていない」と主張する対立が生じます。

⑤検収トラブル：検収基準・検収期間が曖昧なため、発注者が長期間にわたって「検収未了」を主張し、受注者が報酬を受け取れない状況です。逆に受注者が不完全な状態での検収合格を求めてくるケースもあります。

⑥プロジェクト頓挫：開発が途中で打ち切りになるケースで、費用精算・成果物の帰属・損害賠償の可否が問題になります。双方に責任がある「共同原因型」も多く、証拠保全が重要になります。

契約不適合責任（旧・瑕疵担保責任）とは

契約不適合責任とは、引き渡された目的物（システムの場合は成果物）が「種類・品質・数量に関して契約の内容に適合しない」場合に、受注者（売主・請負人）が負う法的責任を指します。2020年4月施行の改正民法（民法第562条以下）によって「瑕疵担保責任」から名称・内容ともに改められました。

改正民法で何が変わったか：旧・瑕疵担保から契約不適合へ

旧民法（改正前）では「隠れた瑕疵（かし）」がある場合に発注者が損害賠償・解除を求められると定めていました。しかし「隠れた」という要件の解釈が難しく、実務上の使い勝手が課題でした。

2020年4月の改正民法では、判断基準が「契約の内容に適合しているか否か」に統一されました。「隠れた」という要件は不要になり、発注者が行使できる権利も追完請求・代金減額請求・損害賠償・契約解除の4つとして明示されています。

発注者が行使できる4つの権利

契約不適合が認められた場合、発注者（注文者）は次の4つの権利を行使できます。ただし、行使できる権利の範囲や要件は、契約書の条項や民法の定めによって異なるため、具体的な判断は弁護士への相談をおすすめします。

• 追完請求（民法第562条）：修補・代替物の引渡し・不足分の引渡しを請求する権利です。システム開発ではバグ修正・機能の追加実装が該当します。
• 代金減額請求（民法第563条）：不適合の程度に応じて代金の減額を請求する権利です。まず追完請求を行い、受注者が応じない場合等に主張できます。
• 損害賠償請求（民法第564条・第415条）：契約不適合によって生じた損害の賠償を求める権利です。受注者の帰責事由が必要で、金額の立証も必要です。
• 契約解除（民法第564条・第541条・第542条）：不適合が軽微でない場合に契約を解除する権利です。解除後は原状回復の問題が生じます。

通知期間と時効の注意点

民法第637条では、発注者が不適合を知った時から1年以内に受注者へ通知することが規定されています。通知を怠ると契約不適合責任を追及できなくなります。ただし、受注者が不適合を知りながら告げなかった場合はこの限りではありません。

また、実際の開発契約では民法の定めより短い保証期間や通知期限を設けている場合があります。契約書の「保証条項」「瑕疵担保条項（契約不適合責任条項）」を確認することが大切です。

請負契約と準委任契約での責任の違い

システム開発では、業務の性質に応じて「請負契約」と「準委任契約」が使い分けられます。この選択がトラブル時の責任範囲を大きく左右するため、契約前に正しく理解しておく必要があります。

実務上の「混合型契約」と注意点

現代のシステム開発では、要件定義フェーズは準委任、本開発フェーズは請負という「フェーズ分割型」の契約が広く使われています。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」でも、フェーズ別の契約分割が推奨されています。

この方式では各フェーズごとに契約書を締結し、責任範囲を明確にすることが重要です。「全体を一つの契約でまとめてしまう」設計は、フェーズごとの成果物定義が曖昧になりやすく、トラブルの温床になります。

トラブルを予防する実務：要件定義・検収・変更管理

システム開発のトラブルの多くは、プロジェクト開始前または進行中の「合意形成の不備」が根本原因です。以下の4つの実務施策が予防の柱になります。

要件定義と仕様書の厳密な文書化

要件定義書・機能仕様書は、後の契約不適合責任を判断する際の基準となる文書です。「口頭合意」や「雰囲気での理解」をなくし、すべての要件をドキュメントに落とすことが出発点になります。

仕様書には、機能要件だけでなく非機能要件（性能・可用性・セキュリティ・画面応答速度など）も記載することが大切です。「普通に動く」「一般的な水準」といった曖昧な表現は、「契約の内容」として認定されにくくなります。

検収基準と検収手続きの明確化

検収は、発注者が「契約内容に適合した成果物を受け取ったか」を確認する手続きです。検収基準が曖昧だと、バグや不具合が残っていても「検収合格とみなす」状況が生じます。

契約書または別途の検収手続き書面には、次の事項を明記することをおすすめします。

• 検収期間：成果物受領後、何営業日以内に検収結果を通知するかを定めます。
• 検収基準：何をもって「合格」とするかを定量的に定めます（例：重大バグがゼロ、画面応答時間が3秒以内など）。
• 修正対応の期限と回数：検収不合格時の修正対応期限と、対応できない場合の取り扱いを定めます。
• みなし検収の有無：期間内に何も通知しなかった場合に「合格とみなす」条項が入っているかを確認します。

仕様変更の変更管理プロセス

開発途中の仕様変更（いわゆる「追加・変更要望」）は、追加費用・納期延長の原因になります。変更を否定するのではなく、変更が生じた際の手続きを契約書または別途の変更管理手順書で定めておくことが重要です。

変更管理の基本プロセスは「変更要望を文書で提出→受注者が影響調査・見積提示→発注者が承認→正式な変更指示書を交わす」という流れです。口頭や非公式チャットでの変更依頼が積み重なると、後から「言った・言わない」の対立が生じます。

議事録と証拠の保全

すべての打ち合わせ・協議の議事録を作成し、双方が確認・署名するか、メールで内容確認を取る習慣が重要です。トラブル発生時に「何が合意されていたか」を立証するのは、議事録・メール・設計書などの書面です。

証拠が口頭のみの場合、法的な立証が困難になります。プロジェクト管理ツールのログ・チャットの履歴も、後から参照できるよう保全しておきましょう。

契約書の必須確認ポイント

既製のベンダー提示契約書をそのまま押印するのは、発注者にとってリスクです。少なくとも次の条項を確認し、必要に応じて交渉または修正を求めることをおすすめします。

• 契約不適合責任（保証）の範囲・期間：民法上の権利を制限する条項がないかを確認します。
• 損害賠償の上限額（免責条項）：「損害賠償は委託料の範囲内に限る」等の制限は、大規模障害時に発注者の補償を大幅に制限します。
• 知的財産権の帰属：開発したシステムのソースコードや設計書の著作権が誰に帰属するかを明記します。
• 再委託の条件：受注者が業務を下請けに出す場合の条件と、元の発注者への通知義務を確認します。
• 契約解除・中途終了時の精算方法：途中でプロジェクトを打ち切る際の費用精算ルールを確認します。

トラブル発生時の対応ステップ

実際にトラブルが発生した場合、感情的な対立を避けながら法的・実務的な対応を進めることが大切です。対応が遅れると証拠が失われたり、通知期間を過ぎたりするリスクがあります。

STEP 1：事実整理と証拠の確保

まずトラブルの内容を時系列で整理します。契約書・要件定義書・仕様書・議事録・メール・設計書・テスト仕様書・検収記録などをすべて収集し、どこで合意が崩れたのかを特定します。

この段階での作業が後の交渉・法的手続きの基盤になります。システムログやソースコードの変更履歴も重要な証拠となる場合があります。

STEP 2：契約内容の詳細確認

契約書を細部まで読み返し、問題となっている事項がどの条項に該当するかを確認します。請負か準委任かの確認、契約不適合責任の条項、損害賠償の上限・免責事項、解除条項、協議条項（まず協議を行う旨の定め）などを確認します。

「契約書には書かれていないが当然の前提だと思っていた」という事項については、民法の任意規定や業界慣行が補充されます。判断が難しい場合は、この時点で弁護士に相談することをおすすめします。

STEP 3：書面による申し入れと協議

相手方への申し入れは、口頭ではなく書面（メールでも可）で行います。内容証明郵便は、通知の事実と日付を法的に証明できる手段として有効です。

申し入れ書面には、問題の事実・根拠となる契約条項・求める対応（修正・返金・損害賠償など）・回答期限を明記します。相手方との協議の内容もすべて記録しておきましょう。

STEP 4：専門家への相談と法的手段の検討

協議で解決しない場合は、弁護士への相談が必要です。法的手段としては、ADR（裁判外紛争解決手続）・調停・仲裁・民事訴訟などがあります。システム開発紛争に詳しい弁護士に依頼することで、技術的な争点の整理も含めた対応が期待できます。

なお、訴訟は時間・費用ともに大きなコストがかかります。ADRや調停の段階で和解的解決が図れないかを検討することも現実的な選択肢です。

STEP 5：解決後の再発防止策の実施

トラブルが解決したら、その原因を分析して再発防止策を実施します。契約書のひな型の見直し、要件定義・検収プロセスの改善、変更管理手順の整備などを行いましょう。

同じトラブルを繰り返すことは、事業上のリスクの継続を意味します。プロジェクト終了後のレビューを制度化し、知見を組織内で蓄積することが重要です。

相談先と専門家活用のポイント

システム開発の契約トラブルに対応するうえで、どの専門家・機関に相談すべきかを把握しておくことは、スムーズな解決につながります。

弁護士への相談

契約不適合責任の追及・損害賠償請求・契約解除などの法的手続きは、弁護士が中心的な役割を担います。IT・システム開発に関する紛争経験を持つ弁護士を選ぶことで、技術的な争点の理解を含めた対応が期待できます。

トラブルが深刻化する前の早期段階での相談が、解決コストを抑えるうえでも有効です。契約書のレビューを事前に弁護士に依頼することも、予防策として検討できます。

IPAの「情報システム・モデル取引・契約書」の活用

IPA（情報処理推進機構）は「情報システム・モデル取引・契約書」を公表しています。発注者・受注者双方が参照できるモデル契約書で、フェーズ別の契約分割や変更管理条項の書き方など、実務上有用な雛形が含まれています。

現行の自社契約書と比較することで、抜け落ちている条項や見直すべき箇所を確認する参考資料として役立ちます。URLは推測で書かず、IPAの公式サイト（ipa.go.jp）でご確認ください。

ADR（裁判外紛争解決手続）の活用

ADR（Alternative Dispute Resolution：裁判外紛争解決手続）は、訴訟によらない紛争解決手段の総称です。中立の第三者が関与することで、当事者間の直接協議では難しい解決を図れる場合があります。

IT系の紛争に対応した調停・仲裁機関への相談も一つの選択肢です。弁護士会や裁判所が運営する調停制度も利用できます。いずれの手段を選ぶにあたっても、弁護士のアドバイスを得ながら判断することをおすすめします。

内製対応が難しい理由：IT開発プロジェクト管理の専門性

システム開発の契約トラブルは、法律の問題であるとともに、技術・プロジェクト管理の問題でもあります。「要件定義が適切だったか」「テスト工程が妥当だったか」「変更対応の範囲が合理的だったか」を判断するには、IT開発プロジェクトの実務知識が必要です。

法務担当者だけでは技術的な事実の評価に限界がある場合もあります。IT開発の実務に精通したパートナーや、元請（プライムベンダー）として開発を受託してきた経験を持つ企業に相談することで、法的・技術的双方の観点から課題を整理できる場合があります。

まとめ：契約トラブルを防ぐ3つの実務的判断軸

本稿では、システム開発の契約トラブル・契約不適合責任（旧・瑕疵担保責任）について、法的背景・責任の違い・予防実務・対応ステップを整理しました。要点を3つに集約します。

第一に、2020年改正民法で契約不適合責任の枠組みが変わった点を正確に把握することが重要です。「瑕疵担保責任」という用語は廃止され、「契約の内容に適合するか否か」が判断基準になりました。発注者は追完請求・代金減額請求・損害賠償・契約解除の4権利を持ちますが、不適合を知った時から1年以内の通知が必要です（民法第637条）。

第二に、請負契約か準委任契約かでトラブル時の責任範囲が根本的に異なります。請負では受注者に完成義務と契約不適合責任が発生します。準委任では善管注意義務が中心で契約不適合責任は原則生じません。フェーズ別に契約形態を使い分け、各フェーズで責任範囲を明確にすることが予防の基本です。

第三に、予防は「文書化・基準化・プロセス化」の三本柱です。要件定義書・仕様書による要件の明確化、検収基準と手続きの文書化、変更管理プロセスの整備、議事録による合意の記録が、トラブルを未然に防ぐ実務的な柱になります。トラブルが発生した際は早期に専門家（弁護士）に相談することが、解決コストを抑えることにもつながります。

よくある質問

「瑕疵担保責任」と「契約不適合責任」はどう違いますか？

2020年4月施行の改正民法により、旧民法の「瑕疵担保責任」という用語は廃止され、「契約不適合責任」に改められました。旧法では「隠れた瑕疵」という要件が必要でしたが、改正後は「契約の内容に適合しない」かどうかが判断基準となっています。発注者が行使できる権利として、追完請求・代金減額請求・損害賠償・契約解除の4つが明示されました。

請負契約と準委任契約では、トラブル時の責任はどう変わりますか？

請負契約では受注者（開発会社）に仕事の完成義務があり、成果物が契約内容に適合しない場合は契約不適合責任が生じます。一方、準委任契約（民法第656条）では受注者の義務は善管注意義務（善良な管理者の注意をもって業務を行う義務）であり、仕事の完成は保証されません。そのため契約不適合責任は原則として生じませんが、善管注意義務違反があれば損害賠償請求の余地はあります。どちらの契約形態を選ぶかが、トラブル時の責任範囲を大きく左右します。

システム開発で契約不適合責任を追及するには何が必要ですか？

契約不適合責任を追及するには、まず「契約の内容」と「実際に引き渡されたもの」のギャップを明確にする必要があります。要件定義書・仕様書・設計書・議事録などの書面が重要な証拠になります。民法第637条では、不適合を知った時から1年以内に受注者へ通知することが必要です。具体的な対応は契約条件や事情によって異なりますので、弁護士への相談をおすすめします。

システム開発のプロジェクト途中で頓挫した場合、費用は返ってきますか？

プロジェクトが途中で頓挫した場合の費用返還は、契約形態・契約書の条項・頓挫の原因（発注者側か受注者側か双方か）によって異なります。請負契約では仕事が完成しなかった場合に報酬の全部または一部が返還される余地があります（民法第634条参照）。準委任では既履行部分への報酬は認められる場合があります。費用返還の可否は個別事情に依存するため、弁護士への相談が重要です。

システム開発のトラブルはどこに相談すればよいですか？

まず契約書・仕様書・議事録を整理し、事実関係を記録することが先決です。相談先の中心は、IT関連の紛争に詳しい弁護士・法律事務所です。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書」は、契約整備の参考として活用できます。裁判外での解決手段として、ADR（裁判外紛争解決手続）の活用も検討できます。いずれの場合も弁護士のアドバイスのもとで進めることをおすすめします。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（情報処理推進機構）「情報システム・モデル取引・契約書」（各年版）— URLは ipa.go.jp 公式サイトにてご確認ください。