システム受入テストの合格条件｜補助金の検収前に確認する20項目

結論：ベンダーテスト・受入・検収・Go-liveを4つに分けるリンク

「完成しました」という一言には、少なくとも4つの状態が混ざります。ベンダーが仕様どおりの動作を確認した状態、発注者が業務で利用できると確認した状態、契約上の成果物を受け取る状態、本番運用を開始できる状態です。決定者、見る資料、停止条件が違うため、一つの承認印で済ませません。

本記事の対象は2番目の受入テストを中心に、3番目の検収判断へ渡すところまでです。本番開始時の問い合わせ体制、監視、切戻し、教育、初日運営を判断するGo-liveは、別の運用開始判定として扱います。

表は横にスクロールして全項目を確認できます

受入テストを始める前に4つの正本を固定するリンク

受入テストの最初の失敗は、テスト項目が少ないことではなく、何を正解とするか決まっていないことです。契約時の要件、開発中の変更、現在の実装、今回テストする版が一致しなければ、不具合なのか追加要望なのかを判定できません。

開始前に、契約・発注の基準、承認済み要件、承認済み変更、テスト対象版の4つを固定します。要件ID、変更ID、リリース番号、環境、基準日を一行で結び、テスト途中の修正版は別の版として記録します。「最新版」というファイル名だけでは、後から検収した版を特定できません。

受入期間が始まってから要件の正本を探すと、現場はテスト時間を資料探索に使い、見つからない要件を口頭で合格にしがちです。4つのどれかが不明なら、まず補助金案件の監査証跡・三版管理で版と証拠を回収します。

表は横にスクロールして全項目を確認できます

受入テストの合格準備を20項目100点で診断するリンク

20項目を各5点、合計100点で確認します。5点は対象、期待結果、担当、証拠、判定がそろう状態、3点は資料があるが差分・担当・再テストのいずれかが未確認、0点は未実施、根拠なし、対象版不明、または重大な矛盾がある状態です。

合計点だけで合格にしません。テスト対象版、必須業務、権限、移行データ、重大不具合、再テスト、検収権限のいずれかが0点なら停止条件です。100点は「契約上必ず合格」「補助金で必ず認められる」という意味ではなく、経営者が判断根拠を確認できる準備度です。

20項目は、機能の数を数える表ではありません。売上計上、受発注、請求、承認、個人情報、締め処理など、止まると事業へ影響する業務から優先します。機能数が多い場合は要件対応表を別に持ち、この20項目は経営判断の集約表として使います。

表は横にスクロールして全項目を確認できます

受入テストは画面一覧ではなく業務シナリオ10列で作るリンク

画面ごとにボタンを押すだけでは、業務がつながるか確認できません。受注を登録し、在庫や与信を確認し、承認し、請求し、会計へ連携する、といった開始から完了までの業務シナリオを単位にします。期待結果は「正常に動く」ではなく、誰のどの状態が、何へ変わるかまで書きます。

シナリオには正常系だけでなく、入力誤り、二重送信、取消、権限不足、締め後修正、外部連携失敗など、現場で起きる例外を入れます。すべての組合せを無制限に試すのではなく、発生頻度、金額、法令・個人情報、停止時間、手作業代替の可否で優先順位を付けます。

テストデータへ実在顧客の個人情報を無断でコピーしません。匿名化・仮名化、利用目的、アクセス権、削除方法を確認し、本番相当の件数や形式が必要な場合も、個人情報・秘密情報の扱いを先に決めます。

表は横にスクロールして全項目を確認できます

重大度は不具合件数ではなく事業影響で4段階に分けるリンク

不具合が100件あるから不合格、3件だから合格という判断はできません。文言のずれが100件残る場合と、売上計上を二重にする不具合が1件残る場合では影響が逆です。重大度は、業務停止、金額・データの誤り、情報漏えい、法令・契約への影響、回避策、復旧時間で決めます。

次のS0〜S3はGXOの内部分類例です。公式規格の等級ではありません。契約・要件・事業特性に合わせて名称と条件を合意し、受入開始前に「どの等級が何件なら合格か」「回避策を誰がいつまで負うか」を決めます。

S0・S1が残る場合、合計点が高くても検収を進めません。S2・S3を残して受け入れる場合も、自動的に適法・妥当になるわけではなく、契約上の扱い、修正期限、費用、保証、再テスト、支払への影響を権限者が確認します。

表は横にスクロールして全項目を確認できます

機能以外にデータ・権限・非機能・納品物を判定するリンク

受入テストが画面操作だけになると、検収後に移行データの欠落、権限過多、処理遅延、バックアップ不能、管理者アカウント未移管が見つかります。機能要件が合格でも、事業で使える状態とは限りません。

データ移行は、総件数だけでなく、主キー、金額合計、日付範囲、ステータス別件数、重複、欠損、文字化け、添付ファイルを照合します。差異をゼロにできない場合は、差異ID、理由、影響、処置、承認を残し、「概ね移行できた」で閉じません。

性能・セキュリティ・可用性は、この記事で一律の秒数や稼働率を決めません。契約・要件で合意した同時利用者、処理件数、応答時間、認証、権限、ログ、バックアップ、復旧条件へ戻します。未定義なら、検収直前に都合のよい数字を作らず、業務影響と追加確認の扱いを決裁します。

納品物の種類と権利は受け取るべき成果物一覧、開発全工程での受入の位置はソフトウェア開発の流れで確認できます。本記事は、その納品版を業務シナリオで合否判定する部分に限定します。

表は横にスクロールして全項目を確認できます

不具合は修正・条件付き・変更要求・保留の4つへ分けるリンク

受入中に見つかった差異を、全部「不具合」または全部「追加要望」にすると対立します。承認済み要件と期待結果へ戻り、まず事実を再現し、契約範囲、業務影響、修正方法、期限を分けます。

合否判定は、無条件合格か全面不合格の二択だけではありません。ただし、条件付き受入を選べるか、支払・保証・責任がどうなるかは契約次第です。GXOが法的結論を出さず、技術事実と残課題を整理し、契約担当・弁護士等の必要な専門家へ渡します。

修正後は、該当ケースだけでなく影響を受ける周辺ケースを再実施します。修正した版、変更箇所、再テスト、回帰テスト、残課題を同じ不具合IDへつなぎ、「対応済み」だけで閉じません。

表は横にスクロールして全項目を確認できます

補助金案件では受入合格と制度上の確認を混同しないリンク

補助金を使ったシステムでも、この記事の20項目が全制度の提出書類になるわけではありません。受入テストは発注者が業務利用可能性を判断する技術・発注の記録です。補助事業上の完了日、検収日、支払期限、提出物、機能確認、現地・オンライン確認は、制度・公募回・経費区分で異なります。

この制度例を他の補助金へ横展開しません。補助対象、額確定、提出可否、未実装の扱いをGXOが判定することもありません。自社の制度資料と事務局回答を確認し、制度側の証拠一覧とUATケースIDを対応させます。

検収日を間に合わせるために過去日付へ戻す、未実施のテストを実施済みにする、現在版の画面で検収版を上書きすることは避けます。期限が危ない場合は、事実と版を保存して補助事業の期限リカバリーへ分岐します。

表は横にスクロールして全項目を確認できます

企業・開発会社・士業・GXOの責任を分けるリンク

受入テストを開発会社へ丸投げすると、作った側が自分の成果物を受け入れる構造になります。開発会社は環境、テスト支援、修正、技術説明を担えますが、自社の業務が回るか、残課題を受け入れるか、検収書へ署名するかは発注者側の判断です。

士業・補助金支援者は、制度・公募回の提出物、期限、手続きの確認を支援します。開発会社は要件対応、対象版、テスト結果、不具合、納品物を説明します。GXOは、第三者としてUAT設計、重大度、再テスト、要件と証拠の接続、検収判定材料を整理します。

誰がRで誰がAかを案件ごとに決めます。社内IT担当がいない場合も、業務の合否を決める利用部門と、残課題・支払を決裁する経営者まで外注することはできません。

表は横にスクロールして全項目を確認できます

30分で検収判断の根拠を第三者が再現できるか試すリンク

検収書へ署名する前に、UATへ直接参加していない役員、内部監査、経理など1人へ案件フォルダーを渡します。30分で、何をテストし、何が合格し、何が残り、なぜ検収を進めるのかを再現できれば、担当者の記憶やベンダーの説明だけに依存していません。

30分はUAT全体を終える時間でも、制度上の審査時間でもありません。GXOの内部再現テストです。8ステップの途中で対象版、要件、不具合、再テスト、合否承認を開けなければ、検収前に不足資料と担当を決めます。

期限が迫り、自社だけで20項目を埋められない場合は、システム開発の相談・第三者レビューで、制度判断と技術判断を分けて整理できます。相談時は契約、要件、変更、対象版、不具合台帳、テスト結果、検収期限を共有すると、初動範囲を限定できます。

「一応動く」で検収してしまう7つの失敗を止めるリンク

受入テストの失敗は、専門知識不足より、期限と責任の曖昧さから起きます。納期に遅れたベンダーが受入期間を短縮し、現場が忙しく、経営者が「致命的でなければ後で直す」と判断すると、未確認の範囲まで合格扱いになります。

特に「運用で回避できる」は停止条件です。誰が、何件を、何分で、いつまで回避するのか、その間の誤りを誰が検知するのかがなければ、回避策ではなく現場への負債移転です。

次の7つに該当したら、署名日を決める前に20項目へ戻します。契約・法的責任の争いが始まっている場合は、記録を上書きせず、技術事実を保全して弁護士等の必要な専門家へ相談します。

まとめ：検収書より先に、合否を再現できる判定表を作るリンク

受入テストの合格条件は、「一応動く」「ベンダーのテストが終わった」「不具合が少ない」ではありません。契約・要件・変更・対象版を固定し、利用者が業務シナリオを実行し、データ・権限・非機能・納品物を確認し、重大不具合と再テストを追える状態です。

まず20項目100点で0点を見つけ、シナリオ10列、重大度4段階、差異の4分岐、30分再現テストの順に整理してください。納品物の有無だけなら成果物一覧、補助金の実績報告・検査まで準備するなら確定検査の12項目へ分岐できます。

対象版が不明、重大度が決まらない、ベンダーと不具合・追加要望の認識が合わない、検収期限までに再テストできない場合は、署名前に第三者レビューを入れます。GXOは技術事実と判断材料を標準票へ戻し、必要に応じてUAT再設計、修正PMO、引継ぎ、実装支援へ接続します。

よくある質問リンク

出典・公式情報リンク

• デジタル庁 デジタル社会推進標準ガイドライン

  政府情報システム向け標準ガイドライン、解説書、実践ガイドブックの公式入口。民間案件では参考資料として使用

  確認 2026-07-24
• デジタル庁 デジタル・ガバメント推進標準ガイドライン解説書

  受入テストと検収の区別、要件・品質・合否判定基準、品質保証資料の考え方

  2025年6月19日更新／P.190〜191・第6章7 検収

  確認 2026-07-24
• IPA 情報システム・モデル取引・契約書（第二版）

  仕様、プロジェクト管理、検収方法を契約時に共通理解とするための公式モデル。利用時は法令改正と個別契約を確認

  掲載文書2025年4月8日更新

  確認 2026-07-24
• 中小企業新事業進出補助金 実績報告ガイド

  完了期限、納入・検収・支払、検収記録、システム構築の要件・工程・機能確認資料の制度固有例

  2026年7月1日・第1.4版／P.5、P.13〜14、P.35〜37

  確認 2026-07-24
• 中小企業新事業進出補助金 資料ダウンロード

  実績報告ガイド、手引き、様式の最新版を確認する公式入口

  確認 2026-07-24

制度の要件・金額・期限は年度や公募回で変わります。最終更新日（2026-07-24）時点の公式情報に基づいて執筆していますが、申請・契約の前に必ず公式サイトで最新情報をご確認ください。