民法（債権関係）の抜本改正により、システム開発に関わる実務が大きく変わりそうだ。請負契約では「瑕疵」という言葉が「契約不適合」に置き換わるほか、ユーザー企業がシステム開発契約を解除できる条件、バグ修正を請求できる期間が変わる。一見するとユーザー企業に有利だが、その分ITベンダーに支払う費用が高くなる可能性もある。
改正民法（債権関係）が2017年5月26日に国会で成立した。この改正法は2020年6月2日までの政令で定める日に施行される。120年ぶりとも言われる抜本改正であり、システム開発の実務にも影響を及ぼすと考えられる。
本連載は2回にわたり、システム開発に広く使われる請負契約と準委任契約について改正のポイントを解説する。初回は請負契約の瑕疵担保責任に関わる変更点を中心に解説しよう。
瑕疵担保責任とは何か
請負契約における改正法のポイントを説明するには、現行民法における「瑕疵担保」の理解が欠かせない。現行法で瑕疵担保が問題となる典型的なケースは、次のような場合だ。
ユーザー企業がITベンダーに対して、システムの開発を発注。納期までに新システムが完成し、稼働した。だが、システムにはバグが多く残っており、マニュアルどおりに操作をしてもエラーメッセージが出てくる。ユーザー企業はITベンダーに修補（改修）を依頼したが、バグを取り切るにはかなりの時間がかかるとの回答だった。加えて一部機能で処理速度が非常に遅く、処理を待つために業務をしばしば止めなければならない状態だった。利用部門からは、業務効率化のため新システムを導入したのにこれでは意味がないとクレームが出ている―。
このような場合、法律上は「システムに瑕疵がある」という。瑕疵とは「欠陥があること」や「期待する性能がないこと」という意味だ。上記のようなシステムは、期待する機能や性能がないとして瑕疵があるといえる。
瑕疵がある場合、システムを発注したユーザー企業は法律上、次の3つの選択肢を取ることができる。
（1）瑕疵を直すよう請求する（プログラムの修正など）
（2）損害賠償を請求する
（3）契約を解除する
このうち（3）の契約解除は、開発のためにITベンダーに支払った報酬の返還を請求できる強力なものだ。このため契約を解除できる条件は厳しく、瑕疵により「契約をした目的を達することができない」場合でなければ解除できないとされている。
さらに（1）～（3）の請求は仕事の目的物を引き渡したときから1年以内にしなければならないとされる。
「瑕疵」が「契約不適合」に
こうした現行法の瑕疵担保責任が、改正法ではどのように変わったのか。主な変更点は4つある。このうち2つは実質的な変更ではないが、残りの2つは契約の実務を大きく変える可能性がある。順にみていこう。
1つめの変更点は「瑕疵」という言葉が「契約不適合」という用語に置き換わったことだ。つまり「請負の目的物に瑕疵があるとき」ではなく「請負の目的物が契約の内容に適合したものでないとき」、ITベンダーは責任を負うという定め方になった。
瑕疵という言葉は改正前から「期待する性能がないこと」と解釈されており、改正法の契約不適合も瑕疵と同じ意味だと考えられている。この部分の改正は、分かりやすくするための用語の変更に過ぎず、実質的な変更はないと考えられる。
2つめの変更点は「代金減額請求権」と呼ばれる権利がユーザー企業に認められたことだ。
契約不適合があった場合、ITベンダー（請負人）に支払う報酬の減額を請求できるようになった。つまり前述した現行の（1）～（3）に加えて（4）の報酬減額請求という選択肢が加わったことになる。
ただしこの部分も、実質的な変更とは言えない。現行の民法でも、瑕疵担保責任に基づく損害賠償請求権をITベンダーの報酬請求権と相殺させることで、実質的に減額請求をすることができるためだ（最判昭和51年3月4日民集30巻2号48頁参照）。
契約を解除できる条件が緩和
三つめの変更点は、ユーザー企業が契約を解除できる条件の変更だ。
現行法は、瑕疵により「契約をした目的を達することができない」場合でなければ、瑕疵担保責任に基づいて契約を解除することができない。
改正法では、瑕疵担保責任に特有の解除ルールがなくなり、債務不履行責任という一般的な契約解除のルールに従うことになった（少しややこしい話だが、この一般ルール自体も今回の改正で変更となったものだ）。
契約解除の一般ルールは少々複雑なため網羅的な説明は割愛するが、契約不適合があった場合、「催告解除」と「無催告解除」という2つのパターンで解除できる。
催告解除はユーザー企業がITベンダーに「契約にしたがった履行をせよ」と催告（催促の通知）して、それでもITベンダーが契約に従って履行しなかったときに初めて契約を解除できるというものだ。ただし、不履行の内容が契約及び取引上の通念に照らして軽微であるときは、解除はできないとされている。
もう1つの無催告解除は、催告をしても意味がない場合などに、催告なしですぐに契約を解除できるというものだ。契約の一部の履行が不可能であり、残りの部分のみでは契約の目的を達成できない場合などに使える。
無催告解除ができるケースとして、例えばバグの修補に相当の時間がかかり、予定時期に稼働できず、それではシステム導入の意味がなくなる場合や、バグの修補は多大な費用がかかるため現実的ではなく、バグが残ったままでは契約の目的を達成できない場合などが考えられる。
この変更は、契約の実務にどのような影響を与えるのか。改正前と改正後では契約解除の枠組み自体が変わったため単純な比較はできない。ただ、現行法で瑕疵担保責任に基づく解除ができたケースと、改正法の下で無催告解除ができるケースは、ある程度重複するのではないかと考えられる。
一方、改正法での催告解除は、現行法の解除とは条件が大きく異なる可能性がある。現行法は「契約の目的を達成することができない」ときにのみ瑕疵担保責任に基づき解除できるとし、解除の条件を厳しくしていた。これに対して改正法の催告解除は、不履行の内容が「軽微」といえるような例外的な場合でなければ解除できる。
何をもって軽微と言えるかは明確ではなく、判例が蓄積されて「相場」が形成されるのを待つ必要がある。ただ条文の文言を比較する限りでは、解除の条件が改正前より緩くなると考えられる。
権利主張の期間が10年に
改正法の4つめの変更点は、権利主張期間の延長である。
現行法でITベンダーの瑕疵担保責任を問うには、システム（目的物）が引き渡されてから1年以内に瑕疵を特定して、修補や損害賠償の請求ないし契約解除の通知をする必要があった。
この権利期間の制限について、改正法は「契約不適合を知ったときから1年」に変わった。
現行法のもとでは、バグの存在に気づくことが難しく、引き渡しを受けてから1年以上経ってからバグを発見した場合には、ユーザー企業はITベンダーに対して瑕疵担保責任を問うことができないとされていた。改正法では、ユーザー企業がバグに気が付いてから1年以内なら修補を請求できる。
ただし、いつまでも権利行使が可能とはいかない。債権一般に関する消滅時効の規定が当てはまり、引き渡し時から10年が経過すると権利行使ができなくなる（改正法166条1項2号）。
契約不適合に気がいてから1年以内にITベンダーへ通知したとしても、気付いてから5年以内に訴訟の提起などをしないと、やはり時効により権利を失う（改正法166条1項1号）。とはいえ、訴訟を提起せずとも気付いてから5年の間は話し合いで解決できる時間があるのだから、この点はそれほど心配する必要はないだろう。
当事者の合意で変更できる
これまで見た通り、今回の改正における実質的な変更点は、解除の可否の条件と権利主張期間の2点である。
ただし、これらの点は任意規定、つまり当事者が合意をすることで変更できる規定であり、契約によって異なる定めを置くことも可能である。契約書の定め方によっては、現行民法と同じ条件を維持することもできる。
このため、もしユーザー企業とITベンダーが現行条件での契約を望むのであれば、改正法に対応して以下の3点を検討する必要がある。
1つは、契約書の中で契約不適合の定義を決めておくことだ。
改正法の「契約不適合」は現行法の「瑕疵」と同等と考えられるが、今まで用いられなかった用語であるため、不確定な部分は残る。そこで当事者間で、どのような場合にITベンダーが責任を負うべきか、不適合の定義をあらかじめ作っておくと良い。例えば「仕様書と異なる場合または契約目的に照らして通常期待される条件を満たしていないとき」などが考えられる。
もう1つは、契約不適合で契約を解除できる条件を再確認することだ。
改正法は現行法と比べて、ユーザー企業側から契約を解除できる条件が緩和される可能性が高い。とはいえ、システム開発は両当事者がプロジェクト体制を組み、長期間にわたって進めていくものである。「軽微な不履行とはいえない」だけで、ユーザー企業が一方的に契約を解除できるようでは、ややバランスを失するともいえる。「契約目的を達成できないときでなければ解除できない」という条項を入れることで、現行法と同等の内容を維持するというのも一つの考え方だろう。
いきなり契約を解除できるのではなく、催告を解除の要件として、ITベンダーに修補など何らかの対応を検討させる方法もあり得る。契約の目的を明確し、あるべき性能をSLA（service level agreement）で示すことで、ITベンダーもユーザー企業も契約解除に関わる不測のリスクを低減できる。
最後の1つは、権利主張期間を改めて契約で設定することだ。
改正法では権利主張期間が延びることになり、引き渡しから10年間は無償で修補を求めることができる。これは一見するとユーザー企業に有利なようだが、そのような無償修補を求めることで、ITベンダーは保守体制を維持するためのコストを保守運用フェーズではなく開発期間中に回収しなくてはならなくなる。このため開発時の費用（請求額）が増大する可能性がある。
改正民法の規定に関わらず、引き渡しの時点からある程度の期間が経過した段階で、瑕疵の修補は有償対応とすると定めることにも合理性はあると言える。
いずれにせよ、開発契約と運用・保守契約の棲み分けも考えつつ、現実的な責任分担となるように契約条項を見直す必要がある。
桃尾・松尾・難波法律事務所 弁護士
