project-risk-register

プロジェクトリスク登録簿

目次

1. ワークフロー
2. よくあるパターン
3. リスク評価フレームワーク
4. ガードレール
5. クイックリファレンス

リスクマトリックス（5×5の確率×影響度）：

Impact →     1         2         3         4         5
Prob ↓    Minimal   Minor   Moderate  Major   Severe

5 High   │ Medium │ Medium │  High  │  High  │ Critical│
         │   5    │   10   │   15   │   20   │   25    │
4        │  Low   │ Medium │ Medium │  High  │  High   │
         │   4    │    8   │   12   │   16   │   20    │
3 Medium │  Low   │  Low   │ Medium │ Medium │  High   │
         │   3    │    6   │    9   │   12   │   15    │
2        │  Low   │  Low   │  Low   │ Medium │ Medium  │
         │   2    │    4   │    6   │    8   │   10    │
1 Low    │  Low   │  Low   │  Low   │  Low   │ Medium  │
         │   1    │    2   │    3   │    4   │    5    │

リスクのしきい値：

• 重大（≥20）：経営幹部にエスカレーションし、直ちに軽減策を実施する必要があります
• 高（12-19）：積極的に管理し、毎週レビューを実施し、軽減策を文書化します
• 中（6-11）：注意深く監視し、毎月レビューを実施し、緊急時対応計画を用意します
• 低（1-5）：受容するか、最小限の軽減策を実施し、四半期ごとにレビューします

例：ソフトウェア移行プロジェクト

リスクID	リスク	確率	影響度	スコア	担当者	軽減策	緊急時対応
R-001	プロジェクトの途中でサードパーティ API が廃止される	3	4	12（中）	エンジニアリングリード	廃止スケジュールについてベンダーに問い合わせる	すぐに切り替えられるよう抽象化レイヤーを構築する
R-002	重要な段階で主要エンジニアが退職する	2	5	10（中）	EM	ナレッジ共有、ペアプログラミング	代替エンジニアを契約する
R-003	データ移行に見積もりの3倍の時間がかかる	4	4	16（高）	データリード	まずデータの10％で移行を試行する	スケジュールを延長し、スコープを縮小する

ワークフロー

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

Risk Register Progress:
- [ ] Step 1: Identify risks across categories
- [ ] Step 2: Assess probability and impact
- [ ] Step 3: Calculate risk scores and prioritize
- [ ] Step 4: Assign owners and define responses
- [ ] Step 5: Monitor and update regularly

ステップ1：各カテゴリのリスクを特定する

体系的なカテゴリ（技術、スケジュール、リソース、外部要因、スコープ）を使って、起こり得る問題をブレインストーミングします。カテゴリ別のチェックリストについては、よくあるパターンを参照してください。登録簿の構成にはresources/template.mdを使用してください。

ステップ2：確率と影響度を評価する

各リスクについて、確率（1～5：まれ～ほぼ確実）と影響度（1～5：最小～深刻）を採点します。正確性を高めるため、対象分野の専門家を交えてください。定義については、リスク評価フレームワークを参照してください。

ステップ3：リスクスコアを計算し、優先順位を付ける

各リスクの確率×影響度を計算します。リスクマトリックス（5×5のグリッド）にプロットして、リスクの全体像を可視化します。まず重大／高リスクの軽減に取り組んでください。モンテカルロシミュレーションなどの高度な手法については、resources/methodology.mdを参照してください。

ステップ4：担当者を割り当て、対応を定義する

高／重大リスクごとに、氏名を明記した担当者（「チーム」ではなく個人）を割り当て、軽減策（確率を下げる）、緊急時対応（影響度を下げる）、およびトリガー（緊急時対応を開始する条件）を定義します。対応計画の構成については、resources/template.mdを参照してください。

ステップ5：定期的に監視し、更新する

リスク登録簿を、進行中のプロジェクトでは毎週、長期プロジェクトでは毎月レビューします。状況の変化に応じて確率／影響度を更新し、新たなリスクを追加し、解消済みのリスクを終了扱いにし、軽減策の進捗を追跡します。監視の頻度については、ガードレールを参照してください。

よくあるパターン

リスクカテゴリ（ブレインストーミングに活用してください）：

• 技術リスク：技術の失敗、統合の問題、パフォーマンスの問題、セキュリティの脆弱性、技術的負債、複雑さの過小評価
• スケジュールリスク：依存関係の遅延、見積もりの誤り、スコープの拡大、リソースの不足、クリティカルパスの停滞
• リソースリスク：キーパーソンの離職、スキル不足、予算超過、ベンダー／請負業者に関する問題、機器の不足
• 外部リスク：規制の変更、市場の変化、競合他社の動向、景気後退、自然災害、ベンダーの倒産
• スコープリスク：要件が不明確、優先順位の変更、ステークホルダー間の意見の相違、過剰な作り込み、当初の目的からの逸脱
• 組織リスク：経営陣の支援不足、優先事項の競合、資金不足、組織変更、政治的な対立

プロジェクトの種類別：

• ソフトウェアプロジェクト：サードパーティ API の変更、依存関係の脆弱性、クラウドプロバイダーの障害、データ移行の問題、ブラウザーの互換性、スケーリングの問題、セキュリティ侵害
• 建設プロジェクト：天候による遅延、資材不足、許可に関する問題、労働争議、土壌の状態、コスト超過、安全上の事故
• 製品のローンチ：製造の遅延、サプライチェーンの混乱、競合製品のローンチ、価格設定の誤り、市場の需要が予想を下回ること、品質の問題
• 組織変更：従業員の抵抗、コミュニケーションの断絶、不十分なトレーニング、予算削減、リーダーシップの交代、企業文化の不一致

リスク対応の種類別：

• 軽減（発生確率を下げる）：トレーニング、プロトタイピング、プロセス改善、冗長化、品質チェック、早期テスト
• コンティンジェンシー（発生時の影響を軽減する）：バックアップ計画、保険、予備（時間／予算）、代替サプライヤー、ロールバック手順
• 受容（何もしない）：軽減コストに見合わないスコアの低いリスク、軽減後に残るリスク
• 移転（他者に移す）：保険、アウトソーシング、契約（違約条項）、保証

リスクプロファイルの一般的な推移：

• プロジェクト開始時：中程度のリスクが多数（不確実性が高い）、重大なリスクは少数（軽減前）
• プロジェクト中盤：重大なリスクが中程度／低程度に軽減され、新たなリスクが発生（依存関係、統合）
• 完了間近：低リスクが大半（ほとんどの問題が解決済み）、高リスクは少数（土壇場での予想外の事態）
• 危険信号：リスクスコアが時間とともに上昇している（軽減が機能していない、解決よりも速いペースで新たな問題が発生している）

リスク評価フレームワーク

発生確率スケール（1～5）：

• 5 - ほぼ確実（>80%）：発生が予想され、過去のデータでも確認されており、緩和策がありません
• 4 - 高い（60～80%）：発生する可能性が高く、類似プロジェクトでも同様の問題があり、緩和策は不十分です
• 3 - 可能性あり（40～60%）：発生するかどうかは状況によりますが、何らかの緩和策があります
• 2 - 低い（20～40%）：発生しない可能性が高く、緩和策があり、過去の前例もほとんどありません
• 1 - まれ（<20%）：発生する可能性は非常に低く、強力な緩和策があり、過去の前例はありません

影響度スケール（1～5）— プロジェクトの状況に応じて各評価軸を調整します：

スケジュールへの影響：

• 5 - 深刻：遅延が20%超（例：3か月のプロジェクトで3週間以上の遅延）、重大な期限を逃す、遅延が連鎖する
• 4 - 大きい：遅延が10～20%、マイルストーンを逃す、依存するプロジェクトに影響する
• 3 - 中程度：遅延が5～10%、スケジュールの予備期間を消費する、外部への影響はない
• 2 - 小さい：遅延が5%未満、スプリント／フェーズ内で吸収できる、スケジュールへの軽微な負担
• 1 - 最小：遅延が1%未満、または遅延なし、スケジュールへの影響は無視できる

予算への影響：

• 5 - 深刻：予算超過が20%超、新たな資金承認が必要、プロジェクトの存続が脅かされる
• 4 - 大きい：予算超過が10～20%、予備費を使い切る、スコープの削減が必要
• 3 - 中程度：予算超過が5～10%、予備費を一部使用する、スコープの削減は不要
• 2 - 小さい：予算超過が5%未満、予算の柔軟性の範囲内で吸収できる
• 1 - 最小：予算超過が1%未満、または予算への影響なし

スコープ／品質への影響：

• 5 - 深刻：中核機能が失われる、顧客に影響する品質問題、規制違反
• 4 - 大きい：重要な機能を削減する、品質が大幅に低下する、顧客から苦情が寄せられる
• 3 - 中程度：あると望ましい機能を削減する、軽微な品質問題、社内での回避策が必要
• 2 - 小さい：特殊なケースの機能を削減する、見た目に関する品質問題
• 1 - 最小：スコープや品質への影響なし

複合影響度（複数の評価軸に影響する場合）：

• いずれか1つの評価軸の最大値を使用します（悲観的かつ保守的な評価）
• または、加重平均を使用します：スケジュール 40%、予算 30%、スコープ／品質 30%

評価例：

リスク：「プロジェクトの途中で主要なエンジニアが離職する」

• 発生確率：2（低い — 勤続年数、満足度、定着率に基づくと20%）
• スケジュールへの影響：4（大きい — 後任者の採用・引き継ぎにより3週間の遅延）
• 予算への影響：2（小さい — 採用手数料、一部の残業代）
• スコープへの影響：3（中程度 — 高度な機能を削減する可能性がある）
• 複合影響度：4（最大値を採用：スケジュールへの影響が最も大きい）
• リスクスコア：2 × 4 = 8（中）

ガードレール

品質を確保する：

1. 事後対応ではなく、事前にリスクを特定する：問題が起きる前にリスクワークショップを実施します

   • ✓ プロジェクト開始時にリスクをブレインストーミングし、チェックリスト（技術、スケジュール、リソースなど）を活用します
   • ❌ インシデント発生後にのみリスクを追加します（事後対応）

2. 曖昧にせず、具体的に記述する：「統合に失敗する」は曖昧ですが、「ベンダー API のレート制限により移行が妨げられる」は具体的です

   • ✓ 「不正利用防止ルールにより、サードパーティの決済ゲートウェイが取引の 10% を拒否する」
   • ❌ 「決済の問題」

3. 発生確率と影響を分ける：「起きたら深刻」と「起きる可能性が高い」を混同しないでください

   • ✓ 小惑星がオフィスに衝突する：確率 = 1（まれ）、影響 = 5（深刻）、スコア = 5（優先度は低い）
   • ❌ 混同：「本当に深刻だから優先度が高いはず」（発生確率の低さを無視）

4. チームではなく、個人名を挙げて担当者を割り当てる：「エンジニアリングチーム」では責任の所在が明確になりませんが、「Sarah（テックリード）」なら明確です

   • ✓ 担当者：Sarah（テックリード）。監視と緊急時対応策の発動を担当します
   • ❌ 担当者：エンジニアリングチーム（責任が分散）

5. 軽減策と緊急時対応策の両方を定義する：軽減策は発生確率を下げ、緊急時対応策は発生した場合に対処します

   • ✓ 軽減策：統合を早期にプロトタイプ化する（発生確率を低減）。緊急時対応策：すぐに切り替えられる抽象化レイヤーを構築する（影響を低減）
   • ❌ 軽減策のみで、代替策がない

6. 定期的に更新する：古いリスク登録簿は、誤った安心感を生むため、ないより悪い場合があります

   • ✓ 進行中のプロジェクトでは毎週（高／重大リスク）、長期プロジェクトでは毎月レビューします
   • ❌ 開始時に登録簿を作成し、その後更新しない（プロジェクトの進行に伴い、発生確率や影響は変化します）

7. 解消したリスクを登録簿から外す：登録簿を際限なく増やさず、軽減済みまたは無関係になったリスクをアーカイブします

   • ✓ リスクを「クローズ」とし、解決日を記録してアーカイブセクションに移動します
   • ❌ すべてのリスクを永久に残す（シグナル対ノイズ比が低下します）

8. 重大なリスクは直ちにエスカレーションする：重大なリスクが発生した場合、週次会議まで待たないでください

   • ✓ 確率 = 5、影響 = 5、スコア = 25 → 同日中に経営陣へエスカレーションし、緊急の軽減策を講じます
   • ❌ 定期レビューまで待つ（リスクが顕在化するおそれがあります）

クイックリファレンス

リソース：

• クイックスタート：resources/template.md - スコアリング表、対応計画、モニタリングログを備えたリスク登録簿のテンプレート
• 高度な手法：resources/methodology.md - モンテカルロシミュレーション、決定木、感度分析、リスク集約、アーンド・バリュー・マネジメント
• 品質チェック：resources/evaluators/rubric_project_risk_register.json - 評価基準

成功基準：

• ✓ すべてのカテゴリ（技術、スケジュール、リソース、外部、スコープ、組織）にわたって、15～30件のリスクを特定している
• ✓ すべての高リスク／重大リスク（スコア ≥12）に、担当者、軽減計画、コンティンジェンシー計画が設定されている
• ✓ リスクスコアに差がついている（すべてを6～9にせず、1～25の範囲全体を活用している）
• ✓ 軽減計画とコンティンジェンシー計画が具体的で実行可能である（「注意深く監視する」だけではない）
• ✓ コンティンジェンシー計画を発動する条件として、定量化可能な閾値が定義されている
• ✓ リスク登録簿が定期的に更新されている（進行中のプロジェクトでは毎週、長期プロジェクトでは毎月）
• ✓ リスクプロファイルがプロジェクトのフェーズに合っている（開始時は不確実性が高く、時間とともに低下する）

よくある間違い：

• ❌ 特定したリスクが少なすぎる（10件未満）→ リスクの全体像が不完全になり、誤った安心感につながる
• ❌ すべてのリスクを中程度（6～9）と評価する → 差がつかず、優先順位が不明瞭になる
• ❌ リスクの記述が曖昧（「うまくいかないことがあるかもしれない」）→ 対応できない
• ❌ リスク担当者が割り当てられていない → 説明責任が分散し、軽減策が実行されない
• ❌ コンティンジェンシー計画を伴わない軽減策 → 軽減策が失敗した場合の代替策がない
• ❌ 一度作成した後に更新しない → データが古くなり、リスクの変化を反映できない
• ❌ マイナスのリスク（脅威）だけを扱う → プラスのリスク（機会）を見落とす
• ❌ リスク登録簿がプロジェクト計画と切り離されている → ワークフローに統合されない

代替手法を使う場面：

• プレモーテム：プロジェクトの開始前に、失敗シナリオを想定したい場合（リスク登録簿を補完します）
• FMEA（故障モード影響解析）：詳細な故障分析が必要な製造／エンジニアリングプロジェクト
• モンテカルロシミュレーション：確率論的なスケジュール／予算予測が必要な場合（methodology.md を使用）
• 決定木：分岐点のある逐次的な意思決定がリスクに関わる場合
• シナリオプランニング：リスクが戦略的／長期的な場合（市場の変化、競合他社の動向）