システムが納期までに完成しなかったとして，ユーザが既払い金の返還を求めた事案。
事案の概要
医療法人Ｘが，歯科医院向けシステムの開発をベンダＹ１に委託し，Ｙ１は，下請業者Ｙ２に再委託した（実際の開発は，ほぼＹ１からＹ２に対して丸投げだったようである。）。Ｘは，Ｙ１に4200万円を支払ったが，Ｙ１が当初定められた納期までにシステムを納入できなかった。
その後，Ｙ２がシステムを提供したが，Ｘは，多数の不具合があるとして契約を解除し，Ｙ１に対し，既払い金の返還と逸失利益の合計約１億円の支払いを求めた。
なお，納期遅延が生じたときの交渉の際に，ＸはＹ１に対して「Ｙ２と直接取引させてもらう」などといったやり取りがあったことから，予備的に契約上の地位がＹ２に移転したとして，Ｙ２に対しても，不法行為に基づく損害賠償として，既払い金相当額の支払いを求めた。
ここで取り上げる争点
ＸとＹ１とのやり取りで，契約上の地位が移転されたかという争点（誰が請負人か）という争点もあったが，ここでは割愛する（裁判所は地位移転の合意までを認めず，あくまでＸの契約の相手方はＹ１だとした。）。
そこで，提供されたシステムが，契約の本旨に従ったものであるか（完成しているか）という点が問題となった。
裁判所の判断
まず，裁判所は，開発対象となる機能を以下の通りに認定した（適宜見やすいように編集）。
(1) 本件元請契約においては，業務の詳細は「Ｘ会殿向けレセプトお見積仕様書」に定めるものとされ（本件元請契約１条），本件下請契約においては，業務の詳細は見積Ｎｏ．２００８０４２２−０１「Ｘ会殿向けレセコンシステム」に定めるものとされていること（本件下請契約１条），(2) Ｙ１は，平成２０年２月２９日，原告に対し，「Ｘ会殿向けレセコンシステム見積仕様書」（本件見積書）を提出したこと，(3) Ｙ２は，本件下請契約に基づき，本件システムに係る要件定義から結合テストに至る工程を請け負い，その要件定義の業務に係る書面として，平成２０年６月２日，Ｙ１に対し，同年５月３１日付け「要件定義」，「業務フロー」及び「今フェーズ 開発に関する業務範囲」をそれぞれ提出したこと，(4) Ｙ２は，同年７月ころ，Ｘに対し，別紙一覧表のうち「大分類」「中文類」「Ｐｈ１」「内容」欄が記載された本件一覧表を提出したことがそれぞれ認められ，これらの事実に照らせば，「Ｘ会殿向けレセコンシステムお見積仕様書」，「要件定義」，「業務フロー」，「今フェーズ 開発に関する業務範囲」及び本件一覧表は，それぞれ本件元請契約の業務範囲に係る合意内容を示すものと認められるから，別紙一覧表のうち「大分類」「中文類」「Ｐｈ１」「内容」欄記載の内容は，それぞれ本件元請契約に基づき，Ｙ１がＸに対して本件システムに備えるべき機能として提供する義務を負うものと解する
長くてわかりにくいところだが，開発対象となる機能を，見積書から出発して，各種ドキュメントの内容からリンクして確定していったといえる。
そして，実際にＹ２が納入してきたシステムについては，
平成２１年３月３日にＹ２から提供された本件システムは，
(1) 多くの項目について，仕様書記載の機能を実装しておらず（別紙一覧表の「検証判定」欄で「Ｄ」と表示したもの。合計４９項目），
(2) 実装されている機能についても，正しいデータが出力されない又は必要なデータが出力されないため全く実用できないものであり（別紙一覧表の「検証判定」欄で「Ｃ」と表示したもの。合計９項目），
(3) 実装され，正しい数値が出力される機能についても，現実の診療の流れを全く考慮していないため，歯科医院向けのレセプトコンピュータシステムの仕様を満たしていない（別紙一覧表の「検証判定」欄で「Ｂ」と表示したもの。合計１０項目）。かろうじて問題がないと考えられる２２項目（別紙一覧表の「検証判定」欄で「Ａ」と表示したもの）は，そのほとんどが「受付」という大項目に係る機能であるが，当該大項目中の「患者登録」の機能は，「エクセル」などの表計算ソフト程度の機能であり，当該大項目中の「予診表」の機能は，いわゆる「メモ帳」程度の機能であって，「ワード」などで代替できる程度の機能しか備えていない。
とのＸの主張を全面的に認めて，未完成であるとした。
その結果，既払い金4200万円の全額の返還は認めたが，Ｙ１が提案書に記載していた「Ｘが歯科医院に対してシステムを提供することによって得られる利益」約6500万円の賠償までは認めなかった。
若干のコメント
システムの完成をどのように判断するのか，というのは確定した基準はありません。しかし，主流だと思われる考え方は，システムには不具合がつきものだから，それは完成後の瑕疵の問題として処理すべきだという前提のもとで，東京地判平14.5.22（http://d.hatena.ne.jp/redips+law/20100110/1327130501）や，東京地判平22.1.22（http://d.hatena.ne.jp/redips+law/20111228/1327155107）のように，「予定されていた工程を終えているか否か」という基準だと思われます。
他方，すべての判例がそのような基準に従ったというわけではなく，本件のように，開発委託契約の目的・範囲を認定し，実際に納入されたシステムが，それを満たしているか，という「正攻法」的な考え方を示す事例もあります。東京地判平21.7.31（http://d.hatena.ne.jp/redips+law/20110419/1327152482）も，こちらのタイプだといえるでしょう。
私が過去に担当したシステム開発紛争でも，裁判官（この裁判官は，システム開発紛争を相当数取り扱っている方）は，「システムの完成」は規範的要件であるから，完成を主張する者は，評価根拠事実の主張・立証が必要だと述べていました。その事例で，完成の評価根拠事実となったのは，「相手方が，（文句をいいつつも）納入されたシステムを本番環境で使用していること」「各工程の終了基準を満たしていること」などでした。
システムの完成が争われることはしばしばありますが，完成を立証する側も，否定する側も，事実経緯，証拠関係に照らして，どのような主張を組み立てるのかが重要となるでしょう。
