EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

施行間近!120年ぶり民法改正、アナタの会社のIT契約書への影響は?

edited by DB Online   2020/02/27 11:00

IPAの考え方

 こうした議論も踏まえて、IPAのモデル契約書では、この契約不適合責任について以下のような条文を記載することになりました。

 (契約不適合責任)

 第29条

 前条の検収完了後、納入物についてシステム仕様書との不一致(バグも含む。以下本条において「契約不適合」という。)が発見された場合、甲は乙に対して当該契約不適合の修正等の履行の追完(以下本条において「追完」という。)を請求することができ、乙は、当該追完を行うものとする。但し、甲に不相当な負担を課するものでないときは、乙は甲が請求した方法と異なる方法による追完を行うことができる。

 (中略)

 5. 乙が本条に定める責任その他の契約不適合責任を負うのは、前条の検収完了後〇ヶ月/○年以内【であって、かつ甲が当該契約不適合を知った時から〇ヶ月以内】に甲から当該契約不適合を通知された場合に限るものとする。但し、前条の検収完了時において乙が当該契約不適合を知り若しくは重過失により知らなかった場合、又は当該契約不適合が乙の故意若しくは重過失に起因する場合にはこの限りでない。

 このようにIPAでは、契約不適合の起算点を旧民法に寄せた形で「検収完了後」としました。ただしその期間については、システムの特性等を踏まえて「〇ヶ月/○年以内」と自由度を持たせる形にしています。確かに、これであればベンダがいつまでも体制を維持し続ける必要はなく、システムに不具合が発見されるであろう期間を想定し、合理的な期間を設定することもできます。

 ただこの考え方にしてもユーザが“顧客”という強い立場を利用して「〇ヶ月/○年以内」を5年、10年という長期に設定してしまえば、新民法の条文が持つ問題は解消されません。やはりベンダは高い費用を請求するでしょう。

鍵は受入試験計画時の話し合い

 では、どうすべきか。私見ですがユーザが行う受入試験の計画時にポイントがあるのではないでしょうか。契約の条文をどうするかを考える以前に、ユーザとベンダは様々な納品後の不具合発生リスクについて腹蔵なく話し合うことです。何が契約不適合にあたるのかをシステムの特性に照らして具体的に話し合うことがどうしても必要だと考えます(“すべての要件を満たすこと?”、“正常系がつつがなく動いて業務上の効果を得られること?”、“あくまで不具合ゼロ?”、“一定の期間が経過すれば良い?”等々) 。

 これを行うことでベンダは、自分達が納品後対応すべき事柄の範囲を決めることができます。その上で、費用交渉を行えば、見積額も必然的に抑えられるはずです。

 またこれは特にユーザの方にしっかりと言っておきたいところですが、受入試験をきちんと行うことも大切です。行うことというよりも受入試験では何を見るのか、そのためのユーザ側体制とスケジュール、資源の準備をどうするのか。これについてベンダと話し合って合意しておくべきです。

 いかにも形式的な試験しかやらない、あるいはベンダの提出した総合テスト結果報告書だけを見るような受入試験では、ベンダの方が不安になります。これではシステム導入後に不具合が多発するかも知れないと考えて、やはりベンダは見積もり額を上げざるを得ません(世間の常識からは外れるように見えますが、これがIT開発の現実でもあります)。

 後で、大きな対応が必要となるような問題を事前に検出するのに十分な試験項目と、それができる準備があることをベンダにも確認してもらい合意すること、これらは結局のところユーザ、ベンダ双方にとって、リスクを低減することにつながりますので、面倒がらずに、しっかりとやっておくべきではないでしょうか。

 そして後々に起こる不具合の数が減らせる、あるいは、“発生するとしてもこの程度”ということがわかれば、ベンダも想定外に高い見積もりを出すことはなくなるでしょう。こういうことがきちんとできていれば、契約の条文をIPAのように、もしくはもっと新民法に近い形にしようとも、対応は可能なのではないかと私は考えています。

 「情報システムの開発は発注者と受注者の共同作業である」とは、ある裁判で裁判長が述べた言葉です。受入試験の計画立案の際こそ、そんなことを意識する必要があるのではないかと、今回の民法改正を機に改めて思いました(了)。



著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心にITベンダ及びITユーザ企業に対するプロセス改善コンサルティング業務を行なう。現在は、東京地方裁判所でIT開発に係わる法的紛争の解決を支援する傍ら、それらに関する著述も行なっている。 おもな著書に、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』 日本実業出版社、『IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』。

バックナンバー

連載:紛争事例に学ぶ、ITユーザの心得

もっと読む

All contents copyright © 2007-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5