roadmap-planning

roadmap-planning skillの概要

roadmap-planning skill は、散らばった要望、目標、制約を、ステークホルダーのレビューに耐えうる戦略的なロードマップへと整理するための skill です。単なる機能一覧では足りず、順序づけ、トレードオフの考え方、そして「なぜ今これを入れ、次に何をし、後回しにするのか」を明確に説明する必要があるチームに最適です。Product Management のために roadmap-planning を行うなら、この skill は戦略から実行への受け渡しを支える用途に向いています。

roadmap-planning skill は何のためにあるのか

この skill は、OKR、顧客の痛み、依存関係、ざっくりした施策案のような入力はすでにあるものの、それらを一貫したリリース計画に落とし込みたいときに使います。やるべきことは、作業を優先順位づけし、適切な粒度で epic を定義し、ロードマップを output ではなく outcome に結びつけることです。そうすることで、経営層との会話でも説明しやすくなり、デリバリー担当チームにとっても実行しやすいロードマップになります。

この skill が特に向いているケース

roadmap-planning skill は、年次計画、四半期計画、チーム横断の順序設計のように、量よりも選択の質が重要な場面に向いています。複数のステークホルダーがそれぞれ別の要望を出していて、何を先に出すかを筋道立てて決める必要があるときに特に有効です。「アイデアが多すぎる」というのが主な悩みなら、汎用プロンプトよりもこちらのほうが適しています。

何が違うのか

この workflow は、単なる整形ではなく、戦略的なフレーミングを重視します。施策を顧客課題、事業目標、依存関係に結びつけるよう促すため、ロードマップにストーリーが生まれます。そのため、単純な優先順位表よりも納得感が高くなりやすく、作業の順番づけにあるロジックも伝わります。

roadmap-planning skill の使い方

roadmap-planning をインストールする

リポジトリの skill コマンドで roadmap-planning skill をインストールします。

npx skills add deanpeters/Product-Manager-Skills --skill roadmap-planning

インストール後は、まず skills/roadmap-planning/SKILL.md を開いてください。ここに workflow の意図、適したケース、期待される計画の流れが定義されています。次に template.md で出力形式を確認し、examples/sample.md で実際の good vs bad の比較を見てください。

適切な入力を与える

roadmap-planning の使い方は、「ロードマップを作って」とだけ頼む曖昧な依頼より、具体的な入力があるときに最も効果を発揮します。次のような情報を与えてください。

• business goals や OKR
• 対象となる顧客セグメント
• 候補となる initiative や epic
• 分かっている依存関係や制約
• quarter や half-year などの時間軸
• トレードオフに影響しそうなステークホルダーの立場

弱いプロンプトの例は「ロードマップを計画して」です。より強い例は「SMB の onboarding と retention に向けた Q2 の roadmap を、churn を 15% から 8% に下げるという目標、8 件の候補 initiative、2 つの engineering 制約、そして経営層にトレードオフを示す必要がある前提で計画して」のようになります。

推奨ワークフローと参照ファイル

この skill は、計画の補助役として使い、その後に自分の product 文脈で妥当性を確認するのが実践的です。おすすめの流れは次のとおりです。

1. 目標、顧客課題、制約を集める。
2. 候補となる epic を起こし、関連する作業をまとめる。
3. skill に outcome ベースで優先順位づけと順序づけを依頼する。
4. ロードマップのストーリーがステークホルダーの現実と合っているか確認する。
5. 実現可能性、依存関係の順序、伝え方を見直す。

repo をざっと見るなら、最初に SKILL.md、template.md、examples/sample.md を確認してください。これらのファイルを見ると、ロードマップの期待される形、抽象度のレベル、そしてこの skill が戦略的ロードマップと backlog の寄せ集めをどう見分けるかが分かります。

出力品質を上げるコツ

何を守るべきか、何なら動かせるか、まだ不確かな点はどこかを明確にしてください。roadmap-planning ガイドは、launch window、チームの capacity、ブロックされている依存関係のような厳しい制約をはっきり書くほどよく機能します。また、ロードマップが社内向けか、経営層向けか、顧客向けかも伝えてください。コミュニケーションのトーンと詳細度はそれによって変えるべきだからです。

roadmap-planning skill の FAQ

roadmap-planning は Product Management 専用ですか？

Product Management 向けの roadmap-planning として設計されていますが、構造化されたリリース計画が必要な隣接ロールでも使えます。特に強いのは、単なるタスク管理ではなく、優先順位づけとステークホルダー調整を担う人が使う場合です。engineering の sprint plan だけを作るのであれば、この skill はたいてい戦略寄りすぎます。

通常のプロンプトとどう違うのですか？

通常のプロンプトでもロードマップの下書きはできますが、この skill には、優先順位づけ、epic の定義、順序づけ、コミュニケーションまでを一貫して扱う再現性のある workflow があります。そのため、理由のない機能一覧に終わるリスクを下げられます。実務では、計画サイクルをまたいで一貫性が必要なときに roadmap-planning skill の価値が高まります。

初心者でも使いやすいですか？

はい、基本的な product 文脈を出せるなら使えます。最初から完成度の高い戦略文書は必要なく、ざっくりした入力を説明可能なロードマップに整理するための skill です。初心者は、template を使い、明確な目標と制約を入れると、より良い結果を得やすくなります。

どんなときは使わないほうがいいですか？

詳細な delivery plan、release checklist、あるいは純粋に technical な実装順序が必要なときには使わないでください。入力が不十分すぎてトレードオフを判断できない場合にも向きません。その場合は、先に文脈を集めるか、より狭い範囲の planning prompt を使ってください。

roadmap-planning skill を改善する方法

より良い判断材料を与える

roadmap-planning の結果を最短で改善するには、モデルに渡す入力の質を上げることです。顧客の証拠、目標指標、そして本当に検討している少数の initiative を含めてください。やりたいことの一覧だけを渡すと、出力もその願望をなぞるだけになりやすく、厳しい選択になりません。

トレードオフと制約を早めに示す

roadmap-planning skill は、何ができないのかをプロンプトに書いたときに最もよく機能します。capacity の上限、戦略的な賭け、technical dependency、順序に影響するステークホルダーの約束を伝えてください。そうすることで、現実離れした「全部今すぐ」型の計画を避けやすくなり、ロードマップの説明もしやすくなります。

実際に使う形式で依頼する

経営層向けのロードマップが必要なら、簡潔な narrative と now/next/later 構成を求めてください。計画支援が目的なら、理由、リスク、dependency のメモを求めるとよいです。roadmap-planning ガイドは、見栄えを盛るための過剰な整形よりも、あなたが下す意思決定に合った出力形式にしたときに最も役立ちます。

1 回目の下書きのあとで反復する

最初の出力は最終回答ではなく、計画の下書きとして扱ってください。優先順位が実際の戦略に合っているか、epic の粒度が大きすぎたり小さすぎたりしていないか、順序が依存関係をきちんと反映しているかを確認します。そのうえで、「enterprise SSO を前倒しする」「reporting を 2 つの epic に分ける」「今 quarter は expansion より retention を優先する」といった修正を加えて roadmap-planning を再実行してください。