ユーザーストーリーは目的を示し、受け入れ条件は完成を確認する基準を示します。
例
ストーリー:
受講生として、提出済み課題を一覧で確認したい。
次に取り組む課題を判断するため。
受け入れ条件:
- 自分の課題だけが表示される
- 提出日時の新しい順に並ぶ
- 0件なら空状態の案内が出る
- 読み込み失敗時に再試行できる
実装方法を書きすぎない
ストーリーにDB名やフレームワークを固定すると、目的より手段が先になります。技術制約が必要なら別に記録します。
テスト可能にする
「使いやすい」のような条件だけでは完了を判断できません。誰が見ても確認できる表示や動作へ分けます。
例外も含める
正常時だけでなく、0件、権限なし、通信失敗、重複操作を必要に応じて書きます。
ケーススタディ：提出一覧を仕様へ変える
「受講生として提出済み課題を見たい」というストーリーから、すぐに一覧画面を実装してはいけません。目的が「次に取り組む課題を判断するため」なら、提出済みだけでなく未提出の課題も必要かもしれず、単なる履歴閲覧とは完成像が異なります。最初に利用者へ、一覧を見た後に何を決めるのか、現在は何に困るのか、講師の一覧と同じ情報でよいかを確認します。
対話の結果、今回の範囲を「自分が提出した課題の受付状況を確認する」に限定したとします。受け入れ条件には、自分の提出物だけが新しい順で表示される、受付中・確認中・差し戻しの状態が分かる、提出がない時は作成ボタンが示される、取得失敗時は再試行できる、と書けます。さらに権限境界として、別の受講生の識別子をURLへ指定しても内容を取得できないことを含めます。ここまで書けば、画面、API、テストの担当者が同じ完成条件を共有できます。
悪い例は「受講生として一覧画面が欲しい。見やすいテーブルにし、Reactでページングを実装する」です。目的が薄く、見やすさを判定できず、技術手段だけが固定されています。良い例は、利用者の判断をストーリーに残し、観測可能な結果を受け入れ条件へ分けます。ページング方式や部品名は、件数や性能制約を確認した後の設計判断として扱います。
条件を作る判断手順
まずストーリーの「誰が」を権限や利用状況まで具体化します。同じ受講生でも、初回利用者、提出済みの人、差し戻しを受けた人では必要な情報が違います。次に「何をしたい」を画面名ではなく行動で書き、「なぜ」をその後の判断や価値へつなげます。理由を削っても実装内容が変わらないなら、まだ本当の目的を聞けていない可能性があります。
受け入れ条件は正常系から書き、空状態、入力境界、権限違い、通信失敗、重複操作の順で必要性を判断します。すべての例外を機械的に追加するのではなく、起きる確率、利用者への損失、復旧の難しさで優先します。二重送信が課金を重複させるなら必須ですが、読み取り専用画面の再読み込みなら優先度は下がります。条件ごとに初期状態、操作、観測可能な結果が一意に読めるかを確認します。
最後に、各条件を誰がどこで確認するか割り当てます。並び順はAPIまたは画面のテスト、権限はサーバー側の結合テスト、主要操作はE2Eなど、最も小さい適切な場所を選びます。条件がテストへ変換できない場合は、「すぐに」「使いやすく」「適切に」のような曖昧語がないかを探し、秒数、表示内容、利用者が完了できる操作へ言い換えます。
失敗条件と観測方法
ストーリーが失敗している兆候は、実装後に「頼んだものと違う」という会話が起きることです。受け入れ条件を全部満たしても利用者の目的を達成できないなら、条件ではなくストーリーの理解が誤っています。逆に、目的は合っていても担当者ごとに完了判定が違うなら、条件が曖昧です。「高速に表示」「適切なエラー」「管理者は全部見られる」だけでは、測定方法や権限範囲を決められません。
観測には、レビューで出た解釈質問、実装中に追加された条件、受け入れ時の差し戻し理由、リリース後の問い合わせを使います。質問がUIの色や技術選択に偏るなら目的が伝わっていない可能性があり、権限や空状態の差し戻しが続くなら例外条件の洗い出しが不足しています。単に条件数を増やすのではなく、どの誤解を防げなかったかを振り返ります。
良い条件は、開発前の会話を終わらせる文書ではなく、会話で合意した具体例の記録です。実装中に新しい事実が分かったら、ストーリーの価値を保ったまま条件を更新し、変更理由を残します。すべてを最初に固定しようとすると、未知の仕様を推測で埋める失敗が起きます。「未決定」を明示し、誰がいつ決めるかを置く方が、偽の精密さより安全です。
よくある誤解：ストーリーは画面仕様書ではない
「利用者として一覧画面が欲しい」は、なぜ必要かがなく、完成後の価値を判断できません。「講師として未確認の提出を期限順に知りたい。対応漏れを防ぐため」のように、役割、目的、価値を結びます。テーブル、色、React部品は受け入れ条件ではなく、制約がなければ設計で決めます。ユーザーストーリーは会話を始める目的、受け入れ条件は会話の合意を検証できる例です。
受け入れ条件をテストケースの大量一覧にする必要もありません。損失が大きい権限境界、空状態、期限境界、重複操作から代表例を選びます。「見やすい」「速い」はそのまま判定できないため、表示項目や応答時間の条件へ変えます。
| 観点 | 条件に書く内容 | 書かない内容 |
|---|---|---|
| 初期状態 | 利用者、既存データ、権限 | 実装クラス名 |
| 操作 | 利用者が行うこと | 内部関数の呼び順 |
| 結果 | 画面、保存、通知 | 好みだけのUI指定 |
| 境界 | 空、期限直前、重複 | 起こり得ない網羅 |
| 非機能 | 測定可能な上限 | 「高速」「安全」だけ |
動作確認：別の人が同じ合否を出せるか
企画、実装、テストの三者が各条件を読み、初期データと期待結果を書き出します。解釈が割れた語は実装前に具体例へ変えます。完成後は正常系だけでなく、別利用者、空一覧、期限境界、二重送信を確認し、ストーリーの目的へ寄与しているかを受け入れます。
条件追加数だけを品質指標にしません。実装中の質問、受け入れ時の差し戻し、公開後の問い合わせを分類し、どの合意が不足したかを直します。良い条件は実装方法を固定せず、異なる実装でも同じ合否を判定できます。
まとめ
ユーザーストーリーと受け入れ条件の違いで大切なのは、用語を単独で暗記することではありません。期待、観測、差分、仮説、操作、結果を順に残し、テーマに合う証拠で判断します。小さく確認し、再現できる説明を残すことが、修正と学習の両方を次へつなげます。
参考リソース
条件を会話で磨く例
「受講生として提出をやり直したい。誤ったファイルを直すため」というストーリーに対し、最初の会話で採点前だけか、期限後も可能か、旧提出を残すか、講師へ通知するかを尋ねます。すべてを一度に実装せず、利用者損失と運用上の必要性で今回の範囲を決めます。
条件は「未採点かつ期限内の本人が新しいファイルを送ると、現在の提出が更新され、旧版は履歴として講師だけが読める」のように観測可能にします。別受講生、採点済み、期限後では更新を拒否し、元データが変わらないことも重要です。拒否文言の詳細はデザイン規約へ委ねても、利用者が次の行動を理解できるという結果は残します。
実装中にファイル容量上限が未定と分かったら、開発者が推測で決めず会話へ戻します。決まった条件をストーリーへ無制限に追記せず、共通アップロード規約に属するならリンクします。重複する条件を一か所で管理すると変更時の不一致を防げます。
受け入れ時には作成者だけでなく、実際の利用役割に近い人が操作します。条件を満たしても目的である誤提出の回復が難しいなら、ストーリーの価値を満たしていません。形式的なチェックと利用者の目的を両方確認します。
