リスク管理表の作り方｜課題との違い・発生条件・対応策の記入例
「リスク管理表はあるが、問題が起きてから見返すだけ」。表に懸念を書くだけでは、準備や判断につながりません。リスクはまだ発生していない不確実な事象、課題は対応が必要な現状の問題として分けると、今行うことを整理できます。
この記事は、納期や運用に悪影響を与える脅威の管理に絞った一般解説です。リスクには好機もありますが、ここでは扱いません。記入例は説明用で、実在の案件ではありません。
原因・起こり得ること・影響をつなげて書く
「外部連携がリスク」では、何を監視するのか分かりません。「接続仕様の回答が遅れると、連携テストの開始が遅れ、受入日程へ影響する可能性がある」と書くと、原因と影響を相談できます。
すでに回答期限を超え、テストを始められないなら、それは現状の課題でもあります。元のリスクIDを残し、発生した課題へ対応を引き継ぎます。同じ対応を二つの表で別々に更新しないよう、主管理する場所を決めます。
発生確率だけでなく、対応開始条件を置く
| 項目 | 説明用の記入例 |
|---|---|
| リスクID | R-01 |
| 原因と事象 | 接続仕様が未確定のため、連携テスト開始が遅れる可能性 |
| 影響 | 受入確認へ進めない。代替の確認範囲を検討する必要 |
| 兆候 | 回答予定日に資料が揃わない、未決項目が増える |
| 事前対応 | 確定済み部分の確認と、回答窓口・予定日の合意 |
| 対応開始条件 | 予定日に必要な仕様が揃わなければ影響調査を開始 |
| 主担当・判断者 | 連携担当が調査、PMが対応方針を判断 |
| 発生時の対応 | 接続対象を分離する案と日程見直し案を比較 |
| 残るリスク | 一部分離しても、全体受入の遅れは残る可能性 |
「発生したら検討」だけでは、検討を始める条件が遅すぎることがあります。兆候を見て準備する時点と、実際に計画を変更する判断を分けてください。先に代替案を考えても、その実行が自動的に承認されるわけではありません。
評価の尺度を、チーム内でそろえる
高・中・低の評価を使うなら、その意味を合意します。影響の「高」が、費用なのか、納期なのか、安全性なのかで対応は違います。必要に応じて影響の種類を分けます。
根拠がないのに「発生確率30％」と精密な数字を入れないようにします。また、高・中・低を便宜的に数値化して掛け算した点数は、期待損失額や実際の確率ではありません。順位付けの補助として使うなら、重大な安全・規程上の条件が点数に埋もれないよう別に確認します。
登録するすべてのリスクへ同じ深さの調査を行う必要はありません。次の節目へ影響するもの、対応に時間がかかるもの、判断が必要なものを優先します。
対応策を「担当者の注意」で終わらせない
「気を付ける」「早めに確認する」では、実施したか判定しにくくなります。確認する資料、連絡する窓口、確認日、代替策に必要な準備を書きます。外部に任せた場合も、自社の監視や判断が不要になるわけではありません。
対応後には、残る影響と新たなリスクを見直します。たとえば対象を減らして納期を守る案は、利用部門に二重運用を残すかもしれません。日程だけを改善して、運用負担を見落とさないことが大切です。
定例では、一覧を読み上げず変化を見る
- 新しいリスクが増えたか。範囲・体制の変更で前提が変わったか。
- 兆候や対応開始条件に達したものはあるか。
- 事前対応は実施されたか。効果を何で確認するか。
- 発生済みなら、課題へ移し対応を追っているか。
- 今の節目を通過して不要になったリスクはあるか。
終了するときも、未発生のまま対象期間を終えたのか、対応で解消したのか、発生して課題へ移したのかを残します。「削除したから問題なし」にはしないでください。
最初の一行では、懸念の名前より「何が起きると、何へ影響し、いつ対応を始めるか」を明らかにします。リスク表は不安の一覧ではなく、準備と判断のための記録です。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
リスク登録簿の基本概念を確認した資料です。評価の尺度や記入例は当サイトの提案です。 Atlassian：Risk Register（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
課題管理表の作り方も必要な作業に合わせて参照してください。
アイキャッチ写真：Gabriel Cox / Unsplash。職場の実写ではなくイメージ写真です。
