roadmap-update

ロードマップの更新

見慣れないプレースホルダーがある場合や、どのツールが接続されているか確認する必要がある場合は、CONNECTORS.mdをご覧ください。

プロダクトロードマップを更新、作成、または優先順位を変更します。

使用方法

/roadmap-update $ARGUMENTS

ワークフロー

1. 現状を把握する

~~project tracker が接続されている場合：

• 現在のロードマップ項目を、ステータス、担当者、日付とともに取得します
• 期限超過、リスクあり、または最近完了した項目を特定します
• 明確な担当者や日付が設定されていない項目を確認します

プロジェクト管理ツールが接続されていない場合：

• 現在のロードマップについて説明するか、貼り付け／アップロードするようユーザーに依頼します
• リスト、表、スプレッドシート、スクリーンショット、文章での説明など、あらゆる形式を受け付けます

2. 操作内容を決める

ユーザーが何をしたいのかを尋ねます。

項目を追加する：新機能、取り組み、または作業項目をロードマップに追加します

• 収集する情報：名前、説明、優先度、予想工数、目標時期、担当者、依存関係
• 現在の優先事項と対応能力に基づいて、適切な位置を提案します

ステータスを更新する：既存の項目のステータスを変更します

• 選択肢：未着手、進行中、リスクあり、ブロック中、完了、取り下げ
• 「リスクあり」または「ブロック中」の場合：阻害要因と軽減策を尋ねます

優先順位を変更する：項目の順序や優先度を変更します

• 何が変わったのか（新しい情報、戦略の転換、リソースの変更、顧客からのフィードバック）を尋ねます
• 役立つ場合は、優先順位付けのフレームワークを適用します。RICE、MoSCoW、ICE、価値対工数については、以下の優先順位付けのフレームワークをご覧ください
• 変更前と変更後を比較して示します

タイムラインを変更する：項目の日付を変更します

• 理由（スコープの変更、依存関係の遅延、リソースの制約）を尋ねます
• 依存する項目への下流の影響を特定します
• 厳守すべき期限を過ぎる項目にフラグを付けます

新しいロードマップを作成する：ゼロからロードマップを作成します

• 期間（四半期、半期、年間）を尋ねます
• 希望する形式（Now／Next／Later、四半期ごとの列、OKRに沿った形式）を尋ねます。詳しくは、以下のロードマップのフレームワークをご覧ください
• 含める取り組みのリストを収集します

3. ロードマップの概要を作成する

次の内容を含むロードマップを作成します。

ステータスの概要

簡潔な要約：進行中の項目はX件、今期に完了した項目はY件、リスクありの項目はZ件です。

ロードマップ項目

各項目について、以下を示します。

• 名前と1行の説明
• ステータス表示（順調／リスクあり／ブロック中／完了／未着手）
• 目標時期または日付
• 担当者
• 主な依存関係

項目は以下の単位でグループ化します。

• 形式に応じて、期間（Now／Next／Later）または四半期別
• または、ユーザーの希望に応じてテーマ／目標別

リスクと依存関係

• ブロック中またはリスクありの項目と、その詳細
• チーム間の依存関係とそのステータス
• 厳守すべき期限が近づいている項目

今回の更新内容

既存のロードマップを更新する場合は、変更点を要約します。

• 追加、削除、または優先順位を変更した項目
• タイムラインの変更
• ステータスの変更

4. フォローアップする

ロードマップを作成した後：

• 特定の対象者向けの形式（経営層向けの概要、エンジニアリング向けの詳細、顧客向け）にすることを提案します
• ロードマップの変更についての告知文を作成することを提案します
• プロジェクト管理ツールが接続されている場合は、チケットのステータスを更新することを提案します

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

Now／Next／Later

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

• Now（現在のスプリント／月）：取り組むことが確定している作業です。スコープとタイムラインの確度は高く、チームが現在積極的に開発している項目です。
• Next（今後1～3か月）：計画済みの作業です。何を行うかの確度は高いものの、具体的な時期の確度はそれほど高くありません。スコープと優先順位は決まっていますが、まだ着手していません。
• Later（3～6か月以上先）：方向性を示す項目です。今後取り組む予定の戦略的な賭けや機会ですが、スコープと時期には柔軟性があります。

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

四半期ごとのテーマ

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

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

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

OKRに沿ったロードマップ

ロードマップ項目を目標（Objective）と主要な結果（Key Results）に直接対応付けます。

• まず、その期間におけるチームのOKRを示します。
• 各主要な結果の下に、その指標を動かす取り組みを列挙します。
• 各取り組みが主要な結果に与える想定効果を記載します。
• これにより、構築するものと測定するものの間に明確な責任が生まれます。

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

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

カレンダーに基づき、項目をタイムライン上に表示します。

• 開始日、終了日、期間を示します。
• 並行作業や順序を視覚化します。
• リソースの競合を見つけるのに適しています。
• 項目間の依存関係を示します。

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

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

RICEスコア

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

• リーチ：所定の期間に、何人のユーザー／顧客に影響しますか？具体的な数値を使います（例：「四半期あたり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. 影響を認める：誰にどのような影響があるのかを示します。優先度を下げた項目を期待していたステークホルダーには、直接伝える必要があります

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

• 新しい情報が出るたびにロードマップを変更してはいけません。変更の基準を設けます
• 緊急性が本当に高い場合を除き、ロードマップの更新は自然な周期（毎月、四半期ごと）にまとめます
• 「ロードマップの変更」（戦略的な優先順位の見直し）と「スコープの調整」（通常の実行段階での見直し）を区別します
• ロードマップの変更頻度を記録します。変更が頻繁な場合、迅速に対応できているのではなく、戦略が不明確である可能性があります

出力形式

明確で一覧しやすい形式を使います。ロードマップ項目には表が適しています。ステータスにはテキストラベルを使います：完了、順調、リスクあり、ブロック中、未着手。

ヒント

• ロードマップはコミュニケーションツールであり、プロジェクト計画ではありません。適切な粒度を保ち、タスクではなくテーマと成果を示しましょう。
• 優先順位を見直すときは、必ず何が変わったのかを確認しましょう。優先順位の変更は、気まぐれではなく新たな情報に基づいて行う必要があります。
• キャパシティの問題は早めに指摘しましょう。ロードマップにチームが対応できる量を超える作業がある場合は、そのことを伝えてください。
• 依存関係はロードマップにとって最大のリスクです。明示的に表面化させましょう。
• ユーザーから何かを追加するよう求められたら、必ず何を外すか、または後回しにするかを確認しましょう。ロードマップはキャパシティに対してゼロサムです。