情報システムの完成基準（東京地判平14.4.22）
事案 石材の加工販売業者である被告は、旧システムの老朽化に対応するめ、外部コンサルの作成した概要提案書を基に、販売管理を始めとする全社システムの構築をＩＴベンダである原告に委託した。ところが、システムの開発作業の過程で、開発を要する機能及び工数が増加することが判明し、稼働の期限直前になっても、進捗は全体の４分の１程度にとどまっていた。そこで、稼働時期の見直しのうえ、一部納品された部分につき並行稼働によるテストが行われたが、機能を見直さないと通常業務で使用できないとの指摘が被告からなされる状態であった。その後、機能の見直しや再度の稼働延期を経て、再納品に対する検収の後、ようやく並行稼働、本稼働へと進んだ。しかし、被告は本稼働後も多数の不具合、特にシステムの処理速度の遅さが著しいとして、原告に補修を求めるなどしていたが、結局、システムの継続使用を断念した。これに対して、原告は残代金１億１千万円余の支払いを求めて提訴した。
原告の代金請求（その一部は増加した作業に対する追加・変更分）に対して、被告はシステムには実際の使用に耐えられない多くの瑕疵があるから完成していない、仮に完成しているとしても、原告が瑕疵を補修しないことを理由に契約を解除したのだから代金の支払義務はないとして争った（なお、被告は既払金につき反訴提起している）。
判旨 判決は、変更契約のうち一つを除いて、開発や交渉の経緯、書面の不存在を理由に、追加・変更の各契約の成立は認められないとした。そのうえで、システムの完成について、「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない」としてうえで、予定されていた〈１〉要件定義、概要設計から〈９〉データ移行までの各工程を終了し、順次納品を行い、「同９年１０月から、本件システムを本格稼働させ、同１０年１０月ころまで使用を継続していることが認められる。以上によれば、原告は、本件システムを完成させたと認めるのが相当」と判断した。
他方、このように一応完成したシステムには、「処理速度が被告の通常業務に耐えられないこと及び処理速度が遅いために通信費用が増加しているとの瑕疵」があり、原告がその修補を請求したのに被告はこれを行っておらず、また、これは契約の目的を達成することのできない瑕疵であり、その原因が被告にあるともいえないから、被告のした解除は有効であるとして、原告の代金請求は棄却した。
コメント 本件はシステム開発に係るＩＴ紛争の典型論点の多くを含んでおり、不具合（瑕疵）の扱いについても言及されていますが、システムの完成如何の点に絞ります。
判旨は、システム開発が請負契約であることを前提に、仕事の完成如何について、建築請負についてはほぼ確立した「最終工程基準」を適用しています。この基準は、不具合の存するシステムが出来上がってしまったときに、そもそも未完成であって代金支払義務が発生しないのか、それとも一応は完成であって瑕疵担保責任（解除や損害賠償）の問題が残るに過ぎないのかについて、「やっていない」ところが残っている場合には前者で、「全部やったが不十分」なところが残っているに過ぎない場合には後者に当たるとするもので、抽象的な基準としては明快ではあります。しかし、実際には、どこまで有用な基準たり得ているかは、疑問があります。
まず、何をもって「全部やった」かどうかを判断するかです。この基準が「最後の工程まで終えているか否か」とする意味は、もちろん、設計が抜けても製造が抜けてもテストが抜けてもどこかのドキュメントだけ抜けても未完成となる理屈ですが、特に最後のテスト工程は、どの程度やれば「全部やった」ことになるのか難しいところがあります。およそテストらしいことを何もやっていないことは稀でしょうが、申し訳程度に画面を叩いただけでは足りないことは明らかです。その中間で、テストが粗い場合にどう判断するかは、別の基準が必要でしょう。そして、テストの精粗の度合いは、システムの品質という実質論に直結します。建築の場合、配管や塗装の粗雑さは当該箇所の瑕疵として修補すれば足りるとしても、テストの粗雑さはシステムのどこにどのような問題を発生させるか分からず、形式論のみでは実態にそぐわない虞があるのです。
また、単体テスト、結合テスト、システムテスト、運用テストとあった場合に、最終工程としてどこまで行えば足りるのか、契約の範囲として明定されていれば良いですが、工程感のはっきりしない一括請負であると判断に迷います。完全な一括請負であれば全テスト完了までなのでしょうが、システムテストや運用テストが請負から外れていた場合、請負人の完成義務をシステムそのものに対するものと捉えるか、各工程毎に限られると捉えるかによって、結論は異なってきます。この関係で、請負範囲から要件定義が外れていたり、準委任となっていたりした場合も、一考を要します。この場合、請負の始まりである外部設計といわゆるＶ字モデルで対応するシステムテストまでとする見解がありますが、Ｖ字モデル上どの設計工程がどのテスト工程に対応するかは、一義的に決まっているものではありません。
そもそも、この最終工程基準は、「最終工程まで一応完了していれば完成で、そうでなければ未完成」と理解すべきでないようにも思われます。この基準の走りである東京高判昭36.12.20は、「工事が途中で廃せられ予定された最後の工程を終えない場合は工事の未完成に当るものでそれ自体は仕事の目的物のかしには該当せず、工事が予定された最後の工程まで一応終了し、ただそれが不完全なため補修を加えなければ完全なものとはならないという場合には仕事は完成したが仕事の目的物にかしがあるときに該当する」としており、逆に言えば「補修を加えれば完全なものになる」ことを前提としているとも読めます。仕事の完成が求められる請負における瑕疵は、本来的には債務不履行の一種ですから、修補によって仕事が完全化する可能性のない場合に完成を認めることは理論的に困難と思われます。その意味で、工程を欠いていれば未完成ということはできても、工程を踏んでいるから直ちに完成、とは言いにくい基準です。ここは実質的な基準で補充する必要がありそうです。
もう一つ、高裁判決で問題になっている未完成部分は、「（イ）一階四畳半の部屋の前の檜縁張替部分のラツカー塗装、（ロ）同じ部屋の欄間の硝子のはめ込み、（ハ）一階洋間（応接室）のマントルピースの上の飾板の塗装、（二）同じ洋間の螢光灯箱のすり硝子のはめ込み、（ホ）一階廊下の床板巾一尺一寸長さ一間半のラツカー塗装、（へ）二階廊下のラツカー塗装、（ト）階段のラツカー塗装等」というものであり、これは工程というよりアクティビティに近いものです。そうだとすると、工程論だけで完成が認められるのは、稀有のことになってしまいそうです。そもそも、建築の場合であれば、なすべき工程の全体像は（事後的であっても）明らかにできそうに思われますが、システム開発の場合は、事前に詳細なＷＢＳでも作られていたような場合を除いて、上記のレベルで明らかにするのは困難です。
なお、本件は検収後本稼働まで行った事案であるため、一応完成の認定もかなりあっさり行われており、上記のような点がどのように扱われているか、別途の基準が必要かどうかなど、特に参考になる判断はなされていません。検収と完成との関係も実務でしばしば見聞するところですが、これは別稿に譲ります。