リスク管理入門：PMが現場で使える「リスク登録簿」の作り方

「問題が起きてから考える」では遅い——これはリスク管理の話をするときによく聞かれる言葉ですが、実際には多くのPMがこのパターンに陥っています。なぜかというと、「まだ起きていないことに時間を使う」のは心理的に難しいからです。この記事では、そのハードルを下げるための具体的な方法を解説します。

リスクと課題の違いから始める

リスク管理でよく混同されるのが「リスク」と「課題」の違いです。

用語	意味	例
リスク	まだ起きていない懸念	「エンジニアが体調を崩すかもしれない」
課題	すでに起きている問題	「エンジニアが体調を崩して離脱した」

リスクは「起きる前」に手を打てるのが最大のメリットです。発生してから対応するのと、あらかじめ備えておくのとでは、かかるコストも時間も大きく変わります。火事でたとえるなら、消火器を準備しておくのか、燃え広がってから消防車を呼ぶのかの違いです。

リスク管理の4ステップ

複雑に考える必要はありません。基本は4ステップの繰り返しです。

① 特定する

「どんなリスクがあるか？」をチームでブレインストーミングします。過去プロジェクトの振り返り資料や、メンバーへのヒアリングが有効です。「もし〜だったら？」という問いかけが洗い出しを助けます。

② 分析する

特定したリスクに対して、発生確率と影響度を評価します。「このリスクはどれくらい起きやすいか？起きたらどれだけ痛いか？」を数値や段階で整理します。

③ 対応策を立案する

優先度の高いリスクから順に、具体的な対応策と担当者を決めます。「誰が、いつまでに、何をするか」まで落とし込むことが大切です。対応策が「検討する」で終わっているリストは、機能しているとは言えません。

④ 監視する

リスクは一度管理すれば終わりではありません。週次・月次の定例で状況を確認し、新しいリスクの追加や対応策の見直しを継続的に行います。

リスク登録簿とは：テンプレートと記入例

リスク登録簿とは、プロジェクトに存在するリスクを一覧で管理するドキュメントです。ExcelやGoogleスプレッドシートで作れる、PMの基本ツールのひとつです。

基本テンプレート

ID	リスク内容	発生確率	影響度	優先度	対応策	担当者	ステータス
R01	外部APIの仕様変更	中	高	高	仕様変更の通知設定を有効化し、代替APIを事前調査する	田中（エンジニア）	対応中
R02	キーマンの離脱	低	高	中	ドキュメント整備・タスクの複数担当化を進める	鈴木（PM）	未着手
R03	要件の大幅変更	高	中	高	週次で顧客と認識合わせの場を設ける	佐藤（PdM）	完了

最初はこの6〜8列をコピーして、自分のプロジェクトのリスクを書き込むことから始めましょう。

発生確率×影響度マトリクスの使い方

リスクが10個も20個もあると、どれから手をつければいいかわからなくなります。そこで使うのがリスクマトリクスです。縦軸に「影響度」、横軸に「発生確率」を置き、優先度を視覚化します。

         ┌───────────────────────────┐
  影      │        │        │  🔴高  │
  響  高  │  🟡中  │  🔴高  │  🔴高  │
  度      ├────────┼────────┼────────┤
         │        │  🟡中  │  🔴高  │
     中  │  🟢低  │  🟡中  │  🔴高  │
         ├────────┼────────┼────────┤
         │        │        │  🟡中  │
     低  │  🟢低  │  🟢低  │  🟡中  │
         └────────┴────────┴────────┘
              低       中       高
                    発生確率

優先度の読み方

優先度	対応方針
🔴 高（赤）	即座に対応策を立案・実行。週次でモニタリング
🟡 中（黄）	対応策を準備しておく。状況変化に注意
🟢 低（緑）	記録しておくが、今は注視するだけでOK

マトリクスを使うことで、感覚ではなく「見える化」によって判断できるようになります。チーム全員が「このリスクはヤバい」という共通認識を持てるのが最大のメリットです。

リスク対応の4つの戦略

リスクが特定できたら、どう対応するかを決めます。選択肢は4つです。

① 回避（Avoid）

リスクの原因そのものをなくし、リスクが発生しないようにする戦略です。

例：「特定の技術スタックに詳しいメンバーがいない」というリスクに対して、その技術を使わず、チームが熟知している技術に変更する。

② 軽減（Mitigate）

リスクの発生確率や影響度を下げる戦略です。現場で最もよく使われます。

例：「本番リリース直前のバグ多発」というリスクに対して、テスト工程を厚くし、ステージング環境でのリハーサルを追加する。

③ 転嫁（Transfer）

リスクの責任や損失を第三者に移す戦略です。

例：「システム障害による損失リスク」に対して、SLA契約やサイバー保険に加入し、リスクを保険会社や外部ベンダーに移す。

④ 受容（Accept）

リスクの存在を認識した上で、あえて何もしないことを選ぶ戦略です。対応コストが見込まれる損失を上回る場合に選択します。

リスクの特性	おすすめの戦略
発生確率・影響度ともに高い	回避または軽減
影響度は高いが確率は低い	転嫁（保険・契約で備える）
発生確率・影響度ともに低い	受容（記録だけしておく）
技術・ノウハウで防げる	軽減

「必ず回避しなければ」とは考えず、コストと現実的な実行可能性を踏まえて戦略を選びます。

AIを使ってリスク登録簿の叩き台を作る

リスクの洗い出しは「思いつかない」という壁にぶつかりやすいですが、AIを使えば数分で網羅的なリストが作れます。

プロンプト例

以下のプロジェクトで想定されるリスクを10個挙げてください。
表形式（リスク内容 / 発生確率 / 影響度 / 優先度 / 対応の方向性）で出力してください。
優先度は発生確率×影響度で高・中・低の3段階にしてください。

【プロジェクト概要】
社内の勤怠管理システムをクラウドツールに移行する
期間：3ヶ月 / チーム：PM・エンジニア2名・外部ベンダー1社

出力サンプル

リスク内容	発生確率	影響度	優先度	対応の方向性
外部ベンダーの納期遅延	高	高	🔴高	週次進捗確認・予備日程を設定
データ移行時の整合性エラー	中	高	🔴高	移行前にサンドボックスでテスト
要件の後出し変更	高	中	🔴高	仕様凍結タイミングを明確に合意
社員の操作習熟不足	高	中	🔴高	事前トレーニング・マニュアル整備
セキュリティ要件の見落とし	低	高	🟡中	情報システム部との事前レビュー
キーメンバーの離脱	低	高	🟡中	タスクの複数担当化・ドキュメント整備

AIのリストを使う前に、「このプロジェクト特有のリスクは何か？」を自分で考えてみましょう。AIが出したリストとの差分が、あなたの経験から来る固有の視点です。両方合わせることで初めて網羅性が高まります。

チームでのブレインストーミングに使うプロンプト

リスク洗い出しのブレインストーミング用に、
「もし〜だったら？」という問いかけを15個作成してください。
対象プロジェクト：[プロジェクト概要を入力]

これを定例会議で使うと、全員が同じ視点でリスクを考えられます。

今日から始める最初の一歩

難しく考えなくていいです。まずこれだけやってみましょう。

スプレッドシートを新規作成する
「リスク内容・発生確率・影響度・対応策・担当者」の列を作る
今担当しているプロジェクトで心配なことを5つ書き出す
それぞれに「高・中・低」で確率と影響度をつける
一番優先度の高いリスクの対応策を1つ決める

完璧なリスク登録簿を作ることが目的ではなく、「見えないリスクを見えるようにする」習慣を作ることが本質です。プロジェクトが始まったら、まずリスクを5つ書き出す——それだけで、チームの安心感と意思決定の質は変わります。