---
type: guideline
title: Step.6 検収
source: デジタル庁
ds_code: ds-120
category: government-system
updated: 2025-06-19
source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip
---

# Step.6 検収

検収は、調達仕様書で定められた納品物が正しく収められているかを確認し、成果物を外部事業者から受け取るという調達の最終盤の作業ですが、ただの儀式ではありません。ここでは検収の際に気をつけておくべきポイントをご紹介します。

## 検収の位置づけと内容を理解する

【標準ガイドライン関連箇所：第３編第６章第８節】

プロジェクトには、その成果物の妥当性や整合性を確認する作業が何種類もありますが、それぞれの作業で確認する観点が異なります。それぞれの確認作業が持つ意味を正しく理解して実施しなければ、成果物の不備や不測を適切なタイミングで発見することができず、トラブルの原因になります。ここでは、検収での確認に関連するポイントを見ていきます。

### 検収と受入れテストの違いを理解する

検収とは、調達手続の一つとして、調達受注者が納めた成果物が調達時に示した仕様（契約）どおりに納められたかを確認する行為です。

重要なのは、調達開始時の約束事を、受注者が果たしたかどうかという点です。検収の実施者は、発注者側の検収担当者である検査職員です。検査職員は、調達仕様書及び契約書に定められた内容と納品物との突合せを行い、仕様どおりに納品されているのかを確認します。そこには、テストに関するドキュメントも含まれますが、内容が充分かどうかは判断が付きません。

一方、受入れとは、ＰＪＭＯを中心として、納品された成果物が今後のサービス・業務の実現に足るかどうかを判断する行為です。この行為は、テストとしての一連の作業からなり、終端は職員が実施する受入れテストとなります。逆に言うと、受入れテストのみでは、その情報システムが受入れ可能かは判断が付きません。

また、プロジェクト開始時は、調達仕様書の内容に沿って作業が進められますが、様々な調整や追加変更を経て、情報システムは完成します。その際の経緯や、結果としてどうなったかは、契約変更を伴うものは検収でも発見できますが、通常のプロジェクト管理の変更管理の範囲での内容は、検査職員には認識されていません。

つまり、検収と受入れは異なるものです。検収は手続上の行為として必要であることは前提としつつ、実質の受入れに対して職員が充分に関与しないと、納品されたが機能しないだけでなくプロジェクトの目的の達成に寄与しない情報システムが出来上がることになりかねないのです。プロジェクトの目的の達成に寄与しない情報システムが出来上がった場合には、最悪、その情報システムを利用する職員が行う業務そのものに悪影響を与え、手戻りが発生するなどして手作業での修正を関係者に強いるおそれがあります。

### 残存する課題（軽微な瑕疵等）の対応を明確にする

スケジュールや優先順位等の関係から、検収の時点で優先度の低い軽微な不具合が残ってしまうことも少なくありません。多くの場合、瑕疵と認められる不具合は契約に基づいて外部事業者が修正することになりますが、契約期間の終了とともに外部事業者側の体制は縮小（又は解消）することが一般的であるため、不具合の改修時期が不明確になることもあります。

このため、検収時点で瑕疵である不具合がわかっている場合は、その不具合に対する改修計画を明確に提出するように求めましょう。各々の不具合に対して、「いつまでに」「誰が」責任を持って「どのように」対応するかを改修計画で明確にさせ、その改修計画が発注者側として受け入れることができるものかどうかを契約期間の終了前に確認し、合意形成をあらかじめ図ることが大切です。

デジタル・ガバメント推進標準ガイドライン

実践ガイドブック

（第３編第７章　設計・開発）

目次

[１ 設計・開発で職員が行うべき事を理解する [7](#設計開発で職員が行うべき事を理解する)](#設計開発で職員が行うべき事を理解する)

[A. 『要件の内容を伝える役割』 [7](#_Toc188970388)](#_Toc188970388)

[B. 『要件どおりに情報システムができたかを確認する役割』 [10](#要件どおりに情報システムができたかを確認する役割)](#要件どおりに情報システムができたかを確認する役割)

[C. 『プロジェクトの進捗状況を正しく把握し適切な調整を行う役割』 [10](#プロジェクトの進捗状況を正しく把握し適切な調整を行う役割)](#プロジェクトの進捗状況を正しく把握し適切な調整を行う役割)

[２ 設計・開発全体を通して理解すべき点とは [10](#設計開発全体を通して理解すべき点とは)](#設計開発全体を通して理解すべき点とは)

[A. 要件を理解した職員の継続的な関与がプロジェクトを安定させる [10](#要件を理解した職員の継続的な関与がプロジェクトを安定させる)](#要件を理解した職員の継続的な関与がプロジェクトを安定させる)

[B. 要求とコストと納期のバランスをとる [11](#要求とコストと納期のバランスをとる)](#要求とコストと納期のバランスをとる)

[C. 設計・開発の全体像と流れを理解する [11](#設計開発の全体像と流れを理解する)](#設計開発の全体像と流れを理解する)

[D. 通常シナリオだけでなく、緊急時の対応計画も準備する [18](#通常シナリオだけでなく緊急時の対応計画も準備する)](#通常シナリオだけでなく緊急時の対応計画も準備する)

[E. メンテナンス性を考慮した成果物の構成、内容を考える [19](#メンテナンス性を考慮した成果物の構成内容を考える)](#メンテナンス性を考慮した成果物の構成内容を考える)

[１ 設計・開発の管理の要点を理解する [21](#設計開発の管理の要点を理解する)](#設計開発の管理の要点を理解する)

[A. 定点観測こそ進捗・品質管理の要（かなめ） [21](#定点観測こそ進捗品質管理の要かなめ)](#定点観測こそ進捗品質管理の要かなめ)

[B. 判断に必要な情報を職員が理解できる説明として事業者に求める [22](#判断に必要な情報を職員が理解できる説明として事業者に求める)](#判断に必要な情報を職員が理解できる説明として事業者に求める)

[２ 設計・開発の実施計画を立てる [23](#設計開発の実施計画を立てる)](#設計開発の実施計画を立てる)

[A. 2種類のプロジェクト計画書の相違点を理解する [23](#種類のプロジェクト計画書の相違点を理解する)](#種類のプロジェクト計画書の相違点を理解する)

[B. 意思決定の手順を明確にする [24](#意思決定の手順を明確にする)](#意思決定の手順を明確にする)

[C. 当初計画からの変更は、必ず関係者で合意する [24](#当初計画からの変更は必ず関係者で合意する)](#当初計画からの変更は必ず関係者で合意する)

[D. 他の関係者との役割分担の境界線を定める [25](#他の関係者との役割分担の境界線を定める)](#他の関係者との役割分担の境界線を定める)

[E. ＷＢＳで作業計画を確認し進捗を把握する [25](#_Toc188970406)](#_Toc188970406)

[F. ＥＶＭを用いた進捗管理手法を理解する [26](#_Toc188970407)](#_Toc188970407)

[３ テストの計画を立てる [32](#テストの計画を立てる)](#テストの計画を立てる)

[A. Ｖ字モデルと発注者・委託先事業者の役割分担を把握する [32](#ｖ字モデルと発注者委託先事業者の役割分担を把握する)](#ｖ字モデルと発注者委託先事業者の役割分担を把握する)

[B. テストのレベルや種類を理解する [34](#テストのレベルや種類を理解する)](#テストのレベルや種類を理解する)

[C. 非機能要件のテスト工程を詳細に確認する [36](#非機能要件のテスト工程を詳細に確認する)](#非機能要件のテスト工程を詳細に確認する)

[D. リスクを踏まえてテストの方針を決める [36](#リスクを踏まえてテストの方針を決める)](#リスクを踏まえてテストの方針を決める)

[E. テストにおける役割分担と必要な環境を明確にする [37](#テストにおける役割分担と必要な環境を明確にする)](#テストにおける役割分担と必要な環境を明確にする)

[F. テストツールを有効活用する [38](#テストツールを有効活用する)](#テストツールを有効活用する)

[G. テスト計画を作成する [39](#テスト計画を作成する)](#テスト計画を作成する)

[H. テスト結果の確認方法を明記する [40](#テスト結果の確認方法を明記する)](#テスト結果の確認方法を明記する)

[I. 取得するテストエビデンスの対象を事前に合意する [40](#取得するテストエビデンスの対象を事前に合意する)](#取得するテストエビデンスの対象を事前に合意する)

[１ 設計内容を確認・調整する [42](#設計内容を確認調整する)](#設計内容を確認調整する)

[A. 基本設計の内容を確実にレビューする [42](#基本設計の内容を確実にレビューする)](#基本設計の内容を確実にレビューする)

[B. 他の情報システムとのデータ連携には細心の注意を払う [44](#他の情報システムとのデータ連携には細心の注意を払う)](#他の情報システムとのデータ連携には細心の注意を払う)

[２ 品質管理の考え方を理解する [45](#品質管理の考え方を理解する)](#品質管理の考え方を理解する)

[A. 見えない品質を見える状態にする [45](#見えない品質を見える状態にする)](#見えない品質を見える状態にする)

[３ 単体テスト・結合テストの品質を評価する [48](#単体テスト結合テストの品質を評価する)](#単体テスト結合テストの品質を評価する)

[A. 単体テストの留意点 [48](#単体テストの留意点)](#単体テストの留意点)

[B. 結合テストの留意点 [49](#結合テストの留意点)](#結合テストの留意点)

[４ 総合テストの品質を評価する [51](#総合テストの品質を評価する)](#総合テストの品質を評価する)

[A. 総合テストの留意点 [52](#総合テストの留意点)](#総合テストの留意点)

[B. 発見できた障害は最大限活用する [54](#発見できた障害は最大限活用する)](#発見できた障害は最大限活用する)

[５ 受入テストを実施する [54](#受入テストを実施する)](#受入テストを実施する)

[A. 受入テストと他のテストとの違いを理解する [54](#受入テストと他のテストとの違いを理解する)](#受入テストと他のテストとの違いを理解する)

[B. 受入テストのテスト計画書を作成する [56](#受入テストのテスト計画書を作成する)](#受入テストのテスト計画書を作成する)

[１ どのプロジェクトでも必ず移行を計画する [58](#どのプロジェクトでも必ず移行を計画する)](#どのプロジェクトでも必ず移行を計画する)

[A. 移行の種類を理解する [58](#移行の種類を理解する)](#移行の種類を理解する)

[B. リハーサルも考慮した移行計画書を立てる [59](#リハーサルも考慮した移行計画書を立てる)](#リハーサルも考慮した移行計画書を立てる)

[２ 次の運用・保守は開発と並行して検討する [60](#次の運用保守は開発と並行して検討する)](#次の運用保守は開発と並行して検討する)

[A. 指標値を運用作業で取得できるように検討する [60](#指標値を運用作業で取得できるように検討する)](#指標値を運用作業で取得できるように検討する)

[B. 運用・保守の計画を立てる [62](#運用保守の計画を立てる)](#運用保守の計画を立てる)

[３ 種類を理解し揃えるマニュアルを厳選する [63](#種類を理解し揃えるマニュアルを厳選する)](#種類を理解し揃えるマニュアルを厳選する)

[A. マニュアルの種類を理解する [63](#マニュアルの種類を理解する)](#マニュアルの種類を理解する)

[１ 本番移行と本番稼働の開始を承認する [66](#本番移行と本番稼働の開始を承認する)](#本番移行と本番稼働の開始を承認する)

[A. 移行判定と稼働判定の違いを理解する [66](#移行判定と稼働判定の違いを理解する)](#移行判定と稼働判定の違いを理解する)

[２ 正しく引継ぎを行い、トラブルを減らす [68](#正しく引継ぎを行いトラブルを減らす)](#正しく引継ぎを行いトラブルを減らす)

事例・参考の一覧