複雑怪奇なIT“業界”を解説する本連載、第1弾はIT業界にまん延する多重下請け構造と偽装請負について、第2弾は多重下請け構造が起こる仕組みについて、第3弾はシステム開発プロジェクトには複数の契約形態が混在することを、第4弾はユーザーはなぜプロジェクトに協力したらがらないのか、第5弾は「案件ガチャ」が起こるメカニズム、第6弾はベンダーの営業が安請け合いする理由、第7弾ではエンジニアの年収が上がらない理由、では第8弾と第9弾では、偽装請負の恐怖、第10弾では、エンジニアが陥りがちな「3つの地獄」について解説しました。
今回は、民法改正で登場した「契約不適合責任」について解説します。
合意できない「契約不適合責任」
民法改正が施行されて2カ月経過し、ITシステムの開発や保守、運用に関わる契約書の中に、これまでの「瑕疵（かし）担保責任」に代わって「契約不適合責任」という文字が見られるようになりました。
皆さんの周囲では、民法改正を元にした契約条項についてユーザーとベンダーがすんなり合意できているでしょうか？ 私の周りでは、この「契約不適合責任」の締結をベンダーが拒んで、旧民法の「瑕疵担保責任」のままにしてほしいと要望する例がまだまだ多いようです。
「契約不適合責任」とは、これまでの「瑕疵担保責任」と異なり、ソフトウェアに不具合があった場合、発注者がそれを発見してから1年以内に受注者に通知すれば、無償の修理や代金の減額、あるいは契約の解除（事前に催告が必要）を求められるというものです。
これまでであれば、納品したソフトウェアに不具合があっても、納品から1年以上経過した後に発見されたなら、受注者であるベンダーには、無償で修補したり、損害を賠償したりする義務はありませんでした。どのような対処を行うか、有償か無償か、あるいはいつ行うのか、については、発注者と相談の上で決めていたわけです。
しかし今回の改正では、受注者であるベンダーは最長10年間、いつ不具合が判明しても対処できるように、要員やテスト環境を確保し続けなければなりません。確かにベンダーが嫌がる気持ちも分からないではありませんし、これに対応するならば見積金額を大幅に上げざるを得ないとするベンダーもいます。そうなると「被害」はユーザーに及ぶことになります。
そんなこともあって実際に結ばれている契約の中には、言葉を契約不適合責任に変えただけで、その実は旧来の瑕疵担保責任と何ら変わらないというものもあります。
そもそも何を意図しての改正だったのか。
しかし、そもそも民法の改正には「IT契約の現実に法律を合わせていこう」という意図があるのではないでしょうか。
私の経験では、ITのシステムは「納品後1年」で不具合が全て見つかることはまずありません。例えば、年次処理の不具合は1年を過ぎてから見つかるものです。何年もデータがたまったり、ユーザーが増えたりして、初めて分かる不具合もあります。また、数年たって初めて使われる機能などもありますから、実際のところ、1年以内に不具合を全てたたき出せないケースは多々あります。
小さなシステムなら、数週間も動かせば一通りの確認ができるものもあるでしょう。しかし、規模や特性にかかわらず全てを「1年」とくくってしまうのは、あまり現実的ではありません。だから今回の民法改正では、この1年という縛りを取り払って、「不具合を発見してから1年以内に通知」すればいいということになったのでしょう。
すり合わぬ平行線
しかし契約現場のやりとりを聞いていると、ユーザーが改正民法をそのまま取り入れようとしても、ベンダーがそれを拒んで交渉が暗礁に乗り上げる、ということが頻繁に起きているようです。
ユーザー、つまり発注者は「せっかく民法がユーザー有利になったのに、わざわざ昔の不利な瑕疵担保責任を維持することはない」と考え、民法そのままに「契約不適合責任」の条項を乗せようとします。しかし受注者であるベンダーは、最長10年もの間、いつ不具合を指摘されても無償で対応できるように、要員や開発環境を維持し続けなければならないのは負担です。何とか1年で責任から逃れられる瑕疵担保責任にしておきたいと考えるのは、自然なことではあります。
ベンダーには、もともと別の不満もあります。
不具合の中には、そもそもユーザーがきちんと受け入れ試験を行っていれば容易に発見し、その場ですぐに修正できたものも多い。それをいい加減なテストで、あるいはテストらしいテストも行わずにシステムを受け取っておいて後から指摘する、といった無責任な行動を取られることです。もし契約不適合責任で契約を結べば、そうしたユーザーの無責任さを助長し、「不具合はいつでも修正させられるから、受け入れテストは、そこそこに」などといういい加減なユーザーが増えることになるのではないか、との不安もベンダーにはあるようです。
しかしユーザーには、前述の通り「不具合の中には、1年を過ぎて初めて判明し、またそれが業務に大きな影響を及ぼすものもあるのだから、1年過ぎたら無罪放免では納得できない」という考えもあります。それはそれで理解はできます。
保守契約は有効か
この問題の解として「保守契約」を利用する案があります。
システムが納入された後、ハードウェアの故障やそれに伴うソフトウェアやデータの破損、小規模な機能修正や追加など、個別に契約を立てるにはあまりに小さな作業について、月額の定額サービスとして契約し、定めた工数の範囲内で必要な作業を実施するという契約です。開発中に仕込まれたソフトウェアの不具合が判明しても、契約工数の中で対応すれば、新たな費用が発生せずに作業を行ってもらえるという考えです。
しかし私は、保守契約が必ずしも「銀の弾丸」になるとは思いません。保守契約は、上述のように、何か後発的な事情で発生した作業を行うためのものです。納入時の品質には問題なかったがその後に起きた事象に対応するもので、潜在的な不具合に対応するのは本来の姿ではありません。
例えば、限られた保守工数を不具合のために使い、本来行うべき作業の時間が取れなかったとしたら、ユーザーの目に見えない損失です。ベンダーも顧客満足度低下という被害を受けることになります。多少のことならともかく、あまり多くの工数を不具合のために割くのは控えるべきでしょう。また、不具合の発生によってユーザーに生じた損害についてはもちろん保守契約の対象外になりますから、やはり、このやり方には限界があります。
契約条項検討の前にお互いの不信感を理解する
では、ユーザー、ベンダー、双方が納得できる契約を結ぶにはどうすればいいのでしょうか。
まずは、ユーザーとベンダーがお互いに持つ「不信感」について考えてみるべきでしょう。そもそも契約不適合責任が結べないのは、この不信感が主たる要因だと私は考えます。
ベンダーの不信感とはどのようなものでしょうか。
「ユーザーは、契約不適合責任を理由に、どこまでも無限に作業を命じてくるのではないか」「いつでも不具合をタダで修正するとなると、ユーザーは受け入れ試験を真面目にやらないのではないか」――これらは、私もオブザーバーとして話を聞いた情報処理推進機構（IPA）で行われた、ソフトウェア開発モデル契約書・民法改正ワーキンググループでベンダーサイドの委員から出た話です。
同じ検討会で、ユーザーサイドの委員からは以下のような意見が聞かれました。
「そもそもベンダーが最初の1年で全ての不具合を出し尽くせるほど品質の良いものを納品するとは思えないし、やはり不具合にお金を出すのは納得いかない」「もし契約不適合責任を採用しても、大幅に上がる見積もりの妥当性にも疑念が残る」という話もありました。
こうした意見は私が目の当たりにした契約交渉でも出ましたので、実際にはかなり多くの当事者たちが同じことを考えているのではないでしょうか。
そう考えると、今後契約を結ぶときには、以下の点について合意する必要があると思われます。
- 契約不適合の対象となる事象や範囲はどこまでなのか
- 契約不適合の責任年限をどう定めるのか（納品後何年間までか）
- ベンダーが上乗せするという見積もりは妥当か
契約の実例
私はある官庁で、前記考えの下、以下のような内容でベンダーと契約を行っています。この考えがうまくいくようであれば、これを省内、政府内に広めていこうとも考えています。上述の「1」から「3」について、実例を元に紹介します。
1 契約不適合の対象となる事象や範囲はどこまでなのか
システムの特性によって異なりますが、過去の裁判などで債務不履行とされた例なども参考に、契約書別紙として以下のような事柄を定めました。
本件システムの開発、更改において以下に記す事象が発生した場合には、これを契約不適合に充たるものとする。
（1）期限までに納入された成果物の個数が仕様書に記す個数に比べて足りないとき
（2）発注者（ユーザー）の帰責事由によらずに、発注者と受注者（ベンダー）が合意したプロジェクト計画書で予定された工程の全てが納入期限までに完了しないとき、もしくは完了しないことが明らかになったとき
（3）発注者の帰責事由によらずに、発注者と受注者が合意した要件の全てが満たされないとき
（4）発注者の帰責事由によらずに、発注者の業務に支障が出ることが想定される不具合が残存しているとき
（5）受入試験中および納品後に発見された不具合について、その改修計画または調査計画立案および不具合残存中の対応策検討のための協議に受注者が応じないとき
（6）受入試験中および納品後に発見された不具合について、その改修計画または調査計画、不具合残存中の対応策について発注者と受注者が合意した期限までに示されないとき
（7）発注者の帰責事由によらずに、発注者と受注者が合意した期限までに不具合の改修が完了しないとき、もしくは完了しないことが明らかになったとき
2 契約不適合の責任年限をどう定めるのか（納品後何年間までか）
責任年限は、基本的なルールの例を以下のように定めました。もちろん組織やシステムの特性によって異なるとは思いますが、切り口はおおむねこうしたものが必要ではないかと考えます。
システムの特徴 | 設定する年限（例） |
年次処理がある | 1年2カ月に設定 |
データがたまって初めて分かる不具合がある | データがたまる期間以上に設定 |
長期に渡って使用されない機能がある | その使用時期を包含できる期間に設定 |
使用される時期が特定できないシステム（処理）がある | 1年に設定し、以降は保守契約で対応 |
特段考慮すべき特性がない | （従来の瑕疵担保と合わせた場合）1年に設定 |
3 ベンダーが上乗せする見積もりは妥当か
見積もりの精査は、「1」「2」の結果なども考慮して詳細に検討する必要があります。
少し注意しなければいけないのは、実際の作業はやってみなければ分からないことが多いので、安全をみてなるべく多めに工数を積みたいけれど、それをやり始めるとキリがない、という点です。
そこで、作業内容が不確定の部分は、何らかの「前提」を置いて上限を付けます。「不確定部分については、別途見積もりとする」「××時間の範囲で実施する」などの前提を付けると、見積もりを抑えられるかもしれません。
ここに挙げたのは、あくまで一例です。しかし、少なくとも、契約不適合責任に関しては、双方の不信感をしっかりと理解し、かなり突っ込んだ話し合いをしないと、本当の意味での合意は難しいと思います。また、そうして決められたものでも、本当にそれが妥当な契約であったかどうかは、やってみないと分からないところもあります。そこで、「この契約は、1年後にもう一度見直す」などの約束を付けるのも良いかもしれません。
民法改正をきっかけに、本当に腹を割って話すことができれば、契約内容が自ずと見えてくるだけではなく、ベンダーとユーザーが真のパートナーになれるのではないか。そんな期待感も私は持っています。