システム開発における契約不適合責任

IT・情報セキュリティ 公開 更新
尾城 亮輔弁護士 尾城法律事務所

 当社は、営業システムの刷新をすることを決めて、ベンダーとの間で、新システムを開発する請負契約を締結しました。納期にベンダーからシステムの納入を受けて、新システムを稼働させたのですが、バグが多数残っており、処理速度も遅いなどの不具合があることが判明しました。当社は、ベンダーに対して、どのような請求をすることができるのでしょうか。

 仕事の完成後に判明した不具合は、契約不適合の問題として処理され、当該不具合が契約不適合であると評価できる場合には、ユーザーは、①修補請求、②代金減額請求、③損害賠償請求、④契約解除(ただし、その不具合が軽微な場合は除く)の方法をとることができます。

 ただし、システム開発の場合、バグについては、ベンダーが遅滞なく補修を終え、またはユーザーと協議のうえで相当と認められる代替措置を講じたときは、そのようなバグは契約不適合ではないと評価されることになります。

 また、処理速度等の非機能要件については、通常有すべき品質・性能を満たしているかという基準が用いられるため、当該システムの導入目的や当該機能を使用する業務の内容などを勘案して、当該不具合が契約不適合といえるかが判断されることになります。

解説

目次

  1. 契約不適合責任とは
    1. 契約不適合責任の内容
    2. 改正民法での変更点
  2. システム開発における契約不適合
    1. バグと契約不適合
    2. 非機能要件について
  3. まとめ
<編注>
2021年3月4日:「民法の一部を改正する法律」(平成29年法律第44号)の施行を踏まえ、記事の一部を加筆、修正しました。

契約不適合責任とは

契約不適合責任の内容

 契約不適合責任とは、請負契約の仕事の目的物について、その種類または品質が契約の内容に適合しないときに、請負人が負うことになる責任です。こういった請負人の責任は、従前、瑕疵担保責任と呼ばれていましたが、2020年4月1日施行の民法改正にて、契約不適合責任という名称に変更されました。

 *契約不適合責任は、民法の売買契約の総則に規定されており、有償契約全体について準用されるものですが(民法559条)、本稿では請負契約に限定して説明します。

 システム開発の最終段階で行われるテストでバグが大量に発見され、稼働予定日を過ぎてもシステムを稼働させることができない場合には、債務不履行(履行遅滞)の問題と整理されますが、システムが稼働して仕事が完成した後にバグが発見された場合には、契約不適合責任の問題であると整理されます。設例のケースでは、新システムが稼働しており、請負人の仕事は完成していると考えられるので、請負人に対して契約不適合責任を追及することができるかが問題となります。

 参照:「システム開発における仕事の完成の判断基準

 契約不適合責任に基づき、ユーザー(注文者)が行使することができる権利には以下の4つがあります。

  1. 履行追完請求権(不具合を修補するよう求める権利)(改正民法562条)
  2. 報酬減額請求権(改正民法563条)
  3. 損害賠償請求権(改正民法564条、415条)
  4. 契約の解除権(改正民法564条、541条、542条)

改正民法での変更点

 2020年4月1日施行の改正民法(以下「改正民法」といいます)により、契約不適合責任についても変更がありました。

(1)報酬減額請求権の新設

 ②報酬減額請求権は、改正民法で新しく認められた権利です。ただし、民法の改正前であっても、瑕疵によって注文者に生じた損害について、注文者は損害賠償請求権を有しており、請負人の報酬請求権と相殺することで、実質的に報酬減額請求権を行使したのと同じことができたので、実務的には大きな影響はないと考えられます。

(2)修補請求権の行使条件の変更

 ①の履行追完請求権について、改正前の民法では、瑕疵が重要でなく、その修補に過分の費用を要するときは請求することができないとされていましたが(旧民法634条)、改正民法で削除されました。

(3)解除の行使条件の変更

 改正前の民法では、瑕疵のために「契約をした目的を達することができないとき」に、注文者は契約を解除することができるとされていましたが(旧民法635条)、改正民法ではこの条項が削除され、解除権の行使が認められるか否かは、債務不履行一般のルールにしたがって判断されることになりました。

 改正民法541条では、催告解除について、「債務の不履行がその契約及び取引上の社会通念に照らして軽微であるとき」は、契約を解除することができないとされているため、契約不適合の程度が「軽微」であるといえるか否かによって、解除権を行使できるか否かが決まることになります

改正前
注文者は、仕事の目的物に瑕疵があり、瑕疵により契約をした目的を達することができないときは、契約の解除をすることができる(旧635条)。

改正後
催告解除(改正民法541条)
債権者(ここではユーザー)が、相当の期間を定めての催告をしたが、その期間内に債務者の履行(契約不適合の修補)がないときに解除できる。ただし、債務の不履行(契約不適合)がその契約および取引上の社会通念に照らして軽微であるときは、解除できない

無催告解除(改正民法542条)
次のいずれかの場合に催告をすることなく解除できる。

  1. 債務の全部の履行が不能であるとき
  2. 債務者(ここではベンダー)がその債務の全部の履行を拒絶する意思を明確に表示したとき
  3. 債務の一部の履行が不能である場合または債務者がその債務の一部の履行を拒絶する意思を明確に表示した場合で、残存する部分のみでは契約をした目的を達することができないとき
  4. 契約の性質または当事者の意思表示により、特定の日時または一定の期間内に履行をしなければ契約をした目的を達することができない場合に、債務者が履行をしないままその時期が過ぎてしまったとき
  5. 上記①~④のほか、債務者がその債務の履行をせず、債権者が催告をしても契約をした目的を達するのに足りる履行がされる見込みがないことが明らかであるとき

 上記のほかに、債務の一部の履行が不能であるときまたは債務の一部の履行を拒絶する意思を明確に表示したときは、催告なくその部分のみを解除することもできる。

(4)権利行使期間の変更

 実務的に影響があると考えられるのは、契約不適合責任の権利行使期間の変更です。改正前の民法では、瑕疵担保責任の権利行使期間は、仕事の目的物(システム)の引渡時から1年とされていましたが(旧民法637条)、改正民法では、この権利行使の起算点が、「契約不適合を知ったとき」から1年へと変更されました。また、契約不適合責任に基づいて認められる権利は、消滅時効の規定(改正民法166条1項)の適用を受けるため、目的物の引渡しを受けたときから10年間行使しないときにも、消滅時効に服することになると考えられます。

 *目的物の引渡しを10年の起算点とすることにつき、最高裁平成13年11月27日判決・民集55巻6号1311頁参照。また、債権者が権利を行使することを知った時から5年間行使しない場合にも消滅時効に服することになりますが(改正民法166条1項1号)、実務的に問題になることは稀と思われます。

 このように、改正民法では、たとえば、システムの引渡しを受けてから、9年後に不具合が発見された場合であっても、契約不適合責任を追及できることになります。しかし、ITシステムというのは、建築物などと比べると更改のサイクルが短く、実務慣行として、稼働後に有償の保守サービスを締結して、メンテナンスを行うことが定着していました。ベンダーは、引渡しから10年間は無償での修補義務等を負うとすると、それだけの期間にわたってシステムの内容を把握した人員を確保しておく必要が生じます。そうすると、ベンダーとしては、そのための費用は開発中に回収しなければならなくなるため、ベンダーは相当高額な開発報酬を提示せざるを得なくなると考えられますが、果たしてそれが妥当といえるかには疑問があります。契約不適合責任の権利行使期間は任意規定であるため、当事者双方で協議をして、契約で当該案件の事情に合った権利行使期間を定めることが望まれます

システム開発における契約不適合

バグと契約不適合

 一般的に、契約不適合とは、契約で予定されていた品質や性能を欠くことと考えられており、システムの場合、基本的には「仕様書(基本設計書)に合致していないこと」と考えることができます。そうだとすると、システムにバグ(プログラムの誤りにより予期せぬ動作をすること)があった場合は、まさに契約不適合の典型例として、ただちにベンダーの契約不適合責任が認められるように思えます。

 しかし、システムというものは極めて複雑なものであり、いかにテストを行ったとしても、バグを完全に防ぐことは不可能です。このようなシステムの特徴から、バグが発見された後に、ベンダーが遅滞なく補修を終え、またはユーザーと協議のうえ相当と認める代替措置を講じたときは、バグの存在をもってプログラムの欠陥(契約不適合)と評価することはできないと考えられています。この点について東京地裁平成9年2月18日判決・判タ964号172頁は、以下のように述べています。

  • いわゆるオーダーメイドのコンピューターソフトのプログラムで、本件システムにおいて予定されているような作業を処理するためのものであれば、人手によって創造される演算指示が膨大なものとなり、人の注意力には限界があることから、総ステップ数に対比すると確率的には極めて低い率といえるが、プログラムにバグが生じることは避けられず、その中には、通常の開発態勢におけるチェックでは補修しきれず、検収後システムを本稼働させる中で初めて発現するバグもありうるのである。多数の顧客が実際に運用することによりテスト済みの既成のソフトウエアを利用し、又はこれを若干手直ししてコンピューターを稼働させる場合には、そのような可能性が極めて低くなるが、顧客としては、そのような既成ソフトのない分野についてコンピューター化による事務の合理化を図る必要がある場合には、構築しようとするシステムの規模及び内容によっては、一定のバグの混入も承知してかからなければならないものといえる。

  • コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから、コンピューターシステムの構築後検収を終え、本稼働態勢となった後に、プログラムにいわゆるバグがあることが発見された場合においても、プログラム納入者が不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認める代替措置を講じたときは、右バグの存在をもってプログラムの欠陥(瑕疵)と評価することはできないものというべきである。これに対して、バグといえども、システムの機能に軽微とはいえない支障を生じさせる上、遅滞なく補修することができないものであり、又はその数が著しく多く、しかも順次発現してシステムの稼働に支障が生じるような場合には、プログラムに欠陥(瑕疵)があるものといわなければならない。

 したがって、納入されたシステムにバグがあった場合には、まず、ベンダーに対して、当該バグを通知し、修補を求める必要があります。バグが多数であるまたは修補が困難であるなどの理由で、修補に時間を要する場合には、ベンダーのユーザーに対する契約不適合責任が認められることになります。

非機能要件について

(1)非機能要件とは

 システムが備えるべき要件のうち、ユーザーがシステムによって実現したいことを機能要件といいます。たとえば、「店舗で商品を購入した顧客の情報を検索できること」などが機能要件にあたります。

 一方、設問で問題となっている処理速度のような機能要件以外の要件を非機能要件といいます。独立行政法人情報処理推進機構(IPA)では、非機能要件を、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目に分類しています(参考:独立行政法人情報処理推進機構(IPA)「非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開」(2010年4月、2019年3月28日最終更新))。

(2)非機能要件に関する契約不適合の判断方法

 非機能要件についても、契約で予定されていた品質や性能を欠いていれば、契約不適合が認められます。

 当該システムが備えるべき品質・性能がどのようなものかは、主観的・客観的な事情を総合的に勘案して判断されることになります。
 たとえば、その日の取引のデータを夜間のうちに処理し、翌日に別の処理に利用できるようにすることが予定されていた場合、夜間のデータ処理に24時間以上かかってしまい、翌朝に前日データが利用できないというのでは、「契約で予定されていた品質や性能を欠く」ことになります。このように、当該システムの導入目的や当該機能を使用する業務の内容などを勘案して、契約不適合であるといえるかが判断されることになります。

 裁判例で契約不適合が認められた例として、財務管理システムの月次更新処理に約84時間かかり、その間新たな販売管理データの入力や販売管理情報の把握ができない(広島地裁平成11年10月27日判決・判時1699号101頁)、在庫照会の検索処理に30分以上の時間を要する場合があり、その間、画面が止まったような状態になる(東京地裁平成14年4月22日判決・判タ1127号161頁)、排他制御により、商品マスタの登録データを開いていると、一括在庫引当処理を含めた商品マスタを利用する各種プログラムの処理が止まる、一括在庫引当処理を行っていると受注エントリーだけではなく、在庫を更新する全業務および商品マスタの保守ができず、同様のことが「要発注リスト」や「棚卸差異反映処理」にもあてはまる(なお、一括在庫引当処理には数十分の時間がかかるとされているため、広範な業務が長時間にわたって止まってしまうという事案であったと考えられる)(東京地裁平成16年12月22日判決・判タ1194号171頁)などがあります。

 また、オンラインショップのウェブ発注システムについて、SQLインジェクションと呼ばれる攻撃手段に対する脆弱性が存在しており、稼働開始から約2年後に、外部からの不正アクセスを受けて、顧客のクレジットカード情報を含む個人情報が流出したという事案も参考になります。同事案において、ベンダーは、契約締結当時の技術水準に沿ったセキュリティ対策を施したプログラムを提供することが黙示的に合意されていたとし、契約締結の2年ないし3年前から、経済産業省およびIPAが、SQLインジェクションによる攻撃が相次いで発生しており、SQLインジェクション対策をすることが必要である旨の注意喚起をしていたこと、当該システムでは、顧客の個人情報を本件データベースに保存する設定となっていたことからすれば、被告は、当該個人情報の漏洩を防ぐために必要なセキュリティ対策を施したプログラムを提供すべき債務を負っていたとして、ユーザーに対する損害賠償請求を認めた事例があります(東京地裁平成26年1月23日判決・判時2221号71頁)。

 一方で、仕様として合意されていた内容については、契約不適合が認められない場合が多いといえます。裁判例では、システムの稼働後にユーザーの従業員が使用することになるハンディターミナルの画面が小さく見づらい、画面上に商品コードしか表示されないから誤入力が多発するという主張に対して、ユーザー自身がこれらを認識したうえで仕様に合意したのであるから、この仕様自体を契約不適合とはいえないとしたものがあります(東京地裁八王子支部平成15年11月5日判決・判時1857号73頁)。また、商品(靴)のバーコードをハンディターミナルで読み取ってデータを生成するシステムにおいて、読み込み数が多くなるに従い動作に遅れが生じるものの、ユーザーから、1度に数百足のバーコードを読み取ることが日常的であるとか、繁忙期には日々数百足から千足近い入出荷を扱うとかの説明が事前にされたことは証拠上認められないため、そのような数量の処理を、バーコードを用いて遅れなく処理することまでがカスタマイズの内容となっていたとは認められないとしたもの(東京地裁平成19年10月11日判決・公刊物未搭載)などがあります。

 もっとも、作業コードをいったん入力するとカーソルが後ろへ戻らず、データを修正しようとしても打ち込めない、作業コードが統一性なく設定され、コード検索画面も1度に6件しか表示されないので、目的のコードを見つけるまでに50回程度画面を切り替えなければならない、というものについて、ユーザー担当者が作業コードを設計していることが認められるが、ベンダーとしては専門技術的見地から統一性・拡張性を備えたシステムになるようサポートする義務があるとして、債務不履行を認めた例もあるところであり(前掲広島地裁平成11年10月27日判決)、通常の用法を考えた場合、あまりにも使い勝手が悪い場合には、契約不適合責任が認められる可能性はあります。仕様を決定した際の手続きが、重要な判断要素となると考えられるため、協議の過程を議事録などの形で記録しておくことは重要といえるでしょう

まとめ

 バグについては一定程度の許容をしているという点が、システム開発契約における契約不適合責任の特殊な点といえます。また、非機能要件も含めて、可能なかぎり、仕様を明確化しておくこと、仕様検討のログを議事録などの形で残しておくことが、トラブル防止のための対策となります。

Q&Aでわかる日本版「司法取引」への企業対応 - 新たな協議・合意制度とその対応 -

無料会員にご登録いただくことで、続きをお読みいただけます。

1分で登録完了

この実務Q&Aを見ている人はこちらも見ています

無料会員登録で
リサーチ業務を効率化

1分で登録完了

無料で会員登録する