IT・システム判例メモ

弁護士 伊藤雅浩が,システム開発,ソフトウェア,ネットなどのIT紛争に関する裁判例を紹介します。

システム開発契約の成立 東京地判平21.9.4

これまでにも類似の事例を紹介してきたが,本件もシステム開発契約が成立したかどうかが問題となった事例。

事案の概要

ベンダXとユーザYとの間で,全社情報システム開発の構想が進められた。その過程で,XからYに,パッケージソフトを用いることとされ,そのライセンス料として,2900万円(税込),カスタマイズ費用として,3155万円(同),要件定義,トレーニングなどの項目を含む見積書(総額8202万円)が提示された。


YからXに,3種の発注書(要件定義作業,ソフトライセンス,講習)が送付された。YはXに対して,ライセンス料の一部(1500万円+税)を支払ったが,その他の支払はしていない。


Xによる要件定義後に,カスタマイズ費用を再度見直したところ,7084万円が提示されたことから,Yは開発中止を通告した。Xは,Yに対し,パッケージのライセンス料残額1400万円,要件定義費用約1000万円の支払を求めた(本訴)。


Yは,上記総額8202万円の見積もりを以って,システム全体を完成させる契約が成立していたとして,システムが完成していないのだから,支払う義務はなく,逆に支払済みの費用の返還を求めた(反訴)。

ここで取り上げる争点

XY間で成立していた契約の個数及び範囲。Yの主張するように,全体が一つの契約であったとすると,システムが未完成であればYに支払義務が生じないようにも考えられる。。

裁判所の判断

裁判所は,Yの主張を採用せず,システム開発契約が成立していない,と判断した。その考慮要素としては次の点があげられている。

  • XもYも相当規模の会社であり,総額8000万円を超える取引であるから。,納期等の契約書面を作成するのが自然であるところ,システム使用許諾契約以外の契約書が作成されていない。
  • 見積書に「ライセンスは,導入決定と共に御発注いただきます。」という記載があるが,「Fit&Gap及び要件定義にて要件の範囲が広がる場合には,追加工数が発生する場合がございます。」「・・を想定して見積もりしております。」などの記載があることから,概算の見積もりを提示するもので,未確定な要素を含んでいる。
  • (開発部分について)発注書のひな形の送付に関するやり取りがあり,別途発注書を作成することが想定されていた。


結果として,要件定義作業は完了し,ライセンスも配布されているので,Xの請求が認容された。

若干のコメント

事実関係に照らすと,想定どおりの判断だが,ユーザとしては,結局使わないパッケージソフトのライセンス料と要件定義費用だけ支払わされて納得いかない結果であったことは疑いない。パッケージソフトの導入に限らず,要件定義*1によって,総額が固まることが多いため,ふたを開けてビックリということがしばしば起こる。


とはいえ,いきなり最初から金額の総額を固めた契約書一本にすることができるかというと,これはほぼ不可能。では,どうやって進めるかが問題になるが,私はよくこういうときに基本合意書のようなものを作ることを提案している。よくあるシステム開発契約の「基本契約書」とはちょっと異なる。基本契約書については,複数の個別発注(要件定義,設計,開発・テスト等)における契約条件の共通部分を抜き出したようなものであって,総額いくらでやるとか,全体スケジュールがどうなっている,といったことが書いていないことが多い(経産省のひな形もそうなっていない。)。基本契約書を取り交わしたとしても,本件の問題が回避できるとは限らない。


ここでいう基本合意書とは,金額,進め方の大枠について合意したことを確認する文書である。ベンダは提案時に総額○億円,開発期間○カ月という額を提示しているのだから,その内容を合意書に埋め込む。ここに法的拘束力を持たせるとなると,ベンダが躊躇するのは当然のことなので,法的拘束力を持たないような表現にしておく。しかし,ただの精神規定ではあまり意味がないので,この総額,期間を変更するには,どういう場合に可能なのか,どういうプロセスで変更するのかといったことも書いておく。可能ならば,途中でとん挫した場合の清算,処理方法についても書いておく。


ポイントは,ベンダの提案書に書いたことを「合意書」という双方のサインがある文書に落とし込んでいくこと。ベンダは,自分で提案したことであるため,合意書に盛り込むことを拒否しにくい。逆に,ベンダは,「前提条件」もしっかり落とし込むことで,自分を守る必要が出てくる。


これはユーザにとっては,途中まで進めておきながら,急に高い見積もりが出てくるという事態を一定程度回避できるし,ベンダにとっても,ユーザからの過大な要求を抑制しつつ,最終工程までの受注可能性を高めることができる。

*1:パッケージソフト利用の場合には,適合性分析,Fit&Gap分析などともいわれる