プロジェクトの立ち上げで、リスクを洗い出してリスク管理表を作る。ここまではどの現場でもやっています。
でも、いざ想定していたリスクが現実になったとき、現場が混乱する。会議が招集され、「どうしますか」「上に確認します」が繰り返され、対応が決まるまでに何日もかかる。
せっかくリスクを洗い出していたのに、なぜこうなるのか。
理由はシンプルです。リスクの「一覧」はあっても、「発生したらどうするか」が決まっていないからです。
この記事では、私が現場で実際に効果を感じているリスク管理のやり方をまとめます。
リスク管理の目的は「一覧を作ること」ではない
リスク管理というと、リスクを洗い出して、発生確率と影響度で評価して、一覧にする。そういうイメージがあると思います。
それ自体は間違っていません。でも、それはリスク管理の入り口にすぎません。
リスク管理の本当の目的は、問題が起きたときに、迷わず動ける状態をつくっておくことです。
問題が発生している最中の調整は、時間がありません。関係者も焦っていて、冷静な判断が難しい。だから、平時のうちに「起きたらこうする」を決めておく。それがリスク管理の価値です。
やり方1：発生確率の高いリスクは「起きたらどうするか」まで決める
洗い出したリスクのうち、特に発生の可能性が高いものについては、発生したときにどうするかを、できるだけ具体的に決めておきます。
たとえば、こんなリスクがあったとします。
「顧客側の仕様確定が遅れ、開発着手が後ろ倒しになる」
一覧に書くだけなら、これで終わりです。でも、ここからもう一歩踏み込みます。
- 仕様確定が何日遅れたら、対応を発動するのか
- 発動したら、何をするのか（範囲を絞る／リリースを分ける／要員を追加する）
- 誰が判断するのか
- 顧客にはいつ、誰から伝えるのか
ここまで決めて、内部で合意を取っておく。これだけで、実際に起きたときの動きは驚くほどスムーズになります。
やり方2：細かく決めきれないなら「判断基準」だけでも決める
とはいえ、すべてのリスクについて、細かい行動まで全部決めておくのは現実的ではありません。
そういうときは、判断基準や方針だけでも決めておく。それだけでも、何も検討していない状態に比べて、混乱を大きく避けられます。
たとえば、
- 「品質と納期がぶつかったら、品質を優先する」
- 「追加要望は、リリース後の改修で受けることを基本とする」
- 「顧客影響のある障害は、原因が不明でも1時間以内に第一報を入れる」
このくらいの粒度で十分です。判断の軸が決まっていれば、現場は細かいところを自分たちで考えて動けます。
経験者の「当たり前」を言語化して共有する
ここで大事なことがあります。
経験を積んだ人は、問題が起きたときにどう動けばいいかを、身をもって知っています。だから、わざわざ決めなくても動けてしまう。
でも、チーム全員が同じ経験をしているわけではありません。経験者にとっての「当たり前」は、若手にとっては「知らないこと」です。
経験者の頭の中にある判断を言語化し、事前に共有しておく。地味ですが、実際の効果はとても大きい。「そんなの常識」と思ったときこそ、たいてい共有を怠っています。
やり方3：「対応しない」という対処も、正式に合意する
リスク管理で見落とされがちなのが、これです。
リスクに対して、必ず何かをしなければいけないわけではありません。
対策にかかるコストが、リスクが起きたときの損失より大きいなら、あえて「対応しない」という選択もあります。リスクを受け入れて、起きたら起きたで対処する。これも立派なリスク対応です。
ただし、ここが重要なのですが、「対応しない」という判断も、正式な合意が必要です。
PMが一人で「これは起きても仕方ない」と判断して黙っていると、いざ起きたときに「なぜ対策していなかったのか」と責任問題になります。でも、事前に関係者と「このリスクは受容する」と合意しておけば、起きたときは粛々と対処するだけです。
問題になる前の合意は、大きなコスト削減になる
問題が起きる前に、合意まで含めて調整しておく。
これは、問題発生中に調整することに比べて、はるかに安くつきます。平時なら30分の打ち合わせで決まることが、問題の最中には、何日もの会議と、関係者の疲弊と、信頼の損失を伴うからです。
リスク管理表に加えたい3つの列
ここまでの内容を、リスク管理表に落とし込むと、こうなります。一般的な「リスク内容・発生確率・影響度」に加えて、次の列を持たせます。
| 列 | 書くこと | 例 |
|---|---|---|
| 発動条件 | どうなったら対応を始めるか | 仕様確定が予定から5営業日遅れた時点 |
| 対応方針 | 発動したら何をするか（「対応しない」も含む） | リリースを2回に分け、第1弾の範囲を絞る |
| 合意状況 | 誰と、いつ合意したか | 〇月〇日 顧客PM・自社部長と合意済み |
特に「合意状況」の列は、ぜひ入れてください。この列が空欄のリスクは、まだ「管理されていない」リスクです。
なお、リスクが実際に発生したら、それはもうリスクではなく課題です。課題管理表に移して管理します。課題管理表の運用は課題管理表が「更新されない」を解決する5つのルールにまとめています。
リスクは「静かな時」に準備する
最後に、心構えの話です。
割り込みは、必ず起きる前提で計画する
プロジェクトでは、想定外のことが必ず起きます。割り込み、仕様変更、メンバーの離脱。
それにいちいちストレスを感じていては、身がもちません。想定外は起きるものとして、最初から計画に織り込んでおく。予定外になったときにどう動くか、先に考えておく。
余白のない計画は、想定外がひとつ来ただけで崩れます。理想の計画より、崩れても直せる計画を。WBSを組むときにも、この余白の考え方は欠かせません（WBS作成のコツ）。
何事もない時こそ、気を抜かない
そして、リスクの準備は、プロジェクトが落ち着いている時にしかできません。
炎上している最中に、次のリスクを洗い出す余裕はありません。だからこそ、何事もない時、うまくいっている時ほど、足元を一度だけ疑う。「次に何が起きるか」を考え続ける。
忙しい時も、そうでない時も、PMのやることは変わりません。
まとめ：リスク管理のポイント
- リスク管理の目的は、一覧を作ることではなく、起きたときに迷わず動ける状態をつくること
- 発生確率の高いリスクは、発動条件・対応・判断者・連絡まで具体的に決めて合意する
- 決めきれないリスクは、判断基準・方針だけでも決めておく
- 経験者の「当たり前」を言語化して共有する
- 「対応しない」も正式に合意しておく
- リスクの準備は、静かな時にしかできない
リスク管理は、未来の混乱を、平時の30分で買い取る仕事です。地味で、目立たなくて、うまくいっている時ほど誰にも評価されません。でも、その地味な準備があるかどうかが、プロジェクトの生死を分けます。
あわせて読みたい
西村 幸一 / Open Field
IT業界25年。PM支援・要件定義・Excel業務効率化。
X：@kn_246
