炎上プロジェクトの火消し術｜PMが最初の48時間でやるべき3原則と5アクション
Yukke
PMへの道
リスク管理の全体プロセス｜PMが「台帳だけ作って終わり」を脱する3原則と5ステップ
Yukke
リスク一覧は作ったんですが、それ以降どう使えばいいんですか？ プロジェクト開始時に埋めて、そのままになっています…。
「リスク管理台帳は作った。でも週次定例で眺めるだけで、何も動いていない」――PM歴1〜3年のころ、私もそんな状態を繰り返していました。台帳を作ること自体が目的になってしまい、リスクが顕在化するまで手を打てなかったのです。
本記事では、リスク管理を「台帳を作って終わり」から「現場で回る仕組み」に変えるための3原則と、全体プロセス5ステップをまとめます。
なぜリスク管理は「台帳を作って終わり」になるのか
リスク管理が形骸化する最大の原因は、「台帳を作ること」と「リスクを管理すること」が別物だと理解されていないことにあります。台帳はあくまでリスクを可視化するツール。それをどう監視し、どう動かすかを設計しないと、台帳は報告用の飾りになります。
用語メモ
リスク：まだ起きていないが、発生すればプロジェクトに悪影響を与える不確実な事象
課題（イシュー）：すでに発生しており、対応が必要な問題。リスクとは別管理が原則
リスク対応策：回避・軽減・転嫁・受容の4パターン。「注意する」は対応策ではない
トリガー：リスクが顕在化しつつあるサイン。事前に定義しておくことで早期対処が可能になる
リスク管理で最も多い誤解は、「リスクと課題は同じもの」という認識です。リスクは「まだ起きていない」、課題は「すでに起きている」。この区別が曖昧なまま同じ台帳で管理すると、対応の優先順位も判断基準もバラバラになります。
仕組みがないと何が起きるか
リスク管理の仕組みが機能していないプロジェクトでは、こんな事態が繰り返されます。
- プロジェクト開始時にリスク台帳を作ったまま更新されず、現実と乖離した「過去の記録」になる
- リスクが顕在化して初めて「そういえば台帳に書いてあったな」と気づくが、対応策は何も準備されていない
- 「対応策：注意する」という記載が台帳を埋め尽くし、実際には何も実行されない
- リスクと課題が混在し、既に起きている問題への対処と、まだ起きていない問題への備えが区別できなくなる
ここがポイント
リスク管理の目的は「問題が起きる前に手を打つこと」です。顕在化してから動くのは課題管理であり、リスク管理ではありません。
押さえるべき3つの原則
現場でリスク管理を機能させるために、私が行き着いた3つの原則です。
原則1：リスクは「特定→評価→対応→監視」の4ステップで動かす
リスク管理はこの4ステップのサイクルで回します。「特定」で終わらせず、「監視」まで設計することが重要です。特定と評価だけやって対応策を決めないプロジェクト、対応策は決めたが誰も監視していないプロジェクト――どちらもよく見かけます。4ステップをセットで設計して初めて、リスク管理は動き始めます。
原則2：「リスク」と「課題」を混在させない
リスクは「起きていない」、課題は「起きている」。この2つは台帳を分けて管理します。リスク台帳に課題が混ざると、まだ予防できるものと既に対処が必要なものが区別できなくなり、どちらも後手に回ります。リスクが顕在化した時点で課題台帳へ移動するルールを決めておくと運用がスムーズです。
原則3：対応策は「顕在化する前」に設計する
リスクが現実になってから「さあどうしよう」と考えるのでは遅いです。平時に「もし〇〇が起きたら△△する」という対応策を決めておくことで、有事の判断スピードが格段に上がります。特に発生確率は低いが影響度が大きいリスクほど、事前設計の効果が出ます。
リスク管理の全体プロセス5ステップ
では具体的な手順です。プロジェクト開始時から終結まで、この5ステップを回します。
ステップ1：リスクを洗い出す
チームでブレインストーミングを行い、考えられるリスクをすべて列挙します。このとき使えるのが「過去プロジェクトのリスク台帳」や「SIでよくあるリスクチェックリスト」です。一人で洗い出すと視点が偏るので、テックリードや業務担当など複数の視点を必ず入れます。「ありえない」と思うリスクも一度は書き出すのが鉄則。評価は次のステップでやれば良いので、この段階では絞り込まないことが重要です。
ステップ2：リスクを評価する
洗い出したリスクを「発生確率」と「影響度」の2軸で評価し、優先順位を付けます。よく使われるのが3×3や5×5のマトリクスで、スコアの高いリスクから対応策を検討します。評価は主観になりがちなので、チームで合意して数値化するプロセスが重要です。全員の認識を揃えることで、優先対応リスクへの共通理解が生まれます。
ステップ3：対応策を選択する
リスク対応には4つのパターンがあります。①回避（リスクが発生しないように計画を変更する）、②軽減（発生確率や影響度を下げる施策を打つ）、③転嫁（保険や外注で第三者に移す）、④受容（コストと照らし合わせてあえて受け入れる）。「注意する」は対応策ではなく、4パターンのどれかに落とし込むことが必要です。
ステップ4：トリガーを設定して監視する
リスクが顕在化しつつあることを示すサイン（トリガー）を事前に定義します。例えば「ベンダーの週次報告が2回連続で遅延→納品遅延リスクのトリガー」のように具体的に決めます。トリガーが観測されたら対応策を即発動するルールを決めておくことで、「様子を見ているうちに手遅れ」を防げます。
ステップ5：台帳を運用する（更新・クローズ）
リスク台帳は週次定例で必ずレビューし、状況変化を反映します。対応済みや期限切れのリスクは「クローズ」として記録を残し、削除しないのがポイントです。過去のリスク履歴は次のプロジェクトの洗い出しで大きな財産になります。
実践のコツ
・リスク台帳の最低限の列：リスクID・内容・発生確率・影響度・スコア・対応策・オーナー・トリガー・ステータス
・オーナーを決めていないリスクは誰も監視しない。必ず担当者名を入れる
・週次定例でリスク台帳を開く習慣だけで、形骸化の大半は防げる
・プロジェクト終結時に台帳をアーカイブし、「実際に顕在化したリスク」をメモしておくと次回の洗い出し精度が上がる
よくあるアンチパターン3つ
「リスク管理はやっているつもりなのに機能しない」現場によく見られるパターンです。
NG1：台帳が「報告用の飾り」になっている
ステコミや定例で見せるためだけに台帳を作り、実際の意思決定には使われていないパターン。台帳のリスクが誰にも見られず、顕在化したリスクが台帳に載っていないという事態が起きます。台帳は「実際に対応策が動いているか」を確認するための作業ツールであり、提出用資料ではありません。
NG2：リスクと課題を同じ行で管理している
「リスク・課題管理台帳」という名前で一つのシートにまとめているプロジェクトをよく見かけます。便利そうに見えて、まだ起きていないリスクへの備えと、すでに起きている課題への対処が混在し、どちらも中途半端になります。リスクが顕在化したら課題台帳へ移動するルールを設け、台帳は分けて管理しましょう。
NG3：対応策が「注意する」「確認する」だけ
台帳の対応策欄に「注意して進める」「定期的に確認する」とだけ書かれているパターン。「注意する」は行動ではなく姿勢です。誰が、いつ、何をするかが定義されていなければ、リスクが顕在化したときに誰も動けません。対応策は「〇〇が発生したら、△△が□□日以内に××する」という形式で書くことを習慣にしましょう。
今日からできる一歩
最後に、この記事を読み終わったあとにすぐできることを1つ。
手元のリスク台帳を開いて、対応策が「注意する」「確認する」になっているリスクを1つ選び、「誰が・いつ・何をするか」を書き直してみてください。
たった1行の書き直しでも、それをやると「このリスクには実際に誰も動いていない」という事実が浮かび上がってきます。そこから対応策を具体化する議論が始まれば、リスク管理は台帳を眺めるだけの作業から、プロジェクトを守る実務に変わっていきます。
リスク管理は完璧を目指さなくていいです。台帳の中から1つだけ、今日動かしてみてください。
ABOUT ME
ITプロジェクトを15年以上担当。プログラマー→SE→PM→PMOコンサルタントとして、さまざまなレイヤーでプロジェクトに関わってきた経験から、実践的なプロジェクトマネジメントノウハウを発信します。