「検収・完成・“みなし検収”の交差点」——システム開発の支払と責任はいつ動くのか

こうした課題に対し、これまでの裁判例は、仕事の完成を判断するための基準、検収が持つ法的な意義、さらには契約書にしばしば盛り込まれる“みなし検収”条項の有効性とその限界について、具体的な指針を示してきました。本稿では、東京地裁平成24年2月29日判決や平成25年9月30日判決、そして比較的新しい令和4年6月22日判決などを重要な手がかりとしながら、軽微な不具合の存在が仕事の完成を妨げるのか、検収がなくとも支払義務が生じうるのはなぜか、そして紛争予防の鍵となる“みなし検収”条項をいかに設計し運用すべきか。これらの点について、モデル契約や実務ガイドの視点も交えながら、システム開発に携わるすべての関係者のために丁寧に解き明かしていきます。

検収と完成はイコールではない——「最終工程まで終えたか」でみる完成の本質

請負契約を基本とするシステム開発の実務では、ユーザーによる受入検査、すなわち検収への合格が、仕事の完成と見なされ、請負代金支払いのトリガーとなるのが一般的です。そのため、多くの開発現場では「検収完了＝完成」という等式が自明のことと認識されています。ところが、司法の場における判断基準は、この実務感覚とは少し異なる視座に立っています。裁判所は、仕事が完成したか否かを、検収という形式的な行為の有無だけで判断するのではなく、より実質的な内容に踏み込んで評価する傾向があるのです。

この点を明確に示したのが、東京地裁令和4年6月22日判決です。この事案で裁判所は、仕事の完成とは「当初の請負契約で予定された仕事の最終工程まで終え、目的物を引き渡したか」という基準で判断され得ると明言しました。たとえユーザーが検収完了の意思を明確に示していなくとも、ベンダーが契約で合意された作業範囲の最終段階までを完了し、その成果物をユーザーに提供していれば、法的には「仕事は完成した」と評価される可能性がある。この指摘は、ユーザーが検収を意図的に遅らせたり、不合理な理由で検収を拒んだりして支払いを不当に遅延させる行為に対する、強力な牽制となり得ます。

さらに注目すべきは、この令和4年の事案では、結果として検収の成立も併せて認定されている点です。その根拠となったのが、取引基本契約に定められていた「一定期間内に不合格通知がなければ検収完了とみなす」という趣旨の、いわゆる“みなし検収”条項でした。ユーザーが契約で定められた期限内に具体的な不合格通知を出していなかったという事実から、裁判所は契約条項に従い検収も成立したと判断しました。この判決は、仕事の完成という実質的な判断と、契約上の手続きである検収の成否という二つの側面からベンダーの権利を擁護する構造を示しており、システム開発契約における完成と検収の関係性を理解する上で、基本となる考え方を提供しています。

「軽微な不具合＝未完成」ではない——バグの存在と完成の分水嶺

システム開発の実務において、納品されたソフトウェアに一切の不具合、いわゆるバグが存在しないことは、現実的に極めて稀です。こうした状況で、ユーザー側から「バグが残っている以上、システムは未完成だ」として、検収の拒否や支払いの留保が主張されることがあります。この問いに答える上で、重要な指針となるのが、東京地裁平成24年2月29日判決です。

この判決は、ソフトウェアという成果物について、「その性質上、納入後にデバッグされることを予定せざるを得ない」という特性を深く理解し、ベンダーに指摘すれば遅滞なく補修することが可能な程度の「軽微なバグ」の存在を理由に、直ちに仕事が「未完成」であるとまではいえない、と判断しました。これは、開発の実務に即した非常に合理的な判断といえるでしょう。システムの根幹を揺るがすような致命的な欠陥ではなく、通常の運用に大きな支障をきたさない、あるいは容易に修正可能な不具合であれば、それは仕事の完成を否定する理由にはなりません。むしろ、納品後の契約不適合責任の範囲で対応すべき問題である、と整理しています。

加えて、この平成24年の判決は、完成性を判断する上での大前提となる「合意された仕様の特定」がいかに重要であるかを再確認させてくれます。この事案で、ユーザー側は「換金機能」が実装されていないことを未完成の理由として抽象的に主張しました。しかし裁判所は、その機能が契約書や仕様関連の書面に具体的に記載されていない限り、当初の合意仕様に含まれていたとは認められない、と退けました。これは、プロジェクトの途中で交わされた口頭での要望や曖昧な期待だけでは、法的な意味での契約内容とはならず、完成度を測る物差しにはならないことを示しています。後の紛争を避けるためには、プロジェクト開始時に、何をもって完成とするかの基準となる仕様を、書面によって明確に合意しておくことが絶対的な要件であることが、この判例からうかがえます。

検収手続きと“みなし検収”条項による完成の裏付け

仕事の完成を法的に主張する上で、客観的な証拠はきわめて重要です。その最も強力な証拠の一つが、ユーザーによって署名・捺印された「検収確認書」であるものの、ユーザーが検収を拒んだり遅延させたりするケースも少なくありません。そのような事態に備え、多くのシステム開発契約では“みなし検収”条項が活用されています。

この仕組みが有効に働いた事例として、東京地裁平成25年9月30日判決が挙げられます。この裁判で裁判所は、まず、個別契約で予定されていた設計、プログラム作成、テスト、成果文書作成、納品という一連の最終工程が完了していることを認定しました。その上で、プログラム一式についてはユーザーから検収確認書が交付されていた事実、そして成果文書については「納品後20営業日以内に検査結果の通知がなければ合格とみなす」という“みなし検収”条項が存在し、期間内にユーザーからの不合格通知がなかった事実を重視しました。

これらの事実関係を総合的に評価し、一部に未実装の機能が残っていたとしても、それは二次開発以降で対応する黙示の合意があったことや、システムが実際に稼働していた実績などを考慮し、仕事の完成を肯定したのです。この判決は、検収確認書という直接的な証拠と、“みなし検収”条項という契約上の仕組みが、いわば合わせ技となって仕事の完成を強固に裏付け、ベンダーの代金請求権を支えることを明確に示しています。

“みなし検収”条項の効力と限界——実務における設計ポイント

“みなし検収”条項とは、成果物を納入した後、契約で定められた検査期間内に、ユーザーが合理的な理由を付した不合格通知を発しない限り、「検収に合格したものとみなす」という効力を持たせる契約上の取り決めです。この条項は、ユーザーによる検収の長期化や意図的な不作為による支払遅延リスクをヘッジするため、実務上広く採用されています。もっとも、この条項が意図したとおりの効力を発揮するには、契約書における設計が肝要となります。具体的には、検査期間、不合格通知の方法、そして、そもそも何を基準に合否を判断するのかという受入基準を、契約上明確に定めておくことが強く推奨されます。

他方で、この条項の運用には注意すべき点もあります。例えば、一つのプロジェクトで複数の契約が重なり合う場合、条項間の整合性が問題となることがあります。ある判例解説によれば、ユーザーとの基本契約で「受入検査期間は60日」と定められている一方、下請けベンダーとの個別契約で“みなし合格”条項の期間が「30日」と設定されていたケースがありました。この場合、裁判所は両条項の趣旨を合理的に解釈し、実質的な検査期間である60日が経過するまでは、“みなし合格”の効果は生じないと判断しました。契約書に書かれた文言を機械的に適用するのではなく、契約全体の趣旨や当事者の合理的な意思を探求するという司法の姿勢がうかがえます。したがって、みなし検収条項を設計する際には、関連する他の契約条項との関係性を十分に考慮し、丁寧な文言の調整が求められます。

支払義務発生への二つの道筋と契約不適合責任との峻別

ここまでの裁判例を整理すると、ベンダーがユーザーに対して請負残代金の支払いを求めるにあたり、法的に主張するための道筋が大きく二つ存在することが見えてきます。一つは「完成ルート」です。これは、たとえ検収が未実施であっても、契約で定められた最終工程までを完了し、成果物をユーザーに引き渡したという実質的な事実をもって「仕事の完成」を立証し、報酬を請求する道筋です。もう一つは「みなし検収ルート」です。これは、契約書に定められた“みなし検収”条項に基づき、検査期間の経過をもって法的に「検収合格」という効果を発生させ、それを根拠に支払いを請求するアプローチです。

実務上、ベンダーとしては、どちらか一方のルートに固執するのではなく、両方の観点から自らの主張を裏付けられるよう、証拠を両建てで整えておくことが最も安全な戦略といえるでしょう。具体的には、最終工程が完了したことを示すプロジェクト管理票や報告書、成果物を引き渡したことを示す納品書や受領書といった「完成」を裏付ける証拠と、検査期間や通知の往復に関するメールの記録といった「みなし検収」の成立要件に関わる証拠の両方を、日頃から意識的に保全しておくことが不可欠です。

ここで明確に区別しておくべきなのは、「検収が完了すればベンダーの責任はすべて免除される」という誤解です。検収は、あくまで仕事の完成を確認し、支払義務を発生させるための重要な区切りです。検収の成立が、その後に発見されたシステムの不具合に対する責任、すなわち契約不適合責任（2020年4月の民法改正前の「瑕疵担保責任」に相当）までを直ちに免責するものではありません。検収時点では発見できなかった隠れた不具合が後日判明し、それが合意した仕様に適合しないものであれば、ユーザーはベンダーに対して、システムの追完（修補）請求などを行うことができます。検収は支払いの画期、契約不適合責任は納品後の品質保証、というように、両者の役割を切り分けて理解することが肝要です。

紛争予防の処方箋——「条項・運用・証拠」の三位一体で未来のリスクを断つ

システム開発を巡る紛争の根源をたどると、その多くは「何をもって合格とするか」という受入基準の不明確さに根差しています。この根本的な問題を解決するためには、契約段階から運用、そして証拠保全に至るまで、一貫した対策を講じる必要があります。

契約条項のレベルでは、JEITA（電子情報技術産業協会）が公表している「ソフトウェア開発モデル契約」などを参考に、受入基準、検査の手順、合否の判定方法を具体的に記した「検査仕様書」を、双方で合意しておくことが紛争予防に極めて有効です。もし契約締結時点で詳細な基準を定めきれない場合でも、少なくとも、その基準を「誰が、いつまでに、どの会議体で協議し、決定するのか」というプロセスだけでも明確に合意しておくことで、後の「言った言わない」の争いを大幅に減らすことができます。

次に、運用のレベルでは、特にユーザー側の対応が重要となります。“みなし検収”条項が設定された契約下では、ユーザーの「沈黙」は、法的に「合格」と解釈されるリスクを常に内包します。ユーザーは、納品された成果物に問題を発見した場合、契約で定められた期限内に、具体的な不具合の内容とそれが不合格に相当する理由を付した通知を、定められた方法でベンダーに送付する運用を徹底しなければなりません。また、ユーザー側にも検査環境の準備といった信義則上の協力義務が課せられ、この協力を怠った場合、ベンダーに有利な判断が下される可能性が高まります。

そして最後に、これらすべての活動を支えるのが、証拠の保全です。納品・引渡しの事実、受入試験の記録、合否通知のやり取り、仕様変更に関する要望管理台帳とその承認プロセスなど、プロジェクトの各段階における合意と履行の過程を、電子メール、議事録、承認印のある書面といった客観的な形で一貫して残しておくこと。これが、万が一紛争に至った場合に自らの正当性を主張するための、まさに生命線となるのです。

検収を「儀式」にしないために

システム開発における検収は、プロジェクト完了を祝う単なる通過儀礼ではありません。それは、支払義務の発生、リスクの移転、そして責任の所在を画する、法的にきわめて重要な意味を持つ転換点なのです。そして、仕事の完成という概念は、検収の有無と常に同義ではなく、最終工程の完了と成果物の引渡しという実質によって判断されるということを、私たちは裁判例から学んできました。

ベンダーとユーザーが、無用な争いを避け、プロジェクトを成功裏に終わらせるために共有すべき行動原則は、突き詰めれば、次の三点に集約されるでしょう。それは、「合意仕様を特定すること」「受入基準を明確化すること」、そして「期限内に書面で合否を通知すること」です。この三点を、契約条項という静的なルールと、日々のプロジェクト運用という動的なプロセス、そしてそれらを裏付ける客観的な証拠によって固めることこそが、双方にとって、将来のリスクを回避するための最善の策となるのです。“みなし検収”条項は、プロジェクトの停滞を防ぐ強力な歯止めとして機能しますが、その設計や運用を誤れば、逆に紛争を深刻化させる両刃の剣にもなり得ます。裁判例が示す軌道は一貫しています。書面に刻まれた明確な合意と、期日通りに手続きを履践する誠実な姿勢こそが、完成、検収、そして支払というプロジェクトの最終局面を、滑らかに、そして確実につなぐ唯一の道なのです。