アジャイル開発では、**ユーザーストーリー（User Story）**が基本的な単位として使われます。
その中で「何をもって完了とするのか？」を明確にするのが、**受け入れ条件（Acceptance Criteria）**です。
この記事では、ISTQB Foundation 4.0のシラバス第4章「Test Analysis and Design」セクション4.5「Collaboration-based Test Approaches」で紹介されている
受け入れ条件の考え方・書き方・実践例をわかりやすくまとめます。
🔍 Acceptance Criteria（受け入れ条件）とは？
**Acceptance Criteria（受け入れ条件）**とは、
「ユーザーストーリーが完了とみなされるために満たすべき条件」を指します。
簡単に言うと：
“この条件を満たせば、このストーリーは完了（＝Done）とみなせる”
という明確なゴールラインを設定することです。
これは単に開発者のためだけでなく、テスターやプロダクトオーナー、ビジネス側の理解を一致させるための共通基準として非常に重要です。
💡 ユーザーストーリーと受け入れ条件の関係
ユーザーストーリーは通常、次のようなテンプレートで書かれます：
As a [ユーザーの種類],
I want to [実現したいこと],
so that [得られる価値・目的].
しかしこのままだと曖昧で、テスト可能な状態ではありません。
そのために「受け入れ条件」を追加し、ストーリーの範囲を明確にします。
✅ 例：ログイン機能のユーザーストーリーと受け入れ条件
ユーザーストーリー：
As a registered user,
I want to log in to my account,
so that I can access my personal dashboard.
受け入れ条件の例：
-
正しいユーザー名とパスワードでログインできること
-
間違ったパスワードを入力した場合、「認証エラー」が表示されること
-
ログイン後、ユーザーの名前が表示されること
-
「パスワードを忘れた」リンクが正しく機能すること
これらの条件をすべて満たしたとき、初めて「このユーザーストーリーは完了」と判断できます。
🧩 Acceptance Criteriaが重要な理由
-
ストーリーの範囲を明確にする
→ 何を実装すべきか・何を除外すべきかを全員が理解できる。
-
テストケース設計の基礎になる
→ テスターは受け入れ条件を「テスト条件」として扱える。
-
関係者間の合意を形成できる
→ 「これができたらOK」という共通認識を作る。
-
見積もり精度を高める
→ 明確な基準に基づき、開発時間やテスト工数を見積もれる。
-
ユーザー受け入れテスト（UAT）の基準となる
→ ビジネス担当者もこの条件で受け入れ判断ができる。
✍️ Acceptance Criteriaの書き方（2つの代表的フォーマット）
① シナリオ形式（Scenario-Oriented Format）
BDD（Behavior-Driven Development）でよく使われる「Given-When-Then」形式です。
例：
Given ユーザーが正しい資格情報を持っている
When ログインボタンをクリックする
Then ダッシュボードが表示される
👉 明確・簡潔・自動テスト（Cucumberなど）への転用も容易です。
② ルール（チェックリスト）形式
シンプルに箇条書きで記述します。
例：
-
正しいID/PWでログインできる
-
無効なID/PWではエラーメッセージが表示される
-
3回連続で失敗したらアカウントをロックする
👉 小規模チームや非技術者が関わる場合に適しています。
⚠️ よくある“あいまいな”受け入れ条件の例と改善方法
❌ あいまいな例：
「ログインはすべての主要ブラウザで動作すること」
この「主要ブラウザ」という表現は人によって異なります。
テスターにとっては「テスト不可能（Non-Testable）」です。
✅ 改善後：
「ログイン機能は、Chrome（最新版）、Safari（最新版）、Firefox（最新版）で動作すること」
👉 具体的・測定可能・テスト可能！
❌ 別の例：「システムのパフォーマンスは最高であること」
「最高」とは何を指すのでしょう？曖昧すぎます。
✅ 改善後：
「100ユーザー同時アクセス時に、レスポンスタイムが2秒以内であること」
👉 測定可能な数値を使って“達成可能な基準”にします。
🧠 テスターが確認すべきポイント
テスターはストーリーを受け入れる前に、次を必ずチェックしましょう：
-
明確か？（Unambiguous）
→ 曖昧な表現がないか確認。
-
テスト可能か？（Testable）
→ 実際にテストで確認できる内容か？
-
達成可能か？（Achievable）
→ 現実的な範囲で実現可能か？
-
完了基準があるか？（Done Criteria）
→ チーム全員が同意できる完了定義になっているか？
🧭 まとめ
|
項目 |
内容 |
|---|---|
|
定義 |
ユーザーストーリーを完了とみなすための条件 |
|
目的 |
明確なゴール設定と共通理解の形成 |
|
書き方 |
「Given-When-Then」形式 または チェックリスト形式 |
|
注意点 |
曖昧・非テスト可能な表現を避ける |
|
テスターの役割 |
受け入れ条件のレビューとテスト可能性の確認 |
📚 まとめの一言
「曖昧な受け入れ条件は、曖昧な結果しか生まない。」
受け入れ条件は、単なる「開発完了のチェックリスト」ではありません。
**チーム全員で共有する“共通の理解”**を形にしたものです。
開発者・テスター・POが協力して、明確でテスト可能な受け入れ条件を作ることが、
高品質なソフトウェアの第一歩です。
コメント