「作った瞬間に死ぬ文書」になっていないか
プロジェクト立ち上げ時、PMはリスク登録簿（リスクレジスター）を丁寧に作る。確率と影響度のマトリクスを埋め、対応策を書き、承認を得る。そして——気づけば誰も開かなくなる。
これは珍しい話ではない。あるシステム開発プロジェクトでは、キックオフ時に20件のリスクを洗い出し、立派な登録簿を作成した。ところが3ヶ月後、ベンダーの財務悪化というリスクが現実のものになったとき、登録簿には「ベンダー選定リスク」として1行あるだけで、最新の対応状況は何も更新されていなかった。チームは「あの文書、どこにありましたっけ」という状態だった。
リスク登録簿は、作ったときが最も古い文書である。プロジェクトが進めば環境は変わり、新たなリスクが生まれ、既存のリスクの状態も変化する。にもかかわらず、多くの現場でリスク登録簿は「一度作って提出する成果物」として扱われている。
問題は意識ではなく、更新し続けるための仕組みがないことにある。
なぜリスク登録簿は更新されなくなるのか
①「誰かがやるだろう」問題
リスク管理の責任が曖昧なプロジェクトでは、登録簿の更新も自然に宙に浮く。PMが「各自が担当リスクを更新して」と言うだけでは、忙しい現場では後回しになる一方だ。過去記事「リスクは誰が”所有”するのか」でも触れたように、所有者の明確化は不可欠だが、所有者を決めただけでは更新は起きない。いつ・何をトリガーに・どこに書くかという「行動の回路」まで設計して初めて機能する。
②更新のコストが高い
Excelで管理しているリスク登録簿が共有フォルダの奥深くに眠っており、開くたびにバージョン競合が起きる——こういった構造的な摩擦が更新を妨げる。更新しようと思ったとき、アクセスの手間が3ステップ以上あるなら、人は本能的に避ける。
③「何を更新するか」が定義されていない
リスクの「状態」をどう表現するかのルールがないと、更新しようとしても手が止まる。「高」「中」「低」のラベルだけでは現状が伝わらず、フリーテキストで書くと読む側も判断できない。更新項目と記載フォーマットを最初から設計しておくことが必要だ。
更新し続けるための仕組み：4つの設計原則
原則1：更新を「イベント」ではなく「習慣」に組み込む
最も効果的なのは、既存の会議体にリスク登録簿のレビューを組み込むことだ。週次のステータス会議の冒頭5分を「リスクレビュー枠」として固定する。このとき重要なのは「全件レビュー」を避けること。上位5件の高リスクと、前週からステータスが変化したリスクだけを確認する「差分レビュー」にすることで、時間コストを抑えながら鮮度を保てる。
あるインフラ更改プロジェクトでは、週次会議の最初に「今週のリスク天気図」と題してA4一枚のサマリーを共有する運用を導入した。PMが毎週作成することで、チームは自然とリスクを意識する文化が生まれたという。
原則2：更新の「粒度」と「項目」を事前に定義する
リスク登録簿に最低限持たせる更新項目を決めておく。おすすめの構成は以下だ。
- ステータス：「監視中／対応中／発生済み／クローズ」の4択
- 最終更新日と更新者：誰がいつ確認したかを可視化する
- 対応策の進捗：計画した対応策が実行されているか
- トリガー条件の変化：リスクが顕在化しつつある兆候があるか
「確率×影響度」のスコアを毎回再計算させるのは現場では負荷が高すぎる。スコアの更新は月次レビュー時に絞り、週次は「ステータスと対応状況の確認」だけに留めると継続しやすい。
原則3：新規リスクを「発見」できる回路を作る
リスク登録簿の更新は、既存リスクの管理だけではない。新たなリスクを発見し、登録し続けることも同じくらい重要だ。ところが多くの現場では、新規リスクの発見が「PMの勘」に依存している。
効果的なのは、3つの情報源を定期的にスキャンする習慣を作ることだ。①チームメンバーからの「気になること」を拾う1on1、②ステークホルダーとの会話で出てくる懸念、③プロジェクト外部の環境変化（法改正・市場動向・組織変更など）。これらをリスク発見のアンテナとして明示的に設計しておくことで、登録簿は自然に育ち続ける。
原則4：「クローズ」の基準を決め、登録簿を軽くし続ける
更新が止まるもう一つの理由は、登録簿が肥大化することだ。発生しなかったリスク、対応済みのリスクが残り続け、「どれが今重要なのか」が見えなくなる。
リスクのクローズ基準を明確に定義し、定期的に「アーカイブ」する運用を組み込もう。「プロジェクトのフェーズを超えた」「トリガー条件が消滅した」「対応策が完了し再発リスクがない」などの基準を設けておくと、PMが判断しやすくなる。アーカイブされたリスクは削除せず別シートや別タグで保存し、レトロスペクティブや次回プロジェクトの参考資料として活用できる状態にする。
仕組みを「定着」させるために
どれだけ良い仕組みを設計しても、最初の4週間が勝負だ。PMが自ら更新し、レビューで積極的に登録簿を参照し、「リスク登録簿を見ながら話す」という行動を繰り返して見せることで、チームの文化になっていく。
逆に言えば、PMが登録簿を使わなければ、チームも使わない。文書管理ツールの話ではなく、PMのリスクに対する姿勢が文書の更新頻度に直結している。
リスク登録簿は、プロジェクトの「不確実性との対話の記録」だ。更新し続けることで、チームは「リスクを管理している」から「リスクとともに動いている」へと進化する。作って終わりの文書を、生きた地図に変えることがPMの役割である。
リスク管理を「仕組み」として機能させたい方へ
リスクが顕在化する前に手を打てるPMへ。週1回の1on1＋実プロジェクト支援で、再現性のあるリスク管理の実践力を身につけます。
