システム開発の損害賠償：請求できる範囲と立証（遅延・瑕疵・再開発費用）

システム開発の損害賠償では、「システムが予定どおり動かなかった」「納期に遅れた」「別ベンダーに作り直しを依頼した」という事情だけで、発生した費用をすべて請求できるわけではありません。請求する側は、契約上どの義務に違反したのか、その違反と損害に因果関係があるのか、請求額が相当な範囲に収まるのかを、資料に基づいて説明する必要があります。

一方、請求を受ける受託者・ベンダー側も、単に「開発は難しかった」「仕様が変わった」と反論するだけでは足りません。契約書、要件定義、仕様書、議事録、課題管理表、検収資料、障害ログ、責任制限条項を確認し、どの損害を認め、どの損害を争うのかを早期に切り分ける必要があります。

システム開発の損害賠償で最初に整理すること

システム開発の損害賠償は、まず「契約上の義務違反」と「損害項目」を分けて整理します。契約違反があるかどうかと、いくら請求できるかは別問題です。仮に受託者側の債務不履行や契約不適合が認められる場合でも、請求できるのは、その違反と相当因果関係のある損害に限られます。

実務では、次の四つを順番に確認します。

この順序を飛ばして、発生した費用の総額だけを請求すると、相手方から「どの不具合に対応する費用なのか」「当初仕様ではなく追加要望ではないか」「発注者側の確認遅れが原因ではないか」と反論されやすくなります。

追加報酬請求との違い

システム開発では、「追加費用」という言葉が、損害賠償と追加報酬の二つの意味で使われることがあります。しかし、両者は法的には分けて考える必要があります。

損害賠償は、相手方の契約違反や不法行為によって損害が発生した場合に、その損害の填補を求めるものです。これに対し、仕様変更・追加開発・契約外作業について、受託者が追加の対価を求める場面は、基本的には追加報酬・追加費用請求の問題です。

本記事では、追加開発の対価そのものではなく、遅延、瑕疵・バグ、未完成、再開発、データ障害などを理由とする損害賠償に絞って説明します。

請求対象になり得る損害の種類

システム開発の損害賠償で問題になりやすい損害は、いくつかの類型に分けられます。請求書や交渉資料を作るときも、損害項目を混ぜずに分類することが重要です。

再開発費・修補費

成果物が契約上の仕様を満たしていない場合、発注者が別ベンダーに修補や再開発を依頼した費用が損害として問題になることがあります。ただし、再開発費が常に全額認められるわけではありません。元の成果物のどこが仕様に適合していなかったのか、修補では足りず再開発が必要だったのか、別ベンダーの費用が合理的な範囲かが争点になります。

再開発費の中に、当初仕様を超える機能追加、業務改善、性能向上、UI刷新などが含まれている場合、その部分は損害から除外又は減額される可能性があります。請求する側は、契約違反を補うために必要だった部分と、追加改善部分を分けて説明する必要があります。

代替運用費・暫定対応費・データ復旧費

システム障害や納品遅延により、手作業で業務を継続した、外部サービスを一時利用した、データ復旧業者に依頼した、といった費用も損害として主張されることがあります。これらは比較的説明しやすい損害ですが、障害や遅延との因果関係、費用の合理性、損害拡大を防ぐための対応だったかが問題になります。

証拠としては、障害発生日、影響範囲、暫定対応の内容、外注先の見積・請求書、社内作業記録、復旧完了日を時系列で整理します。単に「現場が混乱した」という説明だけでは、金額の立証としては弱くなります。

納期遅延による損害

納期遅延では、まず「いつまでに何を納品する義務があったか」を確定します。契約書上の納期、検収完了日、段階納品日、リリース日、マイルストーンの位置づけを確認し、どの時点から遅延と評価できるかを整理します。

次に、遅延の原因を確認します。受託者側の進行管理不足や設計ミスが原因なのか、発注者側の要件確定遅れ、レビュー遅れ、データ提供遅れ、追加要望が原因なのかによって、損害賠償の見通しは大きく変わります。

遅延損害金や違約金条項がある場合は、その条項の発生条件、上限、免責事由も確認します。条項がない場合でも、遅延によって発生した代替費用や追加人員費用を請求できる余地はありますが、具体的な因果関係と金額根拠が必要です。

逸失利益・機会損失

システムのリリース遅延や不具合により、予定していた売上、コスト削減、顧客獲得、事業機会を失ったとして、逸失利益や機会損失が主張されることがあります。

もっとも、逸失利益は、システムが予定どおり完成していれば実際に利益が出たといえるか、他の要因で利益が減った可能性はないか、算定式が合理的かが厳しく問われます。新規事業や新サービスの場合、過去実績がないため、売上予測や事業計画だけでは立証が不十分と評価されることがあります。

請求する側は、過去の売上実績、契約済み顧客、受注確度、粗利率、代替手段の有無、リリース遅延期間を整理する必要があります。請求される側は、市場要因、発注者側の準備不足、広告・営業活動の不足、既存システムや外部環境の問題など、他原因を検討します。

社内人件費・調査費・弁護士費用

発注者側の担当者が障害対応や再調整に多くの時間を費やした場合、社内人件費を損害として主張することがあります。ただし、通常業務の範囲内か、追加で発生した損害といえるか、時間と単価が合理的かが争われやすい類型です。

原因調査費、第三者レビュー費、専門家意見書作成費は、紛争解決や原因究明に必要だった費用として請求されることがあります。弁護士費用は、債務不履行だけの場合には当然に全額請求できるものではなく、不法行為性や契約条項、訴訟上の扱いにより整理が必要です。

瑕疵・バグと契約不適合の立証

バグがあるからといって、直ちに損害賠償が認められるわけではありません。システム開発では、一定の不具合修正を前提に検収や運用開始が行われることも多く、問題の不具合が契約上の仕様不適合なのか、軽微な調整事項なのか、発注者側の運用・設定・データの問題なのかを分けて検討する必要があります。

契約不適合については、システム開発の契約不適合責任で詳しく扱っています。損害賠償を検討する場合でも、まずは契約不適合の有無、追完請求、代金減額、解除との関係を整理することが出発点になります。

請求する側は、感覚的に「使えないシステム」と主張するのではなく、どの仕様に対して、どの機能が、どの程度不適合なのかを特定する必要があります。

プロジェクトマネジメント義務と協力義務

システム開発の損害賠償では、成果物の不具合だけでなく、プロジェクトの進め方そのものが問題になることがあります。受託者には、開発工程を管理し、遅延や仕様不確定などの問題を把握し、必要な働きかけを行う義務が問題になります。発注者にも、要件確定、資料提供、レビュー、承認、テスト協力など、開発に協力する義務が問題になります。

そのため、遅延や頓挫の原因を検討するときは、「ベンダーが遅れた」「ユーザーが協力しなかった」と抽象的に整理するのではなく、どの時点で、誰が、どのタスクを、どの程度遅らせたのかを時系列で確認します。

責任制限条項・免責条項の確認

システム開発契約では、損害賠償額の上限を契約金額や一定期間の利用料に限定する条項、間接損害・逸失利益・特別損害を除外する条項、請求期限を短くする条項が置かれていることがあります。損害額の計算を始める前に、これらの条項を確認する必要があります。

責任制限条項がある場合、請求する側は、条項がどの損害に適用されるのか、故意・重過失、秘密保持義務違反、個人情報漏えい、知的財産権侵害などの例外があるかを確認します。請求される側は、条項の文言、適用対象、上限額、間接損害排除の範囲を確認し、請求額が上限を超えていないかを検討します。

特に情報漏えい、セキュリティ事故、重大な説明義務違反、プロジェクトの大規模頓挫では、契約金額を超える損害が主張されることがあります。責任制限条項をめぐる争いでは、契約交渉時の資料、条項の位置づけ、例外規定、リスク配分の合意内容が重要になります。

裁判例から見る実務上の注意点

システム開発の裁判例では、単に「システムが完成しなかった」「不具合があった」という結果だけでなく、要件定義、プロジェクト管理、ユーザーの協力、責任制限条項、損害額の相当性が細かく検討されます。

プロジェクト管理とユーザー協力

東京地裁平成16年3月10日判決は、オーダーメイド型のシステム開発で、ベンダーのプロジェクトマネジメント義務とユーザーの協力義務が問題になった代表的な裁判例として知られています。開発が頓挫した場合、ベンダー側の管理不足だけでなく、ユーザー側の関与や協力の有無も損害賠償の判断に影響します。

情報漏えい・セキュリティ事故

東京地裁平成26年1月23日判決は、ECサイトの受注システムにおけるセキュリティ対策不足によりクレジットカード情報が流出した事案として知られています。このような事案では、技術的な脆弱性の有無だけでなく、当時一般に求められていた対策、契約条項、秘密保持・個人情報関連条項、責任制限条項の関係が問題になります。

大規模開発と責任制限条項

大規模システム開発では、責任制限条項があるかどうかで賠償額の見通しが大きく変わります。東京高裁平成25年9月26日判決などでも、大規模開発の中止、説明義務、プロジェクト管理、責任制限条項の解釈が問題になっています。裁判例からも、契約書の責任制限条項は、紛争後ではなく契約締結時から具体的に設計しておく必要があることが分かります。

発注者側が請求するときの整理

発注者側が損害賠償を請求する場合は、まず感情的な不満と法的に請求できる損害を分ける必要があります。使えないシステムになったことへの不満が大きくても、請求書には、法的に説明できる損害項目を載せる必要があります。

発注者側は、請求額を大きく見せることよりも、争いにくい損害項目から組み立てることが重要です。代替ベンダー費用や復旧費用のように証拠がある損害、責任制限条項の範囲内で説明しやすい損害から整理すると、交渉が進みやすくなります。

受託者・ベンダー側が防御するときの整理

受託者側が高額な損害賠償請求を受けた場合、まず請求全体を一括して否定するのではなく、項目ごとに分解します。認めざるを得ない部分、契約上の責任制限で上限がある部分、因果関係を争える部分、発注者側要因を主張できる部分を分けます。

受託者側の防御では、現場担当者の説明だけで方針を決めるのは危険です。契約書、議事録、チケット、メール、ソース管理、テスト結果、障害ログを突き合わせ、客観資料と矛盾しない主張に整理する必要があります。

証拠として整理すべき資料

損害賠償の交渉では、証拠の整理が結論を左右します。裁判になった場合だけでなく、内容証明や交渉書面を出す前の段階でも、資料を時系列に並べることが重要です。

契約と仕様を示す資料

トラブルの発生と原因を示す資料

損害額を示す資料

証拠は、単に多く集めればよいわけではありません。どの契約違反が、どの損害に、どの証拠でつながるのかを一つの表にまとめると、交渉でも訴訟でも説明しやすくなります。

交渉・訴訟での進め方

システム開発の損害賠償は、技術論、契約論、損害論が絡むため、早い段階で争点を絞ることが重要です。最初から全損害を満額で請求すると、相手方も全面的に争いやすくなります。

交渉では、損害項目を次のように分類します。

訴訟を見据える場合は、技術的原因について専門家の意見を取るか、ログや成果物を第三者が検証できる形で保存しておく必要があります。システム開発訴訟の全体像は、システム開発訴訟の流れと主な争点で整理しています。

請求前・防御前のチェックリスト

関連する論点との違い

システム開発の損害賠償は、契約不適合、追加費用、契約書なしの報酬請求、トラブル初動と隣接します。記事ごとに役割を分けると、論点を整理しやすくなります。

バグや仕様不適合について、追完、代金減額、解除、損害賠償のどれを選ぶかは、システム開発の契約不適合責任で扱っています。

仕様変更や追加開発により、受託者が追加の対価を請求したい場合は、システム開発の追加費用を請求できるかで扱っています。

契約書を作らないまま要件定義や試作に入った場合の報酬請求は、契約書なしのシステム開発で報酬請求できるかで整理しています。

炎上中の初動、証拠保全、交渉窓口の作り方は、システム開発トラブルの初動対応を確認してください。

よくある質問

システムが使えない場合、開発費全額を返金請求できますか。

システムが使えないからといって、常に開発費全額の返金や損害賠償が認められるわけではありません。契約の解除が認められるか、既に完成・利用できる部分があるか、発注者側の協力不足や仕様変更が影響していないか、責任制限条項があるかを確認する必要があります。

別ベンダーに作り直した費用は請求できますか。

請求できる余地はありますが、元の受託者の契約違反を補うために必要な範囲だったか、金額が合理的か、追加機能や改善費用が混ざっていないかが問題になります。別ベンダーの見積書・契約書・作業範囲を、元の仕様や不具合と対応させて整理する必要があります。

納期遅延があれば当然に損害賠償を請求できますか。

納期遅延があっても、遅延の原因が受託者側にあるか、発注者側の要件確定遅れやレビュー遅れが影響していないかを確認する必要があります。また、遅延によって具体的にどの損害が発生したかを示す必要があります。

逸失利益は認められますか。

逸失利益が認められる可能性はありますが、一般に立証のハードルは高いです。システムが予定どおり稼働していれば得られた利益を、過去実績、契約済み案件、粗利率、事業計画、遅延期間などから合理的に説明する必要があります。

責任制限条項があれば、請求をすべて拒否できますか。

責任制限条項があっても、すべての請求を当然に拒否できるとは限りません。条項の文言、適用対象、例外規定、故意・重過失、秘密保持義務違反、個人情報漏えいなどの事情によって結論が変わります。

追加開発の費用は損害賠償として請求するのですか。

当初仕様を超える追加開発の対価を請求する場合は、通常、損害賠償ではなく追加報酬・追加費用請求として整理します。発注者の追加依頼、承認、追加見積、作業内容、相当額を整理する必要があります。

まとめ

システム開発の損害賠償は、技術的な不具合の有無だけで結論が決まるものではありません。契約書、要件定義、検収、変更管理、ログ、責任制限条項、損害資料をつなげて、どの損害がどの義務違反から生じたのかを説明できるかが重要です。

関連記事