先日、社内の若手PMから「リスク管理って、結局やっても意味なくないですか」と言われた。
その気持ちはよく分かる。私も昔、立派なリスク管理表を作って、そのまま二度と開かなかった側の人間だからだ。だから今日は、リスク管理を「やっても意味がある」状態にするために、私が中小受託の現場でどう運用しているのかを、なるべく正直に書いておきたい。
フレームワークは目的ではなく道具だ、というのが私の口癖なんですが、PMBOKのリスクマネジメントも例外じゃない。教科書のプロセスをそのまま持ち込むと、たいてい現場では回らない。回らないなら、回る形まで削るしかない。
立派なリスク管理表を作って、二度と開かなかった話
正直なところ、若い頃の私はリスク管理を「やっているフリ」でしか通過してこなかった。
ある受託案件で、私はリスクマネジメント計画書とリスク登録簿を、それはもう気合を入れて作った。リスクを20件以上洗い出して、発生確率・影響度・対応戦略（回避／転嫁／軽減／受容）・対応担当・トリガー条件まで、Excelの列にびっしり埋めた。作った時点では、我ながら完璧な管理表に見えた。
問題はそのあとだった。キックオフで一度共有して、それっきり。2週目のミーティングでその表を開いた人は、私を含めて誰もいなかった。案件が進むとリスクの状況は変わっていくのに、表は初日のまま固まっていた。
そして中盤、洗い出していたはずのリスクのひとつ——「顧客側のレビュー担当者が繁忙期で確認が遅れる」——が、まさにそのまま顕在化した。レビュー待ちで1週間近く止まり、後工程が押した。あとで登録簿を見返したら、しっかり書いてあった。書いてあったのに、誰も見ていなかったから、手も打てなかった。
このとき腹落ちしたのは、更新されないリスク登録簿は、リスクがゼロの登録簿と同じだということだ。むしろ「一応やってある」という安心感がある分、たちが悪い。
理屈はそうなんですが、と言いたくなる。丁寧に作ったものを捨てるのは抵抗がある。でも、開かれない管理表は管理じゃない。ここを認めたのが、運用を変えるスタートだった。
なぜ形骸化するのか——重すぎるプロセスの典型パターン
そこから何案件かかけて、「なぜリスク管理は形骸化するのか」を現場で観察してきた。だいたい同じ理由に行き着く。
| 形骸化する原因 | 現場で起きること |
|---|---|
| 項目が多すぎる（20件以上） | 全部を毎週見直す気力が続かず、更新自体をやめる |
| 列が多すぎる（対応戦略・トリガー・残存リスク…） | 1件を書くコストが高く、追記が億劫になる |
| 更新のタイミングが決まっていない | 「気づいたとき」に更新＝結局誰もやらない |
| 計画書とセットで作る建て付け | 初日に作って終わり、運用フェーズに接続されない |
ぶっちゃけ、原因は「難しいから」ではなく「重いから」なんですよね。1回あたりのコストが高いと、人はやらなくなる。ここを軽くしない限り、どんなに気合を入れても2回目で止まる。
だから私が変えたのは、リスク管理の中身の高度さではなく、1回あたりの運用コストだった。
リスク登録簿ライト版——発生確率×影響度だけで並べる
今の私がやっているのは、拍子抜けするほど単純だ。列を思いきり削って、リスクを「発生確率 × 影響度」の掛け算スコアで並べるだけ。それぞれ3段階（1〜3）で付ける。
リスクスコア = 発生確率(1〜3) × 影響度(1〜3) ※ 最大9点
発生確率: 3=起きそう 2=起きるかも 1=たぶん大丈夫
影響度: 3=納期/信頼に直撃 2=数日の遅れ 1=軽微
スコア 6以上 → 「今、対策を決める」対象
スコア 3〜4 → 監視のみ（登録はするが対策は保留）
スコア 2以下 → 登録簿に載せない（キリがないので割り切る）ポイントは、スコアの絶対値ではなく、上位だけに絞り込むためのモノサシとして使うところだ。全リスクに完璧な対策を立てようとするから重くなる。上位数件だけ決めて、あとは監視、と割り切ると一気に軽くなる。
実際のリスク登録簿はこのくらいシンプルにしている。列は5つだけ。
| # | リスク（何が起きうるか） | 確率 | 影響 | スコア | 対策 or 監視 |
|---|--------------------------------|-----|-----|-------|----------------------------------|
| 1 | 顧客レビューが繁忙期で遅延 | 3 | 3 | 9 | 対策: レビュー枠を事前に日程確保 |
| 2 | 仕様の認識ズレが後半で発覚 | 2 | 3 | 6 | 対策: 週次で画面を実物レビュー |
| 3 | 主要メンバーの他案件との掛け持ち | 2 | 2 | 4 | 監視のみ |
| 4 | 外部API仕様が変わる | 1 | 3 | 3 | 監視のみ |登録簿に載せるのは、だいたい5〜7件まで。それ以上は思い切って捨てる。捨てたリスクは監視すらしないので不安になるが、実務上、影響度1〜2のリスクをいちいち管理しても回らない。管理する対象を絞ることこそが、リスク管理を続けるコツだったりします。
ここは好みが分かれるところですが、私は対応戦略（回避／転嫁／軽減／受容）の4分類も、この表からは外している。「対策を決める」か「監視だけ」かの2択で十分現場は回る。分類の正しさより、次のアクションが1行書いてあることのほうが、はるかに効く。
週次ミーティング冒頭5分の「更新ルーティン」
このライト版が効いた最大の理由は、中身の簡単さより更新するタイミングを固定したことだと思っている。
具体的には、もともとやっている週次の進捗ミーティングの冒頭5分を、リスク登録簿の更新にあてる。新しく議題を増やしたわけではなく、既存の会議の頭に差し込んだだけだ。やることはこれだけ。
【週次ミーティング冒頭5分・リスク更新の型】
1. 上位リスク（スコア6以上）を上から読み上げる … 約1分
2. 各リスクについて「確率/影響は先週から変わったか」を一言 … 約2分
3. 新しく出てきたリスクを1〜2件だけ追加 … 約1分
4. 顕在化したリスクがあれば「課題」に格上げして担当を決める … 約1分紙に書くと大げさに見えるが、実際は雑談まじりで5分もかからないことが多い。大事なのは、**毎週必ず登録簿を「開く」**という一点だ。開きさえすれば、状況の変化に気づく。気づけば手を打てる。前述の「書いてあったのに誰も見ていなかった」失敗は、要するに開いていなかったから起きたわけで、開くだけで大半は防げる。
数字でいうと、この運用に切り替えた案件では、リスク由来の手戻り（想定できたのに手を打てず後工程が押したケース）が、体感で以前の半分以下になった。ゼロにはならない。読めないリスクは当然出る。でも「読めていたのに落とした」種類の事故は、明確に減った。
顕在化したリスクは「課題」に切り替える
運用してみて地味に大事だったのが、リスクと課題の線引きだ。
リスクは「まだ起きていない、起きるかもしれないこと」で、課題は「もう起きている、対処が必要なこと」。この2つを同じ表で混ぜると、途端に表が重くなる。だから顕在化した瞬間に、リスク登録簿から外して課題管理のほうへ移す。
うちはRedmineで案件を回しているので、顕在化したリスクはその場でチケットを1枚立てて、担当と期限を付ける。リスク登録簿には「#123へ移管（顕在化）」と1行残すだけ。こうすると、リスク登録簿は常に「まだ起きていないこと」だけの状態を保てる。
# 顕在化リスク → 課題チケット化のときに最低限埋める項目
subject: "[リスク顕在化] 顧客レビュー遅延により結合テスト着手が後ろ倒し"
assigned: "案件PM"
due: "2026-07-15" # 対処の期限（リスクではなく課題なので期限を切る）
note: |
元リスク: リスク登録簿 #1（確率3×影響3=9）
対策として確保していたレビュー枠が繁忙で確保できず顕在化。
→ 代替案: 部分レビュー方式に切り替え、影響範囲を先行確認するこのチケット化のところは、正直まだ改善の余地がある。今は顕在化の判断をPMの感覚でやっていて、「これはもう課題」「これはまだリスク」の線引きが属人的なんですよね。閾値（例えばスコア9になったら自動でチケット化を検討する、など）をもう少し仕組み側に寄せたいと思っているが、そこまでやると今度は重くなるので、バランスを探っている最中だ。
もうひとつのサイクルが、案件の振り返りだ。プロジェクトが終わったあと、「登録していたリスクのうち、実際に顕在化したものはどれか」「登録していなかったのに起きたリスクは何か」を短く振り返る。これを次の案件のリスク洗い出しの初期リストに使う。似た規模・似た業種の案件は、顕在化するリスクの傾向もかなり似ているので、この振り返りの蓄積が地味に効いてくる。登録簿は毎回ゼロから作るものではなく、前の案件から少しずつ育てるもの、という感覚に近い。
振り返って
こうして書いてみると、やっていることはPMBOKのリスクマネジメントの、本当に骨だけを残した形だ。定性的リスク分析（発生確率×影響度）と、リスク対応、そして監視——教科書の流れそのものではある。ただ、それを中小受託の週次会議に載る重さまで削った、というだけの話でもある。
今思えば、昔の私に足りなかったのは知識ではなく、「続けられる重さまで削る勇気」だった。立派な管理表を作れることと、それが毎週開かれることは、まったく別の能力なんだと思う。
今後は、さっき書いた顕在化の判断基準をもう少し言語化して、私以外のメンバーが回しても同じように機能する状態にしていきたい。リスク管理が「PMの職人技」で止まっているうちは、まだ道具として不完全だ。誰が回しても軽く続く形——そこまで持っていけたら、ようやく「使える道具になった」と言えるんだろうと思っている。