№1872 ソフトウェア開発契約の落とし穴
ソフトウェア開発はユーザー側のシロウトであることや、成果物が目に見えないため、トラブルになりやすい。特にシステム開発そのものがかなり高額であるため、顧客もだんだん本当にまじめにやっているのかと疑り始めてしまう。
こうなると、対立は泥沼化し、訳の分からないメールのやりとり、非難応酬が延々とつづく。このやりとりを見るだけでもたいへんな作業だ。東京地裁の事例は書籍の管理、配送する会社が新システムの導入にあたってトラブルになった事例だ。
問題になっているのは、出版社毎の個別対応プラグラムの作成が追加注文に当たるか否かという点にあった。裁判所は当初の契約段階ではこれはなかったと認定した。その上で追加工事部分については請負代金を支払うべきとしているが、この請負代金はあらかじめ決められていなかった。しかし、裁判所は作成したプログラム数のうち増加分を基準に請け負い代金を決めている（東京地裁H17.4.22）。
この事案の問題点はいくつかある。
① 当初の設計段階で要件定義が明確になっていなかった。
② 顧客側もできあがりイメージできず、そもそも内部で意見対立があった。
③ 顧客側に「現行踏襲」という期待があり、現にある使い勝手の再現を求めた。
④ 顧客側が「現行踏襲」という期待がある割には現行の使い勝手を説明しきっていなかった。
⑤ 当初の仕事内容が明確で無いことから手探りがつづき、納期が遅れていった。
などなど。
判決文からは、当初設計段階での不明確さ、顧客の一貫性のなさが大きく原因しているように見える。顧客の協力義務のようなものが履行されていない結果、プログラムを組む側も大幅な人件費を投入することになり、ついには契約決裂ということになった。
顧客に問題が有りとされた事例ではあるが、IT側も当然問題がある。当初の契約について定義を客観化できなかったことや、追加の作業が必要になった時点での強い交渉力が無く、そのまま流されていったことなども原因している。
ユーザー側はシロウトで、当初から意見を持ちようもない立場にある。ユーザーの真の狙いを引き出すのも専門家としてのIT側のつとめのようなところがある。また、実際に分からないことをいいことに、よく分からない人工代が請求されている可能性もある。契約、契約履行過程の透明化はトラブル回避に不可避と思われる。
ときどき、こちらはやって欲しいことをすでに伝えました。やってくれないあなたが悪いというようなIT側の言い分に出くわすことがあるが、これはかなり顧客を怒らせる言葉だということが分かっていないことが少なくない。
こうした問題については経産省委託事業「情報システム・ソフトウェア取引トラブル事例集」が詳しい。
名古屋Ｅ＆Ｊ法律事務所へのお問い合わせはこちら
