sumik5/writing-user-stories

ユーザーストーリーの書き方

ユーザーストーリーとは

ユーザーストーリーとは、ユーザーがシステムに求めるシンプルな説明である。詳細な技術仕様書ではなく、「会話のプレースホルダー」として機能する。

ストーリーの本質

| 観点 | 正しい理解 | よくある誤解 | |------|-----------|-----------| | 目的 | ユーザーのニーズを表現する「ターゲット」 | 開発チームへの「タスクリスト」 | | 詳細度 | ユーザーが望む結果（What） | 実装方法（How） | | 対象読者 | 技術者・非技術者の全員が理解できる | 開発者向けの技術仕様 | | 柔軟性 | 会話を通じて深める出発点 | 変更不可能な契約 |

---

ストーリーテンプレート

As a [ユーザーの種類]
I want [実現したいこと]
So that [得られるメリット]

テンプレートの使い方

• As a: 誰のためのストーリーかを明確にする（例: 顧客、管理者、新規ユーザー）
• I want: ユーザーが望む行動・結果を記述（UIの操作ではなく、達成したい目標）
• So that: ストーリーの価値・目的を示す。なぜこれが重要かを明確にする

---

良いストーリーの特徴

✅ ユーザー視点で記述されている（ユーザーインターフェースではなくユーザーの目標） ✅ 自然言語で書かれており、非技術者にも理解できる ✅ 実装の詳細を含まない（データベース・フィールド・ボタン名を記述しない） ✅ ユーザーが視認できる結果を表現している ✅ 適切なサイズ（1スプリント、理想的には1〜2日で完了できる規模）

良いストーリー vs 悪いストーリー

| 良いストーリー | 避けるべき記述 | |-------------|-------------| | クレジットカードで支払う | コンポーネントXと決済プロバイダYを統合する | | 本を購入する | ホームページに「購入」ボタンを追加する | | 注文が却下された場合に通知を受け取る | 注文却下時に「このテキスト」のエラーダイアログを追加する | | 検索結果を素早く受け取る | システムを100ユーザー対応にスケールする |

---

よくある間違い

1. 解決策から始める

問題を理解する前に実装を定義してしまう。まず「何を解決したいか」を明確にしてから、「どう解決するか」を考える。

2. "What" と "How" の混同

「データを入力する」「ボタンをクリックする」は操作手順（How）。「商品を見つける」「注文する」がユーザーの目標（What）。

3. "リモートコントロール"式の要件

開発チームに「どのコードを書くか」を指定してしまう。チームは問題を深く理解した上で、最良の解決策を自律的に選択できるべき。

4. 契約として扱う

ストーリーは創造的なコラボレーションを促すもの。PO（プロダクトオーナー）と開発者の壁になってはいけない。

5. 書面コミュニケーションへの過度な依存

詳細な文書よりも対話と会話の方が誤解を防ぐ。ストーリーは会話を始めるきっかけであり、終着点ではない。

6. モンスターストーリー

1スプリントで完了できないほど大きなストーリーは分割が必要。

7. 技術タスクリスト化

「データベースカラム追加」「API統合」は技術タスクであってストーリーではない。「クレジットカード支払い」と「データベースカラム追加」を優先順位比較するのは不可能（リンゴとカエルの比較）。

---

技術要件をユーザーストーリーに変換する

技術要件の中には必ずユーザー価値が隠れている。掘り出して表現する。

| 技術要件 | ユーザーストーリーへの変換 | |---------|------------------------| | システムをスケールして、より多くのユーザーに対応する | 注文結果をすばやく受け取れるようにしてほしい | | ディザスタリカバリを実装する | システム障害中でも注文を続けられるようにしてほしい | | 最新バージョンにアップデートする | ハッキングされるリスクを最小化してほしい |

変換のメリット: ユーザーニーズ同士を比較して優先順位を決められるようになる。技術タスクとユーザー機能を混在させると優先順位付けができなくなる。

---

受入条件（Acceptance Criteria）の書き方

受入条件は、ストーリーが「完了した」と判断するための基準。

良い受入条件の構造

Given [前提条件]
When [ユーザーのアクション]
Then [期待される結果]

受入条件のポイント

• ユーザーが得られる結果を記述する（実装詳細ではなく）
• ポジティブ・ネガティブ両方のシナリオをカバーする
  • 例: 「在庫がある場合に購入できる」＋「在庫がない場合に入荷日が表示される」
• チームと合意形成に使う（一人で作らない）

---

ストーリーの粒度

粒度の判断基準

| 状況 | 対応 | |------|------| | 1スプリント（1〜2週間）で完了できない | 分割が必要 | | 1〜2日で完了できる | 適切なサイズ | | 「データベースカラム追加」「APIエンドポイント追加」が並んでいる | 技術タスク化している。ユーザー価値に変換を | | 複数の独立したユーザー目標が1つに混在している | 分割が必要 |

AskUserQuestion: ストーリー粒度が不明な場合

このストーリーの粒度について教えてください:
1. 1スプリント（1〜2週間）で完了できますか?
2. この中に複数の独立したユーザー目標が含まれていますか?
3. ユーザーが実際に価値を感じるのは、この全体ですか? 一部ですか?

---

ストーリー分割テクニック

| 分割軸 | 説明 | 例 | |-------|------|-----| | ワークフローステップ | ユーザーの操作フローを分割 | 「本を探す」→「カートに追加する」→「購入する」 | | ポジティブ/ネガティブ | 正常系と異常系を分割 | 「在庫ありで購入」→「在庫なしで通知受信」 | | ユーザーの種類 | ロールごとに分割 | 「一般ユーザーとして注文」→「管理者として注文確認」 | | データの変化 | 扱うデータパターンで分割 | 「1冊購入」→「複数冊一括購入」 | | シンプルから複雑へ | 最小限の機能から始め、段階的に追加 | 「1種類の支払い方法」→「複数の支払い方法に対応」 |

---

ストーリー作成の始め方

1. 最もシンプルなシナリオから始める — ユーザーがソフトウェアを使うときに最初にすること、または最も重要なことを1つ選ぶ
2. ユーザーになりきる — 実際のユーザーの立場に立ち、良い体験とはどんなものかを考える
3. 過度に形式張らない — テンプレートにこだわりすぎず、自然な言葉で書く
4. 洗練は後で — 最初から完璧を目指さず、理解が深まるにつれてストーリーを追加・修正する

---

誰がストーリーを書くか

ストーリー作成はプロダクトオーナーだけの仕事ではない。コラボレーションが重要。

| 関係者 | 役割 | |-------|------| | プロダクトオーナー / 顧客 | ビジョンと優先順位を持つ | | ドメインエキスパート | 問題領域を深く理解している | | 開発者 | 技術的な実現可能性と代替案を知っている | | QA / テスター | エッジケースと品質基準を考える |

共同作業のテクニック

• Event Storming: ドメインイベントを可視化してストーリーの境界を発見する
• Story Mapping: ユーザーの全体的な旅を地図に描き、優先順位を決める

---

必須複雑性 vs 偶発的複雑性

| 種類 | 説明 | ストーリーへの影響 | |-----|------|----------------| | 必須複雑性 | ユーザーが抱える本質的な問題（例: 税金計算、フライトの乱気流対応） | ストーリーはこちらにフォーカスする | | 偶発的複雑性 | コンピュータで実装するときの技術的な副産物（UI設計、API、データ保存） | ストーリーには含めない。実装の詳細 |

Good User Stories focus on essential complexity from the user's perspective.