ユーザーストーリー

ユーザーストーリーとは

ユーザーストーリーは、「誰が」「何をしたいか」「なぜか」をユーザーの視点で記述する要件定義の手法である。技術的な仕様ではなく、ビジネス価値に焦点を当てる。

カードに書かれた一文は要件そのものではなく、後で顧客と開発者が会話する約束にすぎない。Ron Jeffries は 2001 年の記事で、ストーリーの本質を Card (カード) / Conversation (会話) / Confirmation (確認) の 3 つに整理した。カードは要件の全部を載せる場所ではなく会話のきっかけであり、要件は会話を通じて伝わり、最後に受け入れテストで完了の合意を取る。この前提を外してカードを仕様書として扱うと、ストーリーは書式だけ整った短い仕様書に退化する。

フォーマット

役割 / 要望 / 理由の 3 点を並べる次の書式が最も広く使われている。Agile Alliance の用語集では、この形式は 2001 年に英国の Connextra 社で考案されたことから Connextra 形式とも呼ばれると説明されている。

As a [ユーザーの種類],
I want [実現したいこと],
so that [得られる価値].

例:
As a 購入者,
I want カートに商品を追加したい,
so that まとめて購入できる.

3 つ目の so that が最も落としやすく、同時に最も重要である。理由が書けないストーリーは、優先順位を決める根拠も、実装後に価値が出たかを確かめる基準も持たない。

ただし書式そのものが目的ではない。Agile Alliance は同じ用語集で、この形式を初心者向けの補助として位置づけ、慣れた後は形式に固執せず会話で伝わる表現に緩めてよいとし、書式を機械的に埋めるだけの運用を典型的な失敗として挙げている。

良いストーリーの条件 (INVEST)

Bill Wake が 2003 年に xp123 で発表した頭字語で、良いストーリーが備える 6 つの性質を示す。

Small を「1 スプリントに収まればよい」と読むと大きすぎるストーリーが通ってしまう。原典は、1 か月以上かかるという発言はしばしば中身を理解していないことの言い換えだと指摘しており、小さいほど見積もりの精度も上がるとしている。

Negotiable と Testable は対になっている。詳細を固めないまま着手を合意できるのは、受け入れテストで最終確認する道が用意されているからである。

Acceptance Criteria

Acceptance Criteria (受け入れ条件) は 3C の Confirmation に当たり、どうなったら完了かを実装前に合意した箇条書きである。主導するのは開発者ではなく価値を判断する側で、開発者は実現性の観点から補う。

## ストーリー
購入者として、カートに商品を追加したい

## Acceptance Criteria
- [ ] 商品ページに「カートに追加」ボタンがある
- [ ] ボタンをクリックすると商品がカートに追加される
- [ ] カートのアイコンに商品数が表示される
- [ ] 同じ商品を追加すると数量が増える
- [ ] 在庫がない商品はボタンが無効化される

「正常に動くこと」のような検査できない書き方を避け、在庫切れや重複追加といった境界を含めるのが要点である。上の例では下の 2 行がそれに当たる。逆にボタンの色や実装方式まで書き込むと Negotiable が壊れ、会話で詰める余地が消える。

ストーリーの分割

大きなストーリー (エピック) は小さなストーリーに分割する。エピックは 1 イテレーションに収まらないほど大きいストーリーを指す呼び方で、別種の成果物ではない。関連するストーリーをまとめた束はテーマと呼ばれる。

エピック: ユーザー認証
  ├── ストーリー: メールアドレスでサインアップ
  ├── ストーリー: メールアドレスでログイン
  ├── ストーリー: パスワードリセット
  └── ストーリー: Google OAuth ログイン

分割の目安は、分割後の各ストーリーが単独でも価値を出せること、つまり INVEST の Valuable を保つことである。「画面を作る」「API を作る」「テーブルを作る」のような層での分割は、単体では誰の役にも立たないため避ける。上の例は認証機能を利用者から見た用途で切っている。

技術タスクとの違い

ユーザーストーリーと技術タスクは、誰の言葉で書くかが違う。

技術タスクをストーリーの体裁に無理に押し込む必要はない。Wake は同じ記事で、タスク側の指針として SMART という別の頭字語を挙げている。ストーリーの下に紐づく作業として素直に管理すればよい。

ストーリーマッピング

ストーリーマッピングは Jeff Patton が広めた整理法で、本人の記述によれば最初に記事化したのは 2005 年 1 月の "How You Slice It" である。ストーリーを平坦な一覧ではなく、利用者の行動の流れに沿って二次元に並べる。

ユーザーの行動フロー (横軸):
  商品を探す → カートに追加 → 購入手続き → 支払い → 注文確認

各行動の詳細ストーリー (縦軸):
  商品を探す:
    - キーワード検索
    - カテゴリ絞り込み
    - 価格フィルター

横軸がユーザーの行動フロー、縦軸が各行動の詳細ストーリー。上にあるほど優先度が高い。横一列に並ぶ主要な行動は Patton が背骨と呼ぶ骨格に当たる。この形にするとリリース範囲を縦線で決められるようになり、一通り使える状態を保ったまま範囲を削れる。

実務での活用方法は関連書籍にも詳しい。