user-story-mapping

目的

ユーザージャーニーを可視化するために、上位レベルのアクティビティをステップとタスクに分解した階層マップを作成し、左から右へ物語の流れとして整理します。これを使って、プロダクト、デザイン、エンジニアリングの間で共通認識を築き、ユーザーワークフローに基づいて機能に優先順位を付け、ユーザー体験のギャップや機会を見つけます。

これはバックログではありません。ユーザーが目標をどのように達成するかを示す戦略的な成果物であり、それをもとに何を作るべきかを判断します。

主なコンセプト

Jeff Patton のストーリーマッピングフレームワーク

Jeff Patton が考案したストーリーマッピングでは、作業を 2 次元の構造に整理します。

横軸（左から右）： 時系列に沿ったユーザージャーニー

• バックボーン： ユーザーが行う上位レベルのアクティビティ
• ステップ： 各アクティビティ内の具体的な行動
• タスク： 各ステップを完了するために必要な詳細な作業

縦軸（上から下）： 優先順位とリリース

• 上の行： 必須のタスク（MVP／リリース 1）
• 下の行： あれば便利なタスク（今後のリリース）

ストーリーマップの構造

Segment → Persona → Narrative (User's goal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5]
     ↓              ↓              ↓              ↓              ↓
  [Step 1.1]     [Step 2.1]     [Step 3.1]     [Step 4.1]     [Step 5.1]
  [Step 1.2]     [Step 2.2]     [Step 3.2]     [Step 4.2]     [Step 5.2]
  [Step 1.3]     [Step 2.3]     [Step 3.3]     [Step 4.3]     [Step 5.3]
     ↓              ↓              ↓              ↓              ↓
  [Task 1.1.1]   [Task 2.1.1]   [Task 3.1.1]   [Task 4.1.1]   [Task 5.1.1]
  [Task 1.1.2]   [Task 2.1.2]   [Task 3.1.2]   [Task 4.1.2]   [Task 5.1.2]
  [Task 1.1.3]   [Task 2.1.3]   [Task 3.1.3]   [Task 4.1.3]   [Task 5.1.3]
  ...            ...            ...            ...            ...

効果がある理由

• ユーザー中心： エンジニアリングのモジュールではなく、ユーザーの目標を中心に作業を整理します
• 共通認識： プロダクト、デザイン、エンジニアリングが同じジャーニーを確認できます
• 優先順位が明確： 上位のタスクは MVP、下位のタスクは今後のイテレーションに対応します
• ギャップの特定： 抜けているステップやタスクが明らかになります
• リリース計画： 横方向に「リリースライン」を引いて、スコープを定義します

アンチパターン（これは何ではないか）

• ガントチャートではありません： プロジェクト管理ではなく、ユーザージャーニーを可視化するものです
• 機能リストではありません： アクティビティは機能ではなく、ユーザーの行動です
• 静的なものではありません： ユーザーについて理解が深まるにつれて、ストーリーマップも変化します

使用する場面

• 新しいプロダクトや主要機能の立ち上げ
• ユーザーワークフローについてステークホルダー間の認識をそろえる
• ユーザーニーズに基づいてバックログに優先順位を付ける
• MVP と今後のリリースを見極める
• プロダクトビジョンを新しいチームメンバーに伝える

使用しない場面

• 些細な機能の場合（すでに理解している内容をマッピングする必要はありません）
• ユーザーワークフローが絶えず変化する場合（マップによってワークフローを安定させます）
• ユーザーストーリーの代わりとして使う場合（マップはストーリーの作成に役立ちますが、置き換えるものではありません）

---

適用

ステップ 1：コンテキストを定義する

記入用の全項目を含む構成については、template.md を使用してください。

セグメント

誰のために作っていますか？

### Segment:
- [Specify the target segment, e.g., "Small business owners using DIY accounting software"]

品質チェック：

• 具体的にする： 「ユーザー」ではなく、「エンタープライズ IT 管理者」や「フリーランスのデザイナー」のようにします

---

ペルソナ

このセグメント内のペルソナについて詳しく記述してください（skills/proto-persona/SKILL.md を参照）。

### Persona:
- [Describe the persona: demographics, behaviors, pains, goals]

例：

• 「Sarah は 35 歳のフリーランスのグラフィックデザイナーです。同時に 5～10 件のクライアントプロジェクトを管理しており、請求書の作成や支払いの追跡に苦労しています。事務作業の時間を減らし、デザインにもっと時間を使いたいと考えています」

---

ステップ 2：ナラティブを定義する

ユーザーは何を達成しようとしていますか？Jobs-to-be-Done の形式で表現してください（skills/jobs-to-be-done/SKILL.md を参照）。

### Narrative:
- [Concise narrative of the persona's objective, e.g., "Complete a client project from kickoff to final payment"]

品質チェック：

• 成果に焦点を当てる： 「プロダクトを使う」ではなく、「クライアントのプロジェクトを期日どおりに納品し、報酬を受け取る」とします
• 1 文にする： 1 文を超える場合、スコープが広すぎる可能性があります

---

ステップ 3：アクティビティを特定する（バックボーン）

ペルソナがナラティブを実現するために行う、3～5 個の上位レベルのアクティビティを列挙します。これらがマップのバックボーンになります。

### Activities:
1. [Activity 1, e.g., "Negotiate project scope and pricing"]
2. [Activity 2, e.g., "Execute design work"]
3. [Activity 3, e.g., "Deliver final assets to client"]
4. [Activity 4, e.g., "Send invoice and receive payment"]
5. [Activity 5, optional]

品質チェック：

• 順序に沿っている： アクティビティは順番に行われます（左から右）
• ユーザーの行動にする： プロダクトが提供するものではなく、ユーザーが行うことを記述します
• アクティビティは 3～5 個： 少なすぎると単純化しすぎになり、多すぎると把握が難しくなります

---

ステップ 4：アクティビティをステップに分解する

各アクティビティについて、その実行方法を詳しく示す 3～5 個のステップを列挙します。

### Steps:

**For Activity 1: [Activity Name]**
- Step 1: [Detail step 1, e.g., "Review client brief"]
- Step 2: [Detail step 2, e.g., "Draft project proposal"]
- Step 3: [Detail step 3, e.g., "Negotiate timeline and budget"]
- Step 4: [Optional step 4]
- Step 5: [Optional step 5]

**For Activity 2: [Activity Name]**
- Step 1: [Detail step 1]
- Step 2: [Detail step 2]
...

品質チェック：

• 実行可能： 各ステップはユーザーが行うことです
• 観察可能： 誰かがそのステップを実行する様子を観察できます
• 論理的な順序： ステップが自然な順序に沿っています

---

ステップ 5：ステップをタスクに分解する

各ステップについて、完了する必要があるタスクを 5～7 件挙げます。

### Tasks:

**For Activity 1, Step 1: [Step Name]**
- Task 1: [Detail task 1, e.g., "Read client brief document"]
- Task 2: [Detail task 2, e.g., "Identify key deliverables"]
- Task 3: [Detail task 3, e.g., "Note budget constraints"]
- Task 4: [Detail task 4, e.g., "Clarify timeline expectations"]
- Task 5: [Detail task 5, e.g., "List open questions for client"]
- Task 6: [Optional task 6]
- Task 7: [Optional task 7]

**For Activity 1, Step 2: [Step Name]**
- Task 1: [Detail task 1]
...

品質チェック：

• 細分化されている： タスクは小さく、具体的なアクションになっています
• ユーザー向けまたは裏側の処理： 両方を含めます（例：「メールを送信する」と「確認を受け取る」）
• 優先順位を付けられる： タスクは縦方向に優先順位を付けます（上が必須、下があると望ましいもの）

---

ステップ 6：縦方向に優先順位を付ける

タスクを優先順位の高いものから順に、上から下へ配置します。

• 上段： MVP／リリース 1（必須）
• 中段： リリース 2（重要だが、必須ではない）
• 下段： 将来／あると望ましいもの

対象範囲を区切るため、横線で「リリースライン」を引きます。

---

ステップ 7：抜け漏れと機会を特定する

マップを確認し、次の点を問いかけます。

• 欠けているステップやタスクはありませんか？
• 対応できていない課題はありませんか？
• ユーザーを喜ばせる機会はありませんか？
• すべてのアクティビティは論理的につながっていますか？

---

例

ストーリーマップの全体例については、examples/sample.md を参照してください。

---

よくある落とし穴

落とし穴 1：アクティビティがユーザーの行動ではなく、機能になっている

症状： 「アクティビティ 1：ダッシュボードを使う。アクティビティ 2：レポートを作成する。」

結果： ユーザーの行動ではなく、製品をマッピングしてしまいます。

対策： ユーザーの行動として捉え直します。「アクティビティ 1：プロジェクトの進捗を確認する。アクティビティ 2：関係者向けに作業を要約する。」

---

落とし穴 2：アクティビティが多すぎる

症状： バックボーンに 10 件以上のアクティビティがある

結果： マップが複雑になり、焦点がぼやけます。

対策： 統合します。アクティビティが 10 件ある場合は、アクティビティとステップを混同している可能性があります。大まかなアクティビティを 3～5 件にすることを目指します。

---

落とし穴 3：タスクが曖昧すぎる

症状： 「タスク 1：あれをする」

結果： 曖昧なタスクには優先順位を付けられず、工数も見積もれません。

対策： 具体的にします。「タスク 1：「請求先」フィールドにクライアントのメールアドレスを入力する。」

---

落とし穴 4：縦方向の優先順位付けを無視する

症状： すべてのタスクが同じ優先度で、MVP と今後のリリースが定義されていない

結果： 最初に何を開発すべきかが明確になりません。

対策： 明示的に優先順位を付けます。リリースラインを引きます。MVP に含めるものを厳しく選びます。

---

落とし穴 5：一人だけでマッピングする

症状： PM が一人でマップを作成し、その後チームに提示する

結果： 共通の当事者意識や理解が生まれません。

対策： 協力してマッピングします。プロダクト、デザイン、エンジニアリングのメンバーとストーリーマッピングのワークショップを実施します。

---

参考資料

外部フレームワーク

• Jeff Patton、『User Story Mapping』（2014）— ストーリーマッピング手法の起源
• Teresa Torres、『Continuous Discovery Habits』（2021）— オポチュニティ・ソリューション・ツリー（ストーリーマップを補完するもの）