プロジェクトマネジメントガイド · リスク、品質、コントロール
リスク登録簿：テンプレート、項目、記入例
リスク登録簿とは、プロジェクトで特定したリスクを、その分析、オーナー、対応策、ステータスとともに記録する文書またはツールです。次の実務上の記録となるものです： リスクマネジメント プロセスを通じて行います。
要点
- リスク登録簿は、各リスクをスコア、オーナー、対応策、ステータスとともに記録します。
- わかりやすい列と、合意したスコアの定義を使いましょう。
- 定期的にレビューし、発生したリスクは課題ログに移します。
- 項目は具体的で実行可能な内容にしましょう。
リスク登録簿の目的
- 既知のリスクをすべて1か所にまとめ、チームとスポンサーが確認できるようにします。
- 各リスクのオーナーと、そのリスクに対して何が行われているかを記録します。
- 優先順位を示し、最も重要なリスクに注意が向くようにします。
- 監査、レビュー、および次のための履歴となります： 教訓.
リスク登録簿テンプレート：列
| 列 | 記録する内容 |
|---|---|
| ID | 一意の参照番号（例：R-014） |
| 起票日 | リスクが最初に記録された日 |
| カテゴリー | スケジュール、コスト、技術、資源、外部など |
| リスクの説明 | 原因、事象、影響 |
| 脅威または好機 | 影響の方向 |
| 発生確率（1-5） | 合意した定義に基づく発生可能性 |
| 影響度（1-5） | 合意した定義に基づく深刻度 |
| スコア | 発生確率 x 影響度 |
| 担当者 | 監視と対応に責任を持つ指名された担当者 |
| 対応戦略 | 回避、軽減、転嫁、受容、エスカレーション（または活用、強化、共有） |
| 対応策 | 日付を伴う具体的な行動 |
| トリガー | リスクが顕在化しつつあることを示す警告サイン |
| コンティンジェンシー計画 | 発生した場合に何が起こるか。参考： コンティンジェンシー計画 |
| 残存スコア | 対応策実施後の想定スコア。参考： 残存リスク |
| ステータス | オープン、監視中、クローズ、発生済み |
| 最終レビュー日 | 直近のレビュー日 |
記載例
| ID | 説明 | P | I | スコア | 担当者 | 対応 | ステータス |
|---|---|---|---|---|---|---|---|
| R-001 | APIベンダーが料金体系を変更するため、ライセンス費用が上昇し、予算を8%超過する可能性がある。 | 3 | 3 | 9 | 調達責任者 | 軽減：24か月の固定価格を交渉する | 未対応 |
| R-002 | レガシーシステムを理解しているエンジニアが1人しかいないため、その人が不在になると統合作業が数週間止まる可能性がある。 | 2 | 5 | 10 | デリバリーマネージャー | 軽減：2人目のエンジニアをペアで付け、インターフェースを文書化する | 未対応 |
| R-003 | 規制当局が新しい規則について意見募集を行っているため、プロジェクトの途中で報告要件が変わる可能性がある。 | 2 | 4 | 8 | コンプライアンス責任者 | 受容：意見募集の動向を監視し、コンティンジェンシーを確保する | 監視中 |
| R-004 | 新しいテストフレームワークは並列で実行されるため、回帰テストが計画の半分の時間で済む可能性がある。 | 3 | 3 | 9 | QAリード | 強化：スプリント3で試行する | 未対応 |
リスク登録簿の作成と維持の方法
- 計画段階で、尺度、列、レビュー頻度について合意します。
- リスク特定ワークショップを実施し、すべてのリスクを記録します。
- 各リスクをスコア付けし、スコア順に並べ替えます。
- スコアの高いリスクにはオーナーを割り当て、対応策について合意します。
- プロジェクト会議のたびに、上位のリスクを中心に登録簿をレビューします。
- スコアを更新し、期限の過ぎたリスクをクローズし、新しいリスクを追加します。
- 発生したリスクは次に移します： 課題ログ.
- 上位のリスクを次にまとめます： プロジェクト状況報告書.
リスク登録簿と他のログの比較
| リスク登録簿 | 課題ログ | RAIDログ | |
|---|---|---|---|
| 内容 | 不確実な将来の事象 | 現在起きている問題 | リスク、前提条件、課題、依存関係 |
| 主な問い | 何が起こりうるか？ | 今、何が問題か？ | 何を追跡する必要があるか？ |
| 典型的なサイズ | 詳細 | 詳細 | 多くの場合は概要レベル |
コツ
- 登録簿は読める程度の長さに保ちましょう。曖昧なリスク300件より、よく書かれたリスク30件のほうが役立ちます。
- オーナーが自分の項目を更新できるよう、共有ツールを使いましょう。
- スコアは色分けしても、色だけに頼らず数値も記載しましょう。
- クローズしたリスクは削除せず、アーカイブしましょう。
このトピックの無料テンプレート
よくある質問
リスク登録簿とは何ですか？
特定されたプロジェクトリスクを、スコア、オーナー、対応策、ステータスとともに記録したログ。
リスク登録簿にはどのような列が必要ですか？
最低限、ID、説明、発生確率、影響度、スコア、オーナー、対応策、ステータスが必要です。多くのチームはトリガー、コンティンジェンシー計画、残存スコアも追加しています。
リスク登録簿のオーナーは誰ですか？
通常はプロジェクトマネージャーが維持管理し、個々のリスクオーナーが自分の項目を最新の状態に保ちます。
リスク登録簿はどのくらいの頻度で更新すべきですか？
少なくとも定例のプロジェクト会議のたびに、また新しい情報によってリスクが変化したときに更新します。
リスク登録簿はリスクログと同じですか？
はい。この2つの用語は同じ意味で使われます。
リスク登録簿とRAIDログの違いは何ですか？
リスク登録簿はリスクのみを詳細に扱います。一方、 RAIDログ は、リスク、前提条件、課題、依存関係をまとめて追跡します。
リスク登録簿にExcelを使えますか？
はい。ほとんどのプロジェクトではスプレッドシートで十分です。大規模な組織では、ワークフローとレポート機能を備えた共有ツールを使うこともあります。
好機もリスク登録簿に記載すべきですか？
はい。脅威とあわせて好機も記録することで、チームは意図的に好機を追求できます。
リスク登録簿のリスクはいつクローズすべきですか？
該当するフェーズが完了したなどの理由でその事象がもはや発生しえなくなったとき、または事象が発生して課題ログに移されたときです。
リスク登録簿におけるリスクオーナーとは何ですか？
リスクを監視し、その対応策が確実に実行されるようにする責任を負う指名された担当者です。
PRINCE2ではリスク登録簿を使いますか？
はい。PRINCE2ではリスク登録簿をマネジメント成果物の1つとして使います。