ユーザーストーリーと受け入れ基準
「誰が・何を・なぜ」で要求を表現するユーザーストーリーと、完了を判断する受け入れ基準の書き方を学ぶ
ユーザーストーリーの基本フォーマット
ユーザーストーリーは、要求を 「誰が・何を・なぜ」の視点で簡潔に表現する記法です。仕様の詳細をすべて書くのではなく、 対話のきっかけとなる短い文章として使われます。
As a <ユーザーの役割>
I want <実現したいこと>
So that <その理由・得られる価値>
例:
As a ネットショップの利用者
I want 過去の注文履歴を確認したい
So that 同じ商品を再注文する際に商品を探す手間を省きたいポイント
「So that」の部分（なぜ欲しいのか）を省略しないことが重要です。理由が明確であれば、 実装方法に迷ったときにチームが「その理由に立ち返って」最適な判断を下せます。
良いストーリーの条件（INVEST）
ユーザーストーリーの質を見極める指針として、INVESTという頭文字の原則がよく使われます。
I - Independent（独立している）
他のストーリーへの依存が少なく、単独で着手できる
N - Negotiable（交渉可能である）
実現方法は固定せず、対話を通じて詳細を詰められる
V - Valuable（価値がある）
利用者やビジネスにとって明確な価値がある
E - Estimable（見積もり可能である）
大きさや複雑さをチームが見積もれる程度に具体的
S - Small（小さい）
1イテレーション内に余裕をもって収まる大きさに分割されている
T - Testable（テスト可能である）
完了したかどうかを検証する方法が存在する
受け入れ基準の書き方（Given-When-Then）
受け入れ基準は、そのストーリーを 「完了」とみなすための具体的な条件です。Given-When-Then形式で書くと、 前提・操作・期待結果が明確になり、関係者間の認識齟齬を防げます。
ストーリー: 過去の注文履歴を確認したい
受け入れ基準1:
Given ログイン済みのユーザーに過去1件以上の注文がある
When 注文履歴ページを開く
Then 注文日・商品名・金額が新しい順に一覧表示される
受け入れ基準2:
Given ログイン済みのユーザーで過去の注文が0件である
When 注文履歴ページを開く
Then 「注文履歴はありません」というメッセージが表示される
受け入れ基準3:
Given 未ログインのユーザーである
When 注文履歴ページのURLに直接アクセスする
Then ログインページにリダイレクトされる正常系だけでなく、データが0件の場合や未ログインの場合など、境界値・異常系の受け入れ基準も書いておくことで、 実装時の考慮漏れやテストの抜けを防ぐことができます。
大きすぎるストーリーの分割
1つのストーリーが大きすぎると、見積もりの精度が下がり、1スプリント内に完了しにくくなります。 代表的な分割の切り口を紹介します。
ワークフローの手順で分割
「注文する」を「カートに入れる」「配送先を入力する」「決済する」に分割する
パターン・ケースで分割
「クレジットカード決済」と「コンビニ決済」を別ストーリーにする
CRUD操作で分割
「一覧表示」「新規作成」「編集」「削除」を別ストーリーとして扱う
性能要件を切り出す
まず動くものを作り、性能改善は別ストーリーとして後続で扱う
ポイント
- • ユーザーストーリーは「As a / I want / So that」で誰が・何を・なぜを表現する
- • 「So that」の理由を省略しないことで、実装判断の拠り所になる
- • 良いストーリーの条件はINVEST（独立・交渉可能・価値・見積もり可能・小さい・テスト可能）
- • 受け入れ基準はGiven-When-Thenで前提・操作・期待結果を明確にする
- • 正常系だけでなく境界値・異常系の受け入れ基準も書く
- • 大きすぎるストーリーはワークフロー・パターン・CRUD等の切り口で分割する
確認クイズ
1 / 3ユーザーストーリーで「So that（なぜ）」を書く目的として最も適切なものはどれか？