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

契約不適合責任とは

契約不適合責任の内容

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

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

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

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

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

改正民法での変更点

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

（1）報酬減額請求権の新設

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

（2）修補請求権の行使条件の変更

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

（3）解除の行使条件の変更

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

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

（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日判決）、通常の用法を考えた場合、あまりにも使い勝手が悪い場合には、契約不適合責任が認められる可能性はあります。仕様を決定した際の手続きが、重要な判断要素となると考えられるため、協議の過程を議事録などの形で記録しておくことは重要といえるでしょう。

まとめ

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

• 参考文献
• 裁判例から考えるシステム開発紛争の法律実務
• 著者：難波修一、中谷浩一、松尾剛行、尾城亮輔
• 定価：本体4,600円＋税
• 出版社：商事法務
• 発売年月：2017年2月