roadmap-planning

ロードマップ計画

アイデア、要望、進行中の作業をまとめ、何をいつ、なぜ提供するのかを、納得できる根拠に基づいて計画します。成果物はロードマップ文書と、その信頼性を支える優先順位付けの作業です。

---

使用する場面

• 次の四半期や次の年の計画を立てるとき
• 一部の項目がほかの項目に依存する作業の順序を決めるとき
• 新規開発、改善、保守のバランスを取るとき
• 特定の要望に対して、納得できる理由を示して「対応しない」または「今は対応しない」と伝えるとき
• チーム全員が共有する単一の計画に合意するとき
• チーム外のステークホルダーに計画を伝えるとき
• 戦略の転換、四半期目標の未達、新たな制約を受けて計画を立て直すとき

使用しない場面

• 単一の機能の開発仕様を定めるとき（pm-spec-writing を使用）
• アイデアに開発する価値があるかを検証するとき（ux-research を使用）
• 機能そのものを設計するとき（design-standards を使用）
• 単一の取り組みのローンチ計画を作成するとき（launch-runbook を使用）
• 提供したものと約束したものを振り返るとき（after-action-report を使用）

---

必要な入力

• チームの戦略または上位目標（1～5件の OKR、テーマ、または柱）
• バックログ：候補となるすべての項目と、それぞれ少なくとも1文の説明
• チームのキャパシティ（人員 × 時間）
• 既知の制約（期限、依存関係、採用、予算）
• 計画期間（1四半期、2四半期、1年）

戦略がない場合、ロードマップは計画ではなく機能の一覧になります。作成をいったん止めて、まず戦略を明確にしてください。戦略のないロードマップは、単なる順番待ちリストです。

---

フレームワーク：5つのレイヤー

ロードマップは5つの異なるレイヤーで失敗する可能性があります。ロードマップの質は、最も弱いレイヤーによって決まります。

レイヤー1：テーマ（WHY）

戦略に結び付いた上位のグループです。それぞれのテーマは、「この期間にほかのことを何もしないとしても、どの成果を実現したいか」に答えるものです。

良いテーマの条件は次のとおりです。

• 機能ではなく、成果を示している（「オンボーディングを構築する」より「最初の価値を得るまでの時間を短縮する」）
• 数が絞られている（最大3～5件）
• 根拠を示せる（ほかの選択肢ではなく、これを選ぶ理由を説明できる）
• 測定可能である（それぞれが1～2個の指標に対応している）

悪いテーマは、何でも放り込む引き出しのようになっています。「改善」「技術的負債」「その他」などです。1文で根拠を説明できないなら、それはテーマではありません。

レイヤー2：イニシアチブ（WHAT）

テーマの実現につながる、数週間から数か月にわたる取り組みです。イニシアチブは、機能より大きくテーマより小さい単位です。イニシアチブには次の要素があります。

• 明確な成果（実現すべき指標または結果）
• おおよその規模（S／M／L／XL）
• 確信度（これが適切なイニシアチブだとどの程度確信できるか）
• 依存関係のマップ（先に何を完了する必要があるか）

ステークホルダーから強く要望されるのは、イニシアチブの段階です。ここで日付を確約したいという誘惑には抵抗してください。確約するのは成果とおおよその規模です。

レイヤー3：順序付け（WHEN）

物事を進める順序です。順序付けは、次の制約を受けます。

• 依存関係（Yを開始する前にXを完了する必要がある）
• キャパシティ（チームが同時に取り組める項目数）
• カレンダー上の現実（第4四半期は稼働日が少ない、特定のチームで採用の空白期間がある）
• 戦略的な機会（季節、カンファレンス、競争上の節目より前に公開する必要があるローンチもある）

優先順位付けの後に順序を決めてください。重要なことを決める前に時系列に並べると、インパクトではなく、カレンダーに収まることを最適化した計画になります。

レイヤー4：キャパシティの現実（HOW MUCH）

ここで失敗するロードマップがほとんどです。計画は書面上では良く見えても、全員の時間を100％ロードマップの作業に充てる前提になっています。実際に使えるキャパシティははるかに少ないものです。

キャパシティの標準的な前提は次のとおりです。

• エンジニア：時間の60～70％をロードマップのイニシアチブに充てます。残りは会議、レビュー、オンコール、サポート、面接、デバッグ、業務への習熟に使われます。
• デザイナー：50～60％です。同じ理由に加え、他チームのサポートも多くあります。
• PM：40～50％です。残りは計画、コミュニケーション、ステークホルダー管理、非同期の文書作成に使われます。
• 新規採用者：最初の四半期はフルキャパシティの50％、2番目の四半期は75％、第3四半期以降は100％と見積もります。
• オンコールのローテーション、休暇、祝日：規模を見積もる前に差し引きます。

計算上、チームの稼働時間を100％使わなければ計画を達成できないなら、その計画は間違っています。削減してください。

レイヤー 5：トレードオフの伝達（WHY NOT）

すべてのロードマップには、「実施中」の項目と同じくらい重要な「今はやらない」リストがあります。「今はやらない」項目があることで、計画を正当化できます。

以下を含めます。

• 検討したうえで見送った主な要望
• 見送った理由（時期が適切でない、規模が適切でない、テーマと相反する、期待される効果が小さい）
• その項目を「実施中」に移す条件（指標、日付、前提条件の完了）

削除された項目を推すステークホルダーは、項目が含まれていないことではなく、却下基準に異議を唱えられます。これは建設的な議論です。

---

ワークフロー

ステップ 1：戦略を軸にする

バックログに手をつける前に、テーマを 3～5 個書き出します。チームの OKR や戦略ドキュメントにテーマがある場合は、それを転記します。なければテーマの案を作成し、戦略を担う人たちに確認します。

戦略がなかったり曖昧だったりする場合は、作業を止めます。不明確な戦略に基づいてロードマップを作るくらいなら、何も作らないほうがよいでしょう。課題を明らかにします。

ステップ 2：バックログを一覧化する

候補ごとに、以下を記載します。

• 名前（1 つのフレーズ）
• 関連するテーマ（または「テーマなし」—後で要確認）
• 出所（要望、OKR、振り返り、顧客からのフィードバック、経営陣からの依頼、技術的な必要性）
• 概算規模（S／M／L／XL）
• 担当者または担当候補者
• ステータス（アイデア、検証済み、スコープ確定、着手可能）

「テーマなし」の項目は警告サインです。テーマの一覧が不完全か、その項目を削除すべきかのどちらかです。

ステップ 3：各テーマ内で優先順位を付ける

各テーマの中で、取り組みの優先順位を付けます。優先順位付けのフレームワークを 1 つ選び、一貫して使います。よく使われるものは次のとおりです。

• RICE（リーチ × インパクト × 確信度 ÷ 工数）：機能中心のロードマップに適しています
• MoSCoW（必須／すべき／できれば／しない）：期限が固定されたプロジェクトに適しています
• Kano（当たり前品質／一元的品質／魅力的品質）：製品への投資判断に適しています
• 遅延コスト：工数よりタイミングが重要な場合に適しています
• 戦略との整合性＋インパクト：経営陣向けのロードマップに適しています

フレームワークの種類よりも、一貫性のほうが重要です。1 つ選び、すべての取り組みに同じ方法で適用します。計算内容を記録します。

詳しくは references/prioritization-frameworks.md をご覧ください。

ステップ 4：依存関係マップを作成する

「実施中」の取り組みすべてについて、先に必要なことを列挙します。

• 他の取り組み
• 採用
• 外部依存関係（ベンダーからの納品、パートナーの準備）
• 調査や検証作業
• インフラストラクチャまたはプラットフォームの準備

グラフまたはガントチャート形式の順序で可視化します。依存関係のない項目はすぐに開始できます。未解決の依存関係が複数ある項目は警告サインです。

ステップ 5：順序を決める

次に、取り組みを時系列に配置します。依存関係マップを使います。キャパシティの計算結果を使います。実際に担当できる人に取り組みを割り当てます。

標準的な頻度は、1 四半期分は月ごと、それ以降は四半期ごとです。ほとんどのロードマップでは、週単位は細かすぎます。半年単位では、確約するには大まかすぎます。

ステップ 6：チームで検証する

社外に共有する前に、実作業を担当する人たちと次の点を確認します。

• 規模の見積もりは現実的ですか？
• 依存関係は正しく整理されていますか？
• キャパシティの前提は正確ですか？
• 誰かに過剰な作業を割り当てていませんか？

チームが計画を実行不可能だと言うなら、その計画は実行不可能です。調整します。チームが異議を唱える計画を経営陣に提示すると、信頼を損なうことになります。

ステップ 7：「今はやらない」リストを作成する

「実施中」の各項目について、実施するために何を削除したかを明記します。理由を記録します。後で「実施中」に移すきっかけとなる条件も記録します。

ステップ 8：伝える

対象者ごとに、必要な見せ方は異なります。

• チーム： 詳細な順序、担当者、依存関係、規模
• 部門横断のパートナー： テーマ、取り組み、おおまかな時期、提供してもらう必要があるもの
• 経営陣： テーマ、期待される成果、主要な取り組み、主なトレードオフ
• 一般公開または顧客向け： テーマ、具体的な日付なし、「期待できること」

同じロードマップから、4 種類すべてを作れる必要があります。作れない場合、ロードマップは不完全です。

---

失敗パターン

計画ではなく機能の一覧になっている。 テーマがありません。ロードマップは、月を付けただけのバックログです。対処法：戦略からやり直します。

日程主導の考え方。 「第2四半期の終わりまでに何をリリースできるか？」ではなく、「第2四半期に取り組むべき最も重要なことは何か？」と考えます。日程は制約であり、目標ではありません。

キャパシティの過大な見積もり。 計画では各メンバーの時間を100％使い切っています。サポート、割り込み、計画、未知の未知に対応する余裕がありません。ロードマップは3週目に破綻します。

ステークホルダーからの圧力が戦略に優先する。 強く要求されたからという理由で、声の大きな顧客や経営幹部からの要望が優先され、戦略との整合性は考慮されません。ここで「今はやらない」リストが役立ちます。

依存関係の見落とし。 イニシアチブBがイニシアチブAに依存しているのに、Aの予定が後になっています。または、Aがまだ採用されていない人材に依存しています。実行を始めるまでは、計画に問題がないように見えます。

先を見通しすぎている。 6か月先まで具体的に約束すると、チームが守れない約束をしてしまいます。遠い将来には期間やテーマを使い、近い将来には具体的な内容を示します。

すべてのレベルに同じフレームワークを使う。 プラットフォームの作業、インフラ、探索を含むロードマップ全体にRICEを適用しています。RICEは機能には優れていますが、基盤となる作業には向いていません。イニシアチブの種類に応じて、異なる評価軸を使います。

「今はやらない」がない。 要望が却下された理由の記録がないため、ステークホルダーは2週間ごとに却下された要望を持ち出します。一度記録して、いつでも参照できるようにします。

---

出力形式

ロードマップ文書には、次の内容を含めます。

• 戦略の概要（1ページまたは1セクション）：テーマ、これらのテーマを選んだ理由、上位目標とのつながり
• 計画（ビジュアル）：テーマごとに色分けした、四半期ごとまたは月ごとの表示
• イニシアチブの概要（イニシアチブごとに1つ）：成果、規模、担当者、依存関係、成功指標
• キャパシティモデル：誰が何を担当するか、稼働率の計算
• トレードオフと「今はやらない」：検討して却下した主要項目と、その理由
• リスクと前提条件：計画を頓挫させる可能性のあるもの
• 更新頻度：ロードマップを見直すタイミング（通常は毎月）

ロードマップは常に更新される文書です。毎月見直す計画を立てます。四半期ごとに正式に計画を見直します。契約として扱わないでください。

---

参考ファイル

• references/prioritization-frameworks.md - RICE、MoSCoW、Kano、Cost of Delay、Strategic Alignmentの各フレームワークを詳しく解説します。それぞれを使うタイミング、適用方法、よくある間違いについて説明します。