開発が完了したというためにはシステムが支障なく動作し，十分な性能を有するものである必要があるとしつつ，ドキュメント等が不十分でそれが認定できないとした事例。
事案の概要
Xは，Yから商品先物取引受託業務に使用するシステムの開発を請け負って，開発したにもかかわらず，代金を払わないとして，未払請負代金（約1090万円）と，データセンタ利用料（約530万円）の支払いを求めたのに対し（本訴），
Yは，Xが期限までにシステムを完成させなかったとして，既払代金相当額を含む損害の賠償として約9400万円の支払いを求めた（反訴）。
XY間では複数の契約（覚書含む）が取り交わされたが，これらをまとめて本件システム開発契約とする。
ここで取り上げる争点
（１）Xが請け負った業務の内容と納期
（２）Yは仕事を完成させたか
裁判所の判断
争点（１）業務の内容
システム開発紛争では，システムが完成したか否かが争われることが多いところ，その前提論点として，そもそも「何を作るのか」というところの画定から争われる。本件でも，その点が争点となっていた。ベンダXは，当初の提案書等から，ASPパッケージ部分の開発に限られると主張していたが，ユーザYは，ミドルオフィスを含む新基幹システム全体が対象であると主張していた。
細かいやり取りが認定されているが，注目すべきは，契約書面には，開発対象としてはASPパッケージシステム等としか記載されていなかったが，「本件契約書等の契約書面の記載が，本件システム開発契約において新基幹システムを構築することが合意されていたとの判断を覆すものと解することはできない。」と述べた。要は，契約書の記載よりも，実務上のやり取りを優先して開発対象を認定したことになる。
結局，次のように述べて，開発対象は，既存のシステムの機能をベースに仕様を確定していくというプロセスを経ていると認定した。
X及びYは，平成２１年１２月の時点で，Yが利用している既存の基幹システム（Xの主張するミドルオフィスの内容を含む。）を，並行稼動の期間を経て，Xが提供する新しい基幹システムに切り替えるための検討を始め，Xは，平成２２年１月以降，その開発範囲や仕様を確定する作業を進めていたことが認められる。
そして，本件システム開発契約の対象は，「厳密にASPパッケージシステムの開発に限られるものではなく，本件ミドルシステム等システムを含む新基幹システムの構築を内容とするものであったと認めるのが相当である。」とした。
また，納期は，事実経緯から平成22年6月30日であったと認定した。
争点（２）仕事の完成
裁判所は，システムの完成について次のように述べた。
上記システムの開発が完了したといえるためには，これがY又はYの顧客が使用する端末機器等において支障なく動作し，Yが商品先物取引受託業務を行うに当たり十分な性能を有するものである必要があると解されるところ，Xは，画面のイメージ（甲１８から２５まで）を提出するにとどまり，プログラム本体はもとより，要件定義書，基本設計書，テスト結果報告書などを提出しておらず，Xが開発したというシステムがどのような性能を有しているものか判然としない。
要件定義書や基本設計書が作成されていない理由について，Ａは，ウォーターフォール方式ではなくアジャイルという開発手法をとったためである旨供述するが（X代表者），仮にそうだとしても，システムが完成したのであれば，少なくともそのテスト結果を記録した書面やY側の確認をとった旨記載された書面等は作成されるはずであり，Ｅ及びＡは，そのような書面が作成されていない合理的な理由について説明していない。
実際，Xが平成２２年５月末から同年６月頃提供したテスト品は，テスト発注や顧客情報の登録などを行うことができないものであり，Xは，同月２５日，Yから，動作テストの内容及び結果を明らかにするよう求めるメールの送付を受け，その後も再三にわたって要請をされたものの，テスト結果を書面で明らかにすることはしておらず，それどころか，前記１(3)コのとおり，同月２９日にはシステム開発の遅れを認めて謝罪する文書を送付している。
（略）
以上からすれば，Xが，本件システム開発契約において合意した期限までにＡＳＰパッケージシステムを含む新基幹システムを完成させ，又はXが主張する出来高に至るまで開発を完了したものと認めることはできない。
最終工程を終えているかという基準ではなく，「支障なく動作」「十分な性能」という抽象的な基準を挙げる一方で，具体的にその基準に当てはめたというわけではなく，それを立証するに足りる文書（仕様書やテスト結果報告書等）が作成されておらず，X代表者が謝罪しているといった間接事実から完成を否定した。
よって，システムの完成を前提とするXの本訴請求は棄却され，逆に，Yによるシステム開発地帯による債務不履行に基づく損害賠償請求は全額認められた（Xの過失相殺の主張も退けられた。）。
若干のコメント
本件は，ベンダから完成を理由に代金支払請求したところ，ユーザから損害賠償請求の反訴が提起され，しかもユーザの主張がすべて認められるという典型的な返り討ちパターンとなっています。
本文中にも記載しましたが，システム完成の判断基準として，多くの裁判例で用いられている「最終工程基準」ではなく，より漠然とした基準を用いているところが特徴的です。ただし，本件で認定された事実によれば，仮に，最終工程基準で判断しても完成が否定された可能性は相当程度あると思われます。いずれにせよ，本件の認定方法は，規範と当てはめの対応関係がわかりにくく，予測可能性を欠くということで，疑問がないわけではありません。
また，ウォーターフォールではないから文書を作成していないというベンダXの主張は，結果論としては，完成立証に不利だったといわざるを得ないところで，たとえアジャイル型の開発だったとしても，仕様に関する合意やテスト実施のエビデンスを残しておくということは重要だと思われます。
なお，本文中には記載しませんでしたが，納期を経過しても完成していなかったということについて，Xは，納期延長の合意があったと争っていました。この点については，XからYに同月29日に送付した文書（いわゆる謝罪文書）において，
「システムの開発に遅延が起こっていることを，まずお詫びいたします。」，
「弊社として，開発への負荷の見込みが甘すぎました。重ねてお詫びします。実際に開発する上で，予定以上に時間を要してしまったところがあります。弊社が御社に必要な仕様・データの請求が遅くなってしまった箇所があります。」
という書面が送られおり，X自身は，Yからとりあえず頭を下げてくれと言われたから書いたと述べていましたが，裁判所は次のように認定し，むしろXの責任を裏付けるものであるとしました。
確かに，開発の遅れを踏まえ，内部でもシステム切替え時期を延期する手続が必要だったと考えられることから，上記のようなやり取りがあった可能性はある。しかし，開発の遅れの主たる原因がYの追加発注にあったのであれば，請負代金の支払を受ける必要があったXとしては，少なくとも，一方的に自社に非があることを認めるような文書を作成することは考え難い。（略）上記謝罪文書は，開発の遅れについてXに責任があったことを裏付けるものといえる。
本件では，一見するとベンダから謝罪文書を出したことが重く見られたというように読み取れます。しかし，実際には，謝罪文書というのは決定的なものではなく，裁判所が総合的に見てユーザ有利の心証を抱いた場合には，それを裏付けるものとして援用しているため，重要視されるようにみえるに過ぎないと感じます。逆に，ベンダ有利の心証を抱いた場合は，「プロジェクトを進めるために立場の弱いベンダとしては便宜的に謝罪しただけであって」などといった言辞でもってユーザの主張を退けているケースも少なくありません。もっとも，これが単なる謝罪にとどまらず，詳細な客観的分析とともに不備の内容をまとめたものであるときは異なる判断になることもあるでしょう。この点については，拙コラム*1のほか，桃尾・松尾・難波法律事務所コラム*2に詳しい。
*1:BUSINESS LAWYERS「その顛末書、裁判で不利になるかも？」 https://business.bengo4.com/category3/article101
*2:「システム開発における「謝罪」の法的意義と実務対応」https://www.mmn-law.gr.jp/topics/2017/images/System%20development%20column%20No%201.pdf
