多数の不具合が指摘されたものの，いずれも瑕疵にはあたらないとされた事例。
事案の概要
XとYは，平成22年4月30日，以下の内容とする空調制御システム（本件システム）の開発契約（本件開発契約）を締結した。
開発期間 平成22年5月1日から9月30日
請負代金 合計1230万円
Yは，本件開発契約の納期である平成22年9月30日に，要件定義書，プログラムのソースファイル等をXに納品した。Xは，Yに1230万円を支払ったものの，不具合があるとして，仕事完成義務の不履行または瑕疵担保責任に基づく損害賠償として合計約2340万円の支払いを求めた。
ここで取り上げる争点
（１）本件システムの完成の有無
（２）瑕疵担保責任の有無
裁判所の判断
争点（１）の完成の判断基準については，判例で定着しつつある「最終工程基準」説*1をとることを明示した。
本件開発契約は請負契約であると解されるところ，民法６３２条から６３４条までの規定内容に照らせば，請負人の行った「仕事」の結果が不完全な場合のうち「仕事」の目的物に瑕疵がある場合と「仕事」が完成していない場合とは区別され，「仕事」の目的物に瑕疵が存在したとしても，それにより「仕事」が完成していないとはしない趣旨であると解される。このような法の趣旨に照らせば，請負人が「仕事」を完成させたか否かは，当該仕事につき当初の請負契約で予定されていた最後の工程までが終了しているか否かを基準として判断すべきである。
その上で，次のように述べて最終工程は終わっているとした。
上記を踏まえて検討するに，本件ソフトウェアの開発は，要件定義の作成，設計，製造，結合テスト，システムテストまでのYにおける工程及びXの顧客店舗における運用テスト（パイロット運転）を経ることとされ，その後に▲▲システムの本番稼働が行われる予定であったところ，Yは平成２２年４月３０日に本件要件定義書（初版）を納品したのを初めとして，同年８月３１日及び同年９月３０日に成果物を納品し，同日までに単体テスト，結合テスト及びシステムテストを行っており，同日納品された成果物に関し，XはXの社印を押した検収確認書を交付している。また，同月１４日及び同年１０月４日にはYの立会いの上でXの顧客店舗において運用テストが行われている。これらの事実によれば，Yは，本件開発契約において予定されていた本件ソフトウェアの開発工程の最後の工程まで終了していると認められる。そして，このことは，本件ソフトウェアの完成，納品後，YがY納品ソフトに存在した瑕疵あるいは▲▲システムに発生した不具合に対処したとの事実により左右されるものではない。
さらにXは，検収確認書は暫定的なものであると主張していたが，退けられた。
なるほど，Xは従前の検収報告書には日付を記載していたのにY納品ソフトに係る検収確認書には日付を記載していないが，このことのみからX主張の合意の存在を推認することは困難である。そして，本件開発契約においてはY納品ソフトが本件開発契約の内容に合致していない場合には，XはYに対し通知の上，返品し得るとされていたのに，Xはこのような対応をせず，むしろYに対し同年１０月２９日に本件開発契約に基づく開発代金の残額全額を支払った上，順次顧客店舗に設置・導入していったのであるから，XはY納品ソフトが完成していることを前提として行動していたというべきである。したがって，上記検収確認書に日付が記入されていないとの事実からY納品ソフトの完成を否定することはできない。
続いて，仕事が完成していることから，Xが主張する不具合について，瑕疵担保責任の有無を検討した（争点（２））。なお，Xが主張する不具合のうち，いくつかは本件訴訟手続の過程で主張したものであり，除斥期間が経過しているとして損害賠償請求できないとされている。
裁判所は，残る10個の不具合について，ひとつひとつ瑕疵担保責任の有無を検討した。その中からいくつかピックアップして紹介する。
本件不具合[1]が生じたこと，その原因がY納品ソフトの不備にあったこと及び同不具合はYが平成２３年１月頃対応したことにより解消したことは当事者間に争いがない。このように，Yの対応により本件不具合[1]が解消されていることからすれば，同不具合はY納品ソフトの瑕疵に該当するとまでは評価できない。
上記の判断は，遅滞なく修補されたものは瑕疵とは評価できないという従前の裁判例の判断に沿うものである。
本件不具合[3]の現象が生じたことは，当事者間に争いはない。
（略）新型計測ユニットは複数のコマンドを同時に実行できないものであり，同ユニットがルート更新のコマンドを受信してから更新が完了するまでに１５分以上要する場合があることから，Y担当者のＣは，平成２２年８月２８日，X代表者に対し，▲▲システムの制御スケジュールに関し，ルート更新の時間は通常４５分区間に１分半を確保するが，ルート更新にかかる時間は端末の構成により大きく変わるため，開局時にルート更新にかかる時間を実測して自動的にスケジュールを調整し，１分半を超える場合には自動的に各センサーの処理開始時間を後ろにずらして，ルート更新の時間を確保する設定とするとの変更案を連絡し，同変更について協議し，Xの異議なく開発が進められたことが認められる。
上記事実に照らせば，本件不具合[3]の現象は，本件ソフトウェアの性能に関するXとYの合意に沿うものと認められるから，同不具合はY納品ソフトの瑕疵に該当しない。
上記の判断は，もともとの合意どおりに作られたものであって瑕疵ではないというものである。
（本件不具合[4]について）
なお，Xは，▲▲システムが温度や湿度を計測し，その計測データに基づいて空調の制御を行うことを目的とするシステムであることからすれば，Yには異常な温度・湿度が計測された場合に対処するプログラムをY納品ソフトに組み込むべき義務があったと主張する。しかしながら，Yが開発すべき本件ソフトウェアが有すべき機能は，本件要件定義書により定められ，これについてXとYとの協議で追加，修正を加えることによりYの開発すべき内容が定まるのであり，Xが主張するような▲▲システムの目的から当然に上記プログラムを組み込むべき義務が発生するとは認められない。そして，本件全証拠によっても，XがYに対し，温湿度センサーの誤作動により異常な数値が計測され得ることを告げたり，それに対する本件ソフトウェアでの対応について，XとYが打合せを行ったとも認められない。
したがって，本件不具合[4]の現象を防ぐためのプログラムを組み込むことが，Yの義務となっていたとは認められないから，同現象はY納品ソフトの瑕疵に該当しない。
ユーザが「当然組み込まれるべき」と主張していた機能については，そのような合意もないとして退けられた。
Xは，Y納品ソフトは，ＡＳＰサービスサーバーとの間で通信を行う際にパスワードを要求するプログラムを実装すべきであったのに，同プログラムを欠いており，これは同ソフトの瑕疵に該当すると主張する。
この点，証拠（甲３）によれば，ＡＳＰサービスサーバーにおいて，使用者のユーザーＩＤ・パスワード管理機能を強化することが本件開発契約の内容となっていたとは認められる。しかしながら，いかなる強化方法を用いるかについては，Xから提供される情報や意見を踏まえてXとYとの合意により定まると解されるところ，Xから本件ソフトウェアに上記プログラムを組み込むとの要求があったと認めるに足りる証拠はない。他に，本件開発契約において，X主張のプログラムの実装が合意内容となっていたと認めるに足りる証拠はない。
（略）
したがって，本件不具合[17]は，Y納品ソフトの瑕疵に該当しない。
その他の不具合についても，いずれもYの義務違反，瑕疵担保責任はないとして，Xの請求はすべて棄却された。
若干のコメント
本件は，システムの「完成」「瑕疵」を争うよくある類型です。完成の判断基準も，従前の裁判例に倣って「最終工程」が終えているかどうかを基準とし，納品物を受領して検収確認書が交付され，その後，運用テストも実施されていることなどから，判決文に表れた事実からは完成を争うことは困難であったといえるでしょう。
「瑕疵」の前提となる多くの不具合が指摘されており，その中には，機能要件のほか，セキュリティなどの非機能要件や，ソースコードが納品されていないといった履行義務違反の主張が含まれていました。裁判所はそれらについて，「遅滞なく修正したから瑕疵とは評価できない」「そのような機能を実装する合意はない」「損害が発生した証拠はない」などとしてすべて否定しました。
検収確認書などが交付され，代金も支払われ，実際にシステムが稼働に至ったという状況では，ユーザからそれを覆すことは容易ではなく，最低限，稼働に必要な機能，性能が実装されていることが確認できない限りは，検収，支払をすべきではないでしょう。
特に真新しい判断があったというわけではありませんが，完成や瑕疵が争われた際の一つの判断事例として参考になると思われます。
*1:「最終工程基準説」という名称は筆者が勝手にそう呼んでいるもの。なお，この完成の有無によって法的構成が変わるという考え方は，債権法の改正によって変更されるという考え方が有力である。
