受入テスト計画書のサンプル 記載項目と章立て・合否基準の決め方と進め方を解説

「開発会社から受入テストをお願いしますと言われたが、何を確認すればよいのか分からない」「テスト計画書を作れと言われても、そもそも何を書く文書なのか」。システムを発注した企業の担当者から、頻繁に寄せられる相談です。

受入テストは、発注側が主体となって、納品されたシステムが業務で使える状態かを検証する工程です。そしてその進め方を定めるのが受入テスト計画書になります。

この文書が曖昧なまま始めると、テストが終わりません。どこまで確認すれば合格なのかが決まっていないため、不具合が出るたびに判断が止まり、検収の時期が読めなくなります。

この記事では、そのまま流用できる章立てのサンプルを示したうえで、各項目の書き方、合否基準の決め方、検収との関係、そしてよくある失敗への対策までを順に整理します。

確認したいポイント	結論	詳細
受入テストとは？	発注側が業務目線で行う最終確認	開発側のテストとは別に、発注側が業務要件を満たしているかを検証する工程になります。
計画書に何を書く？	目的・範囲・体制・基準・日程	特に重要なのが合否基準です。ここが曖昧だと、検収の判断ができなくなります。
誰が作成する？	発注側が作り、開発側と合意する	業務要件を知るのは発注側です。開発側の支援を受けつつ、主体は発注側になります。
失敗の原因は？	発注側の体制と期間の見積り不足	通常業務と並行するため、確保できる工数を計画に織り込まないと進みません。

この記事でわかること

• 受入テストの位置づけと、開発側が行うテストとの違い
• そのまま流用できる受入テスト計画書の章立てと、各項目の書き方
• 開始基準・終了基準と、不具合の重要度区分の具体的な決め方
• 受入テストの合格と検収の関係、契約で定めておくべき事項
• 発注側の体制不足など、よくある失敗の原因と事前の対策

システム開発とAI活用の進め方をまとめた資料を無料で配布しています 要件整理の進め方、開発や試験の依頼範囲の決め方、費用と期間の目安を1冊にまとめました。社内での検討材料としてご活用いただけます。 ▶ 資料請求はこちら ※オンライン完結／しつこい営業は一切いたしません

受入テストと受入テスト計画書とは

受入テストは、開発が完了したシステムを発注側が検証し、納品物として受け入れられるかを判断する工程です。ユーザー受入テスト、UAT、検収テストといった呼び方もされます。

IPAが公開する共通フレーム2013は、システムのライフサイクルを通じて必要な作業項目と役割を包括的に規定した枠組みです。契約で規定された受入れレビューとテストの要件が、成果物の納入に際して適切であるかという観点が、この工程の位置づけを示しています。

発注側が主体となるテスト

他のテスト工程との最大の違いは、主体が発注側であるという点です。単体テスト、結合テスト、システムテストはいずれも開発側が実施しますが、受入テストだけは発注側が行います。

理由は明確で、業務で使えるかどうかを判断できるのは業務を知っている人だけだからです。仕様どおりに動いていても、実際の業務の流れに合わなければ受け入れられません。

開発側が支援に入ることは一般的ですが、合否の判断そのものは発注側が下します。この役割分担を最初に確認しておかないと、開発側のテストの繰り返しになってしまいます。

開発側のテストとの違い

確認する観点が根本的に異なります。開発側は「仕様どおりに動くか」、発注側は「業務で使えるか」を見ます。

たとえば、承認画面が仕様書どおりに実装されていても、実際の承認者が使う端末では文字が小さすぎて読めないかもしれません。この種の問題は、業務の現場でしか発見できません。

機能単位ではなく業務の流れ単位で確認するという点も違いです。受注から出荷までを通しで実行し、途中で止まらないかを見ます。

計画書を作る目的

受入テスト計画書は、この工程をどう進め、何をもって合格とするかを事前に定めた文書です。作る目的は3つあります。

• 関係者の認識を揃える：発注側の各部署と開発側が、同じ前提で動けるようにする
• 合否の基準を先に決める：不具合が出てから判断するのでは、交渉になる
• 必要な準備を洗い出す：環境、データ、人員、期間を事前に確保する

2つ目が特に重要です。基準がないまま始めると、「この不具合があっても検収してよいか」という判断のたびに議論が発生し、時間だけが過ぎていきます。

受入テスト計画書のサンプル｜章立て

決まった様式はありませんが、押さえるべき項目は共通しています。ここでは、そのまま流用できる章立てを示します。

そのまま使える章立て

次の12章で構成すると、必要な内容が漏れなく収まります。プロジェクトの規模に応じて、不要な章は削って構いません。

1. 文書情報（版数／作成者／承認者／改訂履歴）

2. 本テストの目的と背景

3. 対象範囲と対象外

4. 実施するテストの種類と観点

5. 体制と役割分担

6. スケジュール

7. テスト環境

8. テストデータ

9. 開始基準と終了基準（合否基準）

10. 不具合の管理方法と重要度区分

11. 進捗報告と会議体

12. リスクと前提条件

この一覧をそのまま目次として使い、埋めていくという進め方が最も速く済みます。埋まらない項目があれば、それが未決事項です。

章立ての考え方

並びには意味があります。前半で「何を」を定め、中盤で「どう進めるか」を決め、後半で「どう判断するか」を規定するという流れです。

特に9章と10章は、読み飛ばされやすい割に実務上の影響が最も大きい部分です。ここが埋まっていない計画書は、実質的に機能しません。

12章のリスクと前提条件も省略しないでください。「開発側のシステムテストが完了していること」といった前提を明記しておくことで、条件が崩れたときの協議が成立します。

規格に沿うかどうか

テストドキュメントには国際規格があり、それに準拠した様式も公開されています。規格に沿うと項目は網羅されますが、その分だけ分量が増えます。

公共案件や監査対応が必要な場合は、規格準拠を検討する価値があります。一方、社内システムの導入であれば、上記の12章で十分に実用に耐えます。

目的は文書を整えることではなく、テストを進められる状態を作ることです。分量を増やすより、9章の合否基準を具体的に書くほうが効果があります。

記載項目ごとの書き方

章立てが決まったら、次は中身です。それぞれの章で何を書けばよいかを、記入例とともに整理します。

目的と背景

何のためにこのテストを行うのかを、数行で示します。「検収のため」だけでは不十分で、業務上の目的まで書きます。

【記入例】

本テストは、新受発注システムが現行の受注業務を代替できる

ことを、営業部および物流部の実務担当者が検証することを

目的とする。合格をもって検収の判断材料とする。

背景には、なぜこのシステムを導入したのかを簡潔に記します。参加者がテストの意味を理解しているかどうかで、指摘の質が変わります。

対象範囲と対象外

どの機能、どの業務を対象とするかを明示します。対象外を書くことが特に重要です。書かれていない範囲について、後から「なぜ確認しなかったのか」という議論が生じます。

対象範囲は機能単位ではなく、業務単位で書くと分かりやすくなります。「受注登録から出荷指示までの一連の業務」といった表現です。

今回のリリースに含まれない機能、既存システムをそのまま使う部分、次期リリースへ送る機能は、対象外として列挙します。

テストの種類と観点

受入テストの中でも、確認する観点はいくつかに分かれます。すべてを行う必要はなく、必要なものを選びます。

• 業務シナリオテスト：実際の業務の流れを通しで実行する。中心となる観点
• 操作性の確認：現場の担当者が迷わず操作できるか
• 帳票・出力の確認：印刷結果やファイル出力が実務で使える形式か
• 既存業務との並行確認：現行システムの結果と突き合わせて一致するか
• 性能の体感確認：実際の使用感として許容できる速度か

4つ目は移行を伴う案件で有効です。同じ入力に対して現行と新システムの結果が一致するかを確認すれば、計算ロジックの誤りを高い確度で検出できます。

体制と役割分担

誰が何を担当するかを一覧にします。発注側の各部署から誰が参加するかを、氏名レベルで明記します。

「営業部から数名」という書き方では、当日になって人が集まりません。担当する業務範囲と、確保する稼働時間まで記載します。

開発側の役割も書きます。環境の準備、質問への回答、不具合の修正、修正版の提供といった作業と、その対応時間を明確にしておきます。

スケジュール

開始日、終了日、そして中間の節目を記載します。不具合の修正と再テストの期間を必ず織り込みます。

実施期間だけを確保して修正期間を見ていない計画は、必ず破綻します。目安として、実施期間と同程度の再テスト期間を見込んでおきます。

発注側の繁忙期を避けるという調整も重要です。月末月初や決算期に受入テストを設定すると、参加者が集まらず日程が空転します。

テスト環境とデータ

どの環境で実施するか、誰がどう用意するかを記載します。本番環境で実施するのか、検証環境かで、扱いが大きく変わります。

データについては、本番相当のデータを使うかどうかを決めます。実データを使う場合は、個人情報の取り扱いに注意が必要です。マスキングの要否もここで定めます。

アカウントと権限の準備も忘れずに記載します。参加者全員分のIDが発行されていないと、開始日にテストが始まりません。

受入テストの体制づくりからご相談いただけます 書き方は分かっても、自社の体制で何をどこまで確認すべきかの判断は別の問題です。計画づくりからご一緒する30分の無料相談をご用意しています。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎

合否基準の決め方

計画書で最も重要な章です。ここが具体的に書かれているかどうかで、テストが終わるかどうかが決まります。

開始基準と終了基準

開始基準は、受入テストを始めてよい条件です。これを満たさないまま始めると、開発側のテストの続きになってしまいます。

【開始基準の例】

・開発側のシステムテストが完了し、報告書が提出されていること

・重要度A（業務停止級）の未解決不具合が0件であること

・テスト環境が構築され、疎通確認が完了していること

・参加者全員のアカウントが発行されていること

終了基準は、合格とみなす条件です。「すべての不具合が解消されること」という書き方は現実的ではないため、重要度で線を引きます。

【終了基準の例】

・計画したテストケースの消化率が100%であること

・重要度AおよびBの不具合がすべて解消されていること

・重要度C以下の残存不具合について、対応方針が合意されていること

3つ目の書き方が実務的です。軽微な不具合を全部直すまで検収しないという運用は、稼働時期を大きく遅らせます。

不具合の重要度区分

終了基準を機能させるには、重要度の定義が必要です。曖昧なままだと、区分をめぐる交渉が発生します。

• A（致命的）：業務が実施できない。データが破損する。回避策がない
• B（重大）：業務に支障があるが、手作業などの回避策がある
• C（軽微）：業務は実施できる。表示の崩れ、誤字、操作性の改善要望
• D（要望）：不具合ではなく、追加の機能要望

Dの区分を設けておくことが実務上のポイントです。テスト中に出てくる「こうなっていたらもっと良い」という声を、不具合と分けて記録できます。

区分の判定を誰が行うかも決めます。発注側と開発側で見解が分かれることがあるため、協議の場と最終決定者を定めておきます。

残存不具合の扱い

重要度C以下を残したまま検収する場合、いつまでに、どう対応するかを合意します。

「稼働後1か月以内に無償で修正する」「次回リリースにまとめて対応する」「対応しないことを合意する」といった選択肢があります。1件ずつ方針を決め、一覧にして残します。

この一覧が、稼働後のトラブルを防ぎます。合意なく持ち越すと、後から「直してもらえると思っていた」という認識の食い違いが生じます。

判定する会議体

終了基準を満たしたかどうかを、誰がいつ判断するかを定めます。判定会議の開催日を、スケジュールに明記しておきます。

出席者は、発注側の責任者、業務部門の代表、開発側の責任者が基本です。決裁権を持つ人が入っていないと、その場で判断できません。

テストシナリオの作り方

計画書とは別に、実際に何を確認するかを記したテストシナリオが必要です。作り方の要点を整理します。

業務の流れを軸にする

機能一覧をなぞるのではなく、日々の業務の流れをそのままシナリオにします。「朝の受注登録から夕方の出荷指示まで」という単位です。

1本のシナリオが複数の画面と機能をまたぐ形になります。これにより、機能単体では見えなかった不整合が浮かび上がります。

現場の担当者に、普段の作業手順を書き出してもらうのが最も確実な作り方です。開発側が作ったシナリオでは、実務の細部が抜けます。

例外と異常系を含める

正常系だけを通して合格とするのは危険です。実務で頻繁に発生する例外を、必ずシナリオに含めます。

受注の途中でキャンセルする、金額を訂正する、承認者が不在で代理承認する、締め処理後に修正が必要になる。こうした場面は、日常的に起こります。

例外処理は仕様書に書かれていないことが多く、受入テストで初めて発覚します。だからこそ、この工程で確認する価値があります。

シナリオ1件あたりの書式

確認する人が迷わない粒度で書きます。手順と期待結果をセットにし、結果を記入する欄を設けるのが基本形です。

シナリオID：UAT-001

業務　　　：受注登録から出荷指示まで

実施者　　：営業部 担当者

前提条件　：得意先マスタに「テスト商事」が登録済み

手順　　　：1. 受注登録画面を開く

　　　　　　2. 得意先「テスト商事」を選択し商品を3件入力

　　　　　　3. 登録ボタンを押す

期待結果　：受注番号が採番され、物流部に通知が届く

実施日／結果／不具合番号：______／合・否／______

期待結果を書かずに手順だけを並べると、実施者が合否を判断できません。何が起これば正しいのかを、必ず明記します。

業務に詳しくない人でも実施できる水準を目安にします。参加者が交代する可能性を考えると、この粒度が結果的に効率的です。

実務に近い条件で行う

件数、金額の桁、文字数、添付ファイルのサイズ。実際の業務で扱う条件に近い形で試します。

テスト用の「テスト太郎」「1000円」といったデータだけでは、実データ特有の問題を見逃します。長い会社名、旧字体、外字、桁数の大きい金額といった条件を混ぜます。

要件の書き方や粒度については要件定義の例｜システム種類別の要件例と、機能要件・非機能要件の書き換え集も参考になります。

検収との関係

受入テストの合格は、契約上の検収と直結します。この関係を理解しておかないと、費用や責任の話でつまずきます。

合格が検収の判断材料になる

多くの契約では、受入テストの合格をもって成果物を受け入れ、検収とする流れになっています。検収が完了すると、支払いの条件が満たされます。

同時に、それ以降に見つかった不具合の扱いも変わります。契約不適合責任の期間や範囲は、検収の時期を起点に定められることが一般的です。

つまり、受入テストは単なる確認作業ではなく、契約上の重要な区切りです。この認識を持って臨む必要があります。

契約で定めておくこと

IPAが公開する情報システム・モデル取引・契約書（第二版）は、ユーザ企業とITベンダのいずれにもメリットが偏らない中立的な契約書を目指して作成されたものです。役割分担や連絡協議会といった条項が整理されており、検収の進め方を検討する際の参考になります。

契約段階で確認しておきたいのは、検収の期間、合否の判定方法、期間内に判定しなかった場合の扱い、そして不合格とした場合の手続きです。

検収期間を過ぎると自動的に合格とみなすという条項が入っていることがあります。テストが遅れると、確認しないまま検収したことになります。

合格後に見つかった不具合

検収後に不具合が発覚することは避けられません。どこまでが無償の修正で、どこからが有償の改修かを、事前に整理しておきます。

契約内容に適合していないものは無償の修正対象になるのが一般的です。一方、要件になかった機能の追加は改修であり、別途の見積りになります。

この線引きの根拠になるのが要件定義書です。受入テストの段階で、要件定義書との対応を確認しておくと、後の判断がしやすくなります。

よくある失敗と対策

受入テストがうまくいかない原因は、技術面ではなく体制と準備にあることがほとんどです。

発注側の体制が確保できていない

最も多い失敗です。通常業務と並行して実施するため、参加者の時間が確保できません。計画では2週間としていたテストが、2か月かかるという事態になります。

対策は、参加者の稼働時間を計画段階で見積もり、上長の合意を取っておくことです。「1日2時間を10営業日」といった形で明示します。

業務の繁忙期を避け、代替要員の手当ても含めて調整します。ここを曖昧にしたまま日程だけ決めると、必ず遅れます。

開発側のテストの繰り返しになる

画面の表示崩れやエラーメッセージの誤りといった、本来なら開発側のテストで潰されているべき不具合が大量に出るケースです。

この状態では、受入テストの本来の目的である業務適合性の確認まで到達できません。開始基準を満たしていないビルドで始めたことが原因です。

開発側のシステムテストの完了報告を確認してから開始するというルールを、開始基準として明記します。品質が明らかに低い場合は、差し戻す判断も必要です。

合否基準がないまま始まる

「一通り触ってみて問題なければ検収」という進め方です。何をもって終わりとするかが決まっていないため、いつまでも終わりません。

不具合が出るたびに「これは検収を止めるほどか」という議論が発生し、その判断に時間を取られます。関係者が増えるほど収束しなくなります。

対策は前述のとおり、重要度区分と終了基準を計画書に書き、開発側と合意しておくことです。開始前の30分の議論が、後の数週間を救います。

指摘が要望に流れていく

テストを進めるうちに、「ここもこうしてほしい」という改善要望が次々と出てくるというパターンです。件数が膨らみ、どれが不具合でどれが要望か分からなくなります。

要望自体は貴重な意見ですが、受入テストの目的は要件を満たしているかの確認です。要件になかった内容は、不具合ではありません。

対策は、前述の重要度区分にDの「要望」を設け、記録は受け付けつつ検収の判定からは切り離すことです。要望は次期リリースの検討材料として別に管理します。

期間が短すぎる

開発が遅れた分のしわ寄せが、受入テストの期間に来るというパターンです。リリース日が動かせないため、確認の時間だけが削られます。

この状態で無理に進めると、確認が形骸化します。稼働後に問題が発覚し、結果的により大きな損失になります。

期間が確保できないなら、範囲を絞るという判断が必要です。重要な業務に絞って確実に確認し、残りは稼働後の並行運用で見るという選択もあります。

準備を進めるためのチェックリスト

最後に、着手前に確認しておきたい項目を一覧にします。計画書を書く前の準備として使えます。

計画書を作る前に決めること

• 受入テストの責任者は誰か（決裁できる人か）
• 参加する部署と担当者、確保できる稼働時間
• 対象とする業務範囲と、対象外とする範囲
• 実施する期間と、繁忙期との重なり
• 契約上の検収期間と、その起点

最後の項目は契約書を確認します。検収期間が10営業日と定められているのに、テスト計画が3週間では整合しません。

開始前に揃えるもの

• テスト環境と、参加者全員分のアカウント
• テストデータ（本番相当のデータを使う場合はマスキングの要否も確認）
• テストシナリオと、確認する項目の一覧
• 不具合を記録する仕組みと、記入のルール
• 開発側の質問窓口と、回答までの目安時間

4つ目を軽視しないでください。記録の形式が揃っていないと、集計も進捗管理もできなくなります。

実施中に記録すること

テストの実施記録は、検収の根拠になります。誰が、いつ、何を確認し、結果がどうだったかを残します。

不具合については、再現手順、発生条件、スクリーンショットを添えます。情報が不足していると、開発側で再現できず調査が進みません。

外注時の全体の進め方や役割分担についてはシステム開発の外注とは｜メリット・デメリット、費用相場、外注先の種類と選び方で整理しています。

まとめ

受入テスト計画書は、目的、範囲、体制、スケジュール、環境、合否基準、不具合管理を定める文書です。本記事で示した12章の構成をそのまま目次として使えます。

最も重要なのが合否基準です。開始基準と終了基準を、不具合の重要度区分とセットで定義しておくことで、テストが終わらないという事態を防げます。

シナリオは、機能一覧ではなく業務の流れを軸に作ります。現場の担当者に普段の手順を書き出してもらうのが最も確実な方法です。

そして、受入テストの合格は契約上の検収と直結します。単なる確認作業ではなく、責任の区切りであるという認識を持って臨んでください。

まずは12章の目次を作り、埋められない項目がどこかを確認してみてください。埋まらない部分が、そのまま関係者と決めるべき論点になります。

発注側としての進め方から、無料で相談できます 検収してよいか判断に迷っている、社内に開発の知見がなく不安があるといった段階のご相談も承っています。営業色は一切ありません。 ▶ 相談予約はこちら ※オンライン完結／秘密厳守／助成金活用のご相談も歓迎