Risk Assessor

リスクアセッサー

リスクアセッサーのスキルは、プロジェクトのリスクが問題になる前に、チームがリスクを事前に特定、分析、優先順位付けし、軽減するのに役立ちます。体系的なリスク管理フレームワークを使用して脅威を洗い出し、発生可能性と影響を評価し、実行可能な軽減策を作成します。

このスキルは、プレモーテム演習の実施、リスク登録簿の作成、発生確率と影響の評価、緊急時対応計画の策定、プロジェクトの頓挫につながる前にリスクを検知する早期警告指標の設定に優れています。

リスクアセッサーは、リスクに対処する最善のタイミングは、危機になる前であるという原則に従います。積極的なリスク管理により、より良い意思決定、現実的な計画、そして予想外の事態の減少が可能になります。

主なワークフロー

ワークフロー 1：リスク評価の実施

手順：

1. リスクの特定

   • プレモーテム演習：プロジェクトが失敗したと想像してください。原因は何でしょうか？
   • ブレインストーミング：チームで潜在的なリスクを洗い出します
   • カテゴリの確認：一般的なリスクカテゴリを確認します
     • 技術：アーキテクチャ、パフォーマンス、セキュリティ、スケーラビリティ
     • スケジュール：期限、依存関係、リソースの確保状況
     • リソース：チームの対応能力、スキルの不足、予算の制約
     • 外部：市場の変化、規制、ベンダーへの依存
     • 品質：バグ、技術的負債、ユーザーエクスペリエンス
     • 組織：ステークホルダー間の認識の一致、優先順位の変化
   • 履歴分析：過去のプロジェクトで発生した問題を確認します
   • 専門家の意見：専門家（セキュリティ、法務など）に相談します

2. リスクの文書化

   • 各リスクについて、以下を記録します：
     • 説明：どのようなリスクですか？
     • カテゴリ：どの種類のリスクですか？
     • 引き金：このリスクは何が原因で発生しますか？
     • 影響：リスクが発生した場合、何が起こりますか？
     • 担当者：このリスクを監視し、管理するのは誰ですか？

3. 発生確率の評価

   • 発生の可能性を評価します：
     • 低（1）：発生確率 10% 未満
     • 中（2）：発生確率 10～50%
     • 高（3）：発生確率 50% 超
   • データ、経験、専門家の判断に基づいて評価します
   • 発生確率の評価に用いた前提を記録します

4. 影響の評価

   • リスク発生時の深刻度を評価します：
     • 低（1）：軽微な遅延またはコスト増加
     • 中（2）：スケジュールまたはスコープへの重大な影響
     • 高（3）：プロジェクトの失敗または事業への重大な影響
   • 時間、コスト、品質、評判など、複数の側面を考慮します
   • 最悪のシナリオを想定します

5. リスクの優先順位付け

   • リスクスコア ＝ 発生確率 × 影響度で算出します
   • スコア（1～9 段階）に基づいて優先順位を付けます：
     • 重大（7～9）：直ちに対処します
     • 高（4～6）：軽減計画を策定します
     • 中（2～3）：定期的に監視します
     • 低（1）：追跡しますが、積極的な軽減策は講じません
   • 優先順位が最も高い上位 5～10 件のリスクに重点を置きます

出力： 特定、評価、優先順位付け済みのリスクを記載したリスク登録簿。

ワークフロー 2：軽減策の策定

優先順位の高いリスクごとに、以下を実施します。

1. 戦略の種類を選択

   • 回避：アプローチを変更する、機能を削除するなどしてリスクをなくします
   • 軽減：テストを追加する、専門家を採用するなどして、発生確率または影響を低減します
   • 移転：保険やベンダーの SLA などを通じて、リスクを第三者に移します
   • 受容：リスクを認識し、発生時の対応を計画します

2. 軽減計画の作成

   • リスクを低減するための具体的なアクション
   • 担当者と期限を割り当てます
   • 成功基準を定義します
   • コストと作業量を見積もります
   • 依存関係を特定します

3. 緊急時対応計画の策定

   • 「リスクが発生した場合は、次の対応を行います……」
   • 代替手段と選択肢
   • 復旧時間目標
   • ステークホルダー向けの連絡計画
   • 必要なリソース

4. 早期警告指標の定義

   • リスクの顕在化を示す先行指標
   • 監視の頻度と方法
   • 緊急時対応を開始する基準
   • 監視担当者と通知先

出力： 担当者が明確なリスク軽減計画と緊急時対応計画。

ワークフロー 3：リスクの監視と更新

毎週：

1. 早期警告指標を確認します
2. 状況が変化した場合は、発生確率／影響度を更新します
3. リスク軽減策の状況を確認します
4. 新たに特定されたリスクを追加します
5. 解決済み、または古くなったリスクをクローズします

毎月：

1. リスク登録簿を全体的に見直します
2. リスク軽減策の有効性を評価します
3. 主要なリスクをステークホルダーに報告します
4. 新しい情報に基づいて優先順位を調整します
5. 緊急時対応計画を更新します

次の場合：

• リスクが発生した場合は、緊急時対応計画を発動します
• 発生したことと学んだ教訓を記録します
• 将来のプロジェクトに向けてリスクモデルを更新します

ワークフロー 4：プレモーテム演習

進行役がいるチームセッション（60 分）：

1. 状況設定（5 分）

   • 「今から 6 か月後を想像してください。このプロジェクトは、みごとに失敗しました」
   • 「何が問題だったのかを理解するために、事後分析を行います」
   • 「失敗の原因は何ですか？」

2. 個人でのブレインストーミング（10 分）

   • 各自が無言で失敗のシナリオを書き出します
   • 独創的で、考えるのがつらい内容も歓迎します
   • 自己検閲や取捨選択はしません

3. 順番に共有（20 分）

   • 各自が自分のシナリオを共有します
   • 共有ボードにすべて記録します
   • 議論や弁明はせず、聞くことに徹します

4. グループ化と優先順位付け（15 分）

   • 類似する失敗モードをまとめます
   • 発生可能性または影響度が最も高いものに投票します
   • 上位 5～10 件の失敗シナリオを特定します

5. リスクへの変換（10 分）

   • 失敗を現在のリスクとして捉え直します
   • リスク登録簿に追加します
   • 初期の担当者を割り当てます

成果物： チーム全体の知見から特定したリスクの一覧です。

クイックリファレンス

アクション	コマンド／トリガー
リスクを評価する	"assess risks for [project]"
プレモーテム	"run pre-mortem for [project]"
リスク登録簿	"create risk register"
リスクを更新する	"update risk status"
主要なリスク	"what are the top risks"
リスク軽減計画	"create mitigation plan for [risk]"
緊急時対応計画	"plan contingency for [risk]"
リスクレポート	"generate risk report"

ベストプラクティス

• 安心して話せる場を作る：率直なリスクの特定を促し、懸念を早期に提起した人を評価します
• 悲観的に考える：リスクを特定する際は、マーフィーの法則（起こりうることは、いずれ起こる）を前提にします
• 可能な限り定量化する：発生確率や影響度には、直感だけでなくデータや指標を使います
• 主要なリスクに注力する：すべてのリスクを軽減することはできないため、優先度の高いリスクに注力します
• すべてのリスクに担当者を割り当てる：各リスクには、監視と軽減策の推進を担う、名前の明確な担当者が必要です
• 危機が起きる前に計画する：冷静なときに作成した緊急時対応計画は、慌てているときに作成するものより優れています
• 定期的に見直す：リスクは変化します。毎週見直すことで、登録簿を最新かつ実行可能な状態に保てます
• 過去から学ぶ：過去のプロジェクトの失敗は、将来のリスクを特定するうえで優れた教訓になります
• 学びに応じて発生確率を更新する：プロジェクトの進行に合わせ、新しい情報に基づいて発生確率を調整します
• 都合の悪い事実を無視しない：話し合いを避けているリスクこそ、最も危険なことがよくあります
• 透明性をもって伝える：主要なリスクをステークホルダーと共有します。予期せぬ事態は信頼を損ないます
• 過度な警戒と前進のバランスを取る：リスク管理は行動を麻痺させるのではなく、行動の判断に役立つべきです

リスクカテゴリのチェックリスト

技術的リスク

• 実証されていない、または新しいテクノロジー
• パフォーマンスまたはスケーラビリティに関する懸念
• セキュリティの脆弱性
• 統合の複雑さ
• 技術的負債の負担
• インフラストラクチャの信頼性
• データ移行の課題

スケジュールリスク

• 厳しすぎる、または現実的でないスケジュール
• 他のチーム／プロジェクトへの依存
• 重要なマイルストーンの不整合
• 複雑さの過小評価
• 祝日や休暇との重複
• 外部の期限によるプレッシャー

リソースリスク

• チームの対応能力不足
• 特定の人への依存（バス係数）
• スキル不足やトレーニングの必要性
• 予算の制約
• 優先事項の競合
• 離職や人員の入れ替わり

外部リスク

• ベンダーの信頼性または変更
• 規制またはコンプライアンスの変更
• 市場環境の変化
• 競合他社の動向
• 顧客需要の不確実性
• サードパーティ API の安定性

品質リスク

• テストカバレッジの不足
• 複雑または不明確な要件
• コード品質またはアーキテクチャの不備
• ユーザーエクスペリエンスに関する懸念
• アクセシビリティまたはコンプライアンスの不備
• ブラウザー／デバイスの互換性

組織上のリスク

• ステークホルダー間の認識の不一致
• 意思決定権限が不明確
• プロジェクト途中での優先順位の変更
• 政治的または組織的な力学
• コミュニケーションの断絶
• チーム間の調整に関する課題

リスクマトリックス

                    IMPACT
              Low (1)  Med (2)  High (3)
PROBABILITY
High (3)      3 (H)    6 (H)    9 (C)
Med (2)       2 (M)    4 (H)    6 (H)
Low (1)       1 (L)    2 (M)    3 (H)

C = Critical  (7-9): Immediate action required
H = High      (4-6): Develop mitigation plan
M = Medium    (2-3): Monitor regularly
L = Low       (1):   Track in register

対策決定の判断フロー

Can we eliminate this risk entirely?
  YES → AVOID strategy (change approach)
  NO ↓

Can we significantly reduce probability or impact?
  YES → MITIGATE strategy (take action)
  NO ↓

Can someone else manage this better?
  YES → TRANSFER strategy (outsource, insure)
  NO ↓

ACCEPT strategy (plan contingency)

リスク登録簿テンプレート

## Risk Register - [Project Name]

Last Updated: [Date]

### Critical Risks (Score 7-9)

#### R-001: [Risk Title]
- **Description**: [What is the risk?]
- **Category**: Technical | Schedule | Resource | External | Quality | Organizational
- **Probability**: High (3) | Medium (2) | Low (1)
- **Impact**: High (3) | Medium (2) | Low (1)
- **Risk Score**: [P × I]
- **Trigger**: [What causes this?]
- **Owner**: [Name]
- **Status**: Active | Monitoring | Closed
- **Mitigation Strategy**: Avoid | Mitigate | Transfer | Accept
- **Mitigation Actions**:
  - [ ] Action 1 - Owner - Due Date
  - [ ] Action 2 - Owner - Due Date
- **Contingency Plan**: If risk occurs, we will...
- **Early Warning Indicators**: [What to watch for]
- **Last Reviewed**: [Date]

### High Risks (Score 4-6)
[Same format as above]

### Medium Risks (Score 2-3)
[Same format as above]

よくあるプロジェクトリスクと軽減策

リスク：主要な開発者がプロジェクト途中で離脱する

• 軽減策：ペアプログラミング、ドキュメント作成、知識共有
• 緊急時の対応策：契約開発者の確保、スケジュールの延長
• 兆候：チームメンバーの意欲低下、転職活動の兆候

リスク：要件が大幅に変更される

• 軽減策：アジャイルなアプローチ、ステークホルダーとの頻繁な確認、MVP への注力
• 緊急時の対応策：スコープの交渉、スケジュールの調整
• 兆候：ステークホルダーの不満、市場からのフィードバック

リスク：サードパーティ API の信頼性が低下する

• 軽減策：キャッシュ、再試行ロジック、サーキットブレーカーの実装
• 緊急時の対応策：代替ベンダーの利用、社内での開発
• 兆候：エラー率の上昇、レイテンシーの急増

リスク：パフォーマンスが要件を満たさない

• 軽減策：早期のパフォーマンステスト、アーキテクチャレビュー
• 緊急時の対応策：最適化スプリント、インフラストラクチャの拡張
• 兆候：負荷テストの失敗、ユーザーからの苦情

リスク：セキュリティ脆弱性が発見される

• 軽減策：セキュリティレビュー、侵入テスト、依存関係のスキャン
• 緊急時の対応策：インシデント対応計画、ロールバック手順
• 兆候：セキュリティアラート、CVE 通知

リスク：プロジェクトの予算が超過する

• 軽減策：正確な見積もり、予備費の確保、コストの追跡
• 緊急時の対応策：スコープの縮小、追加予算の申請
• 兆候：消費ペースが予測を上回る

統合ポイント

• プロジェクトプランナー：計画フェーズでリスクを特定します
• スプリントプランナー：スプリント計画時にリスクを確認します
• タスクマネージャー：軽減策のアクションアイテムを追跡します
• 振り返りの進行役：リスクから得た教訓を記録します
• ステークホルダーとのコミュニケーション：リスクの状況を報告します
• インシデント管理：緊急時対応計画を実行します