検収とは？意味・流れとシステム開発における検収のポイント

検収とは、納品された物品・役務・成果物が、契約書や発注書、要件定義書などで合意した条件を満たしているかを確認し、受け入れるかを判断する手続きです。納品を受けた時点で自動的に完了するものではなく、確認対象、承認者、完了条件をあらかじめそろえることが、差戻しや支払い処理の行き違いを防ぎます。

特にシステム開発では、画面が表示されるかだけでは受入判断を行えません。受入テストの結果、要件、品質、成果物、未解決事項を照合する必要があります。契約・要件・証跡に照らして、受け入れてよいかを判断する進め方を、一般的な検収の流れから順に解説します。

検収は納品や受領そのものではなく、確認結果をもとに受け入れるかを判断する工程です。システム開発では、要件・受入テスト・成果物の証跡を結び付けて確認します。

01Section検収とは？納品・受領・検品・検査との違い

検収は、納品物や提供された役務が、契約・発注条件・仕様を満たすかを確認したうえで行う受入判断です。物品、役務、ソフトウェアでは確認内容が異なり、用語の定義や承認方法も契約書、発注書、社内規程で変わります。そのため、以下は業種横断で使える実務上の整理として捉え、自社の文書上の定義を優先してください。

検収の目的は、主に次の3つです。

• 発注した内容と、納品物・役務・成果物の一致を確認する
• 差異や不具合を記録し、修正・再確認の要否を判断する
• 請求照合や支払いへ進めるための受入承認を残す

受領と検査を同一視しない考え方は、公正取引委員会の取適法に関する資料でも確認できます。取適法の適用可能性がある取引では、受領日が支払いに関する確認の起点になり得るため、社内の検収完了日だけで日付を処理しないことが重要です。

02Section検収の一般的な流れと検収日

一般的な検収は、発注条件の確認から始まり、納品・受領、検査、差異対応、検収承認、請求照合、支払いへ進みます。差異が見つかった場合は、修正内容と再確認の条件を残してから次の工程へ進めます。

検収日は「確認と承認が完了した日」として扱う

検収日は、実務では定められた確認を終え、受入承認した日として扱います。ただし、実際にどの日を検収日とするか、承認者が誰か、書面が必要かは契約と社内規程によります。納品日や受領日を便宜上そのまま検収日にするのではなく、確認完了の事実と記録が対応しているかを確認しましょう。

検収結果を示す書類の役割や基本的な扱いは、検収書に関する解説で確認できます。電子メール、EDI、ワークフローなどで注文書、契約書、納品通知、請求書、承認記録をやり取りする場合は、国税庁の電子取引データ保存要件と自社の経理規程に照らして保存方法を確認してください。

03Sectionシステム開発における検収：受入基準と時系列フロー

システム開発の検収では、受入テストの結果だけでなく、合意した要件や成果物、未解決事項の記録を照合して受入可否を判断します。

システム開発の検収は、完成した画面を確認するだけの工程ではありません。契約書、個別発注書、要件定義書、仕様書、受入基準書、変更管理記録などを基準に、成果物が合意した範囲を満たすかを判断する工程です。文書間で優先関係が定められている場合は、その定めに従います。

デジタル庁の資料は、受入テストの結果を要件・品質・成果物の確認につなげて検収する考え方を示しています。民間案件では契約条件そのものとして扱うのではなく、受入基準、証跡、承認を結び付ける参考例として、デジタル・ガバメント推進標準ガイドライン解説書を参照できます。

受入テストと検収は役割が異なる

受入テストは、利用者側が業務シナリオや合否基準に沿って、システムを利用可能な状態か確認する活動です。一方、検収は受入テスト結果、課題票、納品物、品質資料などの証跡を契約・要件・受入基準に照らし、受入を承認する判断です。受入テストを実施しただけでは検収完了とはいえず、結果に基づく承認工程が必要です。

テストケースの作成や実施方法を深掘りしたい場合は、受入テストの進め方を参照してください。

受入基準に含める確認領域

検収対象は、合意済みの契約範囲に合わせて具体化します。見積書だけ、テスト結果だけで判定せず、基準文書と証跡を対応付けることが大切です。

仕様、プロジェクト管理、検収方法について当事者間の共通理解をつくる際は、IPAの情報システム・モデル取引・契約書（第二版）も参照先になります。ただし、モデル資料をそのまま個別契約の条件や法的効果として扱うのではなく、利用する契約書と照合してください。

納品通知から請求照合までの時系列フロー

04Section不具合がある場合の検収可否

問題が見つかった場合は、要件との差異か、受入基準を満たすか、留保条件を記録できるかを切り分けて、次の対応を判断します。

不具合や未解決事項があるからといって、常に同じ結論になるわけではありません。まず、合意済み要件との不適合なのか、利用開始を妨げない留保事項なのか、契約範囲外の追加要望なのかを切り分けます。重大度の基準は、業務停止、データの正確性、セキュリティ、法令対応、重要な連携への影響を踏まえ、案件ごとの受入基準と承認権限で定めます。

留保事項は、口頭合意で終わらせない

留保事項を残して検収を判断する場合、修正義務や費用負担を一律に決めることはできません。少なくとも、検収前に次の項目を記録し、契約上の扱いと承認者を明らかにします。

業務停止や重要データ、セキュリティ、法令対応に関わる問題は、通常の課題管理だけで進めず、あらかじめ決めた最終承認者へエスカレーションしてください。

05Section検収期間・みなし検収・支払いをどう確認するか

検収期間はテストや修正、承認に必要な工程から逆算します。みなし検収・みなし承認に関する定めがある場合は、通知条件まで契約内容を確認します。

検収期間に一律の適正日数はありません。対象機能、移行や連携の有無、テスト環境とデータの準備、確認担当者の稼働、修正と再テスト、承認経路によって必要な期間は変わります。先に示したシステム開発の検収フローを基準に、実行可能な日程を逆算します。

みなし検収・みなし承認の条項は、通知条件まで確認する

みなし検収やみなし承認に関する定めがある場合、条項の有無だけでは十分ではありません。少なくとも、起算日、異議通知の期限・方法・宛先、対象となる納品範囲、一部納品の扱い、修正後の再確認と留保事項の関係を個別契約で確認します。異議通知が必要な場合に備え、通知条件と根拠となる記録を検収計画に組み込みます。

取適法の対象となる情報成果物作成委託では、検査の有無にかかわらず受領後60日以内に定めた支払期日までの支払いが確認事項となる場合があります。また、一定水準を満たすことを確認した時点を受領とする事前合意の考え方も示されています。適用対象や受領日の認定は、当事者、委託内容、事前合意、納期、実際の受領状況で変わるため、公正取引委員会の取適法Q&Aと個別取引条件を確認してください。契約締結時、受領時、支払い処理時には、現行の公式情報を確認しましょう。

06Section検収後の不具合と契約不適合への対応

検収後に問題が見つかった場合でも、すべてを「無償修正」または「追加開発」と決めることはできません。まず原因と契約範囲を切り分け、記録と契約書に照らして次の対応を決めます。

最初の切り分けは、4つです。合意済みの契約・要件との差異が疑われる場合は契約書、要件定義書、仕様書、受入テストの証跡を確認します。検収時に留保した事項であれば、留保事項一覧にある責任者、期限、再確認条件を確認します。契約範囲外の追加要望であれば、当初要件、見積、変更履歴を確認し、追加発注や変更契約の要否を協議します。利用環境や外部サービスの変更が原因と考えられる場合は、ログ、接続先仕様、運用変更の履歴を確認します。

民法上の契約不適合に関する規定は、e-Gov法令検索の民法で確認できます。ただし、システム開発では請負、準委任、SaaS・ライセンス、保守運用などの契約類型や個別条項で扱いが異なり得ます。IPAも、契約不適合、救済方法、権利行使の期間制限を契約上の論点として整理しています。必要に応じて、IPAの見直しのポイントを参照しつつ、個別の契約内容と事実関係を確認しましょう。

契約締結前や問題発生時に確認すべき観点は、システム開発契約のチェックポイントで整理できます。追加要望が生じた場合は、当初範囲との差分を明確にしてから、見積もりの確認ポイントも参考にしてください。

07Section発注者が検収前に準備することと役割分担

検収を形だけの承認にしないためには、発注者側で基準、担当、環境、記録、期限を検収開始前にそろえる必要があります。開発側は資料提出、説明、修正、再テストを支援しますが、最終的な受入判断は発注者側が担う体制にします。

開発側には、合意済みの範囲で、納品対象一覧、テスト結果、品質保証資料、操作・運用・移行資料、既知不具合一覧、修正計画の提出と説明を依頼します。資料の提出だけでなく、発注者側の確認担当が質問できる場と、指摘の回答期限を設けると、検収後の認識違いを減らせます。

社内だけで判断が難しい場合は、受入基準の作成、テスト計画、品質レビュー、移行・連携・セキュリティの確認など、不足している役割に限定して外部支援を検討します。このときは、依頼範囲、対象規模、期待する成果物、既存の開発側との責任分界、発注者側の最終承認者を先に文書化してください。支援費用は、対象範囲や連携・移行・セキュリティ確認の有無で変わるため、同じ条件をそろえた個別見積もりで確認するのが現実的です。

検収は、納品を受け取るための事務処理ではなく、合意した条件を満たしているかを確認する受入判断です。一般取引では日付と記録を分け、システム開発では受入テストの結果を契約・要件・受入基準へ結び付けることで、承認後の認識違いを抑えられます。

Webアプリ・SaaS開発の相談先を比較する

受入基準の整理、テスト計画、品質確認、移行・連携の確認などで社内の体制が不足する場合は、必要な支援範囲と責任分界を整理したうえで、開発パートナーを比較できます。

Webアプリ・SaaS開発4593社掲載

Webアプリ・SaaS開発の相談先を探す