システム開発の瑕疵担保責任と民法改正

システム開発の瑕疵担保責任と民法改正

開発業者が完成したシステムを納入した後に、発注者から、操作方法が難しい、処理速度が遅い、発注した機能が備わっていない等の理由で、契約を解除するとか、不具合を直すまで報酬を支払わないなどと言われるケースがあります。

システム開発を請負契約で締結する場合、開発業者は、原則として、瑕疵担保責任を負い、瑕疵修補や損害賠償の請求、契約解除がなされるおそれがあります。

開発したシステムにバグなど不具合が発生することを避けるのはなかなか難しいものですが、不具合が瑕疵に当たるならば、上記責任を負わなければなりません。 システム開発における瑕疵はどのように考えられていて、民法改正により瑕疵担保責任はどのように変わるのかなどについて説明します。

瑕疵(かし)とは

一般的に、「瑕疵」とは、契約で予定されていた品質・性能を欠くことをいいます。

システム開発における瑕疵とは、基本的には完成したシステムが仕様と一致していないことを指します。しかし、これは必ずしも仕様書との不一致に限定されるわけではなく、論理的誤りを含む場合や一般常識に照らして著しく品質を欠くものについても瑕疵と評価する場合があり、何をもって「瑕疵」とするかは明確に定まっていません。

したがって、システム開発に関する契約書を作成する際には、「瑕疵(仕様書との不一致、論理的誤りまたは通常有すべき機能、品質、性能を書いている状態)」といった風に、瑕疵の定義を契約内容に明記することが重要となります。こうした定義が明確でない場合は、

  • 法律の一般論としての「瑕疵」が、当該システム開発の場合は何を示すのか
  • 問題の不具合等は「瑕疵」に該当するか

という判断が事後的に行われることになります。

問題の不具合等は「瑕疵」に該当するか

裁判例では、開発したシステムに不具合が発生することは不可避であることは理解しつつ、以下の場合には、瑕疵に当たると述べています。

システム不具合により生じる瑕疵の状況と対応とは?

不具合がシステムの機能に軽微とはいえない支障を生じさせる上、遅滞なく修補することができない場合

例えば、単純なプログラムのコーディングミスで発生した不具合でなく、設計段階まで遡って見直しを要するような場合がこれに当たることになるでしょう。 裁判例では、販売管理システムで在庫照会の検索処理に30分以上要するため、手書きの在庫台帳を作成していた事例や、販売管理システムの一括在庫引当処理で、300件で40分程かかり従来の手作業と変わらず、同規模のシステムで通常要求される仕様は数分程度であった事例や、大学のシステム構築で必要不可欠な排他的制御がない事例で、瑕疵に当たると判断されました。

不具合の数が著しく多く、順次発現してシステムの稼働に支障が生じるような場合

裁判例では、4ヶ月間の検収期間に150件を超える不具合対応を実施したが、再納入後の再検収でもさらに不具合があり、解除の意思表示をされた後にも新たに約30件の不具合が発生した事例で、瑕疵に当たると評価され、契約解除が有効と判断された事例があります。

瑕疵に当たらないと評価される場合

遅滞なく修補した場合または代替措置を講じた場合

裁判例では、ユーザーから不具合を指摘されたとしても、遅滞なく補修した場合、またはユーザーと協議の上相当と認める代替措置を講じた場合には瑕疵に当たらないと述べています。

裁判例では、正しい内容を入力してもエラーが出るなどの不具合を解消する期間が2週間程度であり、契約解除が認められなかった事例があります。また、販売管理システムでデータベースを更新するためには、1台を除く他の全てのパソコンのシステムを閉じる必要があるとしても、更新は1分程で終了し、業務開始時に更新するという運用方法を用いれば、業務に大きな支障をきたさないとして、契約の解除は認められないと判断された事例があります。このような場合には、瑕疵に当たらないと評価されるでしょう。

特定個人が操作方法を容易に理解できなかった場合

操作性や使い勝手に関しては、主観によるものが大きいことから、一般的利用者を基準に使用に堪えられない場合に瑕疵に当たると評価されることになります。

特定個人が操作方法を容易に理解できなかったことのみでは、瑕疵に当たるとは評価されません。

ベンダーの仕事以外が原因で不具合が発生した場合

例えば、ベンダーが調達を担当しないハードウェアのトラブルが原因で不具合が発生した場合には、瑕疵に当たるとは評価されません。

ユーザーの指示により不具合が発生した場合

ユーザーの専門領域で、ユーザーのみが知り得る事情を説明されず、誤った情報を前提に合意した仕様に基づき開発したシステムに不具合が発生した場合には、瑕疵に当たらないと評価されます。

裁判例では、スーパーマーケットの業務システムで、発注データを変更する頻度や必要な時間は青果販売業者であるユーザーの専門領域で、ユーザーのみが知り得る事情であり、これらに関して誤った情報が伝えられ、これを前提に開発し、発注データを修正する際に長時間かかるとしても、瑕疵はないと判断された事例があります。

瑕疵がある場合、発注者から何を主張、追及されるのか

瑕疵担保責任の規定は任意規定であり、当事者間の特約により、責任内容を修補のみにするなど限定したり、責任を負う期間を短くしたりすることができます。かかる特約がない場合には、民法の瑕疵担保責任の規定が適用され、発注者から、以下の主張や追及がなされ得ます。 なお、2017年公布の民法改正(2020年4月1日施行)では、瑕疵担保責任が契約不適合責任に変更されました。瑕疵の定義からすれば、従来の瑕疵の概念を変えるものではありません。完成したか否かは問われず、担保責任から、債務不履行責任が問われることに変更されます。関係する民法改正の内容もあわせて説明します。

瑕疵があるとされた場合のそれぞれの責任追及対応について説明していきます。

瑕疵修補請求

不具合が前述した瑕疵に当たると評価される場合には、発注者から修補請求がなされ得ます。

民法改正により、履行の追完の請求という言い方に変わります。

損害賠償請求

発注者から、開発業者に帰責事由がなくとも損害賠償請求がなされ得ます。損害には、例えば、発注者が他の開発業者に修補を依頼し、それにかかった費用などが当たります。

民法改正により、債務不履行に基づき損害賠償請求がなされることになり、開発業者の「帰責事由」が必要とされるので、開発業者にとっては損害賠償請求されにくくなるといえます。

契約解除

発注者から、瑕疵により「契約目的が達成できない場合」に、解除され得ます。

民法改正により、この契約目的達成不能の限定はなくなり、債務不履行に基づき解除され得ることになります。

そして、債務不履行に基づく解除の規定は、従来は解除する側に帰責事由がなく「相手方に帰責事由がある」場合に限られていましたが、民法改正により、解除する側のみでなく「相手方に帰責事由がない」場合にも、解除ができることになります。解除制度が債務者に対する責任追及ではなく、債権者を契約の拘束力から離脱させるためのものと変わることになるのです。 そのため、開発業者にとっては解除されやすくなるといえます。

報酬減額請求

従来の民法には、瑕疵担保責任として報酬減額請求の規定はありません。

民法改正により、相当期間内に履行の追完を行わない場合に、発注者から、不適合の程度に応じて報酬減額請求がなされ得ることになります。

責任を負う期間

開発業者が発注者から、上記の瑕疵修補請求、損害賠償請求、解除がなされ得るのは、「引き渡した時」から1年以内です。

民法改正により、履行追完請求、損害賠償請求、解除、報酬減額請求がなされ得るのは、発注者が「その不適合を知った時」から1年以内にその旨を通知されたときに変更されます。開発業者にとっては、責任を負う期間が長くなるといえます。

報酬支払拒絶

開発業者が瑕疵修補や損害賠償を行うまで、発注者から、同時履行の関係に立つため、報酬の支払いを拒絶され得ます。

モノリス法律事務所

モノリス法律事務所は、元ITエンジニアで企業経営経験のある代表弁護士の下、約60社のIT・ベンチャー企業の顧問弁護士等を勤めております

Phone: 03-6262-3245 (平日10時-17時)
Email: kawase@monolith-law.jp

モノリス法律事務所

モノリス法律事務所

モノリス法律事務所は、IT・インターネット・ビジネスに強みを持つ、東京・大手町の法律事務所です。

シェアする