この記事の要約
受入テストで発注者が確認する内容を、業務シナリオとチェック項目で解説。Ouverの二重集計の実体験、準備・実施・不具合報告・再確認の手順、検収との違い、よくある質問を紹介します。
受入テストは、発注側が実際の業務に沿ってシステムを使い、合意した条件を満たすか確かめる作業です。画面が開くことだけでなく、担当者の仕事がつながり、必要な結果が正しく得られるかを確認します。
検収は、契約で決めた条件と手続きに沿って納品内容を確認することです。受入テストの結果は判断材料になりますが、テスト完了、検収、利用開始が同じ日とは限りません。今回は、発注担当者が準備するものと、確認・報告の進め方を整理します。
1 画面の確認だけでは業務の問題を見落とす
『登録ボタンが動いた』だけでは、その情報が次の担当者に届くか、集計に正しく反映されるかまでは分かりません。受発注システムなら、注文登録から在庫確認、出荷、売上集計までを一連の場面として確認します。以下の受発注例は説明用の仮の例です。
正常に処理できる場面に加え、数量の変更、取り消し、入力漏れ、権限のない人の操作など、合意した業務ルールも確認します。管理者と現場担当者では見える情報や操作が異なるため、実際の役割に近いアカウントを使うことが大切です。
開発側のシステムテストではシステム全体が要求を満たすかを確認し、受入テストでは発注側が業務上受け入れられるかを判断します。担当範囲は案件ごとに決め、性能やセキュリティの専門的な検証を発注側がすべてやり直す必要はありません。どの項目を開発側の試験結果で確認し、どこを業務担当者が操作するか、役割を分けます。確認対象が曖昧なままでは、同じ作業を繰り返す一方で、重要な項目が抜けてしまいます。
2 Ouverの実体験 売上が二重に集計されたケース
Ouverが自社の管理システムを作り直した際、古いデータの置き場所と新しい置き場所の両方に同じ売上が入り、二重に集計された経験があります。対処として、売上をどちらに置くかを一つに決め直しました。Excelからシステムへのデータ移行の記事で紹介している実例です。
コラムExcelからシステムへのデータ移行：移す前のデータクレンジングと、隠れたルールの見つけ方
これはシステムの作り直しの過程で起きた実例です。画面にデータが表示されるだけでは、正しく業務に使えるとは限らないことが分かります。移行を伴う案件では、件数や合計金額、重複の有無を何と照合するか、旧・新のどちらを正とするかまで確認項目に含めましょう。
厚生労働省が紹介するユークエスト株式会社の取組では、試作品から具体的な試験項目を定め、発注者もレビューに参加しています。仕様と検収条件をそろえたことで手戻りを防いだとされています。確認項目は納品直前に初めて考えるのではなく、早めに共有することが大切です。厚生労働省「問題解決の勘所11」
3 Ouverは業務での使い方を踏まえて確認します
Ouverでは開発側でテストを行い、お客様の確認も踏まえて、合意内容との認識を合わせます。気になる点があれば、仕様への対応か追加要望かを整理して相談します。確認範囲や検収条件は案件ごとに定めます。工程全体との関係はシステム開発の流れをご覧ください。
4 受入テストを進める四つの手順
手順1 担当者と判断基準を決める
現場の確認担当者、業務上の判断をする責任者、開発会社への連絡窓口を決めます。確認する期間だけでなく、不明点への回答、修正、再確認の時間も確保します。各項目を何と比べて合格とするか、未確認や問題が残ったときに誰が判断するかを先にそろえましょう。 ここまでを受入テスト計画としてまとめ、関係者で共有します。
手順2 業務の場面と期待する結果を書き出す
テスト項目には、番号、対象の要件、操作者、前提条件、操作手順、期待する結果、実際の結果を用意します。手順だけでなく『何が起これば正しいか』を書くことがポイントです。
例えば『注文10件のうち1件を取り消す』場面なら、『取り消した注文が出荷対象に残らず、合意した集計ルールどおりに件数と金額が変わる』まで確かめます。実施していない項目は合格とせず、未実施と記録します。確認用データは見本を優先し、本番の個人情報や機密情報が必要な場合は、利用範囲と管理方法を事前に決めます。
金額を確かめるときは、システムが出した数字をそのまま正解にしないことも大切です。例えば、内訳から事前に計算した合計や、確認済みの帳票を用意します。期待する結果を先に決めておくと、『動いたから合格』という判断を避けられます。
手順3 不具合を再現できる形で報告する
『数字がおかしい』だけでは調査を始めにくいため、次の内容を一件ずつ記録します。
- 項目番号、確認日時、環境や版、操作した人の権限
- 使用データ、操作の順番、期待した結果、実際の結果
- 発生頻度、業務への影響、必要な範囲の画面画像
ログイン情報などを報告に書かず、画像の個人情報も伏せます。原因が分からなくても、観察した事実は報告できます。不具合、設定や操作の問題、仕様の認識違い、追加要望のどれかは、開発会社と資料を照合して整理しましょう。
手順4 修正後の確認と残る事項をそろえる
修正済みの連絡を受けたら、どの版に反映されたかを確認し、同じ手順で試します。変更箇所の周辺に影響がないかは、開発会社の確認結果も共有してもらいます。担当者が操作できなかった項目は、後で確認する担当と期限を残してください。
最後に、合格・不合格・未実施・保留をまとめます。残る問題について、影響、暫定対応、対応予定、判断者を記録し、契約に沿って検収や利用開始の可否を相談します。問題が一つでもあれば必ず検収できない、軽微なら必ず問題ない、とは一律に決められません。
5 発注側が手元にそろえるチェック項目
- 日常業務が最初から最後までつながるか
- 取り消しや修正など、合意した例外を扱えるか
- 担当者ごとの閲覧・操作範囲が合っているか
- 件数、金額、帳票、連携先の結果が一致するか
- 未実施や残る問題について、次の対応が決まっているか
これは出発点となる一覧です。自社の業務と合意した要件に合わせて増減し、担当者間で同じ判断ができる表現に直してください。
受入テストの準備から相談したい方へ
『確認項目がまとまらない』『どこまで確認してよいか分からない』ときは、業務の流れと現在の資料をもとにご相談ください。初回相談は無料です。詳しい調査や支援が必要な場合は、対応範囲と費用を確認して進めます。
受入テストの支援範囲や検収条件は、発注前の見積もりでも確かめておきます。
コラムシステム開発の見積もりの見方：見積書で確かめる項目と、2社以上を比べるときのそろえ方
出典確認日：2026年11月6日。事例と説明用の仮の例を区別して記載しています。
よくある質問
受入テストは開発会社に任せられますか？
項目作成や実施の支援は相談できますが、現場の業務に合うかの確認や受入判断には発注側が関わります。具体的な分担を決めましょう。
ITに詳しくなくてもできますか？
普段の仕事を説明し、必要な結果になっているか確かめることが中心です。技術的な原因の調査は開発会社と分担します。
期間は何日必要ですか？
機能数、関係部署、締め処理や外部連携の有無で変わります。操作する日数だけでなく、修正と再確認、社内判断の時間も見込みます。
テスト中に新しい要望が出たらどうしますか？
合意した内容との差分を確認し、不具合と分けて管理します。今回対応するかは費用や日程への影響も踏まえて判断します。
不具合が残っていても利用を始められますか？
業務への影響、回避方法、契約上の条件などによります。件数だけで判断せず、残る事項と対応方針を関係者で確認してください。
