システム開発における要件定義が法的トラブルになりやすい理由

はじめに

「依頼していたシステムと違うものが納品された」
「追加の要望を出しただけなのに、別途費用を請求された」
——システム開発をめぐるトラブルは、企業間紛争の中でも特に多い類型の1つです。

その原因の１つは、開発の初期段階である要件定義にあります。

要件定義とは、「どのようなシステムを作るのか」を発注者と開発者の間で明確にする工程です。

この工程を曖昧なまま開発を進めると、双方の認識にズレが生じ、法的紛争にまで発展することがあります。

本記事では、システム開発における要件定義がなぜトラブルの原因になりやすいのかを解説し、実際の解決事例や予防策についてもご紹介します。

よくあるシステム開発でのトラブル例

システム開発をめぐる紛争は、大きく以下のパターンに分類されます。

1. 成果物が期待と異なる

発注者が「こういうシステムが欲しい」と考えていた内容と、開発者が「こういう仕様で作る」と理解していた内容にズレがあり、納品後に「依頼したものと違う」と主張されるケースです。

特に、要件定義書が作成されていない場合や、口頭・チャットのやり取りだけで開発が進められた場合に、このトラブルが頻発します。

2. 費用に関する認識の相違

開発途中で機能の追加や仕様変更が発生し、当初の見積もりを超える費用が発生するケースです。

発注者側は「当初の契約範囲内だ」と主張し、開発者側は「追加の要望には別途費用が必要だ」と主張して対立します。

3. 納期の遅延・未完成

開発が遅延した場合に、その原因が開発者側にあるのか、発注者側の仕様変更や確認遅延にあるのかが争われるケースです。

4. 契約書が存在しない、または曖昧

そもそも正式な契約書を締結せずに開発が始まってしまうケースは少なくありません。

メールやメッセンジャーでのやり取りだけで合意が形成されている場合、後から「何を合意したのか」の立証が困難になります。

契約内容に齟齬がある場合の交渉

依頼していたものと違い、代金を返還するように言われた場合

発注者から「納品されたシステムが依頼内容と異なるので、支払った代金を返してほしい」と求められるケースは典型的な紛争パターンです。

この場合、法的には「契約不適合責任」（旧・瑕疵担保責任）や「債務不履行」が問題となります。

重要なのは、契約で合意された仕様が何だったのかという点です。

要件定義書、見積書、議事録、メールのやり取りなど、合意内容を示す証拠がどれだけ残っているかが勝敗を左右します。

開発者側としては、要件定義の段階で合意された範囲を正確に記録し、仕様変更があった場合にはその都度書面で確認を取ることが重要です。

顧客からの要望がどんどん増え、工数が合わなくなった場合

いわゆる「スコープクリープ」と呼ばれる問題です。

開発が進む中で発注者からの追加要望が次々と発生し、当初の契約金額では対応できなくなるケースです。

このような場合、追加の要望が当初の契約範囲に含まれるのか、それとも別途の契約（追加発注）として扱われるべきなのかが争点となります。

対処としては、追加要望が出た時点で速やかに工数と費用の見積もりを提示し、発注者の書面による承認を得ることが重要です。

口頭での「とりあえずお願いします」だけで着手してしまうと、後から「そんな追加費用は聞いていない」と主張されるリスクがあります。

開発期間や遅延に関する問題

次から次に修正が出てくる場合

開発の終盤やテスト工程で、発注者から修正要望が次々と出されるケースも紛争の原因となります。

ここで問題となるのは、その修正がバグの修正（開発者の責任）か、それとも仕様変更（追加の発注）かという区別です。

曖昧なまま修正対応を続けると、開発者は無償で際限のない修正へ追われることになりかねません。

また、修正対応の繰り返しで納期が遅延した場合、遅延の責任が開発者側と発注者側のどちらにあるかも争点となります。

発注者側の度重なる仕様変更が遅延の主因であると認定されたケースでは、開発者の責任が否定された裁判例もあります（札幌高判 平成29年8月31日など）。

裁判・紛争に発展した場合の対応

システム開発紛争が裁判に発展した場合、以下の点が重要になります。

証拠の確保

メール、チャット、議事録、仕様書、見積書、発注書など、開発過程で交わされた一切の書類やデータが証拠となります。

特にチャットツールやメッセンジャーでのやり取りは、サービスの終了やデータの消去によって失われるリスクがあるため、早期にスクリーンショットやPDFで保全しておくことが重要です。

専門的知識が必要

システム開発紛争は、技術的な専門知識と法的知識の双方が求められる分野です。

要件定義書や設計書の内容を正確に理解したうえで法的な主張を組み立てる必要があるため、IT紛争の実務経験がある弁護士に相談することが推奨されます。

実際の解決事例

当事務所では、システム開発をめぐる紛争を実際に解決した実績があります。

システム開発の成果物をめぐる損害賠償請求を全面棄却した事例

あるシステム開発会社が、顧客企業からシステム開発を受注し、スクラッチ（一からの独自開発）でシステムを構築しました。

しかし、開発の実装段階において、顧客企業から「依頼した内容が実装されていない」として、数百万円の損害賠償を請求されました。

本件の特徴は、正式な契約書が存在しなかったという点です。

開発の合意はメッセンジャー等のやり取りで形成されており、要件定義の範囲が明確に文書化されていませんでした。

当事務所が被告側（開発会社側）の代理人として受任し、メッセンジャーの履歴を詳細に分析したうえで、以下の点を立証しました。

• 顧客が主張する機能は、当初の合意範囲には含まれていなかったこと
• 開発会社が実装した内容は、当初合意された仕様に合致していたこと
• 追加機能については別途見積もりを提示しており、費用の合意なく開発義務が生じるものではないこと

裁判所は当方の主張を全面的に認め、原告の請求を棄却しました。

相手方は控訴しましたが、控訴審においても控訴棄却の判決が下され、当方の全面勝訴が確定しました。

本件は、契約書が存在しない状況下でも、メッセンジャーの履歴等の間接的な証拠を丁寧に分析・整理することで、当方の主張を裁判所に認めてもらうことができた事例です。

トラブルを防ぐための予防策

システム開発紛争を未然に防ぐうえで、以下の対策が有効です。

1. 要件定義書の作成と合意

開発着手前に、機能一覧、画面遷移、データ構成など、開発するシステムの仕様を要件定義書として文書化し、双方が署名・押印のうえ合意します。

この文書が、後の紛争におけるもっとも重要な証拠となります。

2. 契約書の締結

業務委託契約書またはシステム開発契約書を締結し、開発範囲、納期、代金、支払条件、検収基準、契約不適合責任の範囲と期間、知的財産権の帰属などを明確に定めます。

3. 変更管理プロセスの導入

開発途中で仕様変更や追加要望が発生した場合の手続きを、契約書の中であらかじめ定めておきます。

変更の都度、変更内容・追加費用・スケジュールへの影響を書面で合意する仕組みを構築することが重要です。

4. 議事録・やり取りの記録保全

打ち合わせの議事録を作成し、双方が確認するプロセスを導入します。

また、メールやチャットのやり取りは定期的にバックアップし、証拠として保全しておきます。

5. 検収基準の明確化

「何をもってシステムが完成したとみなすか」という検収基準を、契約段階で明確に定めておきます。

検収基準が曖昧な場合、「完成していない」「いや完成している」という水掛け論に発展するリスクがあります。

当事務所のサポート

当事務所では、システム開発をめぐる紛争について、以下のサポートを提供しています。

• 紛争対応：
  損害賠償請求への対応、交渉代理、訴訟代理
• 契約書作成・レビュー：
  システム開発契約書、業務委託契約書の作成・チェック
• 予防法務：
  要件定義プロセスや変更管理プロセスの構築に関する法的アドバイス

システム開発に関するトラブルは、初期段階での対応が極めて重要です。

相手方から損害賠償を請求された場合はもちろん、開発プロジェクトの進行中にトラブルの兆候を感じた段階でも、早期の弁護士への相談により、紛争の拡大を防ぎ、適切な解決を図ることが可能です。

個別の事案ごとに最適な対応方針は異なりますので、お気軽にご相談ください。

お問い合わせはこちら

お問い合わせはこちら