受入基準の書き方｜「誰が・何を・どこまで」で手戻りを防ぐ実務テンプレート

受入テスト直前に認識がズレる理由

「受入基準は書いたのに、顧客が別の解釈をして手戻りになった」。これは、受託開発のPMがリリース直前に直面する、最も消耗するパターンのひとつです。

なぜこうなるのか。多くの場合、受入基準の書き方に問題があります。例えば「〇〇機能が正常に動作すること」や「ユーザーが問題なく操作できること」といった表現は、一見すると基準のようですが、合否を誰が・どのような状態で判定するかが定義されていません。

結果として、PMはパスしたと思っていても、顧客は「思っていた動きと違う」と言い出す。開発チームは仕様通りに作ったのに、テスト結果が覆される。関係者全員が疲弊する手戻りが発生します。

この記事では、受入基準を機能単位で「誰が・何を・どこまで」の3軸で書くテンプレートを紹介します。曖昧さを排除した文章形式で、受入テスト前に顧客と合意を取れる状態を作ることが目的です。

受入基準が現場で機能しなくなるのは、たいてい以下の3つのいずれかが原因です。

原因1：判定者が「誰でもいい」になっている

本来は「誰が確認しても同じ結果になる」ように書くべきですが、「顧客担当者が確認する」といった曖昧な記述にとどまり、判定者が暗黙のうちに省かれているケースです。実際には、担当者によって合否の判断が変わるケースが後を絶えません。

原因2：確認対象が「機能名」で止まっている

「ログイン機能」や「検索機能」のように機能名だけを対象にすると、何をどこまで確認するのかが決まりません。正常系だけなのか、異常系も含むのか、パフォーマンスも対象なのか、各自の解釈に委ねられてしまいます。

原因3：合否の基準が感覚的になっている

「問題なく動作する」や「スムーズに操作できる」といった表現は、具体的な数値や状態に変換されていません。何秒以内に応答するか、エラーメッセージは何を表示するか、境界値でどう動くかが書かれていないと、合否判断が担当者の感覚に依存します。

「誰が・何を・どこまで」の3軸フレームワーク

受入基準を書くときは、以下の3軸を必ず埋める形式にします。

軸	定義	書き方のポイント
誰が	判定者・確認実施者	役職や担当者名で具体的に指定する
何を	確認対象の操作・状態	機能名ではなく「〇〇の操作をしたとき」と動詞で書く
どこまで	合否の判定条件	数値・状態・メッセージで定義する

この3軸を埋めると、受入基準は自然と「誰が読んでも同じ結果になる文章」になります。

機能単位の受入基準テンプレート

以下が基本テンプレートです。機能ごとにシートの行を1つ使う想定で設計しています。

【機能名】
  対象機能 : ________________

【受入基準】
  誰が    : ________________（例：顧客側業務担当者Aさん）
  何を    : ________________（例：〇〇の操作を実行したとき）
  どこまで : ________________（例：〇〇の状態になること／〇秒以内に応答すること）

【確認方法】
  テスト手順 : ________________
  使用データ : ________________

【合否判定】
  合格条件 : ________________
  不合格条件 : ________________

【確認者サイン欄】
  確認日 :　　　　　　確認者 :

このテンプレートのポイントは、「確認者サイン欄」を設けることです。受入テストは書類上の合意ではなく、担当者が実際に操作して確認したという行為の記録として残します。

記述例

曖昧な書き方と改善後の書き方を機能ごとに並べて示します。

ログイン機能

曖昧な書き方（NG例）

ログイン機能が正常に動作すること

改善後（「誰が・何を・どこまで」形式）

【機能名】
  対象機能 : ログイン機能

【受入基準】
  誰が    : 顧客側システム管理者（山田さん）
  何を    : 登録済みのID・パスワードを入力してログインボタンを押したとき
  どこまで : ダッシュボード画面が3秒以内に表示されること

【確認方法】
  テスト手順 : テストデータ「user01 / Pass1234!」を使って操作する
  使用データ : 本番同等のステージング環境

【合否判定】
  合格条件 : ダッシュボード画面が表示され、ログインユーザー名が正しく表示される
  不合格条件 : 画面遷移しない、エラーメッセージが表示される、3秒を超える

帳票出力機能

改善後（「誰が・何を・どこまで」形式）

【機能名】
  対象機能 : 月次売上帳票の出力

【受入基準】
  誰が    : 顧客側経理担当者（鈴木さん）
  何を    : 帳票画面で対象月を選択して「PDF出力」ボタンを押したとき
  どこまで : A4縦レイアウトのPDFが10秒以内にダウンロードされ、
             ヘッダーに会社名・対象年月が表示されていること

【確認方法】
  テスト手順 : 2026年4月分を選択して出力する
  使用データ : テスト環境に投入済みの4月分サンプルデータ

【合否判定】
  合格条件 : PDFが正常にダウンロードされ、数値がサンプルデータと一致する
  不合格条件 : ダウンロードされない、レイアウトが崩れている、数値が一致しない

実務での活用ポイント

顧客と合意するタイミング

テンプレートを作るだけでは不十分です。いつ・どのように顧客と合意するかがセットで重要です。

推奨するタイミングは2段階です。

設計工程の完了時：機能仕様が固まった段階で受入基準ドラフトを作成し、顧客の合意を取る。この段階で「どこまで」の数値・条件が決まらない項目は、受入基準として認めない。
受入テスト開始の1週間前：最終版の受入基準を顧客担当者と読み合わせ、判定者・確認手順・使用データを全項目確認する。ここで認識のズレがあれば、テスト前に解消できます。

この2段階の合意プロセスを守るだけで、受入テスト直前の認識ズレによる手戻りは大幅に減ります。品質ゲートの設計論については受入基準とリリース延期を止める品質ゲート設計の実務で詳しく解説しています。