ブログトップ 記事一覧 ログイン 無料ブログ開設

IT・システム判例メモ

2012-05-02

要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22(平20ワ16510号)

ユーザがベンダに対し,ベンダが一方的に開発契約を解除したとして,損害賠償を求めたが棄却された事例。


事案の概要


ユーザXは,ベンダYに対し,平成14年9月18日に,Xの人材派遣業務に必要なシステムとして2つのシステムの開発を委託した(契約金額の合計は840万円)。


その後,Yは,9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが,Xは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに,下請業者が交替するなどして,翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが,Xは,やはり記名捺印を拒絶し,確定しなかった。その後もYからはドキュメントが提出されているが,Xはやはり拒絶した。Yは,Xに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局,平成16年9月になって出されたドキュメントについても,Xは記名捺印を拒絶した。


この間,Yからは,Xの望むシステムは,当初契約の想定よりも拡大していることから,追加費用の支払いが必要であると説明したが,Xは追加費用の申し出には応じなかった。


ようやく平成17年1月になって,Yは,Xに対し,内容証明郵便で,たびたびXが仕様の確定を拒否し,追加費用の支払いに応じることなく仕様の確定を遅延させることは信義則に違反するとして,契約を解除する旨を通知した。Yは,契約金額等を返金した。


Xは,Yには債務不履行(履行不能)または告知義務があるとして,システムの完成を前提として支出した費用等の損害賠償約1.2億円を請求した。

ここで取り上げる争点


結果的に,3年かけてもYがシステムを完成させることができなかった上に,Yから契約解除を通知してきたことは,Yの債務不履行となるか。

裁判所の判断


前提として,Xは,Xの主張する機能が,当初の契約の範囲に含まれていたと主張したが,Xが主張するような広範な機能が当初から合意されていたわけではないとされた。


続いて,要件定義がここまでもつれたことについて,裁判所は一般論として,

ソフトウェアの開発は,注文者側と請負人側との間で開発すべきソフトウェアの性能,仕様,形態等に関する具体的なイメージを共有するため,注文者側の技術担当者と請負人側の技術担当者との間に密接な協力関係があることが必要不可欠であるところ,特に,開発の出発点である要件定義を確定する工程については,注文者の要求をまとめる工程であると定義されるとおり,注文者側の意向によってその内容が決せられることになるのであるから,注文者側がどのような内容のソフトウェアの開発を望んでいるかを提示又は説明する責任は,注文者側にそのような能力がないことが前提になっているなどの事情がない限り,注文者側にあるというべきである。


として,仕様提示,説明の責任はユーザ側にあるのが原則であるとした。Yは,システム確認書を提示したり,プロトタイプを納品したりしたにもかかわらず,一向にXがシステム仕様を確定しなかったと認めた。さらに,

一般に,要件定義が定まらない時点で締結されるシステム開発に係る契約については,開発規模それ自体の大きさなどを想定して契約金額が決められるのであるが,契約当事者間において開発内容を具体化していくその後の打合せにおいて,備えるべき新たな機能の追加など,当初の契約段階で客観的に想定されていた開発規模を超える内容のシステム構築を注文者が求めたような場合には,契約当事者の合意の基礎となった事情に変更が生じているのであるから,注文者は,上記内容のシステム開発を当初の契約金額の範囲で受注者に対して製作することを求めることはできないものと解すべきである。


当たり前といえば当たり前のことを述べ,要件追加,変更があれば,そこに対応する追加費用の合意がない限り,ベンダに開発の義務は生じないことを述べている。


結局,履行不能となった原因について,

Xにおいて,Yとの打合せのたびに新たな要求事項を追加するなどして,本件ソフトウェアの要件定義を確定させようとしなかった上,Yからされた追加費用の負担の提案にも一切応じようとしなかったことに最大の原因があると考えられる。そうだとすれば,Yに債務不履行(履行不能)の原因があるということはできないというべきである。


とした。途中で,「最後まで誠意をもって開発を行います。」と書いた念書を差し入れたからといって,いかなる要望をも取り込むことを約したわけではないとした。最終的には,

むしろ,(Yによる追加費用の申し出)を全く受け入れることなく,当初の契約金額による本件ソフトウェアの完成を要求し,これに固執したXの対応こそが不合理なものというべきである。


と,とどめを刺し,Xの請求は棄却された。

若干のコメント


過去の判例でも,システム開発は,伝統的な請負契約と異なり,注文者であるユーザ側が仕様を提示したり,意思決定を適時に行うなどの「協力義務」を負っていることが認められています*1。本件は,具体的にその協力義務の違反があったことを認めた事例の一つとなります。


とはいえ,本件は,若干特殊な事例であり,当初1000万円に満たない規模のシステムであったにもかかわらず,要件の確定に3年も要するなど,尋常でない経緯をたどっています。事実認定を見ると,相当多数回の打ち合わせが行われ,ベンダもプロトタイプを開発するなどの工数を投下したにもかかわらず,ユーザが仕様確定を拒絶しているなど,「モンスターユーザ」の典型であったともいえるでしょう。


本件は,結果的にそのようなユーザの対応が不合理であったということが裁判所に認められ,請求が棄却されたものの,ベンダは,既払い金をすべて返還しており,相当な損失が生じたものと思われます。したがって,ベンダからみれば,もっと早期に対処し,勇気ある撤退をすべきであった事案ですし,そうであったとしても,仕様確定を促すエビデンスさえ残っていれば,ベンダの債務不履行責任は問われなかったと思われます。。

*1:東京地判平16.3.10 http://d.hatena.ne.jp/redips+law/20120210/1328884424 参照。

名無し名無し 2013/06/07 17:13 カレーとシチューはルーを入れるまでは、どちらにするか変更できる。
その後、変更するのは至難であることを説明すべきですね。

名無し名無し 2013/06/19 02:52 モンスターユーザーじゃなくて、要件定義すらできない馬鹿ベンダーが問題ですよ。
現場を考えないイエスマンが客先定例に出て、出来もしないことを約束して工数が膨らむ、典型的なハズレベンダーのパターンですね。

天の声天の声 2014/08/28 13:46 ?仕様書確定以前の概算見積 ?仕様書確定後の見積 ?確定以後の追加・変更分の見積 と分けて対応すべき事案。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証