システム開発の検収・受け入れテストの進め方｜非エンジニアでもできる確認手順とチェックリスト
システム開発を外注して、ようやく「納品が完了しました。検収をお願いします」という連絡が開発会社から届いた。嬉しい反面、「検収って何をすればいいんだろう」と戸惑ってしまう方は少なくありません。
とりあえず画面を開いて「ログインできた」「主要なボタンが動いた」と確認し、検収書にサインを出す。そういったケースが実際に多くあります。しかし、この「とりあえず動いているからOK」という判断が、後になって大きなトラブルを招くことがあります。
「検収完了後に重要な業務フローが動かないと気づいた」「データが正しく保存されていなかった」「検収書を出した後は有償修正と言われた」——こうしたトラブルは、適切な受け入れテストを実施することで防げるものがほとんどです。
本記事では、非エンジニアの発注者担当者でも実施できる受け入れテストの進め方を、業務フローベースの具体的な手順とともに解説します。よくある不具合パターン、不具合発覚時の対応フロー、最後に使えるチェックリストも提供しますので、ぜひ検収前にお読みください。
目次
「とりあえず動いているからOK」が引き起こすリスク
よくある検収の失敗パターン3つ
検収を曖昧に済ませたことで後から発生する問題には、いくつかの典型的なパターンがあります。
パターン1：主要機能は動くが、業務フローが途中で止まる
ログイン・データ入力・一覧表示といった主要機能は問題ないものの、「月末の締め処理をしようとしたら特定の操作でエラーが出る」「複数人が同時に使おうとするとデータが正しく更新されない」といったケースです。個別の機能は動いていても、実際の業務フローで使ったときに初めて問題が顕在化します。
パターン2：テスト環境では動いたが本番データで壊れる
開発中に使用したテスト用データでは問題なく動作していたのに、本番運用で実際のデータを入力し始めると不具合が発生するケースです。「テストデータと本番データで桁数が違った」「特殊文字が含まれるとエラーになった」など、開発環境と本番環境の差異が原因になることもあります。
パターン3：検収後に「それは仕様外」と言われる
「こういう操作もできると思っていた」という認識があっても、検収書を出した後では「それは仕様書に記載されていません」という回答になりやすくなります。検収書の提出は「仕様書通りの成果物を受け入れた」という法的な意思表示であるため、それ以降の修正は有償になる可能性が高くなります。
曖昧な検収が引き起こすトラブルの実態
曖昧な検収の最大のリスクは、問題が発覚した時点で「誰の責任か」が曖昧になることです。
検収前の不具合であれば、開発会社の責任で修正するのが原則です。しかし検収書を出した後は状況が変わります。2020年の民法改正により「瑕疵担保責任」から「契約不適合責任」に変わり、発注者が不具合（契約不適合）を知った時点から1年以内に通知することが請求の要件となっています。
つまり、曖昧な検収で問題を見落とすほど、後から「これも検収前から存在していた不具合だ」と主張しにくくなります。適切な受け入れテストで問題をしっかり検収前に発見し、記録として残しておくことが、発注者としての権利を守ることにつながります。
検収と受け入れテストの違い・位置づけを理解する
開発テストの流れとUATの位置づけ
システム開発では、開発会社側で複数のテストを段階的に実施します。「単体テスト（個々の機能が動くか）」→「結合テスト（機能同士が連携して動くか）」→「システムテスト（システム全体が仕様通りに動くか）」という順番です。
これらは開発会社側のテストです。
最後に実施するのが「受け入れテスト（UAT：User Acceptance Testing）」で、これは発注者側のテストです。開発会社が技術的に正しく作ったとしても、「実際の業務で使えるかどうか」「要件定義で合意したとおりに動くかどうか」は、業務を知っている発注者側でしか確認できません。
検収と受け入れテストは何が違うのか
「受け入れテスト」と「検収」は混同されやすいですが、両者の関係を整理すると次のようになります。
- 受け入れテスト（UAT）：実際に操作して確認する作業プロセス全体
- 検収：受け入れテストを経て「問題なし」と判断し、成果物を正式に受け入れる行為
- 検収書：その意思表示を書面で証明する書類
受け入れテストが「確認作業」、検収が「判断・承認」、検収書が「証拠書類」という関係です。したがって、受け入れテストを十分に実施した後でなければ、検収書を発行してはいけません。
受け入れテストの準備（非エンジニアでも始められる）
確認観点リストの作り方（要件定義書を活用する）
受け入れテストで「何を確認するか」は、要件定義書から導き出します。要件定義書に記載された機能一覧・業務フロー・非機能要件（表示速度、同時接続数など）が、そのまま確認観点の元になります。
要件定義書の作成時点でテスト観点を意識しておくと、後の受け入れテスト準備がスムーズになります。要件定義書の書き方についてはシステム開発の要件定義を成功させる完全ガイド｜失敗しない進め方と注意点を徹底解説も参考にしてください。
確認観点リストは以下の形式で作ると整理しやすくなります。
機能名 |
確認内容 |
合格基準 |
確認方法 |
|---|---|---|---|
ログイン |
正しいIDとパスワードでログインできるか |
ログイン後にトップ画面が表示される |
実際に操作する |
受注登録 |
受注データを入力して保存できるか |
入力したデータが一覧に反映される |
実際に操作する |
PDF出力 |
受注データのPDF出力ができるか |
入力内容が正しくPDFに反映される |
PDFを印刷して目視確認 |
テスト担当者の選び方と役割分担
受け入れテストの担当者は、実際にそのシステムを使う業務担当者が最適です。「このシステムで毎日何をするか」を一番よく知っているのは現場の担当者だからです。
IT部門や管理職だけでテストを行うと、実際の使用シーンで起きる問題を見逃しやすくなります。例えば、経理担当者がいれば月末の締め処理、営業担当者がいれば商談登録〜請求書発行までの一連のフローを確認してもらうとよいでしょう。
ベンダーに事前確認すべき3つのこと
テスト開始前に開発会社へ確認しておくべき事項があります。
- テスト環境の提供: テストはどの環境（開発環境・ステージング環境）で行うのか。本番環境へのデプロイはいつ行われるのか
- テストデータの準備: テスト用のサンプルデータを用意してもらえるか。または発注者側で準備する必要があるか
- テスト期間と不具合対応のスケジュール: 検収期間は何日間か。不具合報告から修正・再確認までの想定スケジュールはどうなっているか
非エンジニアでもできる受け入れテストの進め方
ステップ1：業務フローを洗い出してテストシナリオを作る
受け入れテストで最も重要なのは、「機能」ではなく「業務フロー」を起点にすることです。
「ログインできるか」「データを保存できるか」という機能単位のテストだけでは不十分です。「新規の顧客から注文を受けて、受注登録→在庫確認→出荷指示→請求書発行まで一連の作業ができるか」という業務フロー単位でテストすることで、実際の運用に近い確認ができます。
まず、システムを使って行う主要な業務フローを3〜5つ書き出します。次に、各業務フローで「誰が・何をする」のかをステップごとに分解して、テストシナリオにします。
ステップ2：正常系から順番に確認する
テストは「正常系（正しい操作をした場合）」から始めます。
想定通りの操作を行い、想定通りの結果が返ってくるかを確認します。「正しいIDとパスワードでログインできるか」「必要な項目を全て入力してデータを保存するとどうなるか」など、基本的な動作を業務フローの順番に沿って確認します。
確認結果は必ず記録します。「OK / NG」だけでなく、「NGの場合は何が起きたか（エラーメッセージ、画面のスクリーンショット）」も残しておきましょう。
ステップ3：異常系・エッジケースを確認する
正常系の確認が完了したら、「異常系（想定外の操作をした場合）」を確認します。
- 必須項目を空白にしてデータを保存しようとしたらどうなるか
- 入力欄に非常に長いテキストや特殊文字を入れたらどうなるか
- 同じデータを二重に登録しようとしたらどうなるか
- 存在しないページのURLに直接アクセスしたらどうなるか
これらの操作でエラーが適切に表示されるか、データが壊れないかを確認します。
ステップ4：データの整合性を確認する
データが正しく「保存・表示・連携」されているかを確認します。
- 入力したデータが一覧画面や帳票に正しく反映されているか
- 一つのデータを変更したとき、関連する別の画面にも正しく反映されるか
- CSV出力やPDF出力を行ったとき、データが欠けたり文字化けしたりしないか
- 複数のユーザーが同時に操作したとき、データに矛盾が生じないか
このステップは特に「後から発覚しやすい問題」を見つけるために重要です。
受け入れテストでよく見つかる不具合パターン
機能面の不具合（よく見落とされるケース）
受け入れテストで発見されやすい機能面の不具合には、以下のようなものがあります。
画面表示の問題
- PCで表示するとデザインが崩れる、またはスマートフォンでは一部の機能が使えない
- データ量が多くなると一覧の表示が遅くなる、またはタイムアウトする
- 特定のブラウザ（Internet Explorerなど旧バージョン）で表示が崩れる
業務フロー途中でのエラー
- 複数の手順が必要な処理（例：入力→確認→確定→完了）の途中でエラーが発生し、どこまで処理が完了したか分からなくなる
- メール送信機能で、特定の条件のときだけ送信が失敗する
- 印刷やPDF出力で、長い文字列が途中で切れる
仕様の認識ズレ
- 「一覧に表示する件数は20件だと思っていたが10件だった」など、細かい仕様の認識が合っていない
- ボタンをクリックしたときの挙動が想定と異なる（確認ダイアログが出るか出ないかなど）
データ・権限まわりの確認漏れ
見落とされやすいのが、データと権限まわりの確認です。
データの確認
- 文字数の多いデータを入力したとき、途中で切り捨てられないか
- 数値項目に文字を入力した場合に適切なエラーが返るか
- 削除したデータが完全に消えているか（または意図的に残すべきデータが残っているか）
- バックアップから復元した場合にデータが正しく戻るか（開発会社に確認）
権限の確認
- 管理者・一般ユーザー・閲覧のみなど、権限ごとに正しくアクセス制限されているか
- 権限のないページに直接URLでアクセスしようとした場合、適切にブロックされるか
- ユーザーの追加・削除・権限変更が正しく機能するか
不具合を発見したときの対応フロー
不具合の記録方法（報告書のフォーマット例）
不具合を発見したら、その場で記録します。記録なしの口頭報告は「言った・言わない」のトラブルを招きます。
以下の情報を最低限記録してください。
項目 |
記録内容の例 |
|---|---|
発見日時 |
2026年4月13日 14:30 |
発見者 |
田中（総務部） |
発生箇所 |
受注登録画面 > データ保存ボタン |
操作手順 |
1. 受注登録画面を開く 2. 全項目を入力 3. 「保存」ボタンをクリック |
期待した動作 |
「保存完了」と表示され、一覧に反映される |
実際の動作 |
「エラー500」と表示され、データが保存されない |
再現性 |
毎回発生する（5回試した） |
スクリーンショット |
（添付） |
スクリーンショットは必ず撮影しておきましょう。問題が「その後自然に直った」ように見えても、記録として残しておくことが重要です。
重大度による優先度の判断基準
発見した不具合は重大度で分類し、優先度をつけて対応を依頼します。
重大度 |
基準の例 |
対応方針 |
|---|---|---|
致命的 |
業務が完全に止まる（ログインできない、主要機能が全く動かないなど） |
即時対応を依頼。修正完了まで検収書は出さない |
重大 |
主要な業務フローの一部が機能しない（特定の条件でデータが保存できないなど） |
優先的に修正を依頼。修正確認後に次のテストへ |
軽微 |
業務に影響はないが修正が望ましい（表示のズレ、誤字など） |
まとめて修正を依頼。検収書提出のタイミングを調整 |
致命的・重大な不具合が残っている状態では、検収書を発行してはいけません。軽微な不具合については、修正スケジュールを合意した上で検収書を発行するか、修正完了を確認してから発行するかを判断します。
ベンダーへの修正依頼と契約不適合責任の関係
受け入れテストで発見した不具合は、検収前に修正してもらうのが原則です。
不具合報告を受けた開発会社は、それが要件定義書・仕様書に明記された内容に適合しているかを確認し、適合していない場合は無償で修正します。これが請負契約における基本的な考え方です。
ただし、2020年の民法改正で「契約不適合責任」の概念が強化されました（旧民法の「瑕疵担保責任」から変更）。発注者が契約不適合（仕様通りでない状態）を知った時点から1年以内に通知することで、修補（修正）・代金減額・損害賠償などを請求できます。
つまり、検収後に不具合が見つかった場合でも、それが元々存在していた不具合であれば期間内の通知で対応を求めることができます。ただし、「曖昧な検収」では「検収時に確認すれば分かったはずだ」という主張をされることもあります。適切な受け入れテストと記録の保持が、発注者の権利を守る最善策です。
検収書の作成と正式な検収完了の手続き
検収書に記載すべき内容
受け入れテストが完了し、致命的・重大な不具合がないことを確認したら、検収書を作成します。検収書は「仕様書通りの成果物を受け入れた」という法的意思表示です。
検収書には最低限以下の内容を記載します。
- 発注者名・受注者名
- 開発プロジェクト名
- 検収対象の成果物（システム名、バージョン、納品物のリスト）
- 検収完了日
- 検収者の署名・捺印
なお、検収書は「全ての不具合がゼロ」であることを証明するものではありません。「合意した仕様の範囲内で受け入れた」という意思表示です。軽微な修正残件がある場合は、「○○の修正は○月○日までに実施することを条件として検収とする」という条件付き検収とすることも選択肢の一つです。
「みなし検収」に注意：期限を見落とさない
システム開発契約書には「みなし検収」の条項が含まれていることがあります。これは「納品から○○日以内に検収完了の通知または不合格通知がない場合、検収完了とみなす」というものです。
この条項がある場合、検収期間内に何も行動しなければ、問題があっても自動的に検収完了になってしまいます。
契約書を確認し、みなし検収の期間と条件を把握しておきましょう。検収期間内に確認が完了しない場合は、期間延長の交渉を早めに行うことが重要です。
まとめ：受け入れテスト チェックリスト
以下のチェックリストを印刷またはコピーしてご活用ください。
準備フェーズ
- 要件定義書をもとに確認観点リストを作成した
- テスト担当者（実業務担当者）を選定した
- テスト環境の提供をベンダーに確認した
- テストデータを準備した（またはベンダーに依頼した）
- テスト期間と不具合対応のスケジュールをベンダーと合意した
- 契約書の検収期間・みなし検収条項を確認した
テスト実施フェーズ
- 主要な業務フローをテストシナリオ化した（3〜5フロー）
- 正常系のテストを業務フローの順番で実施した
- 異常系・エッジケースのテストを実施した
- データの整合性（保存・表示・連携）を確認した
- 権限設定（管理者・一般ユーザーなど）を確認した
- 複数ブラウザ・デバイスでの表示を確認した
- 全ての確認結果を記録した（OK/NG・スクリーンショット）
不具合対応フェーズ
- 発見した不具合を重大度で分類した（致命的・重大・軽微）
- 不具合を記録した（発生箇所・手順・期待動作・実際動作・スクリーンショット）
- 致命的・重大な不具合をベンダーに報告し、修正対応を依頼した
- 修正後の再テストを実施した
- 致命的・重大な不具合がないことを確認した
検収書発行フェーズ
- 致命的・重大な不具合がないことを確認した
- 軽微な修正残件がある場合、修正期限を合意した
- 検収書に必要事項を記載した
- 検収書を発行し、ベンダーに提出した
受け入れテストと検収は、発注者がシステムを「自分たちの業務で安心して使える状態」に仕上げるための最終関門です。
秋霜堂株式会社では、受託開発においてお客様が受け入れテストをスムーズに実施できるよう、テスト観点リストの提供や確認作業のサポートを行っています。「どこから手をつければいいか分からない」「一緒にテストを進めてほしい」という場合は、お気軽にご相談ください。
検収が完了した後は、本番運用へ移行します。その後の保守・運用フェーズについてはシステムの保守と運用の違いとは？業務内容の違いを徹底解説、引き継ぎ時の注意点についてはシステム保守の引き継ぎで失敗しないための完全ガイドも参考にしてください。
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
