システム開発の依頼を受け納品した後に、顧客から不具合について責任を問われることは少なくありません。顧客が希望した機能が備わっていなかったり処理速度に問題があったりと、このような問題の責任を受注者が負うことを「瑕疵担保責任」といいます。実は、瑕疵担保責任は2017年に廃止され、代わりに「契約不適合責任」が新設されました。同じ意味合いを持つように感じる概念ですが、責任を負う期間の起算点が異なります。こうした責任があることを理解しておかなければ、万が一トラブルが発生した時に不利益が生じかねません。今回は、瑕疵担保責任と契約不適合責任について詳しく解説します。
目次
新規案件開拓の課題は「発注ナビ」で解決！システム開発に特化したビジネスマッチング
・コンシェルジュが依頼内容をヒアリング
・対応したい案件を選べるエントリー制
・エントリー時の見積作成は不要
・発注者の95％がエンドユーザー
瑕疵担保責任とは契約解除や補修の要求ができる法律のこと
瑕疵担保責任は、2017年に法改正される以前の旧民法635条 に記載されていた「仕事の目的物に瑕疵があり、そのために契約をした目的を達することができない時は、注文者は、契約の解除をすることができる」という文言で表された法律です。
つまり、契約を交わして納品したサービスや製品に不具合が生じ契約の目的に達しなかった場合に、発注者側は契約の解除や補修の要求ができるといった意味があります。
システム開発も例外ではなく、いわゆる「バグ」と呼ばれるプログラミングミスが発生すれば、瑕疵担保責任の対象です。
●瑕疵担保責任を問われる時はどんな時？
一般的に、システム開発において瑕疵担保責任を問われるかどうかの境目となるのが、対応の速さです。瑕疵の内容だけではなく、受注側が瑕疵の報告を受けた後に速やかな対応を行えば、責任を果たしているとみなされます。
反対に、軽微な瑕疵でも長らく放置してしまえば、瑕疵担保責任を問われるでしょう。
前章にて、システム開発も瑕疵担保責任を問われる可能性があることに触れましたが、ITシステムにおいて稼動後の不具合はよくあることです。そのため、軽微なバグや使用頻度の少ない機能に不具合が見つかった場合は、損害賠償の対象から外れる傾向があります。
現在は「契約不適合責任」に法改正された
冒頭でも触れたように、瑕疵担保責任という概念は2017年の段階で廃止されています。その後、2020年4月1日に民法改正が施行され、契約不適合責任という名称に改められました。
契約不適合責任は、請負契約をした仕事の目的物について「種類」「品質」「数量」が契約の内容と合っていない場合に、請負人（受注者）が負う責任のことを指します。つまり、納品した製品やサービスが契約内容と相違していた場合に生じる責任です。
瑕疵担保責任は契約不適合責任とどう違う？
同じような概念に思える「瑕疵担保責任」と「契約不適合責任」ですが、単純に名称が変わっただけではありません。双方の間には、いくつかの相違点があります。どのような違いがあるのかを押さえておくと、万が一トラブルが発生した場合でも安心です。
●責任を負う期間の捉え方が違う
大きな違いとして挙げられるのが、責任が発生する起算点です。瑕疵担保責任の場合、納品物を引き渡した段階もしくは仕事が完了したタイミングを起点として、責任を負う期間が決められていました。
一方、契約不適合責任では不具合を発見したタイミングが起算点となるため、納品後数年経ってから不具合が見つかった場合でも、受注者は責任を負わなければなりません。
しかし、不具合を発見してから5年の間に、発注側が報告しなければ時効です。納品から1年間が責任を負う期間とされていた瑕疵担保責任よりも、受注側が責任を追及される期間が大幅に長くなっている点を把握しておきましょう。
●損害賠償の請求範囲が拡大する
もう1つの違いとして、契約不適合責任に改められたことで、損害賠償の請求範囲が拡大しています。
瑕疵担保責任では、損害賠償請求が信頼利益の範囲に限定されていました。信頼利益とは契約が無効もしくは失効しているのにもかかわらず、有効だと信じた場合に生じた損害を指します。
一方、契約不適合責任においては、信頼利益に加えて履行利益も範囲となりました。履行利益とは、契約が成立していれば得られたと考えられる利益のことを指します。
一例として、納品日にシステムが稼動できなかったために、営業利益が得られなかったケースでは、予定通り納品された場合に得られたと試算される営業利益が履行利益に該当します。
「契約不適合責任」を問われるとどうなるのか？
契約不適合責任に改められたことで、どのような対応を迫られるのでしょうか。万が一契約不適合とみなされると、以下のような対応をする必要があります。
続いては、契約不適合責任になった場合に発生する請求について、詳しく解説します。
●修補請求される
改正された民法では、契約不適合に該当すると判断された場合に、修補請求されます。瑕疵が発覚した場合に、修補して対応するように請求する権利を修補請求といいます。
旧民法において受注者が請求される可能性があったのは、費用請求か契約解除に限られていました。なお、改正後であっても修補が不要とみなされた場合、修補請求が認められないケースもあります。
●支払い代金の減額を請求される
契約不適合だと判断された場合、代金減額請求が行われる可能性があります。発注側が受注者に対して、履行の追完を催告したにもかかわらず、実行に至らない、もしくは履行不可能な場合にされる請求です。
代金減額請求にはルールがあり、不適合に気づいた段階から1年以内にその旨を通知しなければなりません。減額する割合について明確な規定はなく、弁護士の解釈に委ねられます。
●損害賠償請求される
開発してもらったシステムがトラブルを起こして通常業務が行えなかったり、修復不可能だったりする場合には、損害賠償を請求される可能性があります。損害賠償請求の中には、修復に要した費用も含まれるのが一般的です。
従来の瑕疵担保責任では、特別な契約をしていない限り過失の有無にかかわらず、発注側が損害賠償を請求することができました。一方、契約不適合責任では、損害賠償を請求するためには受注者側の過失が要件となっています。
また、損害賠償の範囲も変更されました。従来は過失の有無に関係なく、通常の契約違反を基準にした責任と比較して範囲が限られていました。
しかし、法改正後は受注者の過失が要件となったことにより、損害賠償の範囲には履行責任も含まれるため、実際の不具合に対する請求だけでなく、不具合が原因で得られなかった利益も対象です。
●契約が解除される
発注者から催告され、裁判において「契約の目的が達成できていない」とみなされた場合、契約解除に至ります。基本的に契約解除をするためには催告が必要ですが、修補が不可能なケースや修補できるにもかかわらず拒絶した場合などは、催告がなくても良いと判断される可能性もあるでしょう。
また、従来は契約目的が達成できない場合に限られていましたが、民法改正後はこうした限定が削除されました。一方で、あまりにも軽微な瑕疵であれば、契約の解除が認められないケースもあります。
システムの受発注に関してトラブルが生じた場合は、専門家である弁護士にご相談ください。また、システム開発の案件を獲得するには、契約書にも注意が必要です。開発案件の獲得を考えている方は、発注ナビの利用をご検討ください。
システムやソフトウェアが「契約不適合」に該当するケース
ここまで、瑕疵担保責任と契約不適合責任について説明しました。システム開発においても無視できない責任問題ですが、どのようなケースが契約不適合に該当するのでしょうか。
続いては、システムやソフトウェアの不具合に焦点を当てて、契約不適合に該当する2つのパターンを見ていきましょう。
●システムやソフトウェアに支障が出たが修補が遅延した
例えば商品の照合を速やかに行うためにシステム・ソフトウェアを導入したにもかかわらず、検索に30分以上もの時間を費やすようなトラブルが発生したケースで考えてみましょう。
すぐに修補することができず、別途手書きの台帳を作成して対応するような流れになれば、明らかに発注者に対して履行利益の損害が発生し、契約不適合に該当すると考えられます。
●不具合が順次発現している
各エラーが軽微ですぐに直せる場合だとしても、頻繁に同じようなエラーが発生する事態になれば、正常な状態に戻るまでに長時間かかる可能性があります。
完全な修復までにどの程度時間がかかるのかを明示できなければ、システムを使った通常業務に影響を及ぼすため、契約不適合に該当するでしょう。
システムやソフトウェアの不具合が「契約不適合」に該当しないケース
システムやソフトウェアの不具合や措置によっては、以下4ケースのような、契約不適合に該当しないケースも少なくありません。
どのようなケースであれば該当しないのかを把握しておくと、万が一トラブルが発生した場合も落ち着いて対処できるでしょう。
●遅滞なく修補・代替措置を講じた
発注者からバグが発生していると報告があった時に、速やかな補修を行った場合や発注者と協議をしたうえで、納品されたシステム相当とされる代替措置を講じた場合は、契約不適合に該当しない可能性があります。
システム・ソフトウェアの開発において、絶対にバグが発生しない状況を作るのは非常に困難です。軽微な不具合は避けられないことであり、発生したとしても遅滞することなく補修できれば瑕疵とはいえないでしょう。
●特定の人物のみ操作方法が理解できなかった
一般的なユーザーが操作できて、特定の人物のみが操作できなかったり使い勝手が悪いと感じたりした場合は、契約不適合に該当するとは限りません。
システムやソフトウェアの操作性に関しては、通常、専門知識を有しない一般的なユーザーを基準にして考えられます。そのため、一般的なユーザーにとって使い勝手が悪いと判断されれば、契約不適合に該当する可能性もあるでしょう。
●開発会社の業務以外が原因で不具合が生じた
受注者側が行う業務とは別の原因で不具合が発生した場合も、契約不適合と判断されることはないでしょう。
例えばハードウェアの部品を発注者側で調達した場合に、その部品が原因で不具合が生じたとしても、受注者は関与していないため契約不適合にはなりません。
●発注者が原因の不具合が生じた
発注者側しか知らない情報をもとにシステム開発を行った時に、伝えられた情報が間違っていたため不具合が発生することも考えられます。
システムまたソフトウェア開発において発注者も協力義務があり、発注者からの情報に誤りがあった場合は、原則として受注者が契約不適合責任を負う必要はありません。
準委任契約・検収後の不具合における契約不適合責任の考え方
契約不適合責任に関して一般的に問われやすい疑問として、「準委任契約」の場合と「検収後の不具合」が挙げられます。続いては、これらのよくある疑問について詳しく紐解いてみましょう。
●準委任契約であれば契約不適合責任は問われないのか
近年は、準委任契約で業務を請け負うケースが多く見られます。準委任契約は請負契約とは異なり、成果ではなく作業に対して報酬を支払う契約です。そのため、基本的には契約不適合責任を負う必要はありません。
しかし、システム開発に関しては、作業を行った結果や達成した成果に対して報酬が支払われる「成果完成型」が一般的であり、準委任契約であったとしても成果物を完成することが目的です。
準委任契約では契約不適合責任ではなく、善管注意義務を負うことになるため注意が必要です。
善管注意義務とは、一般的に専門家に対して期待される注意義務を意味します。つまり、プロに対して求められる知識やレベルを踏まえて業務を遂行する義務です。準委任契約であっても責任がなくなるわけではありません。
●検収後に不具合が発見された時の損害賠償責任
いくらテストをしたとしても、検収後に不具合が起こることもあります。検収後であれば修正する義務はないだろうと考える方もいますが、補修や代替措置を行わなければなりません。
一般的にシステム開発の場合、システム完成後に発注者がテストを行い検収します。検収で不具合があれば修正作業を行い、再度検収をするという流れです。
システム稼動後のバグは通常起こりうることであり、不具合だけを見て損害賠償責任を負われることはないでしょう。しかし、検収は報酬を支払うために行うステップであり、検収後の補修を免除する条件ではない点は念頭に置いておくことが大切です。
「契約不適合」を回避する契約書作成のポイント
契約不適合を回避するためには、契約書を作成する段階でポイントを押さえておかなければなりません。
例えばシステム開発において、仕様変更が起因となってトラブルが発生するケースが多々あります。そのため、仕様変更が起こった場合の取り扱いを明確に記載することが大切です。
また、報酬の支払い時期は明確に記載しましょう。報酬の支払いはトラブルが起きやすい要因といえます。
支払い時期は、一般的にシステムが完成した時もしくは労務が完了した時の2パターンに分かれます。契約内容によっては、いつまでも支払いが行われないトラブルが発生することも起こるかもしれません。
そして、報酬に限らず契約内容があやふやだと、双方の間に認識のズレが生じトラブルになりやすいため、内容ははっきりと書きましょう。万が一トラブルが発生した場合の対応方法や責任の所在についても、明記しておくようにしましょう。
ポイントを押さえた契約書の作り方については「システム開発の契約書で絶対にチェックするべきポイントとは」で、詳しくご紹介していますので、ご覧ください。
万が一、顧客とトラブルが発生した場合は、自分で対処せずに専門家である弁護士にご相談ください。また、案件を獲得する時は、契約書作成の注意点もしっかりと押さえることが大切です。開発案件を得たいとお考えの方は、発注ナビの利用をご検討ください。
新規案件開拓の課題は「発注ナビ」で解決！システム開発に特化したビジネスマッチング
・コンシェルジュが依頼内容をヒアリング
・対応したい案件を選べるエントリー制
・エントリー時の見積作成は不要
・発注者の95％がエンドユーザー
■受託案件の獲得に成功した企業インタビュー
