mcpField
R
roadmap-planning

roadmap-planning

github.com/shawnpang生産性370192 回インストール33 週間前に更新
リポジトリ

roadmap-planning について

roadmap-planningは、創業者やプロダクトマネージャーがアイデアや機能要望を成果重視のプロダクトロードマップにまとめるためのスキルです。RICEで優先順位を付け、Now、Next、Laterに分けて、依存関係とチームの対応力を確認します。

主な機能

  1. 01成果を軸にした施策の定義
  2. 02RICEによる優先順位付け
  3. 03Now、Next、Laterの期間区分
  4. 04依存関係と実施順の整理
  5. 05対応力の確認とリスク記録

活用シーン

  1. 01機能バックログの優先順位付け
  2. 02四半期のプロダクトロードマップ作成
  3. 03顧客成果を軸にした機能一覧の再構成
  4. 04チームの対応力に照らした計画範囲の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shawnpang/startup-founder-skills --skill roadmap-planning

インストール後、Claude Code で/roadmap-planningを入力して読み込まれたか確認します。

詳細

ロードマップの計画

使用するタイミング

創業者または PM が複数のプロダクトアイデア、機能リクエスト、戦略的な賭けを抱えており、それらを一貫性のあるロードマップに整理する必要がある場合に有効化します。「第 2 四半期のロードマップを計画したい」「この機能バックログの優先順位を付けたい」「次に何を作るべきか」「今後 6 か月のロードマップを作成して」といった状況が該当します。また、既存のロードマップを、アウトプット重視(機能の一覧)からアウトカム重視(顧客やビジネスへの影響)へ再構成する必要がある場合にも有効化します。

必要なコンテキスト

  • startup-context から: 会社の段階、チームの規模と構成、現在のプロダクトの状態、ビジネスモデル、主要指標、戦略目標、会社の OKR。
  • ユーザーから: 現在のロードマップまたは候補となる施策の一覧、既知の顧客ニーズ、リソースの制約、厳守すべき期限、整合性を取るための戦略文書または会社目標、すでに着手している確約済みの作業。

ワークフロー

  1. 現状を把握する -- 既存のロードマップまたは機能一覧を集めます。ユーザーから戦略文書や会社目標が提供された場合は、より広範な目標とロードマップをどのように整合させるべきかを理解するために確認します。
  2. アウトプットをアウトカムに変換する -- 各施策について、次の点を確認します。どのような顧客の課題を解決するのか。どのビジネス指標が改善するのか。同じアウトカムを達成する、より良い方法はあるか。各項目をアウトカムの記述に書き換えます。
  3. アウトカム記述の形式を適用する -- 次の形式を使用します。「[顧客セグメント] が [望ましい顧客アウトカム] を達成できるようにし、それによって [ビジネスへの影響] をもたらす。」すべてのロードマップ項目がこの条件を満たす必要があります。
  4. スコアを付けて優先順位を決める -- RICE スコアリング(リーチ、インパクト、確信度、工数)を適用して施策を順位付けします。会社目標および OKR との戦略的な整合性も加味します。
  5. 依存関係と順序を特定する -- どの施策がほかの施策に依存しているかを整理します。技術、データ、デザイン、ビジネス面の依存関係を記録します。
  6. 時間軸ごとに順序を決める -- 施策を「Now」(0~6 週間)、「Next」(6~12 週間)、「Later」(12 週間以降)に振り分けます。「Later」の項目には、具体的な日付ではなく、柔軟なリリース期間(四半期単位)を設定します。
  7. 実行能力を検証する -- 計画をチームの実行能力と照合します。エンジニアリングの処理能力の 3 倍を必要とするロードマップは計画ではなく、願望リストです。
  8. 戦略的な背景を加える -- アウトカムと会社の戦略との整合性、顧客ニーズに関する主要な前提、レビューの頻度を記録します。

出力形式

戦略的背景

会社の現在の戦略的優先事項と、このロードマップがそれらにどう貢献するかを一段落で説明します。顧客ニーズに関する主要な前提も含めます。

アウトカム重視のロードマップ
Now(0~6 週間)-- 確定
施策アウトカムの記述主要指標担当者依存関係
元の機能/プロジェクト[セグメント] が [アウトカム] を達成できるようにし、それによって [影響] をもたらす指標 + 目標値チーム一覧
Next(6~12 週間)-- 確度高

同じ形式の表を使用します。ここに記載する項目は計画済みですが、「Now」で得られた知見に基づいて変更される可能性があります。

Later(12 週間以降)-- 探索的

同じ形式の表を使用します。ここに記載する項目は方向性を示すものです。期間は柔軟に設定し、担当者はまだ割り当てません。

実施しないこと(およびその理由)

明確に対象から除外する施策と、その理由を記載します。このセクションはロードマップそのものと同じくらい重要です。

依存関係マップ

どの施策がほかの施策を妨げる、または可能にするかを視覚的または文章で表現します。

実行能力の確認

各時間軸における見積もり工数と利用可能な実行能力をまとめます。

主要な前提とリスク

このロードマップを成功させるために必要な条件を番号付きリストにします。

フレームワークとベストプラクティス

  • アウトプットより成果を重視します。「高度な検索フィルターを構築する」はアウトプットです。「直感的な探索機能によって、お客様が商品を50%早く見つけられるようにする」は成果です。アウトプット重視のロードマップは、精度があるかのような錯覚を生み、成果ではなく機能を中心にチームの方向性をずれさせます。
  • 成果の記述形式。「[顧客セグメント]が[望ましい顧客成果]を達成できるようにし、[ビジネスへの影響]につなげる。」この形式によって、誰が恩恵を受けるのか、何が変わるのか、なぜ重要なのかが明確になります。
  • **「それで何が変わるのか?」テスト。**機能がもたらす成果を説明できない場合は、実際の顧客価値やビジネス価値にたどり着くまで「それで何が変わるのか?」と問い続けます。複数のアウトプットで1つの成果を達成できることもあります。成果に焦点を当てましょう。
  • RICE スコアリング。
    • **リーチ:**四半期あたり、何人のユーザー/アカウントに影響しますか?
    • **インパクト:**0.25(最小)から3(最大)までの尺度で、目標指標にどの程度の変化をもたらしますか?
    • **確信度:**リーチとインパクトの見積もりに、どの程度の確信がありますか?パーセンテージで示します。
    • **工数:**必要な人週。
    • スコア:(リーチ x インパクト x 確信度)/ 工数。
  • 3つの時間軸で構成します。「今/次/後で」と分けることで、ガントチャートのような精度があるかのような錯覚を避けられます。「今」に取り組むことを約束し、「次」の計画を立て、「後で」は検討します。
  • 成果ロードマップは変化に強いものです。「何を」ではなく「なぜ」を示すため、戦略の転換や新たな情報に対して、機能ロードマップよりも柔軟に対応できます。
  • **明確に断ります。**ロードマップは、何を含めるかと同じくらい、何を含めないかによって定義されます。「実施しないこと」のリストを作成し、その理由を共有しましょう。
  • **OKR と整合させます。**すべての成果の記述を、会社またはプロダクトの OKR に紐づけます。どこにも紐づかない取り組みは、方向性のずれを示しています。
  • **四半期ごとに見直します。**1四半期を超えて更新されていないロードマップは古くなっています。定期的なレビューの機会を設けましょう。
  • 段階に応じた計画を立てます。
    • **PMF 前:**学習に焦点を当てた4~6週間のスプリントでロードマップを作成します。12か月計画は立てません。
    • **PMF 後:**OKR に紐づけた四半期ごとのロードマップを作成します。成長機能とインフラストラクチャや技術的負債のバランスを取ります。
    • **スケーリング期:**チーム間の調整を伴う半年ごとのロードマップを作成します。依存関係への対応が大きな課題になります。
  • **ロードマップを見せかけだけのものにしないでください。**チームに実行する能力や確信がない場合、ステークホルダーを満足させるために凝ったロードマップを作成してはいけません。

関連スキル

  • prd-writing -- 「今」の時間軸で取り組むことが決まったら、仕様をまとめるために PRD を作成します。
  • mvp-scoping -- 取り組みをロードマップに載せる前に、現実的な工数を見積もるため、MVP の範囲を定めます。
  • user-research-synthesis -- 顧客のインサイトを活用して、対象セグメントにとって最も重要な成果を検証します。

例

例 1:アウトプットから成果への変換

ユーザー:「第2四半期の計画には、高度な検索フィルターの構築、AI レコメンデーションの実装、ダッシュボードの再設計が含まれています。これを成果ロードマップに変換してください。」

良い出力例:

変換:

  • アウトプット:「高度な検索フィルターを構築する」 --> 成果:「直感的な探索機能によって、お客様が商品を50%早く見つけられるようにする」
  • アウトプット:「AI レコメンデーションを実装する」 --> 成果:「パーソナライズされた探索機能によって、平均注文額を20%増加させる」
  • アウトプット:「ダッシュボードを再設計する」 --> 成果:「ダッシュボードの読み込み時間を80%短縮し、オペレーターがすべてのシステムを監視できるようにする」

これで各成果は検証・測定可能になり、当初指定されていた機能以外の解決策も検討できるようになります。

例 2:機能バックログからロードマップへ

ユーザー:「これが機能バックログです:Slack 連携、SSO、レポート用ダッシュボード、モバイルアプリ、API v2、オンボーディングウィザード。ロードマップの作成を手伝ってください。」

良い出力例:

今(0~6週間): | オンボーディングウィザード | 新規登録ユーザーが10分以内に最初の価値を得られるようにし、アクティベーション率を35%から55%に引き上げる | アクティベーション率 | グロースチーム | なし |

今四半期に実施しないこと:

  • モバイルアプリ -- 現在の利用データによると、モバイルからのセッションは5%未満です。モバイル需要の兆候が強まったら再検討します。「それで何が変わるのか?」と問いかけても、現時点では説得力のある顧客成果が見えてきません。

コメント