伊藤雅浩が,システム開発,ソフトウェア,ネットなどのIT紛争に関する裁判例を紹介します。要件定義書に記載されていない機能について,当事者間のやり取りによって開発対象に含まれるとした事例。平成25年2月7日,セレクトショップを運営するYは,Xに対し,ECサイトの開発を委託した。報酬は640万円(税別)で,着手時に320万円,納品後に320万円を支払うこととなっていた。Yは,上記合意に基づいて,着手金320万円+税を支払った。同年9月30日,XYは,納期を同年12月27日へと変更することのほか,スケジュール管理を怠った場合には,段階的に報酬額を3割減額すること,納品後の報酬を放棄すること,既払いの着手金を返還することといった内容を含む覚書(本件覚書)を取り交わした。Yは,平成26年2月27日付けの文書をもって履行を催告した後,債務不履行を理由とする解除と既払いの着手金を返還するよう求めた。Xは,未払報酬320万円+税の支払いを求めたのに対し(本訴),Yは,解除に伴う原状回復請求として既払金320万円+税の返還を求めた(反訴)。結局,合意した仕様が何なのかが争われた事案である。少々長いが適宜編集しつつ判決文を引用する。小規模な案件だけに,丁寧にドキュメントを作成しながら合意を形成したという経緯がないことが伺える。)を同様の方法により送付し,D及びEも,この内容を了承して,XとYとの間で,本件ECサイトの仕様に関する合意が成立したことが認められ,この他に,本件ECサイトの仕様に関する合意内容を示す要件定義書又はこれに類する文書等は見当たらない。XとYとの間における本件ECサイトの仕様に関する合意内容を示すものとみるべき文書等が存在しない限り,本件要件定義書の記載内容が,XとYとの間における本件ECサイトの仕様に関する合意内容を示すものであるといえる。Yの運営する実店舗とのポイント連携機能が仕様に含まれるか否かが争点になっていた。この点について裁判所は,本件要件定義書の記載には,そのような機能が含まれているとは解されないとしつつも,Dは,Cに対し,本件要件定義書が作成される前である平成25年4月23日,「毎年ポイントを締めて期限付きの値引き対応をする流れとなりました。よって,毎年ある月になるとポイントを締めてメールにて割引を告知。メールには,ネットで使う場合の番号とバーコードが記してあり,ネットでそれを使う場合には,決済時にコードを入力,店舗で使う場合には,バーコードをプリントアウト,もしくはスマホにて表示で持参する。上記をもりこんで再度先日のお打ち合わせで決めた内容を刷新して要件定義をいただけますよう宜しくお願い申し上げます。」との電子メールを送信していることが認められ,また,これに対し,Cが,Dの上記要望を仕様の内容に含めることができない旨をY側に伝えた事実は何らうかがわれない。いったメールのほか,開発期間中のやり取りを取り上げて,実店舗とのポイント連動機能は仕様に含まれると認定した。そのほかにも日英表記の変換を可能にするかどうかも争われていたが,これも同様に各種証拠から仕様に含まれるとした。争点(1)で認定した仕様の範囲に基づいて完成・引渡しを判断した。Xは,Yが平成25年11月30日に本件ECサイトを完成させ,これをYに引き渡した旨主張するが,Xが,Yに対し,同日,実店舗とのポイント連動及び英文サイト構築を含む本件ECサイトを完成させたことを認めるに足りる証拠は全くない。,(略)[1]平成25年9月上旬頃,Xの担当者であるCの所在が不明となり,後任のFは,本件ECサイトの仕様の内容等を十分把握していなかったこと,[2]Fは,Dに対し,同年11月25日及び同月27日,本件ECサイトのオープンの目途が未だ立っていない旨を伝えたこと,[3]Fは,同年12月の時点においても,(略)実店舗とのポイント連動の実現が可能となるか否かを調査していたが,これが不可能であることが後に判明したこと,[4]Yは,平成26年1月14日に,Xが本件ECサイトの構築をg社に下請発注していたことを知り,その後,XにECサイト構築のノウハウがないことや,g社の製作料金が安いことなどから,本件ECサイトの構築をg社に直接発注したいとの意向を示したこと,[5]Xは,Yに対し,同年2月17日付けの書面を送付するまでの間,本件契約に基づく報酬残金320万円の支払を求めることはなかったことをそれぞれ認めることができ,これらの事実に照らせば,Xは,平成25年11月30日の時点及びその後においても,本件ECサイトを完成させるに至っていないものというべきである。以上のように述べて,完成・引渡しを否定した。その結果,Xの本訴請求については全部棄却し,Yの反訴請求のすべて(既払金の返還+決済代行業者やデータセンタ事業者に支払った費用の損害賠償)を認容した。若干のコメント本件は特に法的に真新しい判断があったわけでもなく,世間的に注目を浴びる事案だったわけでもありませんが,中小規模の開発取引における仕様の範囲の認定が実務上の参考になると思って取り上げました。裁判所も,基本的には文書に基づいて仕様の範囲を認定しますから,本件でも要件定義書(改版を含む)に記載されたものが仕様の内容だとしています。そこに記載されていないものが一切仕様に含まれていないということではなく,その契約締結前後におけるメールや会議でのやり取りを踏まえて合意の内容を探索しています。契約分野別研究(製作及び開発に関する契約)」*1に詳しく述べられており,実際の紛争において仕様の範囲を主張・立証する際に参考になります。ユーザとしては,要件定義書や基本設計書をあまり細かくチェックしないままスルーしてしまうものです。本件のようにメールのやり取りなどを通じて「きちんと作ってくれと伝えてた」と立証に成功すればよいのですが,基本的には伝えたことが文書に残っているかどうかをよく確認しておきたいところです。ベンダも,上流工程から参画していればなおさらのこと,ドキュメントに書いてあることだけ作ればよいわけではありません。ところで,本件では,Xの担当者Cが途中で所在が不明になり,経緯のわからない担当者が着任するなど,いろいろと大変なことがあったようです。東京地判平24.5.30(平22ワ16272)アジャイルによる開発の履行の有無が争点の一つとなった事例。東京高判令2.2.7月別アーカイブはてなブログをはじめよう!redipsさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。