検収と納品は同じですか？

同じではありません。納品は成果物を提出する行為、検収は発注側が対象と基準を照合して受け取る判断をする手続きです。提出されたことと、合意条件を満たしたことを分けて記録します。

検収と受入テストはどう違いますか？

受入テストは、システムが業務で意図したとおりに使えるかを確認する試験です。検収は、テスト結果や文書を含む成果物が契約・仕様に沿っているかを確認して受け取る手続きです。契約やプロジェクトによって関係は異なるため、事前に範囲を決めます。

差戻しが残っていても検収できますか？

一律には決められません。残課題の重要度、合意した合否基準、修正期限、支払条件を確認し、契約当事者が判断します。記事内の管理表は法的な判断を代替しません。

AIに検収の合否を決めさせてもよいですか？

仕様と結果の対応候補や不足証拠の抽出には使えますが、最終的な合否や検収通知をAIだけで確定しないようにします。根拠箇所を人が確認し、権限を持つ判断者が記録を残します。

検収とは？システム・業務委託の成果物を確認する手順とチェック項目

システムや業務委託の成果物が届いても、何をもって完了とするかが決まっていないと、担当者は承認できません。現場は使えるかを確認し、管理部門は契約どおりかを確認し、責任者は差戻しを含めて判断します。この三つの作業を一つの「検収」にまとめると、誰の確認を待っているのか分からなくなります。

検収より前に要件を決める体制は要件定義の進め方、開発方式の選び方はスクラッチ開発と既製品の比較、受託側で未検収の明細を管理する方法は受注残の管理方法で扱っています。この記事は、発注側が届いた成果物を確認し、次の処理へ渡す実務に絞ります。

検収とは、発注内容と成果物を照合して受け取る手続きです

検収では、納品された成果物が、契約、仕様、数量、品質などの合意内容を満たしているかを発注側が確認します。単にファイルが届いたことや、画面が開いたことだけでは完了になりません。対象、基準、確認結果、判断を結び付けます。

デジタル庁のデジタル・ガバメント推進標準ガイドライン解説書は、公的調達における検収を、定められた成果物について納品方法、要件、品質が満たされているかを確認して受け取ることと説明しています。また、受入テストはシステムが業務で意図した仕様で動作し、実運用で利用できる状態かを確認するものとして、検収と混同しないよう示しています。民間の個別契約へそのまま適用する規則ではありませんが、確認作業を分ける参考になります。出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」

成果物が届く前に、対象と合否条件を決めます

検収の準備は納品後ではなく、発注や要件定義の段階で始めます。納品後に基準を作ると、発注時にはなかった期待が混ざり、仕様との差なのか追加要望なのかを分けられません。

対象：システム本体、設定、データ、設計書、操作手順、試験結果など、受け取る成果物と版を列挙します。
基準：要件や仕様ごとに、何が起きれば合格かを確認可能な言葉で書きます。
方法：誰が、どの環境とデータで、どの手順を使って確認するかを決めます。
期間：確認開始日、質問期限、修正後の再確認日を置きます。
出口：合格、差戻し、判断保留を選ぶ条件と、決める人を指定します。

IPAの情報システム・モデル取引・契約書は、ユーザ企業とITベンダが各開発段階で担う責務を整理し、モデル契約書と解説を公開しています。2025年4月更新の資料でも検収基準の明確化が示されています。契約ひな型は個別案件へそのまま流用せず、成果物、役割、変更管理、検収条件を当事者と専門家で確認してください。出典：IPA「情報システム・モデル取引・契約書（第二版）」

要件IDから証拠と判断者までを一行でつなぎます

チェックリストは「ログインできる」「帳票が出る」のような項目だけでは足りません。どの合意に対する確認か、何が起きたか、誰が判定したかを同じ行でたどれるようにします。

検収記録に持つ項目
項目	記録する内容	目的
対象成果物	成果物名、版、提出日、対象範囲	何を確認したかを後から特定できます
合意した基準	要件ID、仕様、数量、品質条件	担当者の印象ではなく事前の約束と比べられます
確認方法	操作、照合、レビュー、確認環境	同じ条件で再確認できます
実測結果	期待結果に対して実際に起きたこと	合否の根拠を事実として残せます
証拠	画面、ログ、提出物、議事録の場所	確認者以外も結果をたどれます
判定と判断者	合格、差戻し、判断保留と責任者	確認作業と最終判断を分けられます
次回行動	修正内容、担当、期限、再確認日	差戻しを未処理のまま放置しません

システムであれば、通常入力だけでなく、権限がない利用者、必須項目の欠落、重複データ、連携先の停止なども確認します。業務委託の文書や分析なら、対象期間、元データ、集計条件、提出形式、修正範囲を照合します。成果物の種類が違っても、合意と実測結果をつなぐ考え方は共通です。

確認、相談、承認を分けて進めます

受領：対象成果物と版がそろっているかを確認し、受付日を残します。
実務確認：担当者が合意した方法で結果を記録し、証拠を添えます。
差異整理：期待と違う行を、不具合候補、合意未確認、追加要望に分けます。
相手との確認：事実と根拠を共有し、修正または追加協議の対象を決めます。
判断：権限を持つ人が合格、差戻し、保留を選び、日付と理由を残します。
受渡し：請求、支払、運用開始、資産管理など、次の担当へ状態と証拠を渡します。

操作した人が、そのまま契約上の合格を決める必要はありません。現場担当は実測結果を残し、責任者は契約と影響を見て判断します。分けることで、担当者の技術知識が足りないから検収できないという状態を避けられます。

不具合候補・合意未確認・追加要望を混ぜません

実際に使うと、発注時には気付かなかった要望が出ます。それをすべて不具合として差し戻すと、当初範囲の確認が終わりません。反対に、基準が曖昧だからと全部を追加費用へ回すと、合意した品質を確認できません。まず事実を三つに分けます。

差異の分け方
区分	状態	次の扱い
不具合候補	合意した仕様や期待結果と、実際の動作が一致しない	再現条件と証拠を付けて修正を依頼します
合意未確認	要件や基準の記録がなく、正しい状態を判定できない	決定者と期限を置き、合意後に再確認します
追加要望	当初の合意にはないが、利用して初めて必要だと分かった	検収の不合格理由へ混ぜず、変更要求として範囲・費用・期日を相談します

どの区分に当たるかで意見が分かれる場合は、一方だけで確定せず、参照した契約、仕様、議事録と未合意の論点を並べます。契約上の責任、報酬、支払期限に関する判断が必要なら、弁護士などの専門家へ確認してください。

AIは対応候補と不足証拠の抽出を補助します

要件や結果が多い場合、AIに要件IDとテスト結果の対応候補を出させたり、証拠リンクが空欄の行を抽出させたりできます。出力には元文書と該当箇所を付け、人が照合できるようにします。文章が似ているだけで同じ要件と確定しません。

AIに合格判定、検収通知、支払処理を直接任せません。入力資料が古い、表現が違う、一つの結果が複数要件に関係するといった場合に、誤った対応が生まれます。最初は更新案を作るだけにし、判断者が根拠と影響を確認してから状態を変えます。

試行では、対応漏れ、誤対応、不足証拠の検出、人の修正箇所、確認時間を記録します。この記事はSalesDockによる検収時間の削減率や判定精度を示すものではありません。匿名化または架空の確認表で、自社の条件を使って比較してください。

来週は、成果物一つを7項目で確認します

進行中の案件から成果物を一つ選びます。成果物名と版、合意基準、確認方法、実測結果、証拠、判断者、次回行動を一行にします。書けない欄があれば、担当者の確認不足と決めつけず、発注時の合意や責任分担が不足していないかを確かめます。

一つの成果物で流れを通すと、要件、現場確認、承認、請求・支払がどこで切れているかが見えます。既存のプロジェクト管理ツールを替える前に、同じ要件IDと成果物IDを次の工程へ渡せるかを確認します。