user-story-mapping-workshop

目的

システム、ユーザー、ワークフロー、優先順位について適応型の質問をしながら、プロダクトマネージャーがユーザーストーリーマップを作成できるよう導きます。その後、バックボーン（アクティビティ）、ユーザータスク、リリーススライスを含む二次元のマップを生成します。これを使って、平坦なバックログから、全体像を伝え、機能の不足を特定し、有意義なリリース計画を可能にするビジュアルなストーリーマップへ移行できます。ストーリーがシステム全体の物語とのつながりを失う「文脈のない寄せ集め」を避けられます。

これはバックログ生成ツールではありません。ユーザーのワークフロー（横軸）と優先順位（縦軸）に沿って作業を整理する、ビジュアルコミュニケーションのフレームワークです。

入力

最適な入力： マッピング対象のシステムまたはワークフロー。 あると役立つ入力： 主なユーザー、すでに把握しているワークフローの手順、マップで決めるべきこと（MVP の範囲、リリース計画）。

呼び出し時に渡された情報（スキル名に続くテキスト、貼り付けられたコンテキストのダンプ、または追加された ARGUMENTS: 行）は、すでに回答済みの情報として扱います。その情報を活用し、内容がカバーする質問は繰り返しません。

手ぶらで始めても大丈夫です。 ワークショップではまず、システムとそのユーザーについて質問（Q1）し、その後はファシリテーションの手順に沿って進めます。

呼び出し例： Run a story mapping workshop for our vendor onboarding portal — output should give us a first release slice.

主要な概念

ユーザーストーリーマップとは？

ストーリーマップ（Jeff Patton）は、ユーザーストーリーを二次元で整理します。

横軸（左から右）： 物語やワークフローの順序に沿って並べたアクティビティ。システムについて誰かに説明するときの順序です。

縦軸（上から下）： 各アクティビティ内の優先順位。最も不可欠なタスクを上部に配置します。

構造：

Backbone (Activities across top)
↓
User Tasks (descending vertically by priority)
↓
Details/Acceptance Criteria (at the bottom)

主要な原則

バックボーン： 不可欠なアクティビティがシステムの構造的な中核を成します。これらは互いに優先順位を付ける対象ではなく、物語の流れを形成します。

ウォーキングスケルトン： すべてのアクティビティから最優先のタスクを集めると、最小限の実用最小限の製品、つまりエンドツーエンドの最小限の機能になります。

リブ： 各アクティビティの下に補助タスクを縦に並べ、配置によって優先順位を示します。

左から右、上から下への構築戦略： 1つの機能を完全に仕上げてから次に取りかかるのではなく、すべての主要機能を段階的に構築します。

この方法が有効な理由

• ビジュアルコミュニケーション： ストーリーマップを情報ラジエーターとして表示し続け、全体像への意識を保ちます。
• 物語の構造： 技術アーキテクチャではなく、ユーザーのワークフローに沿って整理します。
• リリース計画： 横方向のスライスによって、MVP や段階的なリリースを明らかにします。
• ギャップの特定： 平坦なバックログでは見えにくい機能の不足を明らかにします。

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

• ガントチャートではありません： ストーリーマップが示すのは優先順位であり、所要時間の見積もりではありません。
• 技術アーキテクチャではありません： マップはシステムのレイヤー（UI → API → DB）ではなく、ユーザーのワークフローに沿います。
• プロジェクト計画ではありません： スケジュールではなく、発見とコミュニケーションのためのツールです。

使う場面

• 新しい製品や主要機能に着手するとき
• 既存のバックログを再構成するとき（平坦なリストからビジュアルマップへ移行）
• スコープと優先順位について関係者の認識を合わせるとき
• MVP や段階的なリリースを計画するとき

使わない場面

• 単一機能のプロジェクト（ストーリーマップは過剰です）
• バックログの内容と優先順位がすでに十分明確な場合
• 技術的なリファクタリング作業（マッピングするユーザーワークフローがない場合）

---

ファシリテーションの信頼できる情報源

このスキルでは、デフォルトの対話プロトコルとして workshop-facilitation を使用します。

以下を定義しています。

• セッション開始時の案内と開始モード（ガイド付き、コンテキストの貼り付け、最善の推測）
• 平易な言葉でのプロンプトを使った、1ターンにつき1つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 割り込みへの対応と一時停止・再開の動作
• 意思決定ポイントでの番号付き提案
• 通常の質問での番号付き選択肢（役立つ場合は Other (specify) を含めます）

このファイルでは、ドメイン固有の評価内容を定義しています。競合する場合は、このファイルのドメインロジックに従ってください。

適用

この対話型スキルでは、各ステップで 3～4 個の番号付き選択肢を提示しながら、適応型の質問を 最大 5 つ行います。

ファシリテーションのアジェンダと出力チェックリストには、template.md を使用してください。

対話パターン：意思決定ポイントで番号付き提案を行い、通常の質問でクイック選択肢を提示しながら、一度に 1 ステップずつ進める場合は、skills/workshop-facilitation/SKILL.md と組み合わせてください。ユーザーが一度にまとめて出力するよう求めた場合は、複数ターンのファシリテーションを省略してください。

---

ステップ 0：コンテキストの収集（質問の前）

エージェントが提案します：

ストーリーマップの作成に取りかかる前に、コンテキストを収集しましょう。

製品／機能のコンテキスト：

• どのシステムまたは機能をマッピングしますか？
• 製品コンセプト、PRD のドラフト、または既存のバックログ
• ウェブサイトのコピー、ポジショニング資料、またはユーザーフロー
• 既存のユーザーストーリー（フラットなバックログから移行する場合）

ユーザーのコンテキスト：

• 対象となるペルソナまたはユーザーセグメント
• ユーザー調査、インタビュー、またはジャーニーマップ
• ジョブ理論（Jobs-to-be-done）または問題の説明

この内容を直接貼り付けるか、システムの概要を簡単に説明してください。

---

質問 1：スコープの定義

エージェントが質問します： 「何をマッピングしますか？（スコープはどの範囲ですか？）」

番号付きの選択肢を 4 つ提示します：

1. 製品全体 — 「発見から完了までの、エンドツーエンドのシステム全体」（新製品や全面的な書き直しでよく使われます）
2. 主要な機能領域 — 「より大きな製品内の特定のワークフロー（例：「オンボーディング」「チェックアウト」「レポート」）」（機能のリリースでよく使われます）
3. ユーザージャーニー — 「特定のユーザー目標またはジョブ理論（例：「請負業者を雇う」「納税申告を行う」）」（ジョブ理論に基づくマッピングでよく使われます）
4. 再設計／リファクタリング — 「再構築または簡素化する既存の製品／機能」（レガシーシステムのモダナイゼーションでよく使われます）

または、具体的なスコープを説明してください。

ユーザーの回答： [選択または自由記述]

---

質問 2：ユーザー／ペルソナの特定

エージェントが質問します： 「このマップの主なユーザーは誰ですか？（ペルソナまたはユーザーセグメントを挙げてください。）」

番号付きの選択肢を 4 つ提示します：

1. 単一のペルソナ — 「主なユーザータイプが 1 つ（例：「小規模事業者」）」（マッピングを簡素化でき、MVP に適しています）
2. 複数のペルソナ、共通のワークフロー — 「ユーザータイプは異なるが、中心となるアクティビティは共通（例：「買い手」と「売り手」のどちらも商品を閲覧する）」（マーケットプレイスでよく使われます）
3. 複数のペルソナ、異なるワークフロー — 「ユーザータイプごとにワークフローが異なる（例：「管理者」と「エンドユーザー」）」（マップを分けるか、スイムレーンを使う必要があります）
4. 組織内の役割 — 「異なる職務（例：「PM」「デザイナー」「エンジニア」）」（社内ツールでよく使われます）

または、ユーザーについて説明してください。

適応： ステップ 0 で提供されたコンテキスト（プロトペルソナ、ジョブ理論など）のペルソナを使用します。

ユーザーの回答： [選択または自由記述]

---

質問 3：バックボーン（アクティビティ）の生成

エージェントが伝えます： 「バックボーン、つまりユーザーが目標を達成するために行うアクティビティの流れを組み立てましょう。」

エージェントは、スコープ（Q1）とユーザー（Q2）に基づいて、左から右へワークフロー順に 5～8 個のアクティビティを生成します。

例（スコープが「E コマースのチェックアウト」の場合）：

Backbone Activities (left to right):

1. Browse Products
2. Add to Cart
3. Review Cart
4. Enter Shipping Info
5. Enter Payment Info
6. Confirm Order
7. Receive Confirmation

エージェントが質問します： 「このバックボーンでワークフロー全体を捉えられていますか？アクティビティを追加、削除、または並べ替えますか？」

ユーザーの回答： [承認、変更、またはカスタムアクティビティの追加]

---

質問 4：ユーザータスクを生成する（各アクティビティの下に配置）

エージェントの発言： 「次に、各アクティビティの下にユーザータスクを優先順位順（上が必須、下があると望ましい）に並べましょう。」

エージェントは、各アクティビティにつき 3～5 個のユーザータスクを生成し、優先順位順に縦に並べます。

例（アクティビティ 2：「カートに追加」の場合）：

Add to Cart (Activity)
├─ Add single item to cart (must-have, walking skeleton)
├─ Adjust quantity (must-have)
├─ Add multiple items at once (should-have)
├─ Save item for later (nice-to-have)
└─ Add gift wrapping (nice-to-have)

**エージェントはすべてのバックボーンアクティビティについて繰り返し、**マップ全体を表示します。

エージェントの質問： 「主要なタスクを捉えられていますか？ 優先順位は正しいですか（上が MVP、下が後続リリースです）？」

ユーザーの回答：［承認、修正、または独自のタスクを追加］

---

質問 5：リリーススライスを特定する（ウォーキングスケルトン＋段階的な追加）

エージェントの発言： 「マップ上に水平線を引いて、リリーススライスを定義しましょう。」

エージェントは 3 つのリリーススライスを生成します：

**リリース 1（ウォーキングスケルトン）：**すべてのアクティビティにわたる最優先のタスク。最小限のエンドツーエンド機能です。

**リリース 2（次の段階）：**コアワークフローを強化する、優先順位が 2 番目のタスクです。

**リリース 3（仕上げ／拡張）：**優先順位が 3 番目のタスク（あると望ましい機能、エッジケース、最適化）です。

例：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 1 (Walking Skeleton):
- Browse products (basic list view)
- Add single item to cart
- Review cart (line items + total)
- Enter shipping info (name, address)
- Enter payment info (credit card only)
- Confirm order (basic confirmation)
- Receive email confirmation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 2 (Enhanced):
- Product filtering/search
- Adjust quantity in cart
- Save for later
- Multiple shipping options
- Multiple payment methods
- Order tracking link
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Release 3 (Polish):
- Product recommendations
- Guest checkout
- Gift wrapping
- Promo codes
- Advanced payment options
- Post-purchase surveys
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

エージェントの質問： 「これらのリリーススライスで問題ありませんか？ スコープや優先順位を調整しますか？」

ユーザーの回答：［承認または修正］

---

出力：ユーザーストーリーマップ

一連の手順が完了すると、エージェントは次を出力します：

# User Story Map: [Scope from Q1]

**Users:** [From Q2]
**Date:** [Today's date]

---

## Backbone (Activities)

[Activity 1] → [Activity 2] → [Activity 3] → [Activity 4] → [Activity 5] → [Activity 6]

---

## Full Story Map

### [Activity 1: Name]
- **[Task 1.1]** — Must-have (Release 1)
- **[Task 1.2]** — Should-have (Release 2)
- **[Task 1.3]** — Nice-to-have (Release 3)

### [Activity 2: Name]
- **[Task 2.1]** — Must-have (Release 1)
- **[Task 2.2]** — Should-have (Release 2)
- **[Task 2.3]** — Nice-to-have (Release 3)

[...repeat for all activities...]

---

## Release Slices

### Release 1: Walking Skeleton (MVP)
**Goal:** Minimal end-to-end functionality

**Stories:**
- [Task 1.1] — [Activity 1]
- [Task 2.1] — [Activity 2]
- [Task 3.1] — [Activity 3]
- [Task 4.1] — [Activity 4]
- [Task 5.1] — [Activity 5]
- [Task 6.1] — [Activity 6]

**Why this is the walking skeleton:** Delivers complete workflow with simplest version of each activity.

---

### Release 2: Enhanced Functionality
**Goal:** Improve core workflow with priority enhancements

**Stories:**
- [Task 1.2] — [Activity 1]
- [Task 2.2] — [Activity 2]
- [Task 3.2] — [Activity 3]
[...]

---

### Release 3: Polish & Expansion
**Goal:** Nice-to-haves, edge cases, optimizations

**Stories:**
- [Task 1.3] — [Activity 1]
- [Task 2.3] — [Activity 2]
[...]

---

## Next Steps

1. **Refine stories:** Use `skills/user-story/SKILL.md` to write detailed stories with acceptance criteria
2. **Estimate effort:** Score stories (story points, t-shirt sizes)
3. **Validate with stakeholders:** Walk through map left-to-right, confirm priorities
4. **Display map:** Print/post as information radiator for ongoing reference

---

**Ready to write user stories? Let me know if you'd like to refine the map or break down specific stories.**

---

例

例 1：適切なストーリーマップ（E コマースのチェックアウト）

Q1 の回答：「主要な機能領域 — E コマースのチェックアウトワークフロー」

Q2 の回答：「単一のペルソナ — オンラインショッパー」

Q3 - バックボーンの生成：

Browse → Add to Cart → Review Cart → Enter Shipping → Enter Payment → Confirm → Receive Confirmation

Q4 - ユーザータスクの生成：

Browse Products
├─ View product list (R1)
├─ Search/filter (R2)
└─ Product recommendations (R3)

Add to Cart
├─ Add single item (R1)
├─ Adjust quantity (R2)
└─ Save for later (R3)

Review Cart
├─ View line items + total (R1)
├─ Apply promo code (R2)
└─ Estimate shipping cost (R3)

[...etc...]

Q5 - リリーススライス：

• **リリース 1：**ウォーキングスケルトン — 追加機能のない基本的なフロー
• **リリース 2：**検索、数量の調整、プロモーションコード
• **リリース 3：**おすすめ、ゲストチェックアウト、ギフトオプション

これがうまくいく理由：

• バックボーンがユーザーのナラティブに沿っている（技術レイヤーではない）
• ウォーキングスケルトンでエンドツーエンドの価値を提供できる
• 段階的なリリースで、コアフローを壊すことなく機能を高度化できる

---

例 2：不適切なストーリーマップ（技術レイヤー）

バックボーン（誤り）：

UI Layer → API Layer → Database Layer → Deployment

これがうまくいかない理由：

• ユーザー中心ではない（ユーザーは技術アーキテクチャを気にしない）
• エンドツーエンドの価値を段階的に提供できない
• ストーリーマッピングを装ったウォーターフォール思考

修正方法：

• ユーザーのワークフローに沿ってマッピングする：「サインアップ → 設定 → チームを招待 → プロジェクトを開始」
• 各リリースでは単一のレイヤーではなく、ワークフロー全体を提供する

---

よくある落とし穴

落とし穴 1：名前を変えただけのフラットなバックログ

**症状：**ストーリーマップが単なる縦のリストで、横方向のナラティブがない

**結果：**コミュニケーション上の利点が失われ、依然として「文脈のない寄せ集め」のまま

**修正方法：**横方向の構造を徹底する。上部にアクティビティを並べ、タスクをその下に縦に配置する

---

落とし穴 2：バックボーンが技術アーキテクチャ

**症状：**バックボーンが「フロントエンド → バックエンド → データベース」になっている

**結果：**ユーザー中心ではなく、価値を段階的に提供できない

**修正方法：**バックボーンはシステムのレイヤーではなく、ユーザーのワークフローに沿わせる

---

落とし穴 3：機能単位で完成させるウォーターフォール

**症状：**リリース 1 が「アクティビティ 1 を完全に構築」、リリース 2 が「アクティビティ 2 を完全に構築」になっている

**結果：**すべてのアクティビティが完了するまで、エンドツーエンドの価値がない

**修正方法：**ウォーキングスケルトンは、すべてのアクティビティにまたがる薄いスライスとし、段階的に強化する

---

落とし穴 4：早い段階で詳細を詰め込みすぎる

**症状：**あらゆるエッジケースや受け入れ基準を最初からマッピングしようとする

**結果：**分析麻痺に陥り、全体像を見失う

**修正方法：**バックボーンと大まかなタスクから始め、後で詳細化する

---

落とし穴 5：ツールの中に隠されたマップ

**症状：**ストーリーマップが Jira／Miro に保存され、表示されない

**結果：**情報放射板としての価値が失われる

**修正方法：**マップを印刷または掲示し、チームが毎日見られるようにする

---

参考資料

関連スキル

• skills/user-story-mapping/SKILL.md — ストーリーマッピングのテンプレートを含むコンポーネントスキル
• skills/user-story/SKILL.md — マップ上のタスクを詳細なユーザーストーリーに変換します
• skills/proto-persona/SKILL.md — マッピング対象のユーザーを定義します
• skills/jobs-to-be-done/SKILL.md — バックボーンのアクティビティに情報を提供します

外部フレームワーク

• Jeff Patton、User Story Mapping（2014年）— ストーリーマッピングフレームワークの起源
• Jeff Patton、「The New User Story Backlog is a Map」（ブログ）— バックボーンの概念を解説しています

Deanの取り組み

• [Deanにストーリーマッピングのリソースがあれば、ここにリンクしてください]

来歴

• skills/user-story/SKILL.md、skills/user-story-splitting/SKILL.md、skills/user-story-mapping/SKILL.mdを基にしています。

---

スキルの種類： インタラクティブ 推奨ファイル名： user-story-mapping-workshop.md 推奨配置場所： /skills/interactive/ 依存関係： skills/user-story-mapping/SKILL.md、skills/user-story/SKILL.md、skills/proto-persona/SKILL.mdを使用します