ロードマップ更新

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

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

使用方法

/roadmap-update $ARGUMENTS

ワークフロー

1. 現在の状態を理解する

プロジェクトトラッカー が接続されている場合：

• 現在のロードマップアイテムを、ステータス、担当者、日付とともに取得
• 遅延しているアイテム、リスク状態のアイテム、最近完了したアイテムを特定
• 明確な所有者または日付がないアイテムを浮き彫りにする

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

• ユーザーに現在のロードマップを説明するか、貼り付け/アップロードするよう依頼
• 任意の形式を受け入れる：リスト、表、スプレッドシート、スクリーンショット、または説明形式

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連動ロードマップ

ロードマップアイテムを目的と主要な結果に直接マップ：

• チームの期間の OKR から開始
• 各主要な結果の下に、そのメトリクスを動かすイニシアチブをリスト
• 各イニシアチブの主要な結果への予想される影響を含める
• これにより、構築するものと測定するものの間に明確な責任が作成される

いつ使用するか：OKR で運用する組織。すべてのイニシアチブが測定可能な結果に結びついた明確な「理由」を持っていることを確認するのに良好。

タイムライン / Gantt ビュー

アイテムがタイムライン上にある時間ベースのビュー：

• 開始日、終了日、期間を表示
• 並列性とシーケンスを可視化
• リソース競合の特定に良好
• アイテム間の依存関係を表示

いつ使用するか：エンジニアリングとの実行計画。スケジュール競合の特定。外部に伝えるのには適していません（誤った精度期待を作成）。

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

RICE スコア

4 つの次元でそれぞれのイニシアチブをスコア付けし、RICE = (Reach x Impact x Confidence) / Effort を計算

• Reach：特定の期間内にこれは何人のユーザー/顧客に影響しますか？具体的な数字を使用（例：「四半期ごとに 500 ユーザー」）。
• Impact：これは到達した人ごとにどの程度針を動かしますか？スケールでスコア付け：3 = 大規模、2 = 高、1 = 中、0.5 = 低、0.25 = 最小。
• Confidence：reach と impact の推定値についてどの程度確信していますか？100% = 確信度が高い（データに支持される）、80% = 中（いくつかの証拠）、50% = 低（直感）。
• Effort：人月いくらの仕事？エンジニアリング、デザイン、その他の機能を含める。

いつ使用するか：定量的で防御可能な優先順位付けが必要な場合。大量のイニシアチブバックログを比較するのに良好。影響が推定しにくい戦略的ベットには適していません。

MoSCoW

アイテムを、必須、重要、可能、不要に分類：

• 必須：これなしではロードマップは失敗します。交渉不可能なコミットメント。
• 重要：重要かつ予想されますが、これなしでも配信は実行可能です。
• 可能：望ましいが、明らかに優先度が低い。容量がある場合のみ含める。
• 不要：この期間には明確に範囲外。明確性のためにリストするのは重要。

いつ使用するか：リリースまたは四半期のスコープ。何が適合するかについてのステークホルダーとの交渉。優先順位付けの会話を強制するのに良好。

ICE スコア

RICE よりシンプル。3 つの次元で各アイテムを 1～10 でスコア付け：

• Impact：これはターゲットメトリクスをどの程度動かしますか？
• Confidence：impact 推定値についてどの程度確信していますか？
• Ease：これは実装するのはどの程度簡単ですか？（工数の逆 — 高い = より簡単）

ICE スコア = Impact x Confidence x Ease

いつ使用するか：機能バックログの迅速な優先順位付け。初期段階の製品またはRICE に十分なデータがない場合に良好。

価値対工数マトリックス

イニシアチブを 2x2 マトリックスにプロット：

• 高価値、低工数（クイックウィン）：最初にこれらをやる。
• 高価値、高工数（大きな賭け）：これらを慎重に計画。投資する価値がありますが、適切なスコープ設定が必要。
• 低価値、低工数（フィラー）：容量を持つときにこれらをやる。
• 低価値、高工数（金銭の無駄）：これらをやらないでください。バックログから削除。

いつ使用するか：チーム計画セッションでのビジュアル優先順位付け。トレードオフの共有理解を構築するのに良好。

依存関係マッピング

依存関係の特定

これらのカテゴリ全体で依存関係を探す：

• 技術的依存関係：機能 B は機能 A からのインフラストラクチャ作業を必要とする
• チーム依存関係：機能は別のチーム（デザイン、プラットフォーム、データ）の作業を必要とする
• 外部依存関係：ベンダー、パートナー、またはサードパーティ統合を待機中
• 知識依存関係：開始前に研究または調査結果が必要
• 順序依存関係：機能 A を出荷してから機能 B を開始する必要がある（共有コード、ユーザーフロー）

依存関係の管理

• ロードマップで明示的にすべての依存関係をリスト
• 各依存関係に所有者をアサイン（それを解決する責任者）
• 「必要な日付」を設定：依存しているアイテムがこれをいつまでに解決する必要があるか
• 依存関係の周りにバッファを構築 — ロードマップ上で最もリスクの高いアイテム
• チーム境界を越える依存関係に早期にフラグを立てる — これらは調整が必要
• 偶発的計画を持つ：依存関係がスリップした場合、何をしますか？

依存関係の削減

• 依存関係を避けるより単純なバージョンを構築できますか？
• インターフェース契約またはモックを使用して並列化できますか？
• 依存関係をより早く移動するために異なる順序でシーケンスできますか？
• 作業をチームに吸収してクロスチームの調整を削除できますか？

容量計画

容量の推定

• エンジニアの数と期間から開始
• 既知のオーバーヘッドを引く：ミーティング、オンコール当番、面接、祝日、PTO
• 一般的な経験則：エンジニアは計画された機能作業に時間の 60～70% を費やす
• 新しいメンバーのチーム ramp time を考慮

容量の配分

ほとんどのプロダクトチームにおける健全な配分：

• 70% 計画機能：戦略的目標を進めるロードマップアイテム
• 20% 技術的健全性：技術負債、信頼性、パフォーマンス、デベロッパー体験
• 10% 未計画：緊急の問題、クイックウィン、その他のチームからのリクエストのバッファ

チームの状況に基づいて比率を調整：

• 新製品：より多くの機能作業、より少ない技術負債
• 成熟した製品：より多くの技術負債と信頼性投資
• インシデント後：より多くの信頼性、より少ない機能
• 急速な成長：より多くのスケーラビリティとパフォーマンス

容量対野心

• ロードマップのコミットメントが容量を超える場合、何か譲歩する必要があります
• 人々がより多くできるふりをして容量の問題を解決しないでください — スコープを削減することで解決
• ロードマップに追加するときは、常に以下を尋ねます：「何が削除されますか？」
• 多くのことを確実に配信するほうが良いです。過度なコミットしてがっかりさせるより。

ロードマップ変更の伝達

ロードマップが変更される場合

ロードマップ変更の一般的なトリガー：

• リーダーシップからの新しい戦略的優先度
• 優先度を変更する顧客フィードバックまたは研究
• 推定値を変更する技術的発見
• 別のチームからの依存関係スリップ
• リソース変更（チームが成長または縮小、主要な人が退出）
• 対応が必要な競争上の動き

変更を伝える方法

1. 変更を認める：何が変わり、なぜかについて直接的であること
2. 理由を説明する：この決定をどの新しい情報が導いたのか？
3. トレードオフを表示：何が優先度を下げられるために削除されたのか？または何がスリップしているのか？
4. 新しい計画を表示：変更を反映した更新されたロードマップ
5. 影響を認める：誰が影響を受け、どのように？優先度を下げたアイテムを期待していたステークホルダーはそれを直接聞く必要があります。

ロードマップウィップラッシュを避ける

• すべての新しい情報に対してロードマップを変更しないでください。変更のしきい値を持つ。
• 何かが本当に緊急でない限り、自然なケイデンス（毎月、四半期ごと）でロードマップ更新をバッチ処理。
• 「ロードマップ変更」（戦略的優先順位の変更）と「スコープ調整」（通常の実行調整）を区別。
• ロードマップが変更される頻度を追跡。頻繁な変更は、応答性が良好でなく、不明確な戦略を示唆する可能性があります。

出力フォーマット

クリアでスキャン可能なフォーマットを使用してください。テーブルはロードマップアイテムに適しています。テキストステータスラベルを使用：完了、順調、リスク、ブロック、未開始。

ヒント

• ロードマップは通信ツールであり、プロジェクト計画ではありません。適切な高度に保つ — テーマと成果、タスクではなく。
• 優先順位を変更するときは、常に何が変わったかを尋ねます。優先度シフトは気まぐれではなく、新しい情報によって駆動されるべき。
• 容量の問題に早期にフラグを立てます。ロードマップにチームが処理できるより多くの作業がある場合、そう言ってください。
• 依存関係はロードマップへの最大のリスクです。明示的に表面化させます。
• ユーザーが何かを追加するよう求める場合、常に何が削除されるか移動するかを尋ねます。ロードマップは容量に対してゼロサムです。