risk-assessment

リスク評価

目次

• 概要
• 使用するタイミング
• クイックスタート
• リファレンスガイド
• ベストプラクティス

概要

リスク評価とは、プロジェクトの成功を脅かす可能性のある脅威を特定し、それらを軽減、回避、または受容するための戦略を策定する体系的なプロセスです。

使用するタイミング

• プロジェクトの開始時および計画段階
• 重要なマイルストーンや意思決定の前
• 新しいテクノロジーを導入するとき
• サードパーティへの依存や統合があるとき
• 組織やリソースに変更があるとき
• 予算やスケジュールに制約があるとき
• 規制やコンプライアンスに関する懸念があるとき

クイックスタート

最小限の実行例：

# Risk identification framework

class RiskIdentification:
    RISK_CATEGORIES = {
        'Technical': [
            'Technology maturity',
            'Integration complexity',
            'Performance requirements',
            'Security vulnerabilities',
            'Data integrity'
        ],
        'Resource': [
            'Team skill gaps',
            'Staff availability',
            'Budget constraints',
            'Equipment/infrastructure',
            'Vendor availability'
        ],
        'Schedule': [
            'Unrealistic deadlines',
            'Dependency delays',
            'Scope creep',
            'Approval delays',
            'Resource conflicts'
        ],
// ... (see reference guides for full implementation)

リファレンスガイド

詳細な実装は references/ ディレクトリにあります：

ガイド	内容
リスク特定の手法	リスク特定の手法
リスク分析マトリックス	リスク分析マトリックス
リスク対応計画	リスク対応計画
リスクの監視と管理	リスクの監視と管理

ベストプラクティス

✅ DO

• プロジェクトの計画段階で早期にリスクを特定する
• 多様なチームメンバーをリスク特定に参加させる
• 可能であればリスクの影響を定量化する
• リスクスコアと影響度に基づいて優先順位を付ける
• 具体的な軽減計画を策定する
• リスクの責任者を明確に割り当てる
• トリガーを定期的に監視する
• リスク登録簿を毎月確認し、更新する
• 顕在化したリスクから得た教訓を記録する
• リスクをステークホルダーに透明性をもって伝える

❌ DON'T

• 問題が発生するまでリスクの特定を待つ
• リスクは顕在化しないと思い込む
• すべてのリスクを同じ優先度で扱う
• 明確なトリガー条件なしに軽減策を計画する
• 早期警告の兆候を無視する
• リスク管理を一度きりの活動にする
• 重大なリスクに対する緊急時対応計画を省略する
• ステークホルダーに不都合なリスクを隠す
• あらゆるリスクを排除する（不可能であり、経済的でもありません）
• 顕在化したリスクについて個人を責める