roadmap-backcast

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

目次

1. ワークフロー
2. 依存関係のマッピング
3. クリティカルパス分析
4. よくあるパターン
5. ガードレール
6. クイックリファレンス

ワークフロー

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

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：固定日付での製品ローンチ

• 目標：期日までに製品を公開し、顧客に提供する
• 主要マイルストーン（逆算）：一般提供開始、ベータテスト、機能凍結、アルファテスト、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％以上を加算する

実現可能性の確認：必要な時間 ≤ 利用可能な時間（バッファー込み）