受入基準の書き方｜曖昧な要件を合否が分かる条件へ変える
「使いやすくする」「正しく表示する」だけでは、実装者と確認者で合格の判断が変わります。受入基準は、対象の機能や成果物が満たすべき状態を、確認できる条件へ変えたものです。
この記事は説明用の申請機能を使った一般解説です。数値や条件をそのまま別のシステムへ適用せず、利用者の要求、規程、技術条件に合わせて合意してください。
結果の条件と、作業方法を分ける
「テストを実施する」は作業です。「必須項目が空欄なら申請できず、対象項目へ案内を表示する」は結果の条件です。受入基準には、利用者や確認者が何を観察すれば合否を判定できるかを書きます。
実装方式は別に制約がある場合を除き、技術設計で検討できます。基準へ不要な方式指定を入れると、目的を満たす別の実装を排除してしまいます。
正常・例外・権限の三方向で確かめる
| 要件候補 | 受入基準の説明用例 | 確認する条件 |
|---|---|---|
| 申請できる | 必須項目を入力した利用者が、一件の申請を登録できる | 事前状態・入力・保存結果 |
| 入力不足を知らせる | 必須項目が未入力なら登録せず、対象項目を表示する | 未入力の項目ごとの挙動 |
| 状況を確認できる | 申請者が自分の申請状況を確認できる | 利用者と申請の対応 |
| 権限を守る | 閲覧権限がない利用者へ申請内容を表示しない | URL直接指定等を含む確認 |
| 二重登録を防ぐ | 合意した重複操作の条件で、重複申請を作らない | 二重操作の定義と結果 |
「二重登録を防ぐ」も、条件を詰めないままでは曖昧です。どの操作、どの時間範囲、どの識別条件を重複とするかを担当者と合意します。この表は観点を示すもので、網羅的な安全確認ではありません。
数値条件には、測る環境と方法を添える
「応答が速い」を数値へ置き換える場合、閾値だけでは不十分です。何の応答を、どの端末・接続・データ量・同時利用条件で測るのか、どの方法と回数で判定するかをそろえます。
数値が未合意なら、勝手に目標を作らず未決事項にします。誰が事業上の必要性を判断し、誰が技術的な成立性を確認するかを置きます。表示だけ速くても保存が終わっていない場合など、観測する状態の違いにも注意してください。
見た目や文章の適切さなど、完全には機械判定できない基準もあります。その場合も、確認者・対象範囲・レビュー観点・承認方法を具体化すると、個人の好みに引っ張られにくくなります。
個別の受入基準と、共通の完了基準を区別する
ある機能に固有の挙動を示す受入基準と、全体で共通に守る完了基準は別に管理すると整理しやすくなります。たとえば「申請者だけが自分の状況を見られる」は個別の条件、「必要なレビューと確認記録が揃っている」は共通の完了条件です。
スクラムのDefinition of Doneは、インクリメントが製品に必要な品質の尺度を満たす状態の正式な記述です。Scrum Guide公式で定義を確認できます。個別の受入基準と同義に置き換えず、チームで何を対象にした条件かを確認してください。
受入基準を満たしていても、必要な運用準備や共通の品質確認が終わっていなければ、そのまま本番へ出せるとは限りません。機能の合否と、リリース全体の可否を分けます。
変更した条件は、確認結果へ反映する
受入基準を追加・変更したら、要件の版、対応する確認項目、確認済み結果に影響があるかを追います。旧条件で通ったテストを、新条件にも合格したように見せないことが大切です。
基準ID 要件ID 事前状態 操作・入力 期待結果 例外 確認方法 判断者 対象版 合意状態合否が曖昧な一項目を選び、「どの状態で、何をしたら、何が確認できるか」へ書き直してみてください。実装者と確認者が同じ条件を読んで合否を話せるかが、見直しの目安です。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
受入基準の検証可能性・結果重視という概念を確認しました。本文では個別基準と共通の完了基準を区別しています。 Atlassian：Acceptance Criteria（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
課題管理表の作り方も必要な作業に合わせて参照してください。
アイキャッチ写真：2H Media / Unsplash。職場の実写ではなくイメージ写真です。
