リスク管理と障害対応
ストーリー
「計画は立てた。でもその通りに行くとは限らない」
渡辺マネージャーが言った。
「計画の価値は『計画通りに進むこと』ではなく、 『想定外が起きた時に素早く対応できること』にある。 リスク管理を覚えれば、どんな困難なプロジェクトも完遂できる」
リスク管理の基本
リスクとは
リスク = 「まだ発生していないが、発生するとプロジェクトに悪影響を与える事象」
リスクの公式:
リスクの大きさ = 発生確率 x 影響度
高確率 x 高影響 = 最重要リスク（必ず対策を用意）
高確率 x 低影響 = 監視対象（発生時に対応）
低確率 x 高影響 = 備え対象（コンティンジェンシープラン）
低確率 x 低影響 = 受容（発生しても影響小）
リスクの特定
エンジニアリングプロジェクトの典型的なリスク
| カテゴリ | リスク例 | 発生確率 | 影響度 |
|---|---|---|---|
| 技術的 | 外部APIの仕様変更 | 中 | 高 |
| 技術的 | パフォーマンスが要件を満たさない | 中 | 高 |
| 技術的 | 未知の技術的課題の発覚 | 高 | 中 |
| 人的 | メンバーの離脱・休職 | 低 | 高 |
| 人的 | スキル不 足による遅延 | 中 | 中 |
| 外部要因 | 外部ベンダーの遅延 | 中 | 高 |
| 外部要因 | 要件の変更 | 高 | 高 |
| スケジュール | 見積もりの大幅な超過 | 高 | 高 |
リスクの洗い出し方法
1. ブレインストーミング
チーム全員で「何がうまくいかない可能性があるか」を出し合う
2. 過去のプロジェクトからの学び
「前回何で困ったか」を振り返る
3. チェックリスト
カテゴリ別のリスクチェックリストで漏れを防ぐ
4. 前提条件の確認
「この計画はどんな前提に基づいているか」を洗い出し、
前提が崩れた場合のリスクを特定
リ スク対応戦略
4つの対応戦略
| 戦略 | 説明 | 例 |
|---|---|---|
| 回避（Avoid） | リスクの原因を排除する | 不安定な外部APIの代わりに自前実装 |
| 軽減（Mitigate） | 発生確率や影響を下げる | PoC（概念実証）で技術リスクを早期に検証 |
| 転嫁（Transfer） | リスクを他者に移す | SLAのある有料APIサービスを利用 |
| 受容（Accept） | リスクを受け入れる | 影響が小さいリスクはバッファで吸収 |
リスク管理表の作成
テンプレート
markdown
# リスク管理表 - コンビニ決済機能追加プロジェクト
| ID | リスク | 確率 | 影響 | 戦略 | 対策 | 担当 | ステータス |
|----|--------|------|------|------|------|------|-----------|
| R1 | 外部決済APIの仕様変更 | 中 | 高 | 軽減 | APIクライアントを抽象化し、変更に強い設計にする | あなた | 監視中 |
| R2 | パフォーマンス未達 | 中 | 高 | 軽減 | 実装初期にパフォーマンステストを実施 | 佐藤 | 対策実施中 |
| R3 | 佐藤さんの他PJ優先 | 高 | 中 | 軽減 | 佐藤さんの担当部分を早期に完了させる | 渡辺 | 監視中 |
| R4 | セキュリティ審査不合格 | 低 | 高 | 軽減 | 設計段階でセキュリティチームにレビュー依頼 | あなた | 対策実施中 |
| R5 | 要件の追加・変更 | 高 | 高 | 回避 | スコープを明確にし、変更はバックログに積む | 渡辺 | 監視中 |バッファの設計
なぜバッファが必要か
バッファなし:
設計(2w) → 実装(4w) → テスト(1w) → リリース(1w) = 8週間ピッタリ
→ 1つでも遅れるとリリースが遅延
バッファあり:
設計(2w) → 実装(4w) → テスト(1w) → [バッファ1w] → リリース(1w) = 9週間
→ 1週間の遅れを吸収できる
バッファの種類と配置
| バッファの種類 | 配置場所 | 目安 |
|---|---|---|
| タスクバッファ | 各タスクの見積もりに含める | 見積もりの20〜30% |
| フェーズバッファ | 各フェーズの終わりに | フェーズ期間の10〜20% |
| プロジェクトバッファ | リリース前に | 全体の10〜15% |
障害発生時の対応プロセス
インシデント対応フロー
[検知] → [トリアージ] → [対応] → [復旧] → [振り返り]
1. 検知（5分以内）
- 監視アラート、ユーザー報告、テスト失敗
- Slackの #alerts チャンネルに自動通知
2. トリアージ（15分以内）
- 影響範囲の確認
- 重要度の判定（Critical/High/Medium/Low）
- 対応チームの招集
3. 対応（影響に応じて）
- Critical: 全員で対応。他の作業は停止
- High: 担当者 + サポート1名で対応
- Medium: 担当者が通常の優先度で対応
- Low: 次のスプリントで対応
4. 復旧
- ロールバック or ホットフィックス
- ユーザーへの影響が解消されたことを確認
5. 振り返り（48時間以内）
- ポストモーテム（事後分析）の実施
- 再発防止策の策定と実行
ポストモーテムテンプレート
markdown
# ポストモーテム - [インシデント名]
日時: YYYY/MM/DD HH:MM〜HH:MM
影響: [影響を受けたユーザー数、期間]
重要 度: [Critical/High/Medium/Low]
## タイムライン
- HH:MM - [何が起きたか]
- HH:MM - [検知方法]
- HH:MM - [対応開始]
- HH:MM - [復旧]
## 根本原因
[なぜ発生したか]
## 対応内容
[何をして復旧したか]
## 再発防止策
| 対策 | 担当 | 期限 |
|------|------|------|
| [対策1] | [担当] | [期限] |
| [対策2] | [担当] | [期限] |
## 教訓
[学んだこと]まとめ
| ポイント | 内容 |
|---|---|
| リスクの定義 | 発生確率 x 影響度 |
| 4つの戦略 | 回避、軽減、転嫁、受容 |
| リスク管理表 | リスクを一覧化し、対策と担当を明確に |
| バッファ | タスク、フェーズ、プロジェクトの3層で配置 |
| 障害対応 | 検知→トリアージ→対応→復旧→振り返り |
| ポストモーテム | 非難なしの事後分析で再発防止 |
チェックリスト
- リスクの4つの対応戦略を説明できる
- リスク管理表を作成できる
- バッファの種類と配置方法を理解した
- インシデント対応フローを知っている
次のステップへ
次のセクションでは、「ステークホルダー管理」を学びます。プロジェクトに関わる様々な人々との関係を管理し、期待をコントロールする技術を身につけましょう。
推定読了時間: 30分