user-story-mapping

目的

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

これはバックログではありません。ユーザーが目標をどのように達成するかを示す戦略的な成果物であり、その内容を踏まえて何を作るべきかを決めます。

入力

最適な入力： マッピング対象となるプロダクトまたはユーザーのワークフロー。 あると便利な情報： 主なユーザー、把握しているエンドツーエンドのナラティブ、配置する既存のバックログ項目、リリース目標。

呼び出し時に渡された情報（スキル名の後に続くテキスト、貼り付けられたコンテキスト、追記された ARGUMENTS: 行など）は、回答済みの内容として扱います。活用し、該当する内容については聞き直さないでください。

何も用意していなくても問題ありません。 このスキルでは、誰のジャーニーをマッピングするのか、そしてその人が何を達成しようとしているのかを尋ねたうえで、バックボーン → タスク → スライスを作成します。

呼び出し例： 経費精算のフローを、レシートの取り込みから払い戻しまでストーリーマップにしてください。パイロット向けのMVPスライスも含めてください。

主な概念

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 が一人でマップを作成し、その後チームに提示する

結果: 共有されたオーナーシップや理解が得られない。

対処: 協働でマッピングする。プロダクト、デザイン、エンジニアリングを交えたストーリーマッピングワークショップを実施する。

---

参考資料

関連スキル

• skills/proto-persona/SKILL.md — ストーリーマップのペルソナを定義する
• skills/jobs-to-be-done/SKILL.md — ナラティブとアクティビティに情報を提供する
• skills/user-story/SKILL.md — マップのタスクがユーザーストーリーになる
• skills/problem-statement/SKILL.md — 問題提起がナラティブを組み立てる

外部フレームワーク

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

Dean の成果物

• User Story Mapping Prompt（Jeff Patton の方法論を基に改変）

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリ内の prompts/user-story-mapping.md を参考にしています。

---

**スキルの種類：**コンポーネント 推奨ファイル名：user-story-mapping.md 推奨配置場所：/skills/components/ 依存関係：skills/proto-persona/SKILL.md、skills/jobs-to-be-done/SKILL.md、skills/user-story/SKILL.md、skills/problem-statement/SKILL.md を参照します。