意外とよくある分割納品
ソフトウェア開発を請負契約で行ったとき、「本来の意味では完成していないけれども、ある工程の区切りで検収し代金の支払いまで済ませてしまう」ことは、ときどきあります。本当に完成した物を引き渡すという請負契約の基本からは外れた行為ですが、たとえば発注者側の予算措置の都合（年度内の予算は年度内に消化したいというような場合）や受注者側の資金繰りの問題など原因は様々ですが、実際にはかなり多く行われているのではないかと思います。
ソフトウェア開発では「基本設計」「詳細設計」「開発・テスト」といった工程に分けて契約することがよく行われますが、この場合はソフトウェアの一部機能を作ったところで検収と支払いを受けるものです。
最初にソフトウェアの中心となる部分を作って納品し、あとで追加的な機能を付け加えていくというわけです。「最初からすべての機能を一本の契約で作ってしまうほうがシンプル」と言えばシンプルなのですが、このように分割をして、納品と検収・支払いを行うことは、たとえばベンダー側にしてみれば開発中の資金繰りが楽になるというメリットがあります。
またユーザー側にとっては、「最初の開発中に後続きで付け足そうと思っていた追加機能に変更がある場合に実行しやすい」というメリットもあるでしょう。そんなこともあり、実際にはこうした納品方式はかなり頻繁に行われています。
分割納品のリスク
しかし、こうした分割納品には当然のことながら、ユーザーにとってのリスクもともないます。
たとえば、最初の契約に基づくソフトウェアが完成し、支払いまで済んだけれども、追加作業の途中でプロジェクトが頓挫。結局、使えるシステムにはならなかったというような場合、ユーザーとしては契約の目的を達成しなかったのだから、最初の開発分も返金してほしいところです。しかしベンダー側は「検収・支払いまで済んでいるということは、あなた方も成果物の完成を認めたということでしょう」と、これに応じない場合があります。
当初納品されたソフトウェアが少しでも役に立つならともかく、そのままではまったく業務に使えないということならユーザーとしては大損です。今回は、そんな分割納品されたソフトウェアの問題を取り上げたいと思います。本件はユーザーとベンダーではなく、ソフトウェア開発の元請企業と下請企業間の争いですが、争点としてはおおむね、「ユーザーとベンダー間と同じ」と言って良いでしょう。
それでは、まず事件の概要から見ていただきたいと思います。
【東京地方裁判所 令和4年3月15日 判決】
ある元請企業が顧客から道路のトンネル工事に使用する姿勢計測システムの開発を受注し、そのうちソフトウェア開発部分を下請企業に発注した。契約は「ソフトウェアの基本的な部分の開発と追加部分の開発に分けること」とされ、元請企業からは、まず基本部分についての発注が行われた。数ヵ月後、下請企業は基本部分の開発を終え、元請企業による検収と支払いを受けた。
下請企業は続いて追加部分の開発をしたが、元請企業が当初開発分も含めて顧客に持ち込みテストを行ったところ不具合が多発して納品に至らなかった。さらにこの改修を行っている最中、下請企業の担当者が死亡して、結局プロジェクトは頓挫した。
このため、元請企業は下請企業へ既に支払った費用の返還を求めたが、下請企業は当該費用については既に検収を受けていることを理由に返還を拒み、裁判となった。
出典 Westlaw Japan 文書番号 2022WLJPCA03158015
