IPAの考え方
こうした議論も踏まえて、IPAのモデル契約書では、この契約不適合責任について以下のような条文を記載することになりました。
（契約不適合責任）
第29条
前条の検収完了後、納入物についてシステム仕様書との不一致（バグも含む。以下本条において「契約不適合」という。）が発見された場合、甲は乙に対して当該契約不適合の修正等の履行の追完（以下本条において「追完」という。）を請求することができ、乙は、当該追完を行うものとする。但し、甲に不相当な負担を課するものでないときは、乙は甲が請求した方法と異なる方法による追完を行うことができる。
（中略）
5. 乙が本条に定める責任その他の契約不適合責任を負うのは、前条の検収完了後〇ヶ月／○年以内【であって、かつ甲が当該契約不適合を知った時から〇ヶ月以内】に甲から当該契約不適合を通知された場合に限るものとする。但し、前条の検収完了時において乙が当該契約不適合を知り若しくは重過失により知らなかった場合、又は当該契約不適合が乙の故意若しくは重過失に起因する場合にはこの限りでない。
このようにIPAでは、契約不適合の起算点を旧民法に寄せた形で「検収完了後」としました。ただしその期間については、システムの特性等を踏まえて「〇ヶ月／○年以内」と自由度を持たせる形にしています。確かに、これであればベンダがいつまでも体制を維持し続ける必要はなく、システムに不具合が発見されるであろう期間を想定し、合理的な期間を設定することもできます。
ただこの考え方にしてもユーザが“顧客”という強い立場を利用して「〇ヶ月／○年以内」を5年、10年という長期に設定してしまえば、新民法の条文が持つ問題は解消されません。やはりベンダは高い費用を請求するでしょう。
鍵は受入試験計画時の話し合い
では、どうすべきか。私見ですがユーザが行う受入試験の計画時にポイントがあるのではないでしょうか。契約の条文をどうするかを考える以前に、ユーザとベンダは様々な納品後の不具合発生リスクについて腹蔵なく話し合うことです。何が契約不適合にあたるのかをシステムの特性に照らして具体的に話し合うことがどうしても必要だと考えます（“すべての要件を満たすこと？”、“正常系がつつがなく動いて業務上の効果を得られること？”、“あくまで不具合ゼロ？”、“一定の期間が経過すれば良い？”等々） 。
これを行うことでベンダは、自分達が納品後対応すべき事柄の範囲を決めることができます。その上で、費用交渉を行えば、見積額も必然的に抑えられるはずです。
またこれは特にユーザの方にしっかりと言っておきたいところですが、受入試験をきちんと行うことも大切です。行うことというよりも受入試験では何を見るのか、そのためのユーザ側体制とスケジュール、資源の準備をどうするのか。これについてベンダと話し合って合意しておくべきです。
いかにも形式的な試験しかやらない、あるいはベンダの提出した総合テスト結果報告書だけを見るような受入試験では、ベンダの方が不安になります。これではシステム導入後に不具合が多発するかも知れないと考えて、やはりベンダは見積もり額を上げざるを得ません（世間の常識からは外れるように見えますが、これがIT開発の現実でもあります）。
後で、大きな対応が必要となるような問題を事前に検出するのに十分な試験項目と、それができる準備があることをベンダにも確認してもらい合意すること、これらは結局のところユーザ、ベンダ双方にとって、リスクを低減することにつながりますので、面倒がらずに、しっかりとやっておくべきではないでしょうか。
そして後々に起こる不具合の数が減らせる、あるいは、“発生するとしてもこの程度”ということがわかれば、ベンダも想定外に高い見積もりを出すことはなくなるでしょう。こういうことがきちんとできていれば、契約の条文をIPAのように、もしくはもっと新民法に近い形にしようとも、対応は可能なのではないかと私は考えています。
「情報システムの開発は発注者と受注者の共同作業である」とは、ある裁判で裁判長が述べた言葉です。受入試験の計画立案の際こそ、そんなことを意識する必要があるのではないかと、今回の民法改正を機に改めて思いました（了）。
