roadmap-planning

ロードマップの形式

対象読者と計画期間に合った形式を選びます。

今／次／その後

日付を不必要に厳密に設定せず、時間軸で示すアプローチです。

• 今（進行中のスプリントまたは今月）：チームが現在実行している作業です。範囲が定まり、納期の確度も高い状態です。
• 次（1〜3か月先）：優先順位が付けられ、おおよその範囲が定まっています。「何をするか」は明確ですが、「いつ行うか」にはある程度の不確実性があります。
• その後（3〜6か月先以降）：戦略的な意図と大まかな方針を示します。範囲と時期は、意図的に柔軟なままにします。

適している用途：対外的なコミュニケーション、リーダーシップ層への進捗報告、具体的な日付を早々に確定させたくないチーム。

テーマ別の四半期計画

各四半期を2〜3つの投資テーマで構成します。

• テーマでは、戦略的な重点分野を示します（例：「セルフサービスでのオンボーディング」「エンタープライズのセキュリティ体制」「開発者エコシステムの成長」）
• 個々の取り組みを各テーマの下にまとめます
• テーマは、会社またはチームレベルの目標と主要な成果に結び付けます
• この形式では、すべての取り組みの背景にある戦略的な「なぜ」を前面に出します

適している用途：経営層によるレビュー、計画サイクル、実行と戦略の整合性の提示。

OKR 主導のロードマップ

ロードマップの各項目を、目標と主要な成果に直接結び付けます。

• 計画期間におけるチームの OKR から始めます
• 各主要な成果の下に、その指標を動かすと見込まれる取り組みを列挙します
• 各取り組みに、主要な成果への貢献見込みを注記します
• これにより、実行と測定を直接結び付ける説明責任の連鎖が生まれます

適している用途：OKR のプロセスを運用しており、構築と測定の間に緊密なフィードバックループを求める組織。

ガントチャート／タイムライン表示

期間、並行作業、順序を示すカレンダー形式のレイアウトです。

• 各取り組みの開始日、終了日、作業期間を表示します
• リソースの競合やスケジュール上のボトルネックを明らかにします
• 項目間の依存関係を視覚的に示します
• 並行する作業の流れが合流する箇所を強調します

適している用途：エンジニアリングの調整やリソース配分に関する議論。日付を厳密に示すと硬直的な期待につながるため、社外への共有は避けてください。

スコアリングと優先順位付けのモデル

RICE スコアリング

4つの要素を使って優先度を定量化します：スコア = （リーチ x インパクト x 確信度） / 工数

• リーチ：定めた期間内に影響を受けるユーザーまたは顧客の数です。具体的な推定値を使います（「四半期あたり800アカウント」など）。
• インパクト：リーチした各人に生じる変化の度合いです。尺度：3 = 革新的、2 = 大きい、1 = 中程度、0.5 = 小さい、0.25 = わずか。
• 確信度：リーチとインパクトの推定に対する確実性です。100% = データに裏付けられている、80% = 妥当な根拠がある、50% = 情報に基づく推測。
• 工数：すべての職能（エンジニアリング、デザイン、リサーチなど）にわたる合計人月です。

適している用途：大規模なバックログを定量的かつ厳密に比較する場合。インパクトを本質的に推測しにくい、大胆な戦略的取り組みにはあまり効果的ではありません。

ICE スコアリング

詳細なデータがない場合に使える、簡略化された方法です。各項目を次の3つの軸で1〜10点評価します。

• インパクト：目標指標に期待される変化
• 確信度：インパクトの推定の信頼性
• 容易さ：実装の簡単さ（工数の逆数で、点数が高いほど簡単です）

スコア = インパクト x 確信度 x 容易さ

適している用途：バックログの迅速な優先順位付け、初期段階のプロダクト、または RICE の入力情報が得られない状況。

MoSCoW 分類

施策を4つの区分に分類し、優先順位について話し合う必要性を明確にします。

• 必須：これがなければ計画は成り立ちません。妥協できない取り組みを表します。
• あるべき：価値が高く、実現が期待されていますが、遅れても計画は実行可能です。
• あれば望ましい：余力があれば歓迎されます。除外してもスケジュールには影響しません。
• 今回は対象外：この期間は意図的に除外します。明記することで曖昧さをなくせます。

最適な用途：何を優先し、何を見送るかを確認する必要があるステークホルダーとの、リリース範囲の決定や交渉の場。

価値と工数の四象限

施策を2×2のグリッドに配置して可視化します。

• 高価値、低工数（クイックウィン）：すぐに実行します。最も効果の高い項目です。
• 高価値、高工数（戦略的投資）：計画的にリソースを投入します。コストに見合う価値がありますが、慎重な計画が必要です。
• 低価値、低工数（機会的な取り組み）：余裕がある時期や、大きな取り組みの合間に進めます。
• 低価値、高工数（落とし穴）：検討対象から外します。見返りが最小限である一方、リソースを消費します。

最適な用途：トレードオフについてチーム内で視覚的な認識を共有する必要がある、共同計画の場。

依存関係の管理

依存関係の分類

次のカテゴリにわたって依存関係を確認します。

• 技術的：施策 B が、施策 A で提供されるインフラストラクチャやプラットフォームの変更に依存している
• チーム間：デザイン、プラットフォーム、データエンジニアリング、または他のプロダクトチームからの成果物が必要である
• 外部：ベンダーの成果物、パートナーとの連携、またはサードパーティ API によってブロックされている
• 情報的：作業を開始する前に、調査スパイク、ユーザー調査、またはデータ分析の結果が必要である
• 順次的：共通の画面やユーザーフロー上の制約により、機能 A のリリース後でなければ機能 B を開始できない

依存関係を効果的に扱う方法

• ロードマップの成果物に、すべての依存関係を明示する
• 各依存関係の追跡と解決を担う単一のオーナーを指名する
• 「必要日」を設定する。下流の項目を予定どおりに進めるには、上流の成果物がいつまでに揃う必要があるかを定める
• 依存関係の前後には余裕を持たせる。依存関係は、どの計画でも最もリスクの高いノードとなる
• チーム間の依存関係は早めにエスカレーションする。調整の負担は遅れるほど大きくなる
• 代替案を用意する。依存関係の解決が遅れた場合、どのような別の進め方があるかを検討する

依存関係を最小限に抑える戦略

• スコープを縮小したバージョンであれば、依存関係を完全に回避できるか検討する
• インターフェース契約やモックを活用し、並行開発を可能にする
• 依存関係がスケジュールの早い段階で解消されるよう、順序を組み替える
• 依存する作業を自チームに取り込み、調整の負担をなくす

チームのキャパシティ計画

利用可能なキャパシティの見積もり

• 人員数と計画期間から始める
• 既知の間接業務を差し引く。定例会議、オンコール当番、採用面接、休日、予定休暇などが該当します
• 実用的な基準として、エンジニアは通常、勤務時間の60〜70％を計画済みのロードマップ作業に充てます
• 新しいチームメンバーがサイクルの途中で加わる場合は、立ち上がりに必要な時間を考慮する

配分のガイドライン

多くのプロダクトチームに適したバランスの取れた配分：

• 70％ 戦略的な提供：ビジネス目標を前進させるロードマップ上の施策
• 20％ インフラの健全性：技術的負債の削減、信頼性の強化、パフォーマンスの調整、開発者向けツール
• 10％ 予備枠：緊急の依頼、寄せられるエスカレーション、小規模な機会への対応

状況に応じて比率を調整します。

• 新しいプロダクトでは、機能への投資を増やし、技術的負債への対応を減らすのが適切です
• 成熟したプロダクトでは、信頼性とスケーラビリティへの投資を増やすと効果的です
• インシデント後の期間は、インフラへの取り組みを強化します
• 急成長期には、スケーラビリティと運用上のレジリエンスへの投資が必要です

野心と現実のバランス

• 計画上のコミットメントが対応可能な量を超える場合、個人の成果への期待ではなく、スコープを縮小する必要があります。
• 恒常的なルールとして、計画に取り組みを追加する場合は、別の取り組みを削除するか、延期する必要があります。
• 過剰にコミットして期限を守れないよりも、コミットメントを減らして確実に遂行するほうが、組織の信頼を築けます。

ロードマップの変更を伝える

ロードマップを見直すきっかけ

• 経営陣からの新たな戦略的指示
• 優先順位を入れ替えるユーザー調査や顧客からのフィードバック
• 工数見積もりを大幅に変えるエンジニアリング上の発見
• 他チームからの依存関係におけるスケジュールの遅れ
• チーム構成の変化：人員の増加、離職、または主要メンバーの退職
• 対応を迫る競合他社の動き

変更を明確に伝える

1. 変更を直接伝える：何がどの方向に動くのか
2. きっかけを説明する：どのような新情報を受けてこの判断に至ったのか
3. トレードオフを明らかにする：変更に対応するため、何の優先度を下げたのか、または何を延期したのか
4. 改訂後の計画を示す：新たな状況を反映したロードマップ
5. 影響を受ける関係者に対応する：優先度を下げた項目を当てにしていた関係者には、直接伝える必要があります。

安定性を維持する

• 新しいデータが得られるたびに、ロードマップを見直す必要があるとは限りません。変更前に、重要性の基準を定めてください。
• 本当に緊急の場合を除き、月次や四半期ごとなど、自然な節目に調整をまとめてください。
• 戦略的な優先順位の見直し（ロードマップの変更）と、通常の実行上の調整（取り組み内でのスコープ調整）を区別してください。
• ロードマップ変更の頻度を追跡してください。変更が過剰に続く場合、適応的な計画ではなく、戦略が曖昧であることを示している可能性があります。