はじめに
受入テストの初日、発注側の担当者が画面を触りながら「思っていたのと違う」「このケースはどうなるの？」と言い始めます。開発側は「仕様書どおりです」と答え、そこから仕様変更か不具合かの議論が始まります。
こうした指摘にも、実は2つの段階があります。発注側の中で要望や指摘について共通認識が取れていれば、まだ「対応するか、しないか」を一緒に検討できます。
もっと厄介なのは、発注側の一人ひとりが、触って思ったことをそれぞれ指摘してくるケースです。発注側の中でも共通認識が取れていないため、全部取り入れると機能同士で齟齬が起き、UI/UXもぐちゃぐちゃになります。そうなると、どれを修正・変更するかを検討することさえできなくなります。
この状態の受入テストは、テストではなく「動作確認会」です。合否を判定する基準がないため、触った人の印象がそのまま指摘になります。原因はテスト工程ではなく、要件定義で「何ができたら合格か」を文章にして、発注側の中でそろえていないことにあります。
この記事では、受入基準を要件定義の段階で書くための手順と、そのまま使えるテンプレートを紹介します。対象は、受託開発や社内開発で要件定義と受入テストの両方に関わるPM・SE、発注側のプロジェクト担当者です。
受入テストが崩れる3つのパターン
1. 「とりあえず触ってみてください」で始まる
テストケースも合否の基準もないまま、業務担当者に環境だけを渡すパターンです。指摘は「使いにくい」「ボタンの位置が変」などの印象論に寄り、本当に確かめるべき例外ケースは誰も試しません。
2. 受入基準が「仕様書どおり動くこと」だけ
契約書に「仕様書どおりに動作することをもって検収とする」とだけあるケースです。仕様書が曖昧な部分は、合否もそのまま曖昧になります。IPAのモデル契約の見直し資料も、仕様書にある機能の実装を確かめるだけでは十分な検査にならない場合があるとしています。検査の基準はユーザとベンダが協力して作るのが望ましい、という整理です（末尾の参考リンク）。
3. 受入テストの期間と担当者が決まっていない
発注側の業務担当者は通常業務と兼務です。受入テストに割く時間を要件定義の段階で確保していないと、期間の後半に指摘が集中し、修正と再テストがリリース日に間に合いません。
| パターン | 起きること | 要件定義で打つ手 |
|---|---|---|
| とりあえず触る | 印象論の指摘、例外が未検証 | 業務シナリオと受入基準を決める |
| 仕様書どおりだけ | 仕様変更か不具合かで対立 | 合否を文章で書き、双方で合意する |
| 期間・担当が未定 | 指摘が後半に集中して遅延 | 体制と期間を計画に入れる |
実際によくあるのは、パターン3とパターン1が重なるケースです。発注側の日常業務の調整がついておらず、受入テストの最終日になって、焦った担当者から大量の要望と指摘が上がってきます。しかも、受入テストのシナリオや仕様をよく見ないまま、モンキーテストのように思いつくまま触って、思ったことを指摘してくるのです。
受入基準を要件定義で書く5つのステップ
受入基準は「テスト工程の成果物」ではなく「要件定義の成果物」として扱います。要件を一つ合意するたびに、その合否も一緒に決めるのが原則です。
-
業務シナリオを列挙する
- 機能一覧ではなく、「誰が、いつ、何のために、どの順で使うか」の単位で書きます。
- 日次・月次・年次の業務、締め処理、代理入力などの周辺業務も拾います。
-
シナリオごとに「何ができたら合格か」を書く
- 前提・操作・結果の3つに分けて書くと、曖昧さが減ります（次の章の Given-When-Then）。
- 「使いやすいこと」「高速に動くこと」のような曖昧な表現ではなく、確認できる結果で書きます。
-
例外・境界のケースを足す
- 取消、重複、上限超え、権限なし、締め後の修正など。正常系だけの受入基準は、本番で最初に困る箇所を外しています。
-
非機能要件を数字にする
- 応答時間、同時利用者数、データ件数、バックアップからの復旧時間などを、測れる形で書きます。
-
発注側と開発側で読み合わせ、合意の記録を残す
- 要件定義書の承認と同じタイミングで、受入基準にも承認をもらいます。以降の変更は仕様変更として管理します。
ステップ3で「この場合はどうするか」を決められない例外が出てきたら、要件定義がまだ終わっていないサインです。受入基準を書く作業は、要件の抜け漏れを見つけるレビューも兼ねています。
受入基準テンプレート（Given-When-Then）
Given-When-Then は、BDD（振る舞い駆動開発）で使われる受入基準の書き方です。Dan North は2007年の記事で、受入基準をシナリオとして書くと「完了」の意味を関係者でそろえられると説明しています。自動テストを書かないプロジェクトでも、文章の型としてそのまま使えます。
| 要素 | 書くこと | 注意点 |
|---|---|---|
| Given（前提） | 操作前の状態・データ・権限 | 必要な前提だけ。書かない前提は暗黙の仮定になる |
| When（操作） | 利用者が行う操作 | 原則、1シナリオに1操作 |
| Then（結果） | 確認できる結果 | 画面表示だけでなく、データ・通知・ログも |
テンプレート（要件定義書の各要件に添える形）：
### AC-[番号]：[シナリオ名]
- 対応する要件：[要件ID]
- 利用者：[役割]
- 目的：[この操作で達成したいこと]
Given [前提となる状態・データ・権限]
And [追加の前提]
When [利用者の操作]
Then [確認できる結果]
And [データ・通知・ログなどの結果]
- 判定者：[発注側の担当者]
- 重要度：[必須／重要／任意]
記入例（架空の施設予約システム）：
### AC-012：締め後の予約取消（締め解除権限なし）
- 対応する要件：REQ-034（予約の取消）
- 利用者：窓口担当者
- 目的：締め済みの月の予約が、権限のない担当者に取り消されず、金額が変わらないこと
Given 10月分の月次締めが完了している
And 10月20日の予約が「利用済」になっている
And ログイン者は窓口担当者権限（締め解除権限なし）である
When その予約の取消ボタンを押す
Then 「締め済みのため取消できません。管理者に依頼してください」と表示される
And 予約の状態と金額は変わらない
And 操作ログに取消の試行が記録される
- 判定者：業務部門の窓口リーダー
- 重要度：必須
非機能要件も同じ型で書けます。例えば「Given 予約データが10万件ある、When 利用日で検索する、Then 3秒以内に一覧が表示される」です（数字は案件ごとに合意して決めます）。
| Before（よくある書き方） | After（受入基準） |
|---|---|
| 予約を取消できること | 締め前・締め後、権限あり・なしで、それぞれの結果を書く |
| 検索が高速であること | データ件数と条件を決め、秒数で書く |
| エラー時は適切に表示すること | 表示する文言と、データが変わらないことを書く |
受入テスト計画で決めること
受入基準があっても、「誰が、いつ、どう判定するか」が決まっていなければ受入テストは回りません。要件定義の終わりまでに、次の項目を受入テスト計画の骨子として決めておきます。
| 項目 | 決めること | 決めないと起きること |
|---|---|---|
| 体制 | 発注側の実施者と判定者、兼務の割合 | 通常業務に押されてテストが進まない |
| 期間 | 実施期間、修正と再テストの周回数 | 指摘が後半に集中し、リリースが遅れる |
| 環境とデータ | 本番相当のデータ件数、個人情報のマスキング | 本番で初めて性能問題が出る |
| 指摘の分類 | 不具合／仕様変更／要望の切り分け方と決定者 | すべてが「不具合」として無償対応を求められる |
| 合格判定 | 必須の受入基準がすべて合格、などの判定条件 | 終わりが決まらず検収が延びる |
契約との関係
請負契約では、受入テストの合格が検収につながるのが一般的です。2020年4月施行の改正民法で「瑕疵担保責任」は「契約不適合責任」に変わり、民法上は、注文者が不適合を知った時から1年以内に通知すれば足りるとされました。一方、IPA・経済産業省のモデル契約の見直しでは、責任を負う期間を契約で個別に定め、その起算点を「検収完了時」とする考え方が維持されています。実際の期間や起算点は、個々の契約の定めによります。
このように検収完了時が責任期間の起算点になる契約では、「何を確かめて検収したか」を記録として残せる受入基準は、発注側・開発側の双方に意味があります。契約の条文そのものは案件ごとに法務や専門家と確認してください。ここでおすすめするのは、「受入基準を検査仕様の中身として使う」という使い方だけです。
要件定義の終わりに確認するチェックリスト
- 業務シナリオが、日次・月次・年次と周辺業務（代理入力・締め後の修正）まで列挙されている
- すべての必須要件に、Given-When-Then の受入基準が1つ以上ある
- 取消・重複・上限超え・権限なしのケースが含まれている
- 「使いやすい」「高速」「適切に」などの曖昧な表現が残っていない
- 非機能要件が、件数・秒数・時間などの数字で書かれている
- 受入テストの実施者・判定者・期間が決まっている
- 指摘を不具合／仕様変更／要望に分けるルールと決定者が決まっている
- 受入基準に発注側の承認をもらい、記録を残している
まとめ
受入テストの質は、テスト工程に入る前にほぼ決まっています。要件を一つ合意するたびに「何ができたら合格か」を Given-When-Then で書き、例外ケースを足し、非機能要件を数字にし、体制と期間を計画に入れる。これで、受入テストは「動作確認会」から「合否を判定する場」に変わります。
受入基準を書くと、要件の抜け漏れも早く見つかります。次の案件では、要件定義書の各要件に AC 番号の欄を1つ足すところから始めてみてください。