2020年4月に施行された改正民法では、旧民法で規定されていた瑕疵担保責任という概念が廃止され、代わりに契約不適合責任が定められました。
瑕疵担保責任が契約不適合責任に改定されたことにより、システム開発の受託案件において、具体的にどのような影響があるのか理解したいという方もいらっしゃるのではないでしょうか。
今回は、瑕疵担保責任と契約不適合責任の違い、契約不適合責任を問われた場合のリスク、契約不適合責任を巡るトラブル事例、リスク回避のために契約書に記載すべき事項などについて解説します。
瑕疵担保責任と契約不適合責任の違いと注意点
瑕疵担保責任から契約不適合責任に変わったことにより、システム開発を受託するベンダーが不利になるといわれていますが、具体的にどのような点で不利になるのでしょうか。瑕疵担保責任と契約不適合責任の違いのうち、特に注意が必要な点について説明します。
1．責任を負う期間の起算点が違う
瑕疵担保責任と契約不適合責任の違いの中で、最も注意が必要な点は、責任を負う期間の起算点の違いです。瑕疵担保責任と契約不適合責任の起算点は以下のとおりです。
- 瑕疵担保責任：納品物の引き渡しもしくは仕事完了時
- 契約不適合責任：契約不適合の事実を知った時
契約不適合責任の場合、契約不適合の事実を知った時、すなわち、クライアントがシステムのバグ（不具合）に気づいた時が起算点となる点に注意が必要です。納品してから２～３年後に日常業務ではほとんど使用しない例外的な処理の不具合が発覚した場合も責任を追及されてしまうのです。
契約不適合責任を追及できる権利は、5年経過後に時効で消滅しますが、5年の間に当時のシステムを開発した担当者と連絡が取れなくなる可能性もあります。責任を負う期間が、納品物の引き渡しから１年間だった瑕疵担保責任と比べて、ベンダー側が責任を追及される期間が大幅に延長されたことにより、ベンダー側が負うリスクは増大したことになります。
2．損害賠償の請求範囲の拡大
旧民法の瑕疵担保責任の損害賠償請求の範囲は信頼利益に限定されていました。信頼利益は、契約が成立しなかった場合に、契約が成立すると信じたことによって被った損害をいいます。
一方、契約不適合責任の損害賠償請求の範囲には、信頼利益に加えて履行利益も含まれます。履行利益は、契約が履行されていれば債権者が得られたはずなのに、契約が履行できなかったことが原因で得られなかった利益のことをいいます。
例えば、システム稼働予定日に稼働開始できなかったために営業不能となり、システムが予定通り稼働していれば得られたはずの営業利益を得られなかった場合、その期間に得られることが想定されていた営業利益は、履行利益に該当します。つまり、信頼利益に履行利益が追加されたことにより、瑕疵担保責任と比較して、損害賠償を請求される可能性のある範囲が大きく拡大したのです。
契約不適合責任を問われた場合のリスク
旧民法では瑕疵担保責任が認められた場合の主な責任追及手段は、損害賠償請求と契約解除でしたが、民法改正により、追完請求と代金減額請求が明文化され、責任を追及する側の選択肢が増えました。責任を問われる側が負うリスクについて説明します。
1．追完請求
改正民法では、契約不適合責任が認められる場合、発注側は受注側に対して履行の追完を請求できることが明文化されました（改正民法第562条）。履行の追完とは、受注側が行った仕事の内容が、契約の内容に適合していない場合、適合する状態にすることを意味します。システム開発においては、不具合（バグ）の修正等が該当します。
2．報酬減額請求
改正民法では、相当期間内に履行の追完が行われない場合や履行の追完が不可能な場合に、発注側から、不適合の程度に応じた報酬減額請求ができることも明文化されました（改正民法第563条）。
不具合（バグ）修正作業が予定より大幅に遅れる、技術的に修正不可能な不具合が発覚する等の場合、発注側の報酬減額請求が認められる可能性があります。
3．契約解除
旧民法では、契約目的が達成できない場合にのみ、契約解除が認められるとされていましたが、改正民法では、この限定はなくなりました。一般的な法定解除の要件を満たせば、債務不履行による解除が可能となりました。
4．損害賠償請求
旧民法では、瑕疵担保責任が認められた場合、ベンダー側に帰責事由があるか否かに関わらず、クライアントは損害賠償を請求することが可能でした。一方、改正民法では、債務不履行に基づく損害賠償請求をする要件として、ベンダー側の帰責事由が必要となります。そのため、ベンダー側は、帰責事由がない限り、損害賠償請求をされる可能性がなくなりました。
契約不適合責任を巡るトラブル事例
契約不適合責任を巡って起きるトラブルの典型的な例について説明します。
1．システムの不具合（バグ）を巡るトラブル
契約不適合責任を巡るトラブルで最も多いのは、やはりシステムの不具合（バグ）に起因するトラブルではないでしょうか。IT業界では、「システム開発にバグはつきもの」というのが常識的な考えかもしれません。しかし、この考えは、一般社会に浸透しているわけではありません。クライアントの中には、「システムは100%完璧に稼働するのが当たり前」と考えている方も多いです。そのため、軽微なバグが発覚した場合にも、契約不適合だと訴えられる可能性があります。
ただし、民法改正前に、システム稼働後に発見されたバグについての瑕疵担保責任が問題となった裁判例では、システムに多少のバグが残るのは不可避であり、バグの存在のみをもって瑕疵とは評価できないとされています（東京地方裁判所平成９年２月１８日判決）。この裁判例では、受注側が不具合発生の指摘を受けて遅滞なく補修を終えるか、発注側と協議の上で相当な代替措置を講じた場合は、瑕疵に該当しないため、損害賠償請求の対象にはならないとされています。現在は、改正民法により瑕疵担保責任が契約不適合責任に変更されましたが、バグの存在のみを根拠として損害賠償請求を行うことはできないという点は変わらないでしょう。ただし、バグが発覚した際に遅滞なく補修することができず、相当な代替措置を講じることもできない場合は、損害賠償請求が認められる可能性があるので注意が必要です。
2．納期遅延・プロジェクト中止を巡るトラブル
システム開発の受託案件では、当初のスケジュール通りに進まず、納期が遅れる、あるいはプロジェクト自体を中止せざるを得ない状況に陥ることは少なくありません。そのような場合に、お互いが被った損害を巡って対立して訴訟等に発展するケースも珍しくはありません。
クライアントが要件定義に協力しなかったために開発フェーズに入ってから仕様変更が多発し、その対応に追われて納期が遅れた場合、ベンダー側はクライアントの協力義務違反を主張することになります。実際、仕様確定後にクライアントから大量の追加要望が出されたケースで、クライアントの協力義務違反が認められ、ベンダーが勝訴した裁判例があります（札幌高等裁判所平成29年8月31日判決）。
他方、パッケージソフトを用いたシステム開発プロジェクトが中断したケースで、ベンダーのプロジェクト・マネジメント義務違反が認められ、ベンダーに対して、クライアントに生じた実損害のほぼ全額の賠償を命じた裁判例もあります（東京地方裁判所平成24年3月29日判決）。
リスク回避のために契約書に記載すべき事項
民法改正による影響や典型的なトラブルの事例を踏まえて、リスクを回避するために契約書に記載しておくべき項目について説明します。
1．業務範囲は具体的に
民法改正により瑕疵担保責任が廃止され、代わりに契約不適合責任が規定されたことにより、以前よりも当事者が契約により合意した内容が重要視されることになります。契約不適合責任が問われる際、契約に定められた内容を基準に判断されることが想定されるので、可能な限り具体的に業務の内容や範囲を定めておきましょう。また、契約不適合責任を判断する際、契約の趣旨や目的に合致しているかという点も考慮されるので、契約の目的についても当事者間で合意し、契約書に明記することが望ましいでしょう。
2．損害賠償責任を負う期間の起算点
前述の通り、瑕疵担保責任から契約不適合責任に変わったことにより、損害賠償の期間の起算点が納品物の引き渡し時から契約不適合の事実を知った時点に変更されました。この起算点の変更により、ベンダーは長期間に渡って損害賠償責任を追及されるリスクを負うことになります。また、契約不適合の事実を知った時点という基準は、発注者側の主観なので、「そんなはずはないだろう」などと反論するのは困難だという問題点もあります。そのため、契約書の中で「検収完了時」または「システム稼働日」等、客観的に判断できる時点を起算点として定めておくことが望ましいでしょう。
3．損害賠償額の上限
瑕疵担保責任から契約不適合責任に変わったことで、損害賠償請求の範囲に、信頼利益に加えて履行利益も含まれるようになりました。履行利益が含まれたことにより、想定外の巨額な損害賠償を請求されるリスクが従来よりも高くなったため、契約書で損害賠償額の上限を定めることの重要性も高まりました。ただし、中には、損害賠償額の上限に関する規定は一切受け入れないという企業も存在します。上限規定を設けることができない場合は、損害賠償の範囲を限定する等、クライアントと協議の上で他のリスク回避策を模索するとよいでしょう。
4．協力義務も大切
前述した裁判例では、仕様確定後にクライアントから追加要望が大量に出されたことが原因で、開発に大幅な遅れが生じ、クライアントの協力義務違反が認められました。しかし、そもそもシステム開発の受託案件において、発注側が協力義務を負うということを認識していないケースは多いです。トラブルを避けるためにも、システム開発の成否を決める要件定義というフェーズではクライアントの協力が不可欠であり、発注側が協力義務を負うことを認識してもらうことが大切です。そのためにも、契約書の中で、発注側が負う協力義務について明記した上で、協力義務が必要な理由について丁寧に説明して理解してもらいましょう。
システム開発における契約書の記載事項や注意点についてはこちらの記事に記載しておりますので、参考にしていただければと思います。
契約不適合責任に関するよくある疑問
最後に契約不適合責任について、よくある疑問に対して回答します。
1．準委任契約なら契約不適合責任は問われない？
最近は、システム開発の受託案件で準委任契約という契約類型が用いられるケースが増えています。準委任契約は、特定の業務を委任された側が業務を遂行し、発注側が業務に対する報酬の支払いを約束する契約です。準委任契約は請負契約とは違い、報酬を支払う対象が成果物ではなく作業となり、契約不適合責任を負うことはありません。
ただし、システム開発の受託案件で用いられる準委任契約は、ほとんどの場合、成果完成型に該当するといわれています。成果完成型の場合、作業自体に対して報酬が支払われるわけではなく、作業の結果として達成された成果と引き換えに報酬が支払われます（改正民法第648条の2）。そのため、受託側は、単純に作業をするだけではなく成果物を完成することが求められ、完成できない場合は債務不履行責任を負うことになります。また、準委任契約では、受託側は発注側に対して善管注意義務を負います（民法第644条）。善管注意義務とは、業務を委任された人の職業や社会的地位などから考えて通常期待される注意義務をいいます。システム開発のプロとして求められるレベルのスキルや専門知識をもって業務を遂行する注意義務を負い、注意義務を怠った場合は損害賠償を請求される可能性があります。つまり、準委任契約では契約不適合責任を負わないからといって、受託側が負う実質的な責任の重さが軽くなるわけではないという点には注意が必要です。
2．検収後に不具合が発覚した場合の損害賠償責任は？
システム開発の受託案件では、システムが完成した後、クライアントがテストを実施し、検収を行います。検収で不具合が発覚した場合、発注側から受注側に対して検収が不合格であることが通知され、受注側が問題点について修正作業を行い、再度、検収が行われます。そのような検収を経て、システムが稼働した後に、不具合が発覚する場合もあります。その際、ベンダーが「検収が完了した後なのだから、修正をする義務はない」と主張することがありますが、それは間違いです。前述した裁判例では、システム稼働後に発覚した不具合の存在のみをもって損害賠償責任を負うことはないが、受注側は遅滞なく不具合を補修する、もしくは相当な代替措置を講じるという対応が求められることが示されています。検収は報酬を支払うための条件であり、以降に発覚した不具合を修正する義務を免除するものではないという点はしっかり認識しておきましょう。
まとめ
今回は、瑕疵担保責任と契約不適合責任の違い、契約不適合責任を問われた場合のリスク、契約不適合責任を巡るトラブル事例、リスク回避のために契約書に記載すべき事項について解説しました。
システム開発の受託案件では、ベンダーとクライアントの認識のズレによる問題が発生しやすく、訴訟等のトラブルに発展するケースも少なくありません。最新の法規制の改正内容や裁判における判決の傾向等も把握しながら、契約書を整備して、自社に損害を与える可能性のある法的リスクを回避することが大切です。
東京スタートアップ法律事務所では、IT業界の法律問題や裁判の傾向等に精通した弁護士が、様々な企業のニーズに合わせたサポートを提供しております。お電話やZoom等のオンライン会議システムによるご相談も受け付けていますので、お気軽にご相談いただければと思います。