システム開発を外部の開発会社に依頼していると、当初予定していたリリース日に間に合わない、開発が大幅に遅れている、いつ完成するのか分からない、といった問題が起こることがあります。
特に、業務システムや予約システム、販売管理システム、顧客管理システムなどでは、リリースが遅れることで業務開始ができなかったり、売上機会を逃したり、社内の準備が無駄になったりすることがあります。
このような場合、発注者側としては、
「開発会社に損害賠償を請求できるのか」
「すでに支払った費用を返してもらえるのか」
「遅延によって発生した損害をどこまで請求できるのか」
「契約書に何が書いてあれば請求しやすいのか」
といった点が気になると思います。
結論から言うと、システム開発のリリース遅延について、開発会社に損害賠償を請求できる可能性はあります。
ただし、単に「納期に遅れた」というだけで、必ず損害賠償が認められるわけではありません。
実際には、契約内容、遅延の原因、発注者側の協力状況、仕様変更の有無、損害の内容、証拠の有無などを総合的に確認する必要があります。
この記事では、中小企業がシステム開発のリリース遅延で損害賠償を検討する際に、まず確認すべきポイントを実務目線で整理します。
システム開発の遅延で損害賠償を請求できる可能性はある
システム開発の契約では、開発会社が契約で定められた内容に従ってシステムを完成させ、納品またはリリースする義務を負う場合があります。
そのため、契約で定めた納期やリリース日に間に合わず、その遅延について開発会社側に責任がある場合には、発注者が損害賠償を請求できる可能性があります。
ただし、実務上は「遅れたからすぐに請求できる」という単純な話ではありません。
システム開発は、発注者と開発会社がやり取りをしながら進める共同作業の性質があります。
そのため、遅延の原因が開発会社にあるのか、発注者側の仕様変更や確認遅れにあるのか、双方に原因があるのかを確認する必要があります。
まず確認すべきは契約書の内容
リリース遅延で損害賠償を検討する場合、最初に確認すべきなのは契約書です。
特に、次の項目を確認します。
- 納期・リリース日が明確に定められているか
- 開発範囲や成果物が明確になっているか
- 検収条件が定められているか
- 遅延時の対応が定められているか
- 損害賠償の範囲が制限されていないか
- 遅延損害金や違約金の定めがあるか
- 契約解除の条件が定められているか
- 発注者側の協力義務が定められているか
契約書にリリース日や納期が明確に書かれていない場合、そもそも「いつまでに完成すべきだったのか」が争点になりやすくなります。
また、納期が書かれていても、その後のメールや打ち合わせでスケジュール変更に合意していた場合は、当初の納期だけを根拠に請求することが難しくなる場合があります。
納期変更に合意していなかったかを確認する
システム開発では、途中で仕様変更や追加要望が発生することがあります。
その結果、当初のスケジュール通りに進まなくなり、開発会社から納期延長を求められることがあります。
このとき、発注者側が明確に合意していなかったとしても、メールやチャット、打ち合わせ内容から、事実上スケジュール変更を受け入れていたと判断される可能性があります。
たとえば、次のようなやり取りがある場合は注意が必要です。
- 開発会社から新しいスケジュール表が送られ、それに異議を出していない
- リリース延期を前提に打ち合わせを続けている
- 追加仕様を依頼し、その分の開発期間延長を認めている
- 当初納期を過ぎた後も、通常通り開発を継続させている
- 納期遅延について明確な催告や抗議をしていない
このような場合、「当初の納期から遅れている」と主張しても、実際には納期変更があったと見られる可能性があります。
そのため、リリース遅延で損害賠償を検討する場合は、契約書だけでなく、メール、チャット、議事録、スケジュール表も確認する必要があります。
遅延の原因がどちらにあるのかを整理する
損害賠償を請求するうえで重要なのは、遅延の原因です。
開発会社側に主な原因がある場合と、発注者側にも原因がある場合では、請求のしやすさが大きく変わります。
開発会社側の責任になりやすい例
- 契約で定めた納期を守らなかった
- 開発体制が不足していた
- 進捗報告が不十分だった
- 必要な技術力が不足していた
- 重大な不具合が多くてリリースできる状態ではなかった
- 発注者から必要な情報を受け取っていたのに作業が進んでいなかった
- 遅延が発生しているのに早期に報告しなかった
発注者側にも原因があると見られやすい例
- 仕様決定が遅れた
- 必要な資料やデータの提供が遅れた
- 確認依頼への返答が遅れた
- 途中で大幅な仕様変更や追加要望を出した
- 検収やテストの対応が遅れた
- 社内で意思決定がまとまらなかった
- 開発会社からの確認事項に回答していなかった
システム開発では、発注者側の協力がなければ進められない作業も多くあります。
そのため、開発会社に損害賠償を請求する場合でも、発注者側の対応に問題がなかったかを冷静に確認することが重要です。
損害賠償として請求できる可能性があるもの
リリース遅延によって発注者に損害が発生した場合、内容によっては損害賠償の対象になる可能性があります。
たとえば、次のようなものです。
- リリース遅延により発生した追加費用
- 代替システムや暫定対応にかかった費用
- 外部業者への追加依頼費用
- リリース延期に伴う告知・販促物の修正費用
- 延期により無駄になった準備費用
- 開発会社の責任でやり直しが必要になった作業費用
- 別会社へ引き継ぐために必要になった調査・移行費用
ただし、すべての損害を当然に請求できるわけではありません。
損害賠償を請求するには、一般的に、遅延と損害との因果関係や、損害額を説明できる資料が必要になります。
また、契約書に損害賠償の上限額が定められている場合もあります。
請求が難しくなりやすい損害
リリース遅延による損害の中には、請求が難しくなりやすいものもあります。
特に注意したいのは、次のような損害です。
- 本来得られるはずだった売上
- 将来の利益
- 信用低下による損害
- 顧客離れによる損害
- 社内対応にかかった人件費
- 精神的負担や社内混乱に関する損害
これらは、遅延との因果関係や金額の算定が難しく、請求しても争いになりやすい項目です。
特に「リリースが予定通りであればこれだけ売上があったはず」という主張は、根拠資料が弱いと認められにくい場合があります。
そのため、損害賠償を検討する場合は、まずは請求しやすい実費や追加費用から整理するのが現実的です。
契約書の損害賠償制限条項に注意
システム開発契約では、損害賠償について上限が定められている場合があります。
たとえば、次のような条項です。
本契約に関連して発生した損害賠償責任は、当該契約に基づき受領した委託料の総額を上限とする。
このような条項がある場合、発注者に大きな損害が発生していたとしても、請求できる金額が契約金額の範囲に制限される可能性があります。
また、間接損害、特別損害、逸失利益などを除外する条項が入っていることもあります。
そのため、リリース遅延で損害賠償を検討する場合は、契約書の損害賠償条項を必ず確認する必要があります。
損害賠償を検討する前に集めておきたい証拠
損害賠償を請求するには、感情的に「遅れて困った」と伝えるだけでは不十分です。
いつ、何が、どのように遅れ、どのような損害が発生したのかを示す資料が必要になります。
最低限、次のような資料を整理しておくとよいでしょう。
- 契約書
- 見積書
- 発注書
- 仕様書
- 要件定義書
- スケジュール表
- 進捗報告書
- 議事録
- メール
- チャット履歴
- 開発会社からの遅延報告
- 不具合一覧
- テスト結果
- リリース延期によって発生した費用の請求書や領収書
- 代替対応にかかった費用の資料
特に重要なのは「時系列」です。
「いつ契約したのか」「いつリリース予定だったのか」「いつ遅延が判明したのか」「誰が何を依頼したのか」「どの時点で何が未完了だったのか」を整理することで、状況を説明しやすくなります。
開発会社へ連絡する前に整理すべきこと
損害賠償を検討する場合でも、最初から強い表現で請求するのはおすすめできません。
まずは、事実確認と今後の対応を求める形で進めるのが現実的です。
開発会社へ連絡する前に、次の点を整理しておきます。
- 現在の開発状況
- 未完成の範囲
- 当初のリリース予定日
- 現在の遅延日数
- 遅延の原因についての開発会社の説明
- 発注者側の未対応事項が残っていないか
- 今後完成する見込みがあるのか
- リリース延期によって発生した具体的な損害
- 契約解除を検討するのか、継続を前提にするのか
これらを整理しないまま感情的に連絡すると、話し合いがこじれやすくなります。
まずは書面で説明を求める
リリース遅延が発生している場合、まずは開発会社に対して、書面やメールで状況説明を求めることが重要です。
たとえば、次のような内容を確認します。
- 現在の進捗状況
- 未完了の作業内容
- 遅延の原因
- 今後の修正スケジュール
- 新しいリリース予定日
- 追加費用の有無
- 発注者側で対応が必要な事項
- 再発防止策
この段階では、いきなり損害賠償を強く請求するよりも、まずは事実を明確にすることが重要です。
開発会社からの回答内容は、その後の交渉や専門家への相談時にも重要な資料になります。
催告・契約解除・損害賠償請求は慎重に進める
開発会社が明らかに納期を守らず、完成の見込みも不明確な場合には、発注者側として、催告、契約解除、損害賠償請求を検討することがあります。
ただし、契約解除や損害賠償請求は、対応を誤ると発注者側にもリスクが生じます。
たとえば、発注者側が一方的に契約を解除したと見られると、逆に開発会社から報酬や損害賠償を請求される可能性もあります。
そのため、次のような対応をする前には、契約書や証拠を整理したうえで、必要に応じて弁護士などの専門家へ相談することをおすすめします。
- 契約解除通知を送る
- 支払い済み費用の返金を求める
- 損害賠償請求書を送る
- 開発を別会社へ引き継ぐ
- ソースコードやデータの引き渡しを求める
- 開発会社との契約を打ち切る
特に、すでに高額な費用を支払っている場合や、事業開始に大きく影響している場合は、早めに専門家へ相談した方が安全です。
開発を継続する場合に確認すべきこと
損害賠償を請求するかどうかとは別に、開発を継続する場合は、今後の進め方を明確にする必要があります。
そのまま曖昧な状態で開発を続けると、さらに遅延が広がる可能性があります。
開発を継続する場合は、次の点を文書で確認しておくとよいでしょう。
- 残作業の一覧
- 修正すべき不具合の一覧
- 新しいリリース予定日
- テスト期間
- 検収方法
- 追加費用の有無
- 遅延が再発した場合の対応
- 進捗報告の頻度
- 発注者側で対応する作業
- 開発会社側で対応する作業
特に、再設定したスケジュールについては、口頭ではなくメールや議事録で残しておくことが重要です。
別会社へ引き継ぐ場合に確認すべきこと
開発会社との継続が難しい場合、別会社へ開発を引き継ぐこともあります。
その場合、次の資料やデータが必要になります。
- ソースコード
- データベース設計書
- 仕様書
- 要件定義書
- 画面設計書
- サーバー情報
- ドメイン・SSL・クラウド環境の情報
- 管理画面のアカウント情報
- 使用しているライブラリや外部サービスの情報
- 不具合一覧
- テスト結果
ただし、契約内容によっては、ソースコードや設計書が納品対象に含まれていない場合があります。
そのため、別会社への引き継ぎを検討する場合も、契約書の納品物や成果物の範囲を確認する必要があります。
発注者側にも記録管理が必要
システム開発の遅延トラブルでは、開発会社の責任だけでなく、発注者側の対応も確認されます。
そのため、発注者側も次のような記録を残しておくことが重要です。
- いつ仕様を確定したか
- いつ資料を提供したか
- いつ確認依頼に回答したか
- いつ追加要望を出したか
- 開発会社からの質問にどう回答したか
- 社内確認でどの程度時間がかかったか
- 検収時にどのような指摘をしたか
これらの記録が残っていないと、後から「発注者側の確認が遅かった」「仕様が固まらなかった」と主張される可能性があります。
損害賠償を請求するかどうかに関係なく、システム開発では発注者側の記録管理も重要です。
中小企業が注意したいポイント
中小企業のシステム開発では、正式な契約書や詳細な仕様書を作らずに、見積書とメールだけで開発が始まることがあります。
しかし、リリース遅延や未完成トラブルが起きると、次のような問題が出やすくなります。
- 納期が明確でない
- 開発範囲が曖昧
- 追加要望か当初範囲内か判断できない
- 検収条件が決まっていない
- 損害賠償の条件が分からない
- ソースコードやデータの引き渡し条件が不明
- 開発会社を変更しにくい
このような状態では、トラブルが起きた後に発注者側が不利になることがあります。
そのため、開発前の段階で、最低限の契約条件と資料管理の方法を決めておくことが大切です。
リリース遅延を防ぐために事前に決めておきたいこと
リリース遅延による損害賠償を検討する前に、本来は遅延を防ぐための管理が重要です。
開発を依頼する前に、あらかじめ次の点を決めておくとトラブルを減らしやすくなります。
- 要件定義の範囲
- 開発範囲
- 納品物
- リリース予定日
- 中間確認のタイミング
- 発注者側の確認期限
- 仕様変更時の手続き
- 追加費用の判断基準
- 検収条件
- 遅延時の対応
- 損害賠償の範囲
- 契約解除の条件
システム開発では、契約時点で曖昧な部分が多いほど、後からトラブルになりやすくなります。
特に、リリース日が事業計画や営業開始日に直結する場合は、納期や遅延時の対応を契約書で明確にしておくことをおすすめします。
まとめ
システム開発のリリース遅延について、開発会社に損害賠償を請求できる可能性はあります。
ただし、実際に請求できるかどうかは、契約内容、遅延の原因、発注者側の協力状況、損害の内容、証拠の有無によって変わります。
特に重要なのは次の点です。
- 契約書に納期やリリース日が明記されているか
- 納期変更に合意していなかったか
- 遅延の原因が開発会社側にあるか
- 発注者側の確認遅れや仕様変更がなかったか
- 損害額を証明できる資料があるか
- 契約書に損害賠償の上限や除外条項がないか
- メール、議事録、進捗報告などの証拠が残っているか
リリース遅延が発生した場合は、感情的に請求するのではなく、まずは契約書と時系列、証拠資料を整理することが大切です。
そのうえで、開発会社に状況説明を求め、必要に応じて弁護士などの専門家へ相談しながら、損害賠償請求、契約解除、開発継続、別会社への引き継ぎを検討するのが現実的です。
IT顧問のITAでは、システム開発トラブルの整理をサポートしています
IT顧問のITAでは、八王子市を中心に、中小企業・小規模事業所様のIT運用やシステム導入、開発会社とのやり取りを実務目線でサポートしています。
「開発会社のリリースが遅れて困っている」
「契約書や見積書の内容をIT面から整理したい」
「開発会社に何を確認すればよいか分からない」
「別会社へ引き継げる状態か確認したい」
「損害賠償を検討する前に、まず状況を整理したい」
このようなお悩みがありましたら、お気軽にご相談ください。
損害賠償請求や契約解除などの最終的な法的判断は弁護士などの専門家の領域ですが、IT面でどの資料を確認すべきか、開発会社に何を聞くべきか、今後の運用や引き継ぎにどのようなリスクがあるかを整理するお手伝いが可能です。
※本記事は、システム開発におけるリリース遅延トラブルについて、一般的な確認ポイントを整理したものです。個別の契約内容や損害賠償請求の可否については、弁護士などの専門家へご相談ください。
