ストーリー

リスクの体系化

技術基盤刷新の5大リスクカテゴリ

リスク登録簿

リスクヒートマップ

影響度
  5  │  R06     R01,R03,R07  R02
     │         R10
  4  │                R08    R05
     │
  3  │  R09          R04
     │
  2  │
     │
  1  │
     └──────────────────────────
        1     2     3     4     5
                    確率

リスク緩和戦略

各リスクの緩和策詳細

R05: 変革抵抗への対応（Month 8の知見）

変革の5段階（ADKAR）:

Awareness（認知）:
  └── なぜ変革が必要かを全社タウンホールで説明

Desire（意欲）:
  └── 開発者の痛み（手動デプロイ、ツール分散）を解消するメリットを提示

Knowledge（知識）:
  └── 新ツール・新プロセスのトレーニングプログラムを提供

Ability（能力）:
  └── パイロットチームによるハンズオン支援、ペアプログラミング

Reinforcement（定着）:
  └── 成功事例の共有、表彰制度、メトリクスの可視化

R02: キーパーソン離職への対応

撤退計画

施策レベルの撤退判断

プロジェクトレベルの撤退判断

プロジェクト継続/撤退の判定フレームワーク:

判定時期: Phase移行時（3ヶ月、12ヶ月、24ヶ月）

判定基準:
  RED（プロジェクト中止を検討）:
    - 予算超過が30%以上
    - スケジュール遅延が50%以上
    - 主要マイルストーンの2つ以上が未達
    - 経営層スポンサーの喪失

  YELLOW（計画修正が必要）:
    - 予算超過が15-30%
    - スケジュール遅延が25-50%
    - 主要マイルストーンの1つが未達
    - チーム士気の低下

  GREEN（計画通り継続）:
    - 予算・スケジュールが計画の15%以内
    - 全マイルストーン達成
    - チーム士気良好

段階的縮小（Graceful Degradation）

プロジェクト全体が厳しい場合の段階的縮小:

優先度1（死守する施策）:
  ├── CI/CD統一（開発生産性の基盤）
  ├── セキュリティスキャン統合（リスク低減）
  └── SLI/SLO定義（信頼性の可視化）

優先度2（できれば実施）:
  ├── IDP構築（開発者体験向上）
  ├── IaC拡大（運用効率化）
  └── データカタログ（データ可視化）

優先度3（余裕があれば実施）:
  ├── ゼロトラスト（セキュリティ高度化）
  ├── AI/ML基盤（将来投資）
  └── データメッシュ（データ高度化）

「撤退計画は失敗を認めることではない。戦略的な判断力の証だ。撤退計画がないプロジェクトは、沈没する船にしがみつくようなものだ」 — 田中VPoE

まとめ

チェックリスト

• 5大リスクカテゴリを理解した
• リスク登録簿の作成とスコアリングができる
• 変革抵抗への対応（ADKAR）を把握した
• 撤退計画の必要性と設計方法を理解した
• 段階的縮小の優先順位付けができる

次のステップへ

次は演習です。Step 3で学んだ移行戦略、ストラングラーフィグ、フェーズドロールアウト、リスク管理を統合して、TechForward社の移行ロードマップを策定しましょう。

推定読了時間: 30分