ユーザーストーリーとは？
ユーザーストーリーは、プロダクトに求めることを、利用者の立場から短い文で書いたものです。XP（エクストリーム・プログラミング）で生まれました。Agile Alliance によると、最初に文章で説明されたのは1998年です。今ではスクラムのチームでも、プロダクトバックログのアイテムの書き方として広く使われています。ただし、スクラムガイドはユーザーストーリーを必須としていません。
ユーザーストーリーは、それだけで完結した仕様書ではありません。ロン・ジェフリーズが2001年に示した「3つのC」では、ストーリーを次の3つの組み合わせとして捉えます。
- 1
カード（Card）
要求を短く書く。カードに収まるくらいの量
- 2
会話（Conversation）
詳しい内容は、プロダクトオーナー・利用者・開発者が話して詰める
- 3
確認（Confirmation）
受入基準で、できたかどうかを確かめる
書いた文より、それをきっかけにした会話の方が大切です。
ストーリーはプロダクトバックログに並べて使います。並べ方やリファインメントはプロダクトバックログとは？で解説しています。
テンプレートはどう書く？（〜として〜したい）
よく使われるテンプレートは次の形です。
「（利用者の種類）として、（したいこと）をしたい。なぜなら（得たい結果）だからだ」
3つの部分には、それぞれ意味があります。「誰」が分かると、その人の事情を考えて作れます。「理由」が分かると、もっと良い作り方が見つかったときに、目的を外さずに変えられます。悪い例と良い例を比べてみます。
| 例 | 問題点・良い点 |
|---|---|
| 悪い例：「予約テーブルにキャンセル日時の列を追加する」 | 作業の指示で、誰のどんな必要か分からない |
| 悪い例：「ユーザーとして、システムを使いやすくしたい」 | 誰か・何をしたいかがあいまいで、できたか判断できない |
| 良い例：「会員として、予約を自分で取り消したい。なぜなら急な用事のときに電話する手間を省きたいからだ」 | 誰が・何を・なぜが分かり、受入基準を書ける |
| 良い例：「店舗の受付担当として、当日の予約一覧を時刻順に見たい。なぜなら来店の準備を順番に進めたいからだ」 | 利用者を具体的に分けている（会員と受付担当） |
「ユーザーとして」のように誰でも当てはまる書き方は避けます。会員・管理者・初めての利用者など、具体的な利用者の種類を書きます。
ユースケース・要件定義書とどう違う？
ユーザーストーリーは、要求の書き方の1つです。ほかの書き方と比べると、特徴がはっきりします。
| 観点 | ユーザーストーリー | ユースケース | 要件定義書（予測型） |
|---|---|---|---|
| 書く単位 | 利用者の1つの目的 | システムとのやりとりの一連の手順 | システム全体の要求 |
| 詳しさ | 短い文＋会話＋受入基準 | 正常の流れと例外の流れを手順で書く | 開発の前に細部まで確定させる |
| 詳しくする時期 | 作る直前に、会話で詳しくする | 設計の前に書くことが多い | 開発の前に承認を得る |
| 主な使い方 | アジャイルのバックログ | 手順や例外を細かく決めたい要求の分析 | 予測型の契約や設計の基準 |
Agile Alliance の用語集では、3つのCは、ユースケースのような文書中心の方法と区別する考え方です。ストーリーの狙いは、文書を減らすことより、会話を増やすことにあります。
INVESTの6条件とは？
良いユーザーストーリーの条件として、ビル・ウェイクが2003年に提案した INVEST がよく使われます。6つの英単語の頭文字です。
| 頭文字 | 意味 | 満たしていない例 |
|---|---|---|
| I（Independent） | 独立している。他のストーリーに頼らず、順番を入れ替えられる | 「Aが終わらないとBもCも始められない」 |
| N（Negotiable） | 交渉できる。細部は会話で決められる余地がある | 画面の細部まで固定した仕様書になっている |
| V（Valuable） | 価値がある。利用者や事業にとって意味がある | 「データベースを設計する」だけのストーリー |
| E（Estimable） | 見積もれる。開発者が大きさを見積もれる | 内容があいまいで、どれくらいかかるか分からない |
| S（Small） | 小さい。1つのスプリントで完了できる | 「予約システム全体を作る」 |
| T（Testable） | テストできる。できたかどうかを確かめられる | 「速く表示されるようにする」（基準がない） |
特に大事なのは、V（価値がある）と S（小さい）です。この2つを両立させる分け方は、次の節で扱います。
大きなストーリーはどう分ける？
価値を保ったまま小さく分けるには、画面・処理・データベースのような「層」で横に切りません。利用者が使える一連の流れを、薄く縦に切ります。代表的な切り口は次のとおりです（当サイトの整理）。
- 手順で分ける： 「予約する」を「空き枠を探す」と「予約を確定する」に分ける
- 条件の違いで分ける： 「取り消す」を「当日以外（無料）」と「当日（手数料あり）」に分ける
- データの種類で分ける： 「支払う」を「クレジットカード」と「ポイント」に分ける
- まず基本の流れだけ： 例外の処理や細かな入力チェックは、別のストーリーにする
どの分け方でも、分けた後のそれぞれが、利用者にとって意味のある価値を持つようにします。
受入基準（受け入れ基準）はどう書く？
受入基準は、そのストーリーが「できた」と判断するための条件です。プロダクトオーナーが中心になり、開発者や利用者と話し合って決めます。書き方の代表的な形は2つあります。
- 箇条書き： 「前日の18時まで取り消せる」「取り消すと確認メールが届く」「当日の取り消しボタンは表示しない」
- Given・When・Then： 前提・操作・結果の3つで書きます。例：「予約が明日の10時にある（前提）。会員が今日の17時に取り消す（操作）。予約が取り消され、確認メールが届く（結果）」
Given・When・Then の形は、そのままテストの手順になるのが利点です。
受入基準は、ストーリーごとに違う条件です。これに対して完了の定義（DoD）は、すべてのアイテムに共通する品質の基準（コードレビュー済み・自動テスト合格など）です。両方を満たして初めて「完了」になります。違いは完了の定義（DoD）とは？で詳しく扱います。
エピックとストーリーマッピングとは？
エピックは、1つのスプリントでは終わらない大きなストーリーです。「会員が予約を管理できる」のようなまとまりで、リファインメントで小さなストーリーに分けていきます。
ストーリーマッピングは、ジェフ・パットンが広めた手法で、ストーリーを2次元に並べます。横軸に利用者の行動の流れ（探す→予約する→変更する→来店する）を、縦軸に優先度を置きます。一番上の行を横につなぐと、最小限で使える一連の流れが見えます。それを最初のリリースにすると、MVP（実用最小限の製品）の範囲を決めやすくなります。
ストーリーの大きさの見積もりには、ストーリーポイントがよく使われます。見積もり方はストーリーポイントとは？で解説しています。
よくある失敗は？
- 作業の指示になっている： 「テーブルに列を追加する」など、誰の価値か分からない。
- 1つに複数の要望が入っている： 「検索して、比較して、予約したい」は分ける。
- 作り方まで書き込む： 画面の配置や技術を決めてしまい、会話の余地がない。
- 受入基準がない： レビューで「欲しかったのはこれではない」が起きる。
どれも、3つのCのうち「会話」と「確認」が欠けたときに起きます。カードに書いて終わりにしないことが大切です。
確認問題1
作業の指示になっているストーリー
（当サイトの独自問題）プロダクトバックログに、技術的な作業の指示のようなアイテムが多く並んでいます。たとえば「注文テーブルにインデックスを追加する」「APIのレスポンス形式を変更する」です。プロダクトオーナーは、どれを先にやるべきか判断できず困っています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。プロダクトオーナーが価値で並べられるよう、誰のどんな必要を満たすかが分かる形に書き直します。技術的な作業も、利用者にとっての効果（「注文履歴が2秒以内に表示される」など）として表せます。
2・4：並び順を決めるのはプロダクトオーナーです。3：プロダクトバックログは作業の唯一の源で、透明でなければなりません。
確認問題2
大きすぎるストーリー
（当サイトの独自問題）開発者がリファインメントで、あるストーリーを見積もりました。「会員として、ポイントを使って支払いたい」というストーリーです。結果は、1スプリントには収まらない大きさでした。開発者の一人は「画面・処理・データベースの3つに分けよう」と提案しています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。分けた後もそれぞれが利用者に価値を持つよう、使える流れごとに縦に分けます。
1：層で分けると、どれも単独では価値がなく、INVEST の V を満たしません。2：1スプリントで完了できない大きさのまま入れると、完了の定義を満たすインクリメントが作れません。4：スプリントの長さは固定するのが基本です。
確認問題3
受入基準がないストーリー
（当サイトの独自問題）スプリントレビューで、「管理者として、売上を確認したい」というストーリーの成果を見せました。プロダクトオーナーは「欲しかったのは店舗別の比較だった」と言いました。開発者は「言われたとおり合計は出している」と反論しています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：2。原因は「できた」の条件があいまいだったことです。受入基準をリファインメントで話し合って書けば、会話と確認の2つのCがそろいます。店舗別の比較は、新しいストーリーとしてバックログに入れます。
1：プロダクトオーナーの期待とずれたまま進みます。3：ストーリーは会話で詳しくするもので、PMの仕様書に置き換えるのは趣旨に反します。4：スプリントの終わりに、PMが作業を指示するのは不適切です。
要求の扱いが問われる問題は、無料模試30問でも出しています。