リスクを洗い出して、計画に織り込む
「リスクを洗い出しておいてください」と言われて一覧を作ったものの、その後一度も見返さなかった。そんな経験はないでしょうか。
リスク管理が形だけになるのは、「起きるかもしれないこと」を書くだけで、「いつ気づくか」と「そのとき何をするか」が書かれていないからです。
■ リスクと課題は違う
まず区別しておきます。
リスク まだ起きていないが、起きるかもしれないこと
課題（イシュー） すでに起きていて、対応が必要なこと
リスクが現実になったら、課題管理表に移します。リスク管理表に「発生済み」の項目が残っていると、どちらの表も機能しなくなります。
■ 6つの列で書く
リスク管理表に必要なのは、次の6つです。
① リスク（起きるかもしれないこと）
「要件定義の遅延」では漠然としています。「誰の」「何が原因で」「何が起きるか」まで書きます。「業務側のレビュー要員が繁忙期で確保できず、要件確定が遅れる」まで書けば、打ち手が見えてきます。
② 兆候・トリガー
ここがいちばん抜けやすく、いちばん重要な列です。「何が見えたら、このリスクが現実になりかけていると判断するか」を書きます。
「6月の月次締めで、鈴木さんの予定が3日埋まる」
「サンプル1万件の検証でエラー率が3％を超える」
「4月の合同会議で、先方の体制が示されない」
トリガーが書いてあると、毎週の定例で「その兆候は出ていますか」と確認できます。書いていなければ、問題になってから気づくことになります。
③ 確率 ④ 影響
高・中・低の3段階で十分です。細かい点数計算は、実務ではあまり意味がありません。大事なのは、上位3〜5件に絞って集中することです。
⑤ 対応方針
4つの選択肢から選びます（後述）。「注視する」は方針ではありません。
⑥ 担当と期限
誰が、いつまでに手を打つか。ここが空欄のリスクは、結局誰も動きません。
■ 対応方針は4つから選ぶ
回避 リスクが起きない形に計画を変える。「連携をやめて手動運用にする」「その機能を第2弾に回す」
軽減 確率か影響を小さくする手を先に打つ。「先にデータ調査を実施する」「レビューを前倒しする」
転嫁 他者に引き受けてもらう。「保守契約に含める」「請負契約にする」「保険をかける」
受容 起きたら対応すると決めておく。ただし「何もしない」ではなく「準備しておく」のが受容です
確率が低くても影響が大きいものは、受容しつつ準備します。「主要メンバーの離任」は防げませんが、設計の要点を文書化し、副担当を置いておけば被害は小さくなります。
■ 洗い出しのコツ
思いつくままに書くと、当たり障りのないものばかりになります。次の切り口を使うと出てきます。
過去に起きたこと 前のプロジェクトで何が起きたか。似たことは繰り返します
自分でコントロールできないところ 他部署、他システム、外部ベンダー、法令、機材の納期
初めてやること 使ったことのない技術、組んだことのない相手、経験のない規模
見積の幅が大きいところ 幅が広いのは、分かっていないからです
メンバーが不安に感じていること 「なんとなく心配」は、たいてい当たります
最後の点は、キックオフで「心配なことを一人ひとつ」と聞いたときに出てきたものが、そのままリスクの候補になります。
■ 計画に織り込む
リスク管理表は、作るだけでなく計画に反映させて初めて意味があります。
軽減策の作業を、工程表にタスクとして入れる（「データ事前調査 4月 佐藤 5日」）
確率と影響が大きい箇所の手前に、バッファを置く
リスク対応にかかる費用を、予備費として見積に含める
「リスクがあります」と書いてあるだけで工程表に何もないなら、それは織り込まれていません。
■ 運用のしかた
毎週の定例で上位3件だけ確認する 「兆候は出ていますか」の一言で足ります
月次で全体を見直す 新しいリスクを追加し、消えたものは閉じる
フェーズの変わり目で入れ替える 設計期とテスト期では、危ないところが変わります
現実になったら課題管理表へ移す 移した記録も残しておくと、次に活きます
■ まとめ
リスク管理で効くのは、リスクの数ではなく「兆候」と「担当・期限」です。何が見えたら動くのかを決め、その手当てを工程表に入れる。ここまでやって、ようやく計画に織り込んだと言えます。
いまのリスク一覧を開いて、兆候の列が埋まっているか確認してみてください。空欄なら、そこから始めます。