roadmap-planning

目的

優先順位付け、エピックの定義、ステークホルダーとの合意形成、リリースの順序付けに関するスキルを構造化されたプロセスとして組み合わせ、プロダクトマネージャーによる戦略的なロードマップ計画を支援します。これを活用して、まとまりのない機能リクエストを、ステークホルダーの足並みをそろえ、作業を論理的な順序で並べ、戦略的な意図を伝える、一貫性のある成果重視のロードマップへとまとめましょう。戦略的なストーリーや顧客中心の枠組みが欠けた「機能工場」のようなロードマップを避けられます。

これはガントチャートではありません。何を作るのか、それがなぜ重要なのか、そして事業成果にどうつながるのかを示す、戦略的なコミュニケーションツールです。

入力

特に役立つ情報： 対象となるプロダクトと計画期間（次の四半期、来年など）。 あると便利な情報： ひも付ける戦略や OKR、候補となる取り組みのリスト、チームのキャパシティ、既知のステークホルダーからの圧力。

スキル名に続けて入力されたテキスト、貼り付けられたコンテキスト情報、追記された ARGUMENTS: の行など、呼び出し時に提供された内容はすべて、すでに回答済みの情報として扱います。それを活用し、該当する内容については質問を繰り返さないでください。

情報がなくても問題ありません。 このワークフローは戦略的なコンテキストの確立から始まり、優先順位付け、エピックの定義、順序付けへと進みます。

呼び出し例： Plan a 2-quarter roadmap for our mobile app: here are our 3 OKRs and a list of 12 candidate initiatives.

主要な概念

戦略的なロードマップ計画とは？

ロードマップ計画とは、次のプロセスです。

1. 情報を集める — 顧客の課題、事業目標、技術的な制約
2. 取り組みを定義する — 明確な仮説と成功指標を伴うエピック
3. 優先順位を付ける — 影響度、工数、戦略との適合性に基づいて取り組みを順位付けする
4. 順序を決める — 論理的な依存関係を考慮して、リリースや四半期に割り当てる
5. 伝える — 戦略的なストーリーとともにロードマップをステークホルダーに提示する

ロードマップの種類

Now／Next／Later ロードマップ：

• Now： 現在の四半期（確定済み）
• Next： 次の四半期（確度が高い）
• Later： 将来の検討事項（確度が低い）
• 最適な用途： アジャイルチーム、不確実性への対応、継続的なディスカバリー

テーマベースのロードマップ：

• 戦略的なテーマ（例：「リテンション」「エンタープライズへの拡大」「モバイル体験」）ごとに整理します
• 最適な用途： 経営幹部への説明、戦略的な意図の提示

タイムライン型ロードマップ（四半期）：

• 第1四半期：エピック A、B、第2四半期：エピック C、D、第3四半期：エピック E、F
• 最適な用途： リソース計画、ステークホルダーとのコミュニケーション

機能ベースのロードマップ（アンチパターン）：

• 背景のない機能の一覧（例：「ダークモード」「SSO」「高度なレポート機能」）
• 失敗する理由： 戦略的なストーリーがなく、顧客の課題が明確に示されていません

効果がある理由

• 成果重視： 取り組みを事業や顧客の成果に結び付けます
• ステークホルダーとの合意形成： プロセスの透明性によって、政治的な摩擦を減らします
• 戦略の明確化： 「何を」するかだけでなく、「なぜ」するのかも示します
• 柔軟性： ディスカバリーやデリバリーを通じて得た知見に応じて適応します

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

• 確約ではありません： ロードマップは戦略計画であり、契約ではありません
• 機能一覧ではありません： ロードマップでは、解決策だけでなく課題を明確にします
• ウォーターフォールではありません： 学びに応じて、ロードマップは四半期ごとに進化します

この方法を使うタイミング

• 年次または四半期ごとの計画サイクル
• プロダクト戦略セッションの後（戦略をロードマップに反映する）
• 新しいステークホルダーのオンボーディング（方向性について合意を形成する）
• 既存のロードマップの再構成（機能主導から成果主導へ移行する）

この方法を使わないタイミング

• 戦術的なスプリント計画の場合（代わりにバックログを使用する）
• 戦略が不明確な場合（最初に product-strategy-session を実施する）
• ステークホルダーが日付の確約を期待している場合（最初に期待値を調整する）

---

ファシリテーションにおける唯一の参照元

このワークフローをガイド付きの会話として実行する場合は、workshop-facilitationを対話プロトコルとして使用してください。

次の内容を定義します。

• セッション開始時の案内と開始モード（ガイド付き、コンテキストの一括提示、最善の推測）
• 平易な表現のプロンプトを使った、1ターンにつき1つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 割り込みへの対応と一時停止・再開の動作
• 判断が必要な場面での番号付きの推奨事項
• 通常の質問に対する番号付きのクイック選択回答オプション（役立つ場合はOther (specify)を含める）

このファイルでは、ワークフローの手順と、分野固有の出力を定義します。競合がある場合は、このファイルのワークフローのロジックに従ってください。

適用

全項目を記入する形式にはtemplate.mdを使用してください。

このワークフローでは、複数のコンポーネントスキルと対話型スキルを使用して、1～2週間にわたる5つのフェーズを進行します。

---

フェーズ1：入力を収集する（1～2日目）

**目標：**ビジネス目標、顧客の課題、技術的制約、ステークホルダーからの要望を収集します。

アクティビティ

1. ビジネス目標を確認する（OKR、戦略的取り組み）

• **情報源：**会社のOKR、経営陣の戦略メモ、取締役会資料
• 質問：
  • 今年、会社が最優先する事項は何ですか？3つ挙げてください。
  • どの指標を改善する必要がありますか？（売上、顧客維持、顧客獲得、効率性）
  • 戦略的な賭けはありますか？（新しい市場、パートナーシップ、製品ライン）
• **出力：**最適化するビジネス成果を3～5件

2. 顧客の課題を確認する（ディスカバリーから得られた知見）

• **情報源：**ディスカバリーインタビュー、サポートチケット、NPSフィードバック、解約アンケート
• **使用：**最近完了している場合は、skills/discovery-process/SKILL.mdの知見を使用します。
• 質問：
  • 顧客の主なペインポイントを3～5件挙げてください。
  • 最も多くの顧客に影響している問題はどれですか？
  • 影響の度合いが最も大きい問題はどれですか？
• **出力：**検証済みの顧客課題を3～5件

3. 技術的制約と機会を確認する

• **情報源：**エンジニアリング部門のリーダー、技術的負債の評価
• 質問：
  • 技術的な阻害要因はありますか？（スケーリング、パフォーマンス、セキュリティ）
  • 実現に役立つ投資はありますか？（プラットフォームのアップグレード、APIの書き換え）
  • 技術ロードマップはどうなっていますか？（移行、廃止）
• **出力：**必要な技術投資の一覧

4. ステークホルダーからの要望を確認する

• **情報源：**営業、マーケティング、カスタマーサクセス、経営陣
• 質問：
  • 営業からは何を求められていますか？（エンタープライズ向け機能、インテグレーション）
  • マーケティングからは何を求められていますか？（成長施策、ポジショニング）
  • カスタマーサクセスからは何が指摘されていますか？（解約リスク、拡大の阻害要因）
• **出力：**ステークホルダーからの要望一覧（まだ確約していないもの）

フェーズ1の出力

• **ビジネス成果：**OKRまたは戦略目標を3～5件
• **顧客の課題：**検証済みのペインポイントを3～5件
• **技術投資：**プラットフォーム／技術的負債に関する項目
• **ステークホルダーからの要望：**社内チームからの機能要望

---

フェーズ2：イニシアチブ（エピック）を定義する（3～4日目）

**目標：**入力情報を、仮説、成功指標、工数見積もりを含むエピックにまとめます。

アクティビティ

1. エピックの仮説を定義する

• 使用: skills/epic-hypothesis/SKILL.md (コンポーネント)
• 各イニシアチブについて: 仮説ステートメントを書く
• 形式: 「私たちは、[ペルソナ] 向けの [X の構築] が [成果] を達成すると信じています。なぜなら [前提] だからです。」
• 参加者: PM
• 所要時間: エピックごとに 60 分
• 成果物: 10〜15 件のエピック仮説

エピックの例 (SaaS プロダクト):

Epic 1: Guided Onboarding
Hypothesis: We believe that adding a step-by-step onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.

Success Metric: Activation rate (% completing first action within 24 hours)
Target: 40% → 60%

Epic 2: Enterprise SSO
Hypothesis: We believe that adding SSO for enterprise accounts will increase enterprise deals closed from 2/quarter to 5/quarter because enterprise buyers require SSO for security compliance.

Success Metric: Enterprise deals closed per quarter
Target: 2 → 5

Epic 3: Mobile-Optimized Workflows
Hypothesis: We believe that optimizing core workflows for mobile will increase mobile DAU from 5% to 20% because mobile-first users currently can't complete workflows on the go.

Success Metric: Mobile DAU as % of total DAU
Target: 5% → 20%

2. 工数を見積もる (Tシャツサイズ見積もり)

• 参加者: PM + エンジニアリングリード
• 所要時間: 90 分
• 方法:
  • Small (S): 1〜2 週間 (エンジニア 1〜2 名)
  • Medium (M): 3〜4 週間 (エンジニア 2〜3 名)
  • Large (L): 2〜3 か月 (エンジニア 3〜5 名)
  • Extra Large (XL): 3 か月以上 (エンジニア 5 名以上)
• 成果物: エピックごとの工数見積もり

3. ビジネス成果にマッピングする

• 各エピックについて: 主要なビジネス成果でタグ付けする
• 例:
  • エピック 1 (ガイド付きオンボーディング) → リテンション
  • エピック 2 (エンタープライズ SSO) → 獲得 (エンタープライズ)
  • エピック 3 (モバイルワークフロー) → エンゲージメント

フェーズ 2 の成果物

• 10〜15 件のエピック: それぞれに仮説、成功指標、工数見積もりを含む
• ビジネス成果のマッピング: どのエピックがどの OKR を推進するか

---

フェーズ 3: イニシアチブに優先順位を付ける (5 日目)

目標: インパクト、工数、戦略的適合度によってエピックを順位付けします。

アクティビティ

1. 優先順位付けフレームワークを選ぶ

• 使用: skills/prioritization-advisor/SKILL.md (インタラクティブ)
• 参加者: PM
• 所要時間: 30 分
• 成果物: 推奨フレームワーク (RICE、ICE、Value/Effort など)

2. エピックをスコアリングする

• 参加者: PM、エンジニアリングリード、プロダクトリーダーシップ
• 所要時間: 120 分
• 方法: すべてのエピックにフレームワークを適用する
• 例 (RICE スコアリング):

エピック	リーチ	インパクト	確信度	工数	RICE スコア
ガイド付きオンボーディング	10,000 ユーザー	3 (甚大)	80%	1 か月	24,000
エンタープライズ SSO	500 ユーザー	3 (甚大)	90%	2 か月	675
モバイルワークフロー	5,000 ユーザー	2 (高)	60%	3 か月	2,000
高度なレポート	2,000 ユーザー	2 (高)	50%	2 か月	1,000

3. 戦略的適合度に合わせて調整する

• スコアを確認: ビジネス目標と一致していますか？
• 戦略的オーバーライド: 戦略的賭けに沿うエピックを昇格させる (スコアが低くても)
• 例: エンタープライズ SSO はスコアが低いですが、エンタープライズ拡大戦略にとって重要です → 優先度を引き上げます

フェーズ 3 の成果物

• 順位付けされたバックログ: 優先度順に並べたエピック (RICE スコア + 戦略的調整)
• トップ 10 エピック: ロードマップに向けた最優先のイニシアチブ

---

フェーズ 4: ロードマップを順序付ける (6〜7 日目)

目標: 論理的な依存関係を考慮して、エピックを四半期/リリースに整理します。

アクティビティ

1. 依存関係をマッピングする

• 質問:
  • エピック B はエピック A に依存していますか？ (例:「高度なレポート」には「データパイプラインのアップグレード」が必要)
  • 技術的なブロッカーはありますか？ (例:「モバイルアプリ」には「API 再設計」が必要)
• 成果物: 依存関係グラフ (エピック A → エピック B → エピック C)

2. 四半期 (またはリリース) ごとに順序付ける

• Now (Q1): 上位 3〜5 件のエピック、依存関係なし
• Next (Q2): 次の 3〜5 件のエピック、Q1 の完了に依存する場合あり
• Later (Q3+): 残りのエピック、確信度は低め

ロードマップの例 (タイムライン形式):

Q1 2026 (Now - Committed):
├─ Guided Onboarding (Retention)
├─ Enterprise SSO (Acquisition)
└─ Mobile-Optimized Workflows (Engagement)

Q2 2026 (Next - High Confidence):
├─ Advanced Reporting (depends on Data Pipeline, Q1)
├─ Slack Integration (Engagement)
└─ Pricing Page Redesign (Acquisition)

Q3 2026 (Later - Lower Confidence):
├─ Mobile App (depends on API Redesign)
├─ AI-Powered Recommendations
└─ Multi-Language Support

Q4 2026 (Exploration):
├─ Marketplace/Plugin Ecosystem
└─ Enterprise Onboarding Concierge

代替案: Now/Next/Later ロードマップ

NOW (Current Quarter):
- Guided Onboarding
- Enterprise SSO
- Mobile-Optimized Workflows

NEXT (Following Quarter):
- Advanced Reporting
- Slack Integration
- Pricing Page Redesign

LATER (Future):
- Mobile App
- AI Recommendations
- Multi-Language Support

3. エンジニアリングと検証する

• 参加者: PM + エンジニアリングリード
• 質問:
  • 順序は現実的ですか？ (キャパシティ、依存関係)
  • 隠れた技術的ブロッカーはありますか？
  • スコープを調整する必要がありますか？
• 成果物: 検証済みのロードマップ順序

フェーズ 4 の成果物

• 順序付けされたロードマップ: Q1、Q2、Q3 ごとに整理されたエピック
• 依存関係マップ: 何が何に依存しているか
• キャパシティチェック: エンジニアリングが順序の実現可能性に同意している

---

フェーズ 5: ロードマップを伝える (第 2 週)

目標: ステークホルダーにロードマップを提示し、フィードバックを集め、合意形成を図ります。

アクティビティ

1. ロードマップのプレゼンテーションを作成する

• 形式： 30〜45 分のプレゼンテーション
• 構成：
  • スライド 1： 戦略的背景（ビジネス目標、顧客の課題）
  • スライド 2〜3： ロードマップの概要（Q1、Q2、Q3）
  • スライド 4〜6： 四半期ごとの詳細（エピック、仮説、成功指標）
  • スライド 7： ロードマップに含まれないもの（およびその理由）
  • スライド 8： 依存関係とリスク
• 参加者： PM、デザイン
• 所要時間： 準備に 2〜3 時間

2. ステークホルダーに発表する

• 対象者： 経営幹部、プロダクトリーダーシップ、エンジニアリング、営業、マーケティング、CS
• 所要時間： 45 分のプレゼンテーション＋15 分の質疑応答
• 重点項目：
  • 戦略的なストーリー：「Y より X を優先する理由は次のとおりです」
  • 成果を重視：「各エピックが［ビジネス成果］をもたらします」
  • 柔軟性：「このロードマップは計画であり、確約ではありません。学びを得ながら調整していきます」

3. フィードバックを集める

• 質問する項目：
  • この優先順位はビジネス目標に沿っていますか？
  • 重要な顧客の課題を見落としていませんか？
  • 依存関係は明確ですか？
  • 懸念事項はありますか？
• 成果物： フィードバック、懸念事項、質問の一覧

4. ロードマップを改善する

• フィードバックに基づく対応： 優先順位を調整し、見落としていたエピックを追加し、依存関係を明確にします
• 所要時間： 1〜2 日
• 成果物： 最終版ロードマップ v1.0

5. ロードマップを公開する

• 社内： チームと共有します（Confluence、Notion、Productboard など）
• 社外（任意）： 顧客向けの公開ロードマップ（Now/Next/Later 形式を使用）
• 形式： ビジュアルロードマップ＋説明ドキュメント

フェーズ 5 の成果物

• ロードマップのプレゼンテーション： 30〜45 分のスライド資料
• ステークホルダー間の合意： フィードバックを反映し、懸念事項に対応
• 公開済みロードマップ： チーム（社内）または顧客（社外）が閲覧可能

---

ワークフロー全体：エンドツーエンドの概要

Week 1:
├─ Day 1-2: Gather Inputs
│  ├─ Review business goals (OKRs)
│  ├─ Review customer problems (discovery insights)
│  ├─ Review technical constraints
│  └─ Review stakeholder requests
│
├─ Day 3-4: Define Initiatives (Epics)
│  ├─ skills/epic-hypothesis/SKILL.md (60 min per epic)
│  ├─ Estimate effort (90 min)
│  └─ Map to business outcomes
│
├─ Day 5: Prioritize Initiatives
│  ├─ skills/prioritization-advisor/SKILL.md (30 min)
│  ├─ Score epics (120 min)
│  └─ Adjust for strategic fit
│
└─ Day 6-7: Sequence Roadmap
   ├─ Map dependencies
   ├─ Sequence by quarter (Q1, Q2, Q3)
   └─ Validate with engineering

Week 2:
└─ Communicate Roadmap
   ├─ Create presentation (2-3 hours)
   ├─ Present to stakeholders (60 min)
   ├─ Gather feedback
   ├─ Refine roadmap (1-2 days)
   └─ Publish roadmap

総所要時間：

• 短縮プラン： 1 週間（既存のエピックを活用し、迅速に合意）
• 標準： 1.5〜2 週間（エピックを定義し、ステークホルダーがレビュー）

---

例

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

短い例：

Now: Guided onboarding (activation +20%)
Next: Enterprise SSO (deal velocity)
Later: Mobile workflows (DAU lift)

よくある落とし穴

落とし穴 1：機能主導のロードマップ（成果がない）

症状： ロードマップに、背景説明のない機能（「ダークモード」「SSO」「高度なフィルター」）が列挙されている

結果： 戦略が明確でなく、ステークホルダーが「なぜ」を理解できない

対策： エピックを、成功指標を伴う仮説として提示します（単なる機能名にしない）

---

落とし穴 2：HiPPO（最高額報酬者の意見）による優先順位付け

症状： 経営幹部がロードマップを指示し、データに基づく優先順位付けが行われない

結果： 間違ったものを作り、顧客の課題を無視してしまう

対策： 優先順位付けのフレームワーク（RICE、ICE）を使って、エピックを透明性のある方法でスコアリングします

---

落とし穴 3：ロードマップを確約とみなす（ウォーターフォール思考）

症状： ロードマップが契約のように扱われ、調整する余地がない

結果： 新しい情報を得ても方向転換できない

対策： ロードマップを「学びに応じて変更される戦略的計画」として伝えます

---

落とし穴 4：依存関係を整理していない

症状： 技術的な依存関係を確認せずに、エピックの順序を決める

結果： Q1 の依存項目が完了せず、Q2 のエピックがブロックされる

対策： フェーズ 4 で依存関係を明示的に整理し、エンジニアリングチームと検証します

---

落とし穴 5：PM 単独のロードマップ（ステークホルダーの意見を取り入れない）

症状： PM がロードマップを一人で作成し、完成した計画を発表する

結果： 賛同が得られず、ステークホルダーが疎外感を抱く

対策： フェーズ 1 で全ステークホルダーから意見を集め、フェーズ 5 でドラフトを発表してフィードバックを得ます

---

参考資料

関連スキル (このワークフローによってオーケストレーションされる)

フェーズ 2:

• skills/epic-hypothesis/SKILL.md (コンポーネント)

フェーズ 3:

• skills/prioritization-advisor/SKILL.md (インタラクティブ)

フェーズ 4:

• (依存関係は手動でマッピング、特定のスキルなし)

フェーズ 5:

• (プレゼンテーションは手動で作成、特定のスキルなし)

オプション/関連:

• skills/product-strategy-session/SKILL.md (ワークフロー) — ロードマップ計画の前に実行して戦略を確立します
• skills/discovery-process/SKILL.md (ワークフロー) — フェーズ 1 に顧客課題のインプットを提供します
• skills/user-story-mapping-workshop/SKILL.md (インタラクティブ) — リリース計画が必要な複雑なエピック向け

外部フレームワーク

• Bruce McCarthy, Product Roadmaps Relaunched (2017) — アウトカム駆動型ロードマップ
• C. Todd Lombardo, Product Roadmaps Relaunched (2017) — Now/Next/Later フレームワーク
• Intercom, "RICE Prioritization" (2016) — 優先順位付けフレームワーク

Dean の成果物

• [Dean がロードマップ計画のリソースを持っている場合は、ここにリンクしてください]

---

スキルタイプ: ワークフロー 推奨ファイル名: roadmap-planning.md 推奨配置場所: /skills/workflows/ 依存関係: skills/epic-hypothesis/SKILL.md、skills/prioritization-advisor/SKILL.md、および手動アクティビティをオーケストレーションします