この記事でわかること
- システム開発における検収の意味と発注者の役割
- 機能・非機能・UI/UX・ドキュメントの4カテゴリ別チェックリスト（すぐ使えるテンプレート付き）
- 受け入れテストを5ステップで進める具体的な手順
- 合否判定基準の決め方と検収書の書き方
- 検収でよく起きるトラブルと対処法
「開発会社からシステムが納品されたが、どうやって確認すればいいかわからない」「検収でNGを出したいが、判断基準がない」――こうした悩みを持つ発注者は少なくありません。
検収（受け入れテスト）は、システム開発プロジェクトの最終関門です。ここをしっかり乗り越えられるかどうかで、その後の運用品質が大きく変わります。本記事では、発注者がすぐに使えるカテゴリ別チェックリストと検収書テンプレートを提供しながら、受け入れテストの進め方を体系的に解説します。
検収とは？発注者が知っておくべき基本
検収の定義と目的
検収（けんしゅう）とは、発注者が納品物を受け取り、契約通りに仕様が満たされているかを確認し、合否を判定するプロセスです。システム開発では「受け入れテスト（UAT：User Acceptance Testing）」とも呼ばれます。
検収の主な目的は以下の3点です。
- 仕様適合の確認：要件定義・設計書に記載された機能がすべて実装されているか
- 品質の保証：バグや不具合がない状態で本番運用に移行できるか
- 法的・契約上の区切り：検収完了をもって代金支払い義務が発生するケースが多い
検収と納品の違い
| 用語 | 意味 | 実施者 |
|---|---|---|
| 納品 | 開発会社がシステムを引き渡すこと | 開発会社 |
| 検収 | 発注者が納品物を確認・承認すること | 発注者 |
| 検収完了 | 発注者が合格を正式に通知すること | 発注者 |
納品＝検収完了ではありません。納品後に発注者が確認期間（通常2〜4週間）を設け、問題がなければ検収完了の通知を行います。
検収を発注者が主導すべき理由
検収は開発会社に任せきりにしてはいけません。理由は明確です。実際にシステムを使う現場のことを最もよく知っているのは発注者側だからです。開発会社がいくら単体テストや結合テストを行っても、実務での使い勝手や業務フローとの整合性は発注者しか判断できません。
また、検収の合否判定が曖昧なまま本番運用に移行すると、後から発生した不具合が「仕様か不具合か」の争いになりがちです。明確な検収基準と記録を残すことが、トラブル防止に直結します。
関連記事：検収の基準策定や納品トラブル防止の詳細は「システム開発の検収・納品ガイド｜検収基準の決め方とトラブル防止策」もあわせてご参照ください。
検収チェックリスト（カテゴリ別）
以下のチェックリストは、発注者が実際の受け入れテストで使用できるように設計されています。プロジェクトの規模や種類に応じて項目を追加・削除してお使いください。
カテゴリ1：機能テスト項目
システムが仕様書通りに動作するかを確認します。
| No. | 確認項目 | 確認方法 |
|---|---|---|
| 1-1 | 全画面が仕様書通りに表示される | 画面一覧と目視比較 |
| 1-2 | ナビゲーション・メニューのリンクが正しく動作する | 全リンクをクリック確認 |
| 1-3 | 画面遷移フローが仕様通りである | 業務フロー図と照合 |
| 1-4 | データ登録（新規作成）が正常に動作する | 実データを入力してテスト |
| 1-5 | データ参照（一覧・詳細）が正しく表示される | 登録済みデータで確認 |
| 1-6 | データ更新（編集）が正常に動作する | 既存データを変更してテスト |
| 1-7 | データ削除が正常に動作する（物理削除・論理削除） | テストデータで確認 |
| 1-8 | 検索・フィルタリング機能が正常に動作する | 各条件でテスト |
| 1-9 | ソート機能が正常に動作する | 昇順・降順で確認 |
| 1-10 | ページネーションが正常に動作する | 件数をまたいでテスト |
| 1-11 | ファイルアップロード・ダウンロードが正常に動作する | 各ファイル形式でテスト |
| 1-12 | メール送信機能が正常に動作する | テスト環境で送信確認 |
| 1-13 | 権限管理が正しく機能する（一般ユーザー・管理者など） | 各権限でログインして確認 |
| 1-14 | ログイン・ログアウトが正常に動作する | 正常・異常ケースで確認 |
| 1-15 | バリデーション（入力チェック）が仕様通りに動作する | 必須チェック・形式チェック等 |
| 1-16 | エラーメッセージが適切に表示される | 異常入力でテスト |
| 1-17 | CSVエクスポート・インポートが正常に動作する | 実データでテスト |
| 1-18 | 帳票・PDF出力が正常に動作する | 各帳票パターンで確認 |
| 1-19 | 外部システム連携が正常に動作する（API・データ連携） | 連携先と疎通確認 |
| 1-20 | バッチ処理・定期実行が正常に動作する | テスト実行で確認 |
カテゴリ2：非機能テスト項目
パフォーマンス・セキュリティ・可用性など、機能以外の品質を確認します。
| No. | 確認項目 | 基準値の例 |
|---|---|---|
| 2-1 | 一般画面の表示速度が許容範囲内である | 3秒以内 |
| 2-2 | データ量が増えても検索・一覧表示が遅くならない | 1万件で5秒以内 |
| 2-3 | 複数ユーザーの同時アクセスに耐えられる | 想定同時接続数で確認 |
| 2-4 | パスワードが適切に暗号化されている | ハッシュ化（bcrypt等） |
| 2-5 | SQLインジェクション対策がされている | 脆弱性診断レポートで確認 |
| 2-6 | XSS（クロスサイトスクリプティング）対策がされている | 同上 |
| 2-7 | CSRF対策がされている | トークンチェック確認 |
| 2-8 | 通信がHTTPS（SSL/TLS）で暗号化されている | 証明書確認 |
| 2-9 | 不正ログイン対策がされている（ブルートフォース対策等） | ロックアウト機能確認 |
| 2-10 | セッションタイムアウトが適切に設定されている | 30分以内 |
| 2-11 | データのバックアップが自動で取得される | 日次バックアップ確認 |
| 2-12 | バックアップからのリストアが正常に動作する | テストリストア実施 |
| 2-13 | エラーログが適切に記録される | ログファイル・監視ツール確認 |
| 2-14 | 障害発生時のアラート通知が設定されている | メール・Slack通知確認 |
| 2-15 | 本番環境のスペックが要件を満たしている | CPU・メモリ・ストレージ確認 |
カテゴリ3：UI/UXチェック項目
画面の使いやすさ・見た目・アクセシビリティを確認します。
| No. | 確認項目 | 確認方法 |
|---|---|---|
| 3-1 | PC・タブレット・スマートフォンで正常に表示される（レスポンシブ対応） | 各デバイスで目視確認 |
| 3-2 | 主要ブラウザで正常に動作する（Chrome・Safari・Edge・Firefox） | 各ブラウザで確認 |
| 3-3 | デザインカンプ（モックアップ）と実装画面が一致している | 並べて目視比較 |
| 3-4 | フォントサイズ・色・余白が統一されている | デザインガイドと照合 |
| 3-5 | ボタン・リンクのクリック領域が適切である | スマートフォンで操作確認 |
| 3-6 | ローディング中の表示（スピナー等）がある | 低速ネットワークでテスト |
| 3-7 | 操作完了後の通知（成功・エラーメッセージ）がわかりやすい | 各操作後に確認 |
| 3-8 | 削除・送信など取り消せない操作に確認ダイアログがある | 各操作で確認 |
| 3-9 | キーボードのみで主要操作ができる（アクセシビリティ） | Tabキーで動作確認 |
| 3-10 | 画像にaltテキストが設定されている | ソースコード・スクリーンリーダー確認 |
| 3-11 | 入力フォームのラベルが明確である | 目視確認 |
| 3-12 | エラー時に該当フィールドが視覚的にわかりやすい | バリデーションエラーで確認 |
カテゴリ4：ドキュメントチェック項目
システムの運用・保守に必要なドキュメントが揃っているかを確認します。
| No. | 確認項目 | 確認方法 |
|---|---|---|
| 4-1 | 要件定義書が最終版で提供されている | ファイル・バージョン確認 |
| 4-2 | 基本設計書・詳細設計書が提供されている | ファイル確認 |
| 4-3 | ER図（データベース設計書）が提供されている | ファイル確認 |
| 4-4 | インフラ構成図が提供されている | ファイル確認 |
| 4-5 | 操作マニュアル（ユーザー向け）が提供されている | 内容の網羅性を確認 |
| 4-6 | 管理者マニュアルが提供されている | 内容の網羅性を確認 |
| 4-7 | 環境構築手順書が提供されている | 手順通りに再現できるか確認 |
| 4-8 | テスト仕様書・テスト結果報告書が提供されている | ファイル確認 |
| 4-9 | ソースコードが納品されている（契約上必要な場合） | リポジトリアクセス確認 |
| 4-10 | ライセンス情報（利用しているOSS等）が明示されている | ドキュメント確認 |
受け入れテストの進め方（5ステップ）
チェックリストを持っていても、テストの進め方が体系化されていないと効率が落ちます。以下の5ステップで進めることをお勧めします。
ステップ1：検収計画の策定（納品2〜3週間前）
納品前に、検収の計画を立てます。計画に含めるべき内容は以下の通りです。
- 検収期間：開始日〜終了日（通常2〜4週間）
- 担当者：検収責任者・各カテゴリの担当者
- テスト環境：ステージング環境のURL・アクセス方法
- 合否判定基準：どのレベルのバグがあれば不合格か
- 不具合報告方法：課題管理ツール（Backlog・Jira等）の使い方
- 修正期限：不具合修正のデッドライン
注意：検収計画は開発会社と事前に合意しておくことが重要です。「いつまでに修正するか」「何回まで修正対応するか」を明確にしないと、後でトラブルになります。
ステップ2：テスト環境の確認（納品日）
納品時に、テスト環境が正常に利用できるかを確認します。
- ステージング環境にアクセスできるか
- テスト用のアカウント（権限別）が用意されているか
- テスト用のサンプルデータが準備されているか
- 開発会社からの説明・引き渡し資料を受領したか
ステップ3：チェックリストを使ったテスト実施（検収期間中）
カテゴリ別のチェックリストを使って体系的にテストを進めます。効率的に進めるためのポイントを紹介します。
- 業務フロー順にテスト：ランダムではなく、実際の業務の流れに沿ってテストする
- 正常系→異常系の順：まず正しい操作で動作確認し、次に意図的な誤操作でテスト
- スクリーンショットで証跡を残す：後で開発会社に報告する際の証拠になる
- 実務担当者を参加させる：実際に使う人が違和感を覚えるかどうかが重要
ステップ4：不具合報告と修正対応（検収期間中）
不具合を発見したら、速やかに開発会社へ報告します。報告する際は以下の情報を含めることで、修正速度が上がります。
- 発生画面：URL・画面名
- 再現手順：どの操作をするとどうなるか
- 期待する動作：本来どうなるべきか
- 実際の動作：実際にどうなったか
- スクリーンショット・動画：視覚的な証拠
- 優先度：業務への影響度（高・中・低）
ステップ5：最終確認と検収書の交付（検収完了）
すべての不具合が修正され、チェックリストの全項目が「合」となったら、検収完了の手続きを行います。
- 修正対応が完了したことを確認する
- 修正箇所の再テスト（デグレード確認）を実施する
- 検収書を作成・交付する
- 開発会社から検収書への署名・捺印を受ける
- 本番環境へのリリース承認を行う
参考：テスト工程全体（単体テスト・結合テスト・システムテスト）の詳細は「システム開発のテスト工程｜発注者が知るべき受入テストの進め方」をご覧ください。
合否判定基準の決め方
検収で最も重要なのが「何をもって合格とするか」の基準設定です。基準が曖昧だと、発注者と開発会社の間で認識のずれが生じます。
バグの重大度（シビアリティ）レベルの設定
| レベル | 定義 | 例 | 合否への影響 |
|---|---|---|---|
| Critical（致命的） | システムが使用不能になる | 画面が真っ白、データ消失 | 即不合格・修正必須 |
| High（重大） | 主要機能が使えない | ログインできない、注文が送信できない | 修正完了まで不合格 |
| Medium（中程度） | 機能は使えるが不便 | 表示崩れ、検索が遅い | 修正計画があれば条件付き合格も可 |
| Low（軽微） | 業務に影響しない些細な問題 | 誤字脱字、余白のズレ | 次期リリースでの修正で合格も可 |
判定基準の例
以下は一般的な合否判定基準の例です。プロジェクトの性質に応じて調整してください。
- 合格条件：Criticalバグ：0件、Highバグ：0件、Mediumバグ：修正計画書あり、Lowバグ：一覧化されている
- 不合格条件：Criticalバグが1件以上、またはHighバグが1件以上残存している
- 条件付き合格：Mediumバグが修正計画書付きで残存している場合（〇週間以内に修正することを確約）
重要：「条件付き合格」を採用する場合は、修正期限と未修正時のペナルティを契約書または覚書に明記してください。口頭での約束は後からトラブルになります。
検収書テンプレート（記載例付き）
以下は、システム開発の検収書テンプレートです。Word・Excel等でご利用いただけます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 検 収 書 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 発行日： 年 月 日 文書番号：QA-2026-001（例） 株式会社〇〇（開発会社名） 〇〇部 〇〇様 株式会社△△（発注者名） 〇〇部 〇〇（担当者名） 印 件名：〇〇システム開発業務 検収完了のご通知 【1. 検収対象】 納品物名 ：〇〇管理システム Ver.1.0 納品日 ： 年 月 日 検収期間 ： 年 月 日 〜 年 月 日 【2. 検収結果】 上記納品物について、以下の内容を検収した結果、 下記の通り判定いたします。 検収判定： ■ 合格 □ 条件付き合格 □ 不合格 【3. 検収内容】 ・機能テスト ：合格（実施件数：〇件 合格：〇件） ・非機能テスト ：合格（実施件数：〇件 合格：〇件） ・UI/UXテスト ：合格（実施件数：〇件 合格：〇件） ・ドキュメント ：確認済み 【4. 残存課題（条件付き合格の場合）】 課題No. 内容 重大度 修正期限 ＃001 〇〇の表示崩れ Low 〇月〇日まで （なし） 【5. 備考】 本検収書の発行をもって、貴社との契約に基づく 〇〇システム開発業務の検収が完了したことを通知いたします。 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
検収書作成のポイント
- 文書番号を付ける：後から参照できるよう管理番号を振る
- 発行日を明記：支払い条件に関わるため正確な日付が重要
- 残存課題を明記：条件付き合格の場合は修正期限も記載
- 双方の署名捺印：電子署名・電子捺印でも可
- 保管期間：契約書と同様に適切な期間（5〜7年）保管する
よくあるトラブルと対処法
トラブル1：「仕様か不具合か」の争い
状況：発注者が「この動きはおかしい」と指摘したところ、開発会社から「要件定義書にはそう書いてあります」と返答された。
対処法：
- 要件定義書・設計書を実際に参照し、記載内容を確認する
- 記載が曖昧な場合は、過去のメール・議事録・Slackのやり取りを確認する
- 発注者側に記載漏れがあった場合は「変更要件」として追加費用の交渉が必要になることも
- 今後のためにも、要件定義の段階で「具体的な動作」まで文書化することを徹底する
参考：要件定義の書き方については「要件定義のやり方｜システム開発を成功させる最初のステップ」をご覧ください。
トラブル2：検収期間中に次々と不具合が見つかり終わらない
状況：2週間の検収期間を設けたが、不具合が続出し、修正→再確認のループが終わらない。
対処法：
- 不具合をシビアリティ別に分類し、Criticalから優先的に対処する
- Low・Mediumの不具合については「次期リリース課題」として切り分ける
- 開発会社と「修正対応の打ち切り日」を明確に設定する
- 不具合数が想定を大幅に超える場合は、開発会社側のQA（品質保証）工程の問題として議論する
トラブル3：開発会社が「検収完了」を一方的に宣言する
状況：開発会社から「テストは完了しています。検収書を発行してください」と言われたが、まだ確認できていない部分がある。
対処法：
- 検収の合否判定権は発注者にあることを明確に伝える
- 契約書の検収条項を再確認し、検収手続きの定義を確認する
- 未確認の部分については「追加確認期間」を設けるよう交渉する
- 今後のために、契約時点で検収手続きの詳細を明文化しておく
トラブル4：本番リリース後に重大な不具合が発覚する
状況：検収では問題がなかったが、本番データを使い始めたら重大なエラーが頻発した。
対処法：
- ステージング環境と本番環境の差異（データ量・設定等）を確認する
- 不具合が検収時に発見できなかった原因を分析する（テストデータ不足・テスト項目不足等）
- 契約書の瑕疵担保条項（通常1年）に基づいて修正対応を要求する
- 修正対応が迅速に行われるよう、エスカレーションルートを確認する
「納品後に不具合が続出して困っています」というご相談をいただくことがよくあります。実は多くの場合、検収フェーズで体系的なチェックリストを使わずに「なんとなく確認」してしまったことが原因です。本記事のテンプレートを印刷して、1項目ずつチェックしながら進めるだけで、見落としは格段に減ります。ぜひ次の検収に活用してください。（FUNBREW 開発担当）
まとめ
システム開発の検収は、プロジェクトの品質を守る最後の砦です。本記事で紹介したチェックリストと検収書テンプレートを活用することで、抜け漏れのない受け入れテストが実施できます。
検収を成功させる3つのポイントをまとめます。
- 事前準備が9割：検収計画・合否判定基準・チェックリストを納品前に準備する
- 記録を残す：テスト結果・不具合報告・修正確認をすべて文書化する
- 開発会社と合意を取る：判定基準・修正期限・手続きを双方で事前確認する
FUNBREWでは、要件定義から検収・納品まで、発注者に寄り添った開発体制を整えています。「検収をどう進めればいいかわからない」「品質基準の決め方を相談したい」という方はぜひお気軽にご相談ください。
なお、検収期間の目安や期間の設定・延長対応については、システム開発の検収期間の目安もあわせてご覧ください。
この記事をシェア