roadmap-management

ロードマップ管理スキル

プロダクトのロードマップ策定、優先順位付け、コミュニケーションに精通しています。プロダクトマネージャーが、戦略的で現実的な、意思決定に役立つロードマップを作成できるよう支援します。

ロードマップのフレームワーク

Now / Next / Later

最もシンプルで、多くの場合最も効果的なロードマップ形式です。

• Now（現在のスプリント／月）：確約済みの作業です。スコープとスケジュールの確度が高く、チームが現在取り組んでいる内容です。
• Next（今後1〜3か月）：計画中の作業です。何をするかの確度は高いものの、具体的な時期の確度はそれほど高くありません。スコープと優先順位は決まっていますが、まだ着手していません。
• Later（3〜6か月以降）：方向性を示すものです。取り組む予定の戦略的な賭けや機会ですが、スコープと時期は柔軟に変更できます。

使用する場面：ほとんどのチームで、ほとんどの場合に適しています。日付を過度に正確に見せることを避けられるため、社外や経営陣への説明に特に適しています。

四半期ごとのテーマ

四半期ごとに2〜3つのテーマを設定して、ロードマップを構成します。

• 各テーマは、戦略的な投資領域を表します（例：「エンタープライズ対応」「アクティベーションの改善」「プラットフォームの拡張性」）
• 各テーマの下に、計画している具体的な取り組みを列挙します
• テーマは会社またはチームのOKRに対応させます
• この形式を使うと、何を作るのか、そしてなぜ作るのかを説明しやすくなります

使用する場面：戦略との整合性を示す必要がある場合に適しています。計画会議や経営陣への説明に役立ちます。

OKRに沿ったロードマップ

ロードマップの項目を目標と主要な結果に直接対応させます。

• 期間中のチームのOKRから始めます
• 各主要な結果の下に、その指標の達成に貢献する取り組みを列挙します
• 各取り組みが主要な結果に与えると予想される影響を記載します
• これにより、構築するものと測定するものとの間に、明確な責任関係が生まれます

使用する場面：OKRを運用している組織に適しています。すべての取り組みに、測定可能な成果に結び付いた明確な「理由」があることを確かめるのに役立ちます。

タイムライン／ガントビュー

項目をタイムライン上に表示する、カレンダーベースのビューです。

• 開始日、終了日、期間を示します
• 並行作業と順序を可視化します
• リソースの競合を見つけるのに役立ちます
• 項目間の依存関係を示します

使用する場面：エンジニアリングチームとの実行計画や、スケジュールの競合の特定に適しています。社外への説明には適していません（過度に正確な期待を生みます）。

優先順位付けのフレームワーク

RICEスコア

各取り組みを4つの観点で評価し、RICE =（リーチ × インパクト × 確信度）／工数を計算します。

• リーチ：一定期間内に影響を受けるユーザー／顧客の数です。具体的な数値を使います（例：「四半期あたり500人のユーザー」）。
• インパクト：リーチした人それぞれに、どれほどの効果をもたらすかです。次の尺度で評価します。3 = 非常に大きい、2 = 大きい、1 = 中程度、0.5 = 小さい、0.25 = 最小限。
• 確信度：リーチとインパクトの見積もりにどれほど確信があるかです。100% = 確信度が高い（データに裏付けられている）、80% = 中程度（ある程度の根拠がある）、50% = 低い（直感に基づく）。
• 工数：必要な作業量を人月で表します。エンジニアリング、デザイン、その他の職能を含めます。

使用する場面：定量的で、根拠を説明できる優先順位付けが必要な場合に適しています。多数の取り組みがあるバックログの比較に役立ちます。インパクトの見積もりが難しい戦略的な賭けには、あまり適していません。

MoSCoW

項目を「必須」「あるべき」「あるとよい」「対象外」に分類します。

• 必須：これらがなければロードマップは失敗です。妥協できない確約事項です。
• あるべき：重要で実現が期待されていますが、なくてもリリースは可能です。
• あるとよい：望ましいものの、優先順位は明らかに低い項目です。キャパシティに余裕がある場合にのみ含めます。
• 対象外：この期間のスコープから明示的に除外する項目です。明確にするため、一覧に記載することが重要です。

使用する場面：リリースや四半期のスコープ設定、関係者との実現可能な範囲の調整に適しています。優先順位についての話し合いを促すのに役立ちます。

ICE スコア

RICE よりシンプルです。各項目を、次の 3 つの観点で 1〜10 点で評価します。

• インパクト：目標指標をどの程度動かせるでしょうか？
• 確信度：インパクトの見積もりにどの程度確信がありますか？
• 容易さ：実装はどの程度容易ですか？（工数の逆で、点数が高いほど容易です）

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

使用する場面：機能バックログを手早く優先順位付けするときです。初期段階のプロダクトや、RICE に必要なデータが十分にない場合に適しています。

価値と工数のマトリックス

取り組みを 2x2 のマトリックスに配置します。

• 高価値、低工数（クイックウィン）：これらを最初に実施します。
• 高価値、高工数（大きな賭け）：慎重に計画します。投資する価値はありますが、適切なスコープ設定が必要です。
• 低価値、低工数（穴埋め）：余力があるときに実施します。
• 低価値、高工数（無駄な投資）：実施しないでください。バックログから削除します。

使用する場面：チームの計画セッションで視覚的に優先順位を付けるときです。トレードオフについて共通認識を築くのに適しています。

依存関係のマッピング

依存関係の特定

次のカテゴリについて、依存関係を確認します。

• 技術的な依存関係：機能 B の実現には、機能 A によるインフラ作業が必要です
• チーム間の依存関係：機能の実現に、別のチーム（デザイン、プラットフォーム、データ）の作業が必要です
• 外部依存関係：ベンダー、パートナー、サードパーティとの統合を待っています
• 知識の依存関係：着手前に調査や検証の結果が必要です
• 順序上の依存関係：機能 B に着手する前に機能 A をリリースする必要があります（コードの共有、ユーザーフロー）

依存関係の管理

• すべての依存関係をロードマップに明記します
• 各依存関係に担当者を割り当てます（解決の責任者）
• 「必要期限」を設定します。依存する項目では、いつまでに解決が必要でしょうか？
• 依存関係には余裕を持たせます。ロードマップ上で最もリスクの高い項目です
• チーム間の調整が必要な依存関係には早めにフラグを立てます
• 依存関係が遅れた場合に備えて、代替案を用意します

依存関係の削減

• 依存関係を回避できる、よりシンプルなバージョンを作れますか？
• インターフェース契約やモックを使って並行して進められますか？
• 依存関係を前倒しできるよう、順序を変更できますか？
• チーム間の調整をなくすために、作業をチーム内に取り込めますか？

キャパシティ計画

キャパシティの見積もり

• エンジニアの人数と期間から始めます
• 既知の間接業務を差し引きます。会議、オンコールのローテーション、面接、祝日、休暇などです
• よく使われる目安として、エンジニアが計画済みの機能開発に使う時間は全体の 60〜70% です
• 新メンバーがチームに慣れるまでの時間も考慮します

キャパシティの配分

多くのプロダクトチームに適した配分は次のとおりです。

• 70% 計画済みの機能開発：戦略目標を前進させるロードマップ項目
• 20% 技術的な健全性：技術的負債、信頼性、パフォーマンス、開発者体験
• 10% 計画外の作業：緊急の問題、クイックウィン、他チームからの依頼に備える余裕

チームの状況に応じて比率を調整します。

• 新しいプロダクト：機能開発を増やし、技術的負債を減らす
• 成熟したプロダクト：技術的負債と信頼性への投資を増やす
• インシデント発生後：機能開発を減らし、信頼性を高める
• 急成長中：スケーラビリティとパフォーマンスへの取り組みを増やす

キャパシティと意欲

• ロードマップのコミットメントがキャパシティを超える場合、何かを諦める必要があります
• 人々がより多くの仕事をこなせると見せかけて、キャパシティの問題を解決しないでください。スコープを削減して解決します
• ロードマップに項目を追加するときは、必ず「何を外しますか？」と尋ねます
• 過剰に約束して期待を裏切るより、少ない項目にコミットして確実に届けるほうがよいです

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

ロードマップが変更されるとき

ロードマップ変更のよくあるきっかけ：

• 経営陣による新たな戦略上の優先事項
• 優先順位を変える顧客フィードバックや調査結果
• 見積もりを変える技術的な調査結果
• 他チームの依存関係の遅れ
• リソースの変更（チームの拡大や縮小、主要メンバーの退職）
• 対応が必要な競合の動き

変更の伝え方

1. 変更を認める：何が、なぜ変わるのかを率直に伝えます
2. 理由を説明する：どのような新しい情報を受けて、この決定に至ったのかを説明します
3. トレードオフを示す：枠を確保するために何の優先度を下げたのか、または何が遅れているのかを示します
4. 新しい計画を示す：変更を反映した最新のロードマップを示します
5. 影響を認める：誰にどのような影響があるのかを伝えます。優先度を下げた項目を期待していた関係者には、直接知らせる必要があります。

ロードマップの頻繁な変更を避ける

• 新しい情報が入るたびにロードマップを変更しないでください。変更を判断する基準を設けましょう。
• よほど緊急でない限り、ロードマップの更新は月次や四半期ごとなど、自然なタイミングにまとめましょう。
• 「ロードマップの変更」（戦略的な優先順位の見直し）と「スコープの調整」（通常の実行上の見直し）を区別しましょう。
• ロードマップの変更頻度を記録しましょう。頻繁な変更は、対応力の高さではなく、戦略が不明確であることを示している可能性があります。