受け入れ基準：書き方と実例
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
受け入れ基準とは、チームがリリース可能と判断するためにユーザーストーリーが満たすべき条件のことです。適切に設定すれば、手戻り、認識のズレ、レビュー時の予期しないバグを大幅に減らすことができます。
受け入れ基準とは何か？
受け入れ基準とは、1つのユーザーストーリーに紐づく、具体的でテスト可能な条件の集合です。ユーザーの視点から見て、機能が何をすべきか（そして何をしてはいけないか）を定義します。すべての条件をクリアすればストーリーは承認され、1つでも失敗すれば作業を継続します。
機能を依頼した人と、それを構築するチームとの間の契約のようなものです。推測も「そういう意味だとは思わなかった」という言い訳も不要です。開発開始前に書かれた、合否が明確な条件のリストがあるだけです。
受け入れ基準はストーリーレベルで設定します。「このストーリーが完了したとわかるのはどんなときか？」という問いに答えるものです。「スプリントが完了したとわかるのはどんなときか？」という問いとは別で、そちらはDefinition of Doneが答えます。
重要なポイント
- Given-When-Then形式の受け入れ基準は、Dan Northが2006年頃に振る舞い駆動開発（BDD）の一環として紹介したもので、チームが期待する振る舞いを構造的かつテスト可能な形で表現できるようになりました。（出典：Dan North、「Introducing BDD」、dannorth.net、2006年）
- Agile Allianceは、曖昧または欠落した受け入れ基準がAgileプロジェクトにおける手戻りの最も一般的な原因の1つであると指摘しています。（出典：Agile Alliance Glossary、agilealliance.org）
- 受け入れ基準をコーディング前に作成するチームは、テスターが何を検証すべきかを事前に把握しているため、開発からQAへの引き渡しが迅速になると報告しています。
受け入れ基準の記述形式
主に2つの形式が使われています。どちらが優れているとは一概に言えません。チームのやり方に合ったものを選びましょう。
Given-When-Then（シナリオ形式）
Gherkin形式とも呼ばれるこの形式は、振る舞い駆動開発（BDD）に由来します。各条件を3つの部分で構成されるシナリオとして記述します。
- Given（前提） - 出発状態または文脈
- When（操作） - ユーザーが行うアクション
- Then（結果） - 期待される結果
実例 - ユーザーログイン：
Given 登録済みのユーザーがログインページにいる場合
When 有効なメールアドレスと正しいパスワードを入力し「サインイン」をクリックすると
Then ダッシュボードにリダイレクトされ、ウェルカムメッセージが表示される
Given 登録済みのユーザーがログインページにいる場合
When 有効なメールアドレスと誤ったパスワードを入力すると
Then 「メールアドレスまたはパスワードが正しくありません」というエラーメッセージが表示され、ログインページに留まる
この形式は、動作が順序立てて進む場合や、ハッピーパスと並行して複数の失敗シナリオを記述できる場合に適しています。QAエンジニアは各シナリオをそのままテストケースに転換できます。
ルールベース（チェックリスト形式）
よりシンプルな箇条書きリストを好むチームもあります。条件が順序立てではなく独立している場合に適した形式です。
実例 - 商品検索：
- どのクエリに対しても検索結果が2秒以内に表示される
- デフォルトでは結果が関連度順にソートされる
- ユーザーはカテゴリ、価格帯、評価でフィルタリングできる
- 検索結果がない場合、「[クエリ]に一致する結果がありません。別のキーワードをお試しください。」と表示される
- 結果が読み込まれた後も、検索バーにはユーザーのクエリが表示され続ける
ルールベースの受け入れ基準は書きやすく、見やすいです。UIの制約、パフォーマンス要件、ユーザーの操作フローに綺麗に当てはまらないエッジケースに最適です。
受け入れ基準とDefinition of Done
この2つの概念はよく混同されますが、解決する問題が異なります。
| 受け入れ基準 | Definition of Done | |
|---|---|---|
| 対象範囲 | 1つのユーザーストーリー | すべてのストーリー、すべてのSprint |
| 誰が書くか | Product Ownerとチームが協力して | チーム全員が一緒に |
| いつ書くか | 開発開始前 | プロジェクトまたはSprintサイクルごとに1回 |
| カバーする内容 | この機能に対する機能的な条件 | テスト、レビュー、ドキュメントなどの品質基準 |
| 失敗した場合 | そのストーリーは承認されない | Sprint内のどのストーリーもリリースされない |
ストーリーはすべての受け入れ基準をクリアしても、Definition of Doneで不合格になる場合があります。たとえば、ユニットテストがない場合やピアレビューが未実施の場合がそれに当たります。作業が真に完了するためには、両方のリストをクリアする必要があります。
詳しくはDefinition of Doneの記事をご覧ください。
良い受け入れ基準の特徴
すべての条件リストが良い受け入れ基準になるわけではありません。役立つものと曖昧なものを分けるポイントを示します。
テスト可能であること。 各条件には明確な合否がなければなりません。「UIが見た目に良い」はテストできません。「ボタンのコントラスト比が4.5:1を満たしている」ならテスト可能です。
ユーザーの視点で書かれていること。 受け入れ基準は、コードの構造ではなく、ユーザーが体験する内容を記述します。「APIが200のステータスを返す」のような実装の詳細は避けましょう。「ユーザーが更新されたプロフィールをすぐに確認できる」が適切な表現です。
具体的であること。 数値、状態、ラベルが重要です。「高速なレスポンス」は「1.5秒未満のレスポンス」に。「エラーメッセージ」は「正確なテキスト：『パスワードは8文字以上必要です。』」に。
開発開始前に合意されていること。 機能が構築された後に書かれた基準は、必要だったものではなく構築されたものを合理化しがちです。Backlog Refinementの際に書きましょう。
多すぎないこと。 3〜8個が適切な範囲です。15個の受け入れ基準があるストーリーは、おそらく2〜3個のストーリーが1つに詰め込まれています。
受け入れ基準の書き方
ステップ1：ユーザーストーリーから始める
明確なユーザーストーリーなしに受け入れ基準は書けません。次の形式で記述されていることを確認してください。
[ペルソナ]として、[目標]したいので、[理由]。
ストーリーが曖昧な場合は、条件を書く前にストーリーを明確にしましょう。
ステップ2：「これが機能するために何が真でなければならないか？」を問う
機能が生み出すべき動作と結果をリストアップします。まずハッピーパスを、次にエッジケースと失敗状態をカバーします。
ステップ3：形式を選ぶ
動作が順序立てていてQAがテスト作成を主導する場合はGiven-When-Thenを選びます。条件が独立しているか、時間的プレッシャーがある場合はルールベースを選びます。
ステップ4：テスト可能な言葉で書く
曖昧な言葉を置き換えます。「素早く」は数値に。「適切にフォーマットされた」は正確な形式に。「モバイルで動作する」は「幅375pxでレイアウトがレスポンシブ対応している」に。
ステップ5：開発開始前にチームでレビューする
開発者、QA、ステークホルダーと下書きを共有します。開発者は技術的に不可能な条件を見つけます。QAは欠落したエッジケースを見つけます。ステークホルダーはビジネスロジックのエラーを見つけます。コードが1行も書かれる前に全員が合意できるよう、Backlog Refinementやスプリントプランニングの際に行いましょう。
ステップ6：ストーリーに添付する
最終的な基準をProduct Backlogのストーリーに追加します。開発中はずっとそこに添付され、スプリントレビューの際にチームが使うチェックリストになります。
受け入れ基準の実例
異なるストーリーの種類にわたる3つの実例を示します。
実例1：ユーザーログイン
ストーリー： 既存ユーザーとして、自分のアカウントにアクセスするためにメールアドレスとパスワードでサインインしたい。
Given ユーザーがサインインページにいる場合
When 登録済みのメールアドレスと正しいパスワードを入力し「サインイン」をクリックすると
Then 2秒以内にダッシュボードにリダイレクトされる
Given ユーザーが誤ったパスワードを3回入力した場合
When 4回目のログインを試みると
Then アカウントが30分間ロックされ、次のメッセージが表示される：
「ログイン試行が多すぎます。30分後にもう一度お試しください。」
Given ユーザーがサインインしている場合
When 「サインアウト」をクリックすると
Then セッションが終了し、ホームページにリダイレクトされる
実例2：注文合計
ストーリー： 買い物客として、支払い前に注文合計を確認したいので、正確な金額を把握できる。
| 条件 | 合格の条件 |
|---|---|
| 小計が表示される | 明細項目の合計が正確に計算される |
| 税金が明細化される | 税率と金額が別々に表示される |
| 割引が適用される | プロモコードが税前の小計を減額する |
| 送料が表示される | 費用が表示される、または対象の場合は「送料無料」と表示される |
| 合計がリアルタイムで更新される | カートの変更時にページリロードなしで合計が再計算される |
実例3：検索結果なし
ストーリー： ユーザーとして、検索で何も結果が出なかった場合に別のキーワードを試せるよう、その旨を知りたい。
- 検索結果がゼロの場合、「'[クエリ]'に一致する結果がありません。別のキーワードをお試しください。」と表示される
- 検索バーにはユーザーの元のクエリが表示され続ける
- 利用可能な場合、メッセージの下に関連するカテゴリの提案が表示される
- ページタイトルが空の検索状態を反映して更新される
避けるべき一般的なミス
後付けで書く。 開発後に書かれた受け入れ基準は、必要なものではなく構築されたものを記述します。先に書きましょう。
エラー状態を曖昧にする。 ハッピーパスのみの基準は、開発者に障害処理を推測させます。必ず少なくとも1つの失敗シナリオを含めましょう。
技術的な実装を混在させる。 「サービスがPOSTリクエストで決済APIを呼び出す」は受け入れ基準ではありません。「ユーザーが3秒以内に支払い確認を確認できる」が正しい表現です。
大きすぎる内容にする。 受け入れ基準が複数の異なる機能をカバーしている場合は、ストーリーを分割しましょう。適切な基準を持つ良いストーリーはインデックスカードに収まります。
チームレビューを省略する。 単独（通常はProduct Owner）で書かれた基準は、開発者の制約とQAのエッジケースを見落とします。Sprint開始前に一緒にレビューしましょう。一貫して行うためにはAgile CeremoniesのようなRefinementを活用しましょう。
よくある質問
受け入れ基準とは何ですか？
受け入れ基準とは、チームがユーザーストーリーを完了と認めるために満たすべき、具体的でテスト可能な条件のことです。ユーザーの視点から機能が何をすべきかを定義し、開発開始前に書かれます。
誰が受け入れ基準を書きますか？
通常はProduct Ownerが受け入れ基準の下書きを作成しますが、開発者、QA、時にはステークホルダーを含むチーム全員が開発開始前にレビューして洗練させます。単独で基準を書くと、エッジケースの見落としや手戻りが発生します。
受け入れ基準とDefinition of Doneの違いは何ですか？
受け入れ基準はストーリーごとのものです。1つの特定の機能が何をすべきかを記述します。Definition of Doneはグローバルなものです。Sprint内のすべてのストーリーに適用されるチェックリスト（ピアレビュー、テストカバレッジ、ドキュメントなど）です。ストーリーがリリースされる前に両方をクリアする必要があります。
Given-When-Thenとは何ですか？
Given-When-Thenは、受け入れ基準をテスト可能なシナリオとして書くための構造化された形式です。「Given」は文脈を設定し、「When」はユーザーのアクションを記述し、「Then」は期待される結果を述べます。Dan Northが2006年頃に振る舞い駆動開発（BDD）の一環として導入し、今日のAgileチームで広く使われています。
ユーザーストーリーの受け入れ基準はいくつが適切ですか？
3〜8個を目安にしましょう。3個未満は仕様が不十分なことが多く、8個を超える場合はストーリーが大きすぎるため、より小さいストーリーに分割する必要があります。
適切な受け入れ基準は優れた製品を保証するものではありませんが、誰も意図しないものを作り上げるという特定の失敗を防ぎます。早めに書き、チームで一緒にレビューすれば、スプリントレビューが「完了」の意味をめぐる議論から、実際に動くソフトウェアを素直に披露する場に変わっていくでしょう。
Senior Operations & Growth Strategist