リスク管理表の作り方｜最低限の項目と「書いて終わり」にしない運用

リスク管理表は、プロジェクトの不確実性を「見えるもの」に変換するための最も基本的な道具だ。ところが多くの現場では、キックオフ直後に一度作られたきり更新されず、リスクが実際に顕在化してから「そういえばあれ書いてあったな」と気づく状態に陥っている。本記事では、実務で機能するリスク管理表に最低限必要な項目と、テンプレートを作っただけで放置される「書いて終わり」状態を避けるための運用ルールを解説する。読み終える頃には、明日から使える項目定義と、更新を止めないための具体的な仕組みが分かるはずだ。

リスク管理表が形骸化する理由

リスク管理表が放置される最大の原因は、「作成」と「運用」を別工程だと認識していないことにある。多くのPMはキックオフ時にリスクを洗い出し、Excelやスプレッドシートに一覧化した時点で満足してしまう。しかしリスクは静的なものではなく、プロジェクトの進行とともに発生確率や影響度が変化し、新しいリスクも生まれ続ける。

更新が止まる理由はもう一つある。項目設計が悪く、更新作業自体が重い場合だ。自由記述欄が多すぎる、対応策が抽象的すぎて次に何をすべきか分からない、といった表は誰も触りたがらない。逆に言えば、項目を適切に設計し更新のハードルを下げるだけで、リスク管理表は継続的に機能するようになる。

最低限入れるべき項目

リスク管理表に入れるべき項目は、多ければよいわけではない。現場で実際に更新され続ける表は、次の10項目程度に絞られていることが多い。

項目	内容	記入例
リスクID	一意の管理番号	R-014
リスク内容	「事象」と「影響」をセットで記述	外部API仕様変更により開発が2週間遅延する可能性
発生確率	高/中/低、または数値(%)	中(40%)
影響度	高/中/低、または金額・工数換算	高(スケジュール2週間、追加コスト150万円)
リスクスコア	発生確率×影響度で優先順位付け	高
対応区分	回避/軽減/転嫁/受容のいずれか	軽減
対応策	誰が読んでも次のアクションが分かる具体策	外部ベンダーとの仕様凍結会議を月次で設定
オーナー	対応の責任者名(役割ではなく個人名)	田中(PM)
ステータス	未対応/対応中/クローズ	対応中
更新日	直近の更新日	2026-07-20

この項目数であれば、週次の定例会議で1リスクあたり数十秒の更新で済む。項目を増やしたくなる誘惑はあるが、増やすほど更新は止まりやすくなる点を覚えておきたい。

各項目の書き方：曖昧な記述を避けるコツ

項目を用意しても、書き方が曖昧だと表は機能しない。特に「リスク内容」と「対応策」の2欄は書き手の力量が出やすい。

リスク内容は「不安」ではなく「事象+影響」の形で書く。「スケジュールが心配」ではなく「要件確定が2週間遅れており、開発着手が遅延する可能性がある」と書けば、誰が読んでも同じ状況を想像できる。

対応策も同様で、「注意する」「気をつける」といった精神論は対応策として認めない。「誰が」「いつまでに」「何をするか」が読み取れる文にする。「外部ベンダーとの仕様凍結会議を毎月第1営業日に設定し、PMが議事録を確認する」のように、実行の主語と期限が入っていれば、後から進捗を確認できる。

対応区分の使い分けも重要だ。回避はリスク要因そのものをなくす対応、軽減は発生確率や影響度を下げる対応、転嫁は保険や契約で第三者にリスクを移す対応、受容は許容範囲として何もしない判断を指す。「受容」を選ぶこと自体は悪くない。重要なのは、受容すると判断した理由を一行残しておくことだ。

更新を止めない運用の型

リスク管理表を機能させる鍵は、項目設計よりも運用リズムにある。理想は週次のプロジェクト定例に「リスクレビュー」を5〜10分固定で組み込むことだ。この場で全リスクを毎回読み上げる必要はない。スコアが高いものと、更新日が2週間以上停止しているものだけを確認すれば十分機能する。

オーナーを個人名にする理由もここにある。「開発チーム」のような役割名にすると、誰も自分ごととして更新しない。個人名にしておけば、定例で名指しで進捗を聞くことができ、放置を防げる。

新規リスクの洗い出しは、キックオフ時の一度きりで終わらせない。フェーズの節目や大きな仕様変更のタイミングで再度洗い出しの時間を取る。プロジェクト開始前の段階でリスクを網羅的に洗い出す手法としては、Pre-Mortem分析：プロジェクト開始前に「失敗を想定」して防ぐ技術が有効だ。「プロジェクトが失敗した」という前提で理由を逆算する手法で、リスク管理表の初期項目を埋める際の洗い出し精度が上がる。

よくある失敗パターン

現場でよく見る失敗は大きく3つに分類できる。

1つ目は「作って終わり」パターンだ。キックオフ資料の一部として作成されるが、その後のレビュー機会が設計されておらず、プロジェクト終盤まで更新日が空白のまま放置される。

2つ目は「粒度がバラバラ」パターンだ。「メンバーのモチベーション低下」のような抽象的な項目と、「特定APIのレスポンス遅延」のような具体的な項目が同じ表に混在し、対応策の書きやすさに差が出て結局対応が進まない。

3つ目は「経営層への報告に使えない」パターンだ。項目は充実しているが、優先順位が一目で分からず、経営層やステアリングコミッティへの報告時に別資料を作り直す羽目になる。この場合、リスクスコアを経営層向けに集約して可視化する手法としてBCG DICEフレームワーク：プロジェクト崩壊リスクをスコアで見える化して経営層を動かすを組み合わせると、リスク管理表の生データを経営層が判断しやすい形に変換できる。

顕在化したリスクへの対応

リスクが実際に問題として顕在化した場合、リスク管理表の役割は「予兆管理」から「事後対応」に切り替わる。ここで重要なのは、表のステータスを「クローズ」にして終わりにせず、なぜ予測より早く、あるいは想定より大きく顕在化したのかを一段掘り下げることだ。

表面的な事象だけを記録して終えると、同種のリスクは次のプロジェクトでも同じ形で再発する。顕在化したリスクの根本原因を掘り下げる際は、なぜなぜ分析（5 Whys）でプロジェクト炎上の根本原因を特定するの手順で「なぜ」を数回繰り返し、対応策を次回以降の予防策としてリスク管理表のテンプレート自体にフィードバックするとよい。

まとめ：明日から始める3ステップ

リスク管理表は、項目を整えるだけでは機能しない。運用のリズムまで含めて設計して初めて意味を持つ。まず着手すべきは次の3点だ。

第一に、既存の表を先述の10項目に整理し直す。項目が多すぎる場合は、対応策とオーナーが曖昧なまま放置されている項目から削る。第二に、週次定例にリスクレビューの時間を固定で確保する。第三に、オーナーを個人名で記載し直す。この3つだけでも、次回のレビューからリスク管理表は「作って終わり」の資料から、実際にプロジェクトを守る道具に変わる。

あわせて読みたい

プロジェクトのトラブル解決大全：リスクが顕在化し炎上に発展した後の立て直し方を、具体的な対応手順として体系化した一冊。リスク管理表の「対応策」欄の解像度を上げたい人に向く。

PMBOK ガイド 第7版：リスクマネジメントを含むプロジェクト管理の知識体系全体を俯瞰できる。自己流の管理表運用を標準的な枠組みと照らし合わせて見直したい人向け。