roadmap-analyzer

ロードマップアナライザー

ICP に基づき、収益への貢献度で次に構築するものを順位付けします。出力されるのは、創業者が自分自身に説明できるバックログです。各項目は、有料セグメントの獲得、維持、または拡大につながっています。

コードは読み取り専用です。分析を作成しますが、コミットや課題は作成しません。バックログを追跡可能な作業にするには、roadmap-to-milestones に引き継ぎます。

契約

入力：

• .agents/memory/icp.md（icp スキルによるもの）— セグメントと、その獲得・維持・拡大の手段が記載されています。存在しない場合は作業を中断し、最初に icp を実行するよう提案してください。ICP のないロードマップは、収益ではなく好みで順位付けすることになります。
• コードベースとプロダクトドキュメント。現在提供されている機能を棚卸しするために使用します。

出力：

• ギャップ分析：ICP のニーズと現状の比較。深刻度を付与します。
• 収益順のバックログ：各項目に収益上の理由を一行添えた P0／P1／P2。
• 戦略テーマ：注力領域を 3～5 個、順序付けして提示します。

作成／変更：

• なし。読み取り専用です。

委任先：

• ICP ドキュメントがまだない場合は icp。
• 順位付けしたバックログを GitHub のマイルストーンと課題にするには、roadmap-to-milestones を推奨します。
• バックログ項目を 1 つ選んで PRD に展開するには、feature-intake ／ prd-writer を推奨します。

ステップ 1 — ICP を読み込む

.agents/memory/icp.md を読み込みます。主要セグメントについて、差し迫った課題、購入のきっかけ、解約理由、拡大の道筋を抽出します。これらがロードマップで実現する 3 つの収益レバーです。

• 獲得 — 主要セグメントの購入を妨げている要因を取り除きます。
• 維持 — 明示された解約理由を取り除きます。
• 拡大 — 示された拡大の道筋（シート数、利用量、プラン）を実現します。

icp.md がない場合は、顧客像を推測してはいけません。その旨を伝え、icp を推奨してください。

ステップ 2 — 現在提供されている機能を棚卸しする

記憶に頼らず、コードとドキュメントから現在の機能を把握します。プロダクトの中核となる操作、自動化、コラボレーション、連携、課金の各領域を検索します。各機能について、状態（本番／一部対応／未対応）と品質（堅牢／粗削り／プロトタイプ）を記録し、根拠となる file:line の参照を付けます。存在する機能を正当に評価してください。ギャップは、何もない状態ではなく、実際の状態を基準に測ります。

ステップ 3 — ギャップ分析

ICP のニーズと棚卸し結果を比較します。ニーズごとに 1 行記載します。

ICP のニーズ（セグメント）	レバー	現状	ギャップの深刻度
	獲得／維持／拡大	未対応／一部対応／堅牢	重大／高／中／低

深刻度は収益を重み付けして判定します。主要セグメントの獲得または維持に関するギャップは、少なくとも「高」とします。「ICP の対象外」のセグメントに関するギャップは、規模がどれほど大きくても「低」とします。

ステップ 4 — 労力だけでなく、収益で順位付けする

候補ごとにスコアを付けます。

• 収益インパクト（1～5） — 新規販売の獲得、解約理由への対処による維持、またはアカウントの拡大につながるか。主要セグメントの獲得／維持は 4～5 点、二次セグメント向けの改善は 1～2 点です。
• 緊急度（1～5） — 現在、販売、更新、または解約を妨げているか。
• 労力（1～5） — 実際に必要となる構築規模。

スコア =（収益 × 2 + 緊急度）÷ 労力。 スコアが高いほど、早く着手します。

次に、単純なスコアでは見落とす 2 つのルールを適用します。

• 着手より完了を優先する。 収益レバーに関わる機能が一部対応の状態なら、それはバックログ項目ではありません。積極的に収益を漏らしている、解約や販売機会の損失につながるリスクです。新しい機能に着手するより、先に完成させます。中核機能を半端な状態で出すのは進捗ではなく、負債です。
• 見栄えより販売可能性を優先する。 新しい不完全なストーリーを追加するより、顧客が対価を払うストーリーを完成させる項目を優先します。80％の完成度の機能が 10 個あるより、100％の機能が 7 個あるほうが売れます。

順位付けしたリストを P0（今すぐ構築）、P1（次）、P2（後）に分類し、最も早く MRR を伸ばすクイックウィン（収益インパクトが高く、労力が少ない項目）を抽出します。

ステップ 5 — 戦略テーマ

バックログを 3～5 個のテーマにまとめます。各テーマにはプロダクト独自の言葉で名前を付け、収益レバーと結び付けます。順序は、主要セグメントの獲得を可能にする基盤を最初にし、次に維持、最後に拡大とします。各テーマについて、一行のビジョン、対象となる ICP セグメント、成功指標（できれば見栄えだけの指標ではなく、収益または維持率の数値）を示します。

出力

# Roadmap Analysis — <product> (<date>)

## Executive summary
- <3–5 bullets: the revenue story and the single most important next move>

## Gap analysis
<table from Step 3>

## Revenue-ranked backlog
### P0 — build now
1. **<feature>** (score X.X) — Lever: <Land/Retain/Expand>. Why: <revenue rationale>.
### P1 — next
### P2 — later

## Quick wins
- <high-impact, low-effort items>

## Strategic themes
1. **<theme>** — serves <segment>, <lever>. Success: <metric>.

## Recommended next step
Run `roadmap-to-milestones` to sequence P0/P1 into milestones with due dates.

アンチパターン

• ICP を定めずに順位付けする。 icp.md がなければ、優先順位は好みに左右されます。まず icp を実行してください。
• 労力を優先して順位付けする。 安く簡単にできることと、収益を伸ばすことは同じではありません。 スコアで収益を 2 倍に重み付けしているのには理由があります。
• すべてのセグメントを同等に扱う。 プライマリーセグメントに最適化してください。ICP に該当しないセグメントの大きなギャップでも、評価は LOW です。
• 収益上の根拠なしに機能を列挙する。 すべての項目で、どのレバーに影響するかを明記してください。そうでなければ、バックログに加えるべきではありません。
• 完了より新規着手を優先する。 収益レバーに関わる未完了の機能は、新規の項目より優先されます。今まさに収益が漏れているためです。