要件定義も設計もしてもらいましたが、他社に発注します。もちろんお金は払いません!:「訴えてやる!」の前に読む IT訴訟 徹底解説(24)(2/3 ページ)
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回も正式契約なしに着手した開発の支払いをめぐる裁判を紹介する。ユーザーの要請でエンジニアを常駐して設計まで進めた開発案件、「他社に発注することにした」はアリ? ナシ?
契約前作業を行ったが、受注できなかった裁判の例
まずは、事件の概要から見ていただきたい。
東京地方裁判所 平成20年7月29日判決より抜粋して要約
あるインターネット通販会社(以下ユーザー企業)が、開発ベンダー(以下ベンダー)にシステム開発を委託しようと考え、機密保持契約と開発基本契約を締結した。ただし、プロジェクトの金額や範囲については、別途、契約書を作るものとして、その時点では作成していなかった。
ベンダーはこれを事実上の発注と考え、作業に着手し、多数のメンバーがユーザー企業に常駐して、要件定義と設計作業を行った。
ところがユーザー企業は、この最中にベンダーが作成した資料に基づいて提案依頼書を作成して、入札を行った。ベンダーは入札に参加したものの受注できず、開発は別のベンダーに発注された。
ユーザー企業はベンダーに対して、要件定義の費用は支払ったが、設計にかかる費用は支払わず、ベンダーはその費用3800万円を求めて訴訟を提起した。
法律論はともかく、一般常識、あるいは人間の情として、ユーザー企業の態度に同意しかねる読者は多いだろう。
ベンダーからすれば、秘密保持契約や基本契約を結び、実際に設計まで作業を進めていることを容認していたのだから、ユーザーの発注意思を疑う理由がない。「自分たちが作成した資料を元に作った提案依頼書を他ベンダーに配布して入札を行う」と知らされたときの、ベンダーの驚きと落胆、そして怒りは想像に難くない。
だが、金額や作業範囲、成果物などを記した契約書がない以上、ユーザー企業を縛る明確な債務はない。
範囲も金額も定かでない基本契約では、債権・債務関係が成立しない
では、契約成立について、裁判所はどう判断したのだろうか。
東京地方裁判所 平成20年7月29日判決より抜粋して要約(続き)
このユーザー企業とベンダー間のシステム開発契約は、秘密保持契約締結時点において、開発範囲が明確になっておらず、基本契約にも委託範囲を記していない。また、金額についても具体的な協議がないことから、成立していたとは認められない。
簡単に言えば、開発範囲と金額について協議し、契約書に書かれていない以上、契約は成立していないということだ。かなりベンダーに厳しい判断だ。
「契約前作業など、そもそもやるべきではない」というのは正論だ。近年、大手ITベンダーでは、正式契約のない作業着手は禁止されつつある。
しかし、ベンダーとしてシステム開発に参画したことのある方なら分かるだろう。システム開発は、スケジュールがひっ迫しているのが常であり、ユーザー企業が希望する納期を達成するためには、一日たりとも無駄にできない。基本契約まで結んでいるのであれば、時間のかかる「費用交渉」や「法務的なチェック」は営業担当と法務部門に任せ、現場は少しでも作業を前に進めたいと考えるものだ。
また、正式発注までエンジニアを待たせておくことは、ベンダー企業にとって月に数百万、場合によっては数千万円の損失になる。
ユーザー企業はエンジニアの待機時間分まで費用を払ってはくれない。かといって、いつプロジェクトが始まるか分からない状態で、エンジニアを他のプロジェクトに振り向けてしまうわけにもいかない。ならば、「基本契約しかないけれど作業を始めてしまおう」とベンダーが思ったとしても、無理からぬことかもしれない。
こうした事情もくんでか、裁判所は判決を次ページのように続けている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- PMBOK流:業務委託先の選び方
外部に委託する作業が決まったら、委託先の業者を決定するための準備に移ります。このプロセスの主要なアウトプットは、「調達文書」と「評価基準」です - 「契約もアジャイルに」、中堅SIerの新たな挑戦
アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている - 締結5日前にユーザーが白紙撤回! 契約は成立? 不成立?
ユーザー窓口が確約した「○月○日に正式契約しましょう」を信じて一部作業に事前に着手したベンダーは、突然の契約白紙撤回に泣き寝入りするしかないのか? - システム化範囲がぶれていれば失敗する
プロジェクトの失敗で、一番多いのはシステム化範囲(スコープ)がいつのまにか大きく膨らんでしまい、納期も遅れ、コストも膨らんでしまうケースである - IT業界の下請け構造を知る
皆さんが下請けという言葉に悪いイメージを持っていることは認識していますが、下請けがすべてダメなわけではありません