パッケージベースの開発において，カスタマイズの範囲が争われるとともに，検収手続が完了していないながらもシステムの完成が認められた事例。
事案の概要
ベンダXは，ユーザYとの間で，販売管理システム（本件システム）の開発を目的として，平成15年3月25日にシステム開発基本契約（本件基本契約）を締結した。そのサービス内容には，要件定義，設計，構築，運用準備・移行サービスが含まれていた。
XY間では，要件定義（279万3500円），設計（301万0200円），構築（1512万8400円），運用準備（306万7900円）の個別契約が締結された（その他の契約も締結されているが説明を割愛する。）。
Xは，本件システムを構築し，平成16年2月頃に本件システムの説明会を行ったが，Yから不具合が指摘された。XY間ではYの指摘に対応するための追加カスタマイズ契約（500万円）が締結された。しかし，その後，Xが作業を進め，Yに対して検収を求めたものの，本件システムの検収には至らなかった。
そこで，Xは，Yに対し，契約締結分の2526万0410円に加え，追加要望対応の費用，6663万3000円等を加えた9232万0300円の支払いを求めたのに対し，Yは，反訴請求として，Xの債務不履行があったとして，約4000万円の損害賠償を請求した。
原審（東京地判平26.10.30・平23ワ31512*1）は，ユーザの検収協力は不可欠であって，ユーザが検収を協力しない場合には，ベンダ側で必要な作業を終えていれば完成を認めてよいなどと述べて，本件システムの仕様を完成させていたものと推認できるとし，既契約締結分の2526万0410円について請求を認容し，Yからの反訴請求を棄却した。
ここで取り上げる争点
（１）カスタマイズ範囲
（２）本件システムの完成の有無及びYの債務不履行の有無
裁判所の判断
カスタマイズ範囲について
「完成」の判断の前提には，対象システムの「仕様」が問題となる。Yは，提案書において「現状の機能を網羅すること」などの記載があることを根拠に「要件定義が確定しなかった以上は，現行システムと同等の機能を備えたシステム」が仕様であるなどと主張していた。
パッケージベースでの導入では，どこまでカスタマイズするのかということが問題となる。ベンダは，当然，カスタマイズ機能一覧といった書面で書かれたものに限られると主張するであろうが，ユーザとしては，当該パッケージにはどのような機能が備わっているのかわからないため，そこに「カスタマイズ機能一覧」と合わせ見ても，それが必要十分なものかどうかわからないため，「現行維持」といった抽象的な要件を頼りにせざるを得ないところである。
この点について，裁判所は次のように述べた。少々長いが引用する。
本件においては、Xが、既存のパッケージソフトをカスタマイズして、システムの開発を行うこととされていたものである。既存のパッケージソフトを利用する方法は、フルスクラッチと比べて開発費用と工期を抑制するメリットがあるが、このような開発手法の下では、一般に、パッケージソフトには業務遂行に必要な基本的な機能が装備されているから、これを基本にしてシステムを構築するのが原則であり、それでも賄えないユーザーに特有な仕様についてはカスタマイズにより対応するものである。パッケージソフトにカスタマイズを加えることは、その分工数が増えることになるから、費用、開発期間等のメリットを生かすために、できるだけこれを少なくするほうが望ましい。仮に、ユーザーにおいて既に採用されているシステムと全く合致するような機能及び業務処理手続を、新たにシステムに導入しようとすれば、必要なカスタマイズ工数が膨大になるとともに、仮にこれを実現した場合であっても、将来的な環境や条件の変化に対応したメンテナンスが困難になるという問題が生じる。そのため、開発にあたっての一般的な考え方としては、基本的には、カスタマイズを最小限にし、むしろ業務をパッケージに合わせるようにすることが重要であるとされている。
（略）
以上のような、パッケージソフトを利用してカスタマイズを行う方法によりシステム開発をする際の問題状況からすれば、当事者の合意は、要件定義書等の成果物に記載のあるものについてはこれによって認めることとし、こうした成果物に記載のないものについては、特段の事情のない限り、パッケージソフトの仕様によっているものと考えるのが合理的であるといえる。
すなわち，「成果物に記載のないものについては，特段の事情のない限り」パッケージソフトの仕様どおりでよい，としている。さらに，裁判所は，次のように述べてYの主張を退けた。
Yは、本件システム開発を行うこととなった動機となる事情や、本件システム確認書や本件提案書に「現システムの業務内容を継承」、「現状の機能を網羅する」という記載があることを指摘して、現行システムと同等の機能を具備するものを開発する合意をしたとも主張するが、まず「現行システムと同等」とは、具体的にどのような水準・内容のものをいうのかが、そもそも明らかとならないし、上記指摘に係る事情についても、パッケージソフトの仕様によりながら、これに運用や業務方法の見直しも併用して、新しいシステムを活用して今後の業務を行っていくことも考えられるから、これらから、現行システムと同等の機能を具備するものを開発する合意が認められることにはならないというべきである。
本件システムの完成の有無及びYの債務不履行の有無
この点については，原審の判断が維持されているため，以下の点は原判決からの引用とする。
請負型のソフトウェア開発契約においては、原則として、構築したソフトウェアについてユーザーによる検収作業が行われ、検収が完了することにより、仕事が完成したというべきであるが、検収のためにはユーザーの協力が不可欠であり、ユーザーが検収に協力をしないために、検収を完了できない場合には、ベンダー側で検収前の作業を全て完了し、構築したソフトウェアが仕様確定作業により確定された仕様を満たす状態で、ユーザーにおいて検収できる状態にしていれば、請負の仕事の完成を認めるのが相当である。
また、ソフトウェア開発においては、初期段階で軽微なバグが発生するのは技術的に不可避であり、実務的にも納品後のバグ対応も織り込み済みであることに照らせば、バグが存在したとしても順次解消できる類のものであれば、瑕疵担保責任の問題として考えるべきであり、当該ソフトウェアの完成の認定を妨げるものではない。
そして，遅くとも平成19年2月のテスト稼働時点*2では，本件システムは完成させていたことが推認できるとされた。
これに対し，Yは，多数の不具合があると主張していたことから，これらが完成を妨げる特段の事情に該当するかどうかが検討された。Yが主張する不具合には，（ａ）本件システムに生じているバグと，（ｂ）本件システムが備えているべき現行システムの機能の欠如があった。
これらの詳細については判例DBでは省略されているが，（ａ）については，平成19年2月のテスト稼働時点以前に生じていたバグであるかどうか，（ｂ）については，現行システムが備えている機能かどうかではなく，確定仕様を具備しているかどうかという観点で判断し，いずれもYの主張は退けられた。
以上を踏まえて，
以上によれば、遅くとも、平成一九年二月のテスト稼働終了時には、本件システムは完成していたものということができる。そうとすると、前記のとおり、ソフトウェア開発においては、構築したソフトウェアの検収作業は、ユーザーとベンダーの協力作業となり、ユーザーにも検収に協力する義務があるというべきであるのに、Yは、平成一九年二月のテスト稼働時には本件システムが完成していたにもかかわらず、それまでの合意に反し、ロール発注残のデータ移行ができないことにクレームを述べて本稼働を行わず、その後も合理的な理由なく検収を拒み続けたものであるから、この点について、Yに債務不履行があったといえる。
と述べて，Yの債務不履行を認定した。
本件の請求根拠としては，システムの完成を理由とする報酬支払請求ではない。XY間の契約が合意解約されたことを前提に，それはYの債務不履行によるものだとして，履行利益（契約代金分）の請求を認めた。なお，控訴審では，一審認容額に若干の誤りがあったため，修正されている。
若干のコメント
パッケージソフトウェアの導入プロジェクトにおいて，ユーザがテストを行う段階になって「あれがない，これがない」と言われて揉めることは少なくありません。もちろん，ベンダとしては，事前にFit&Gap分析を行い，カスタマイズ対象を確定させたつもりであっても，こうした問題は起きています。ただし，本件では，一般論としてカスタマイズを最小限にするという考え方があることから，成果物に記載のないものが仕様に含まれるわけではないという結論を導いています。
また，本件で大きな争点となったのは，「検収協力義務」です。Yは，それまでの合意に反して「ロール発注残のデータ移行ができないことにクレームを述べ」るなどして，合理的な理由なく検収を拒絶したことが債務不履行にあたるとされました。
こうした事例から言えることは，ベンダとしては，カスタマイズ対象範囲を書面に落とし込んで承認を得ておくのは最低限のことであって，ユーザの見落としによるリスク，その場合の追加機能開発によるスケジュール・費用への影響までも説明しておくべきだといえます。ユーザとしても，カスタマイズ範囲を安易に承認するのではなく，現行業務あるいは現行システムとの網羅性を確認しながら承認プロセスを実施し，万が一漏れていた場合の取扱いや考え方についてもベンダに説明を求めることが必要でしょう。
本件は，結果的に契約締結済の報酬額が認容されたとはいえ，平成16年2月に最初のテスト稼働が行われ，その後も何度も修正とテスト稼働が行われ，平成22年になってようやく開発の中止に至っています。そして，平成23年には調停が申し立てられたものの不調に終わり，同年訴訟が提起され，平成27年6月に控訴審判決が出るまでは3年半程度を要しています。そう考えると，Xは，訴訟には勝ったものの，得られた金銭によって機会損失・費用が十分に補填されたとはいえず，双方にとってもう少し早い段階で何とかできなかっただろうかと思わされます。
なお，Xは，追加報酬についての請求もしていますが，
原判決も説示するとおり、Xは、新たに追加費用の見積を行っていないし、また、単にサービスであることを超えた有償の業務であり、追加費用が発生することを告知するなどした事情も認められない。Xが追加開発作業を行った当時は、Yとは本件システム開発に関する契約当事者であったのであり、追加要望分について行った実作業費用相当額について、真実Xに負担を求めないつもりであったか否かはともかくとしても、後に費用請求をするのなら、少なくとも何らかの事前告知が必要であったと解される。こうした事情が認められない以上、信義則に照らしても、Xの主張にかかる実作業費用相当額が損害であると認めることはできない
として否定されました。よって，相当長期に渡る本稼働に向けた折衝期間は無償の作業だったことになります。
