納品・検収執筆:林部(株式会社リベライズ 代表)

検収の進め方と注意点|合格・不合格の判断基準

システム開発の検収の進め方と注意点を解説。受入テストとの関係、確認すべき項目、不合格のときにすぐ通知すべき理由、検収書を出すタイミングと支払いの関係を紹介します。

システム開発の検収は、納品されたものを確認して「受け取る」と意思表示する手続きです。検収をあいまいに済ませると、あとで不具合が見つかっても修正を求めにくくなったり、逆に支払いが遅れて開発会社との関係がこじれたりします。この記事では、検収の進め方と注意点を、受入テストとの関係、確認すべき項目、不合格のときの通知、検収書と支払いの関係の順に説明します。

検収とは:システム開発における目的と受入テストとの関係

検収とは、発注者が納品物を確認し、契約どおりであると認めて受け取ることです。検収が終わると、多くの契約では次のことが起こります。

  • 納品物の引き渡しが完了したものとして扱われる
  • 開発会社が残りの代金を請求できるようになる
  • 不具合への対応が「開発中の修正」から「契約不適合責任(納品物が契約内容に合わないときの責任)」に基づく対応に変わる

受入テストと検収は似ていますが、役割が違います。受入テストは「業務で使えるか」を確かめる作業で、検収はその結果をもとに「合格として受け取る」と決める手続きです。受入テストの進め方は受入テスト(UAT)の進め方で説明しています。

受入テスト検収
性格確認の作業受け取りの意思表示(手続き)
主な担当発注者(開発会社が支援)発注者
成果テスト結果、不具合の一覧検収書(合格の通知)
契約上の意味検収の判断材料引き渡し完了、代金の請求、責任の区切り

検収で確認すべき項目

検収では、動くかどうかだけでなく、納品物全体が契約どおりかを確認します。次の4つの観点で整理すると漏れが減ります。

観点確認すること
機能要件定義書・仕様書の機能がすべて実装され、受入テストに合格しているか
保守性ソースコード一式が納品されているか。第三者が読める状態か。必要な設定やアカウントが引き渡されているか
使いやすさ現場の担当者が業務で使えるか。操作で迷う箇所が許容範囲か
ドキュメント設計書、操作マニュアル、運用手順書、テストの結果報告書がそろっているか

見落としやすいのが保守性とドキュメントです。動いているシステムでも、設計書やソースコードがそろっていなければ、将来ほかの会社に改修を頼むことが難しくなります。何を納品物とするかは、契約の段階で一覧にしておくと検収で迷いません(ソースコードと著作権の考え方)。

合格の基準は、検収のときに考えるのでは遅すぎます。「どの不具合が残っていたら不合格か」を契約時か受入テストの前に決めておきましょう。たとえば「業務が止まる不具合は0件」「回避策のある不具合は期限を決めて修正」のように決めておくと、判断がぶれません。

不合格のときは遅滞なく通知する

検収で不合格と判断したら、すぐに開発会社へ通知します。理由は2つあります。

1つ目は、契約上の期限です。多くのシステム開発の契約書には、納品から一定の期間内に検査結果を通知すること、その期間内に通知がなければ合格とみなすことが書かれています。通知が遅れると、不具合が残っていても合格扱いになるおそれがあります。

2つ目は、法律上のルールです。会社どうしの売買では、買主は受け取った物を遅滞なく検査し、不適合を見つけたら直ちに売主に通知しなければならないと定められています(商法第526条)。システム開発のような請負の契約にこの条文がそのまま当てはまるかは見解が分かれますが、通知を急ぐべきことに変わりはありません。また、請負で納品物が契約内容に合わないとき、発注者がそれを知ってから1年以内に通知しないと、修正などを求められなくなるのが原則です(民法第637条)。

不合格の通知には、次の内容を書面(メールでも可)で残します。

  • 不合格と判断した項目と理由
  • 該当する受入テストの結果や不具合の一覧
  • 修正の期限と、再検収の予定日

「とりあえず使い始めて、問題があれば言う」という運用は避けてください。使い始めた事実が、受け取りを認めたと受け取られることがあります。

検収書を出すタイミングと支払いの関係

検収書(検収合格の通知)は、合格と判断した時点で速やかに出します。検収書は支払いの起点になることが多いため、出し遅れは開発会社の資金繰りに直結します。

支払いとの関係で押さえておきたいのは次の点です。

  • 請負の報酬は引き渡しと同時が原則: 請負契約の報酬は、契約で別に定めなければ、仕事の目的物の引き渡しと同時に支払うものとされています(民法第633条)。実務では「検収合格の翌月末払い」などと契約で定めるのが一般的です。
  • 取適法の60日ルール: 発注者と開発会社の資本金や従業員数が一定の条件に当てはまる取引では、2026年1月に施行された取適法(中小受託取引適正化法、旧下請法)により、検査をするかどうかにかかわらず、納品物を受け取った日から60日以内に支払期日を定める必要があります(公正取引委員会「委託事業者の義務」)。検収に時間がかかっても支払いを先延ばしにできるわけではありません。
  • 分割の支払い: 着手金と残金に分ける、工程ごとに検収して支払うなど、契約で支払いの区切りを決めることもあります。区切りごとに何を検収するかを決めておきましょう。

検収前に準備しておくこと

検収をスムーズに終えるには、納品の直前ではなく、契約の段階から準備を始めることが大切です。次の項目を確認しておきましょう。

準備すること決める時期
納品物の一覧(ソースコード、設計書、マニュアルなど)契約時
検査の期間(納品から何営業日以内に結果を通知するか)契約時
合格の基準(残してよい不具合の種類と件数)契約時〜受入テストの前
検収を判断する人と、社内の承認の流れ受入テストの前
支払いの時期と、検収書の様式契約時

社内の承認の流れは特に見落とされがちです。担当者は合格と判断していても、決裁者の承認に時間がかかり、契約の検査期間を過ぎてしまうことがあります。検査期間の中に社内承認の日数も含めて、日程を組んでください。

工程ごとに分けて検収する場合は、どの区切りで何を受け取るかも契約に書いておきます。設計書は設計工程の終わりに、ソースコードと操作マニュアルは最終の納品時に、というように決めておくと、最後にまとめて確認する負担を減らせます。

受託開発の現場から

受託開発の現場で実践されている検収と支払いの進め方から、発注者に役立つものを紹介します。

  • 細かく検収を引く: アジャイルで進める準委任契約(成果完成型)では、最後にまとめて検収するのではなく、区切りごとに細かく検収してもらう方針をとっています。一度に大量の確認が発生するのを避け、問題を早く見つけるためです。
  • 何をもって完了とするかを先に書く: 調査フェーズでは、効果試算書、施策一覧、ロードマップ、画面の設計図、調査報告書、確定見積といった成果物を提案書に列挙し、その納品をもって完了とすると明記しています。
  • 目的に合う範囲を担保したうえで検収する: 成果完成型の契約では、目的に適合した範囲の実現は工数にかかわらず開発会社が担保し、その実現範囲について検収してもらう形があります。
  • 支払いと不適合対応の条件を見積に書く: 支払いは着手時に半額、完成後に残額という形が多く、納品後12か月の契約不適合への対応と、外部サービスに起因する不具合は対象外であることを提案書に明記しています。

まとめ

  • 検収は、納品物を契約どおりと認めて受け取る手続きで、受入テストの結果をもとに判断します。
  • 機能だけでなく、保守性・使いやすさ・ドキュメントまで確認します。
  • 不合格のときは、契約の検査期間内に、理由と修正期限を書面で通知します。
  • 検収書は支払いの起点になるため、合格したら速やかに出します。

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

検収の基準や支払い条件は、発注前に決めておくほど後で揉めにくくなります。FastProposal の無料AI相談では、案件の内容を整理し、開発の範囲と費用の目安を数分で確認できます。契約の準備を始める前の整理にお使いください。