システム開発案件で損害賠償責任が発生する主な要因と裁判例
全国20拠点以上！安心の全国対応
記事目次
システム開発の受託案件では、開発を依頼したユーザー側の企業と開発を担当するベンダーとの間で、認識の違い等からトラブルが生じて、法的紛争に発展することは珍しいことではありません。法的紛争に発展した場合、双方が多額の損害賠償責任を問われる可能性があるため、注意が必要です。
今回は、システム開発で損害賠償責任が発生する法的根拠、損害賠償の範囲と上限を定める契約書の責任限定条項、システム開発案件で損害賠償責任が発生する主な要因、システム開発を巡る損害賠償請求の裁判例などについて解説します。
システム開発で損害賠償責任が発生する法的根拠
システム開発契約は請負契約（民法第632条）に分類されることが多いです。そのため、納品したシステムに欠陥があるなど、仕事が完成していないと判断される場合は、損害賠償責任を負います（同法第415条第１項）。
また、仕事が完成したとしても、目的物が契約の内容に適合しない場合は代替物の引き渡しなど履行の追完や代金減額を請求されることがあります（民法第562条、第563条、第559条本文）。また、債務者に帰責事由がある場合は、これらに加えて損害賠償を請求されることもあります（同法第564条、第559条本文、第415条第１項）。
債務者に帰責事由がない場合には、損害賠償責任は免責されます（この場合も、履行の追完や代金減額の責任は残ります）、どのような場合に免責されるのかにつき、「契約その他の債務の発生原因及び取引上の社会通念に照らして」判断されます（同法第415条第１項但し書）。この文言から読み取れるように、債務者の帰責事由の有無は、契約内容だけでなく契約の性質・当事者の契約締結の目的・契約締結当時の取引慣習等の諸般の事情を考慮して判断されることとなります。また、填補賠償（債務の履行に代わる損害賠償請求）が可能な場合もあります（同法第415条第２項）。
損害賠償の範囲と上限を定める契約書の責任限定条項
システム開発でトラブルが生じた場合、業務に支障が生じることによる損害やビジネスチャンスの喪失など、膨大な損害が生じるおそれもあります。システム開発を担当した会社がその損害の全てを負うのは非常に大きなリスクとなります。そのため、通常は、システム開発を開始する際に締結する契約書で、損害賠償の範囲と上限を定めます。損害賠償の範囲と上限を定める規定は、システム開発を担当した会社が負う責任を限定することから、責任限定条項と呼ばれています。
1．損害賠償の範囲に関する規定
①逸失利益の除外
システムに不具合があり、システムが停止した場合、システムの停止により業務に支障が生じて、ユーザー側の企業が本来得られるはずの利益が得られない場合があります。このような本来得られるはずだったのに得られなかった利益のことを、逸失利益といいます。システム開発を巡る法的紛争の場では、逸失利益が問題になることも多く、逸失利益は膨大な金額になる可能性もあるため、契約書の損害賠償に関する規定の中に、逸失利益を除く旨を定めることは重要なポイントとなります。
なお、IT業界で用いられている契約書の中には、逸失利益を損害賠償の対象外とするために、「直接かつ現実的に生じた損害に限る」と記載されているケースも散見されますが、逸失利益を除くことを明記した方が望ましいでしょう。
②通常損害と特別損害
民法第416条には、通常損害と特別損害の２つの種類の損害について規定されています。それぞれの損害の定義は以下の通りです。
- 通常損害：通常生ずべき損害（相当因果関係が認められる損害）（同法同条１項）
- 特別損害：債務者が予見すべき特別な事情により生ずる損害（同法同条2項）
損害賠償の範囲に特別損害を含めると、想定外の事情によりシステムのトラブルが発生して、業務が停止した場合に、予見すべき特別な事情の有無について当事者間で争いになる可能性があります。そのため、特別損害は損害賠償の対象外とするのが通常です。
なお、損害賠償の範囲から特別損害を除外する場合、「通常損害に限る」と記載するだけではなく、「特別損害を除く」と明記することが望ましいです。
2．損害賠償額の上限に関する規定
システム開発を巡る裁判では、膨大な金額の損害賠償を求められることも少なくありません。そのため、多くの契約書では、損害賠償額の上限が定められています。上限の金額は、システム開発の委託料とするのが一般的です。
このような規定を設けることにより、相当因果関係が認められて損害の範囲が非常に広範になった場合でも、実際に支払う損害賠償の額は、契約書に記載された上限とすることが可能です。
損害賠償責任を負う期間と起算点
システム開発のプロジェクトが終了後、どの程度の期間まで、損害賠償責任を問われる可能性があるのでしょうか。損害賠償責任を負う期間と起算点について説明します。
1．損害賠償責任を負う期間と起算点の原則
2020年4月に施行された改正民法により、瑕疵担保責任が契約不適合責任に変わりました。瑕疵担保責任を負う期限は、納品物の引き渡し時から1年以内だったのに対し、契約不適合責任を負う期限は、契約不適合の事実を知った時から1年以内となります（改正民法第637条1項）。このように起算点が変更されたことにより、ベンダーが責任を負う期間が大幅に延長される可能性があります。
例えば、システムを納品してから4年後に、ユーザー側の企業が、契約不適合に該当するシステムの不具合に気づいた場合、その時点から1年以内、つまり納品から5年後も責任を負うことになります。
2．契約書に起算点を定めることも可能
システム開発の受託案件では、システムが完成した後、ユーザー側の企業が受け入れテストを実施して、検収を行います。検収で不具合が発覚した場合、ベンダーが不具合を修正し、再度、テストと検収が行われます。そのような過程を経て、システムが本番環境で稼働することになります。
検収はあくまでもシステムが報酬を支払うための条件を満たすかを確認するために行われるものですが、受け入れテストを行うことにより、システムの不具合をある程度洗い出すことが可能です。そのため、契約不適合責任の期限の起算点を、民法の原則である「契約不適合の事実を知った時」ではなく「検収完了時点」と契約書で定めているケースもあります。「検収完了時点」を起算点とすることにより、ベンダーが責任を負う期間が大幅に延長されるリスクを回避することが可能です。
このように、契約書は、損害賠償に関するリスクを回避するために重要な役割を果たすものなので、しっかりと内容を精査しておきましょう。
システム開発案件で損害賠償責任が発生する主な要因
システム開発を巡り、損害賠償責任が発生する主な要因について説明します。
1．要件定義の不備
システム開発の初期段階で行う要件定義に不備があることが要因となり、システム開発を担当するベンダーと開発を委託したユーザー側の企業との間でトラブルが生じ、法的紛争に発展するケースは非常に多いです。
要件定義は、ユーザー側の企業が開発するシステムに対して求める機能や性能を全て洗い出す作業です。要件定義に抜け漏れや誤りがあると、ユーザー側の企業が期待するシステムを開発することは不可能です。ユーザー側の企業の期待に沿うシステムが提供できないと、ユーザー側の企業との紛争に巻き込まれるリスクが高まるため、要件定義はシステム開発の根幹となる非常に重要な工程です。
抜け漏れのない要件定義を行うためには、ユーザー側の企業の協力が不可欠です。特に、開発するシステムの対象となる業務に従事している現場の従業員へのヒアリングは重要なポイントとなるので、十分に時間をかけて行うことをおすすめします。
2．仕様変更・追加による開発遅延
要件定義が完了し、プログラムの開発フェーズに入った後に、ユーザー側の企業の要望により、仕様変更や機能追加が必要になることは少なくありません。しかし、開発フェーズに入った後に、仕様変更や機能追加を行うと、開発スケジュールに遅延が生じます。スケジュールの遅延は、テスト不足による重大な不具合の発生などのトラブルにつながる可能性もあります。
仕様変更や機能追加が必要になった場合は、リスケジュールをする、今回は見送って新たな開発案件として対応するなどの適切な調整を行うことが大切です。契約書に記載のある納期などスケジュールについても、調整が必要になることがあります。
システム開発を巡る損害賠償請求の裁判例
最後に、IT業界では有名な、電子カルテを中心とした大学病院の情報管理システムの開発を巡る裁判例をご紹介します。
1．事件の概要
この事件は、大学病院の情報管理システムの開発を大手システム開発会社が受託した案件で、度重なる仕様変更が原因となり、大規模な法的紛争に発展したケースです。
この開発案件では、仕様確定の予定日を過ぎても、システムのエンドユーザーである現場の医師達から1000近くにのぼる要件追加や仕様変更の要望が続々と寄せられました。そこで、システム開発会社は、1000近くの要望のうち625項目を受け入れた上で、仕様凍結（これ以上の要件追加・変更は行なわないこと）の合意をし、納期も延長することが決まりました。
しかし、仕様凍結後も現場の医師達からの要望は止まず、さらに171項目の追加要求を含めて開発を継続しましたが、一部に不具合が発生し、ユーザー側による到達度評価で不合格となり、開発は頓挫しました。
その後、大学病院はシステム開発会社に対し、システム導入失敗に伴う逸失利益として約19億４千万円を請求しました。これに対し、システム開発会社は大学病院に対して不当な受領拒絶による損害として、約22億8千万円を請求しました。
2．第一審判決の内容
第一審（旭川地方裁判所平成28年3月29日判決）では、仕様凍結合意の後に大学病院が開発要望を出したことは、仕様凍結合意に違反すると判断されました。しかし、システム会社側が適切に進捗管理を行うプロジェクトマネジメント義務を果たしていないとされ、ユーザーとベンダーの過失割合を２：８とし、双方の請求とも一部が認容される結果となりました。この判決に対し、双方ともが控訴をしました。
3．控訴審判決では逆転の結果に
控訴審（札幌高等裁判所平成29年8月31日判決）は、一審判決を取り消し、大学病院側のみに約14億円の支払いを命じるという、逆転判決となりました。
控訴審では、システム会社が行った以下の2つの対応を根拠に、同社の対応にロジェクトマネジメント義務はなかったと認められたのです。
- システム開発会社は、大学病院側が要望する追加開発の多くは仕様外であり、追加開発を行った場合はシステムの稼働が予定日に間に合わなくなる旨を大学病院に対して繰り返し説明していた
- システム開発会社が、大学病院側の追加要望を受け入れた上で、仕様凍結の合意を取り付けていたこと
大学病院側は判決を不服として、最高裁判所に上告しましたが、上告不受理の決定が下されて、判決は確定しました。
4．プロジェクトマネジメント義務と協力義務
システム開発会社のプロジェクトマネジメント義務違反については、地方裁判所と高等裁判所で判断が別れました。従来は、システム開発が頓挫した場合、ベンダー側とユーザー側の双方に落ち度がある場合が多く、ベンダー側にはプロジェクトマネジメント義務違反、ユーザー側には協力義務違反が認められるという考え方が基本でした。
しかし、本件控訴審の判決では、ベンダー側がプロジェクトマネジメント義務を果たしたと判断され、ユーザー側に非があることが全面的に認められました。この点で、本判決は従来とは異なる画期的な考え方を示したといわれています。
まとめ
今回は、システム開発で損害賠償責任が発生する法的根拠、損害賠償の範囲と上限を定める契約書の責任限定条項、システム開発案件で損害賠償責任が発生する主な要因、システム開発を巡る損害賠償請求の裁判例などについて解説しました。
システム開発の失敗に関する損害賠償責任を巡り、ユーザー側とベンダー側が争う場合、どこまでがユーザー側の責任で、どこまでがベンダー側の責任であるかの判断は非常に難しい場合が多いです。法的紛争に発展する可能性がある場合は、自社に非がないことを証明するための証拠を集める必要があるため、早めにIT業界に精通した弁護士に相談することをおすすめします。
東京スタートアップ法律事務所では、IT業界の商慣習や法律問題に精通した弁護士が、様々な企業のニーズを丁寧にヒアリングした上で適切なサポートを提供しております。システム開発を巡るトラブルに関する相談等がございましたら、お気軽にご連絡いただければと思います。
