見積もりに合意してないから、要件追加分のお金は払いません！：「訴えてやる！」の前に読む IT訴訟 徹底解説（22）（1/3 ページ）

東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「見積もりの返事を待たずに着手した追加部分」の支払いをユーザーに拒否されたベンダーの裁判例を紹介する。裁判所の判断はいかに？

[ITプロセスコンサルタント 細川義洋，＠IT]

連載目次

　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。ここ数回はソフトウエアの著作権に関する判例を取り上げ、前回は「頭の中に入れた設計情報や機能を、新しい会社で生かし、同じような機能を持つソフトウエアを開発した場合、著作権法に反する行為となるのか」を、裁判例を基に解説した。

　本連載で何度か書いてきたように、最も多いシステム開発失敗の原因は「要件定義と管理の不備」だ。「この機能を作ってくれるはずだった」「いや、そんなことは聞いていない」「動作がイメージしたものと違う」「確かにこのように聞いた」――といった応酬がなされるトラブルは、IT紛争の定番と言ってもいいくらいだ。

　特に多いのは「要件の追加、変更」をめぐるトラブルだ。いったん合意したはずの要件に、「変更したい」「追加したい」とユーザーが後から言いだし、ベンダーが対応しきれずにプロジェクトが頓挫する例は後を絶たない。

　この問題は判例が多く、システム開発プロジェクト成功に資する知見も多いので、数回にわたって解説していこう。今回は「要件の追加・変更を裁判所がどのように考えているのか」を表す判例を紹介する。

ユーザーの要件追加・変更が原因の裁判例

　事件の概要から見ていただこう。

東京地裁 平成15年5月8日判決より抜粋して要約

　あるソフトウエア開発業者（以下ベンダー）が、通信販売業者（以下ユーザー）から、販売管理システムなどの開発を、一括請負6500万円で受託し開発を開始した。

　開発はシステムを幾つかに分けて、順次、開発し納品する形で進められたが、開始当初から、多項目にわたる修正・改善要求がユーザーから出された。

　ベンダーは、これらの要求に対応して作業を行い、追加費用3150万円を請求する見積書を提出したが、ユーザーがこれを支払わなかったため、訴えを起こした。

　ユーザーは自分から追加・変更要望を出しておきながら、なぜ費用を払わないと言いだしたのだろうか。ユーザーは、支払いを拒んだ理由を以下のように述べて反論している。

支払いを拒んだユーザーの言い分

　確かにベンダーから3150万円の見積もりを受け取ったが、ユーザーはこれに合意しておらず、契約の変更は成立していない。ベンダーは追加・変更分についてすでに作業を行っているが、合意が成立していないのだから支払いの対象ではない。

　この論争にはIT独特とも言える慣習が影響している。例えば建築業界だったら、施主が建設着手後に「やはり、もう一つ部屋を作ってほしい」と要求しても、建築業者はすぐに作業をしたりはしない。追加の見積もりを行い、施主が合意するまでは追加の部屋を作るための作業など何もしないだろう。

　しかしITの場合は、要件の不足や誤りに途中で気付くことや、技術的、工数的な問題で要件変更が必要になることは日常茶飯事だ。

　納期が迫る中、時間と工数を無駄にしたくないベンダーが、正式な合意を待たずに追加の作業を行う行為はよくあることだ。「いつも起きていることなら、いちいち作業を止めるよりやってしまった方がいい」という考えが支配的なのだ。

　裁判所は、この辺りの事情を考慮して、判断してくれるのだろうか。