roadmap-backcast

ロードマップのバックキャスト

目次

1. 目的
2. 使用する場面
3. 概要
4. ワークフロー
5. 依存関係のマッピング
6. クリティカルパス分析
7. 一般的なパターン
8. ガードレール
9. クイックリファレンス

目的

ロードマップのバックキャストでは、固定された目標や期限から現在に向かって逆算し、必要なマイルストーン、依存関係、クリティカルパス、実現可能性の制約を特定します。意欲的な目標を、実行可能で順序立てられた計画に変換します。

使用する場面

次のような場合に、このスキルを呼び出してください：

• 固定された期限（製品のローンチ、イベント、コンプライアンス期限）に向けて計画を立てる
• 戦略的な目標から現在の取り組みまで逆算する
• 複雑な取り組みの依存関係と順序をマッピングする
• クリティカルパス（所要期間を決定する最長の工程）を特定する
• 野心的なスケジュールの実現可能性を評価する
• 共通のマイルストーンに向けて部門横断の作業を調整する
• 中間チェックポイントを設けて、複数年にわたる変革を計画する
• 相互に積み上がる取り組みの順序を決める
• 依存する作業ストリーム間でリソースを割り当てる

このスキルを呼び出すユーザーのフレーズ：

• 「[日付]までにローンチする必要があります」
• 「目標から逆算してください」
• 「[成果]を達成するには何が必要ですか？」
• 「目標から逆算して計画する」
• 「期限は固定ですが、実現可能なことは何ですか？」
• 「[将来の状態]からバックキャストする」
• 「納品までのクリティカルパス」

概要

次の手順でバックキャスト型のロードマップを作成します：

1. 最終状態を定義する（具体的で測定可能な目標成果と日付）
2. 逆算する（その一つ前の段階で何が成立している必要があるか？ さらにその前は？）
3. マイルストーンを特定する（明確な成果物を伴う主要なチェックポイント）
4. 依存関係をマッピングする（何が何に依存し、何を並行して進められるか）
5. クリティカルパスを見つける（最短所要期間を決定する最長の連鎖）
6. 実現可能性を評価する（目標日までに現実的に達成できるか）

簡単な例（2025年第1四半期までに製品をローンチ）：

• 目標：2025年1月31日までに、1,000人の顧客向けに製品を本番環境で稼働させる
• T-4週（1月3日）：50人の顧客によるベータテストを完了し、重大なバグを修正
• T-8週（12月6日）：機能を完成させ、社内QAに合格
• T-12週（11月8日）：MVPを構築し、主要機能を動作させる
• T-16週（10月11日）：設計を確定し、APIコントラクトを定義
• T-20週（9月13日）：要件を確定し、チームを編成
• 今日（9月1日）：スコープの拡大がなく、20％の時間的余裕を含めれば実現可能

ワークフロー

このチェックリストをコピーして、進捗を記録してください：

Roadmap Backcast Progress:
- [ ] Step 1: Define target outcome precisely
- [ ] Step 2: Work backward to identify milestones
- [ ] Step 3: Map dependencies and sequencing
- [ ] Step 4: Identify critical path
- [ ] Step 5: Assess feasibility and adjust

ステップ1：目標成果を正確に定義する

曖昧な目標ではなく、具体的な成果、目標日、成功基準を明示します。成果の定義例については、一般的なパターンを参照してください。シンプルなバックキャストには、resources/template.mdを使用してください。

ステップ2：逆算してマイルストーンを特定する

ゴールから始め、「その直前の段階で何が成立している必要があるか？」と繰り返し問いかけます。主要なマイルストーンを5～10個作成してください。複雑な複数年のロードマップについては、resources/methodology.mdを確認してください。

ステップ3：依存関係と順序をマッピングする

何が何に依存しているか、何を並行して進められるかを特定します。手法については、依存関係のマッピングを参照してください。

ステップ4：クリティカルパスを特定する

依存するタスクの最長の連鎖を見つけます（これが最短所要期間を決定します）。クリティカルパス分析を参照してください。

ステップ5：実現可能性を評価して調整する

必要な期間と利用可能な期間を比較します。余裕（20～30％）を設け、リスクを特定し、必要に応じてスコープまたは日程を調整してください。最終決定の前に、resources/evaluators/rubric_roadmap_backcast.jsonを使用してセルフチェックを行います。最低基準：平均スコア ≥ 3.5。

依存関係のマッピング

依存関係の種類：

順次（A → B）：A が完了するまで B を開始できません

• 例：エンジニアリングを開始する前に、設計を完了する必要があります
• クリティカルパスへの影響：スケジュールが延びます
• 対策：A をできるだけ早く開始し、安全に進められる作業は並行して行います

並行（A ∥ B）：A と B を同時に進められます

• 例：バックエンド開発とフロントエンド開発
• クリティカルパスへの影響：なし（必要なリソースが確保されている場合）
• メリット：全体のスケジュールを短縮できます

合流（A, B → C）：C を完了するには A と B の両方が完了している必要があります

• 例：テストにはコードの完成とテスト環境の準備の両方が必要です
• クリティカルパスへの影響：C は A と B のうち遅い方を待ちます
• 対策：両方の経路を監視し、遅い方を加速します

分岐（A → B, C）：A によって B と C の両方を進められます

• 例：API コントラクトを定義すると、フロントエンドとバックエンドの両方の作業を開始できます
• クリティカルパスへの影響：A の遅延は、その後のすべての作業を遅らせます
• 対策：A を優先し、手戻りを避けるため高品質を確保します

クリティカルパス分析

クリティカルパス：依存関係のあるタスクのうち最長の連鎖（プロジェクトの最短期間を決定します）

クリティカルパスの特定方法：

1. 期間を含めてすべてのマイルストーンを列挙します
2. 依存関係グラフを描きます（前提となるタスクから依存するタスクへ矢印を引きます）
3. 各マイルストーンの最早開始日と最早終了日を計算します（順方向パス）
4. 各マイルストーンの最遅開始日と最遅終了日を計算します（逆方向パス）
5. 余裕がゼロのマイルストーン（最早日＝最遅日）がクリティカルパス上にあります

例：

Milestone A (4 weeks) → Milestone B (6 weeks) → Milestone D (2 weeks) = 12 weeks (critical path)
Milestone A (4 weeks) → Milestone C (3 weeks) → Milestone D (2 weeks) = 9 weeks (non-critical, 3 weeks slack)

クリティカルパスは12週間です（A→B→D の経路）

クリティカルパスの管理：

• 綿密に監視する：クリティカルパス上の遅延は、プロジェクトを直接遅らせます
• バッファを追加する：クリティカルパス上のタスクに20～30％を追加します（マーフィーの法則）
• リソースの優先順位付け：クリティカルパスに人員を優先的に配置します
• ファストトラッキング：クリティカルパスを支援するために、クリティカルでない作業を遅らせられますか？
• クラッシング：リソースを追加してクリティカルパスを短縮します（効果は逓減し、ブルックスの法則が当てはまります）

よくあるパターン

パターン1：期日が決まっている製品ローンチ

• 目標：期日までに製品を公開し、顧客に提供する
• 主なマイルストーン（逆算）：GA ローンチ、ベータテスト、機能凍結、アルファテスト、MVP、設計完了、要件確定
• クリティカルパス：通常は設計 → エンジニアリング → テスト（順次）
• バッファ：エンジニアリングに20～30％（不確定要素）、テストに20％（バグ）

パターン2：コンプライアンスの期限（規制）

• 目標：規制上の期限までに準拠する（延期できません）
• 主なマイルストーン：監査合格、統制の導入、ポリシーの更新、ギャップ分析の完了
• クリティカルパス：ギャップ分析 → 是正 → 検証
• バッファ：40％以上（規制上のリスクは許容されないため、余裕を多めに確保します）

パターン3：戦略的な変革（複数年）

• 目標：将来のあるべき姿を実現する（例：「2027年までにクラウドネイティブアーキテクチャを実現」）
• 主なマイルストーン（年次）：3年目（移行完了）、2年目（50％移行済み）、1年目（パイロット完了）、0年目（戦略承認）
• クリティカルパス：基盤作業（パイロット、学び）によって規模を拡大できます
• バッファ：各フェーズに30％以上（不確定要素は時間とともに積み重なります）

パターン4：イベント企画（カンファレンス、ローンチイベント）

• 目標：期日にイベントを開催し、参加者に素晴らしい体験を提供する
• 主なマイルストーン：イベント当日、リハーサル、コンテンツ準備完了、登壇者確定、会場予約、日程発表
• クリティカルパス：リードタイムの長い会場予約がクリティカルパス上にあることがよくあります
• バッファ：10～20％（イベントには厳守すべき期限があり、柔軟性は低くなります）

ガードレール

実現可能性の確認：

• 利用可能な時間 ≥ 必要な時間：逆算したスケジュールが今日より前に達する場合、目標は実現不可能です
• バッファを含める：見積もりに20～30％を加えます（ホフスタッターの法則：「ホフスタッターの法則を考慮に入れても、いつも予想以上に時間がかかる」）
• 依存関係が現実的である：依存する作業を本当に順番に進められますか（引き継ぎ時間、手戻りなど）？
• リソースの制約：必要な箇所で並行作業を行うための人員や予算はありますか？

よくある落とし穴：

• 楽観的な順序付け：引き継ぎが完璧で、手戻りも障害もないと想定する
• 依存関係を無視する：「すべてを一度に始められる」→実際には順次進行が必要
• バッファがない：余裕が0％の計画は、最初の問題で破綻します
• スコープクリープ：実行中に目標の成果が拡大し、バックキャストが無効になる
• サンクコストの誤謬：バックキャストで実現不可能と分かったら、スコープや日程を調整します（そのまま突き進まない）

品質基準：

• マイルストーンには明確な成果物がある（「Xに取り組んでいる」ではない）
• 依存関係が明示的に整理されている（想定に頼らない）
• クリティカルパスが特定されている（スケジュールを決定する要因を把握する）
• 実現可能性が正直に評価されている（希望的観測に頼らない）
• リスクが文書化されている（スケジュールを延長する可能性のある要因は何か）
• 各マイルストーンに担当者が割り当てられている（説明責任）

クイックリファレンス

リソース：

• クイックバックキャスト：resources/template.md
• 複雑なロードマップ：resources/methodology.md
• 品質評価基準：resources/evaluators/rubric_roadmap_backcast.json

5ステップのプロセス：目標を定義 → 逆算する → 依存関係を整理する → クリティカルパスを特定する → 実現可能性を評価する

依存関係の種類：順次（A→B） | 並行（A∥B） | 合流（A,B→C） | 分岐（A→B,C）

クリティカルパス：依存関係のある最長の連続工程 = プロジェクトの最短所要期間

バッファのルール：見積もりに20～30％を加えます。不確実性の高い作業には40％以上を加えます

実現可能性のテスト：必要な時間 ≤ 利用可能な時間（バッファ込み）