以前、リスク一覧をきちんと作った案件で、そこそこの規模の炎上をやったことがあります。
キックオフの前にメンバーを集めてリスクを洗い出し、表にして、影響度と発生確率まで付けました。手順としては何も間違っていません。それでも防げませんでした。後から見ると、実際に燃えた原因は一覧の中にちゃんと書いてありました。書いてあったのに、誰も手を打っていなかったというだけです。
この経験以来、リスク管理で難しいのは洗い出しそのものではなく、洗い出した後に順位をつけて手を寄せるところだと思っています。この記事では、識別と評価をどうやるのかを中心に書きます。洗い出した後にどう運用を続けるかはリスク管理の重要性：ITプロジェクトでのベストプラクティスの方に分けました。
目次
1. リスク一覧を作っただけでは何も防げない
冒頭の案件で何が起きたのかを書いておきます。
画像認識のモデルを作って既存システムに組み込む、という内容でした。洗い出しの段階で「学習データの提供が遅れる可能性がある」というリスクは挙がっていました。影響度は高、発生確率は中。表の上の方に載っていました。
そして実際に遅れました。当初の予定より1か月半ほどです。
問題は、そのリスクに対して決めていた対応が「先方に早めに依頼する」だけだったことです。これは対応策ではなく願望です。遅れたときに何をするのかが決まっていなかったので、遅れてから慌てて検討を始めることになりました。結果として、モデルの検証に使えるはずだった期間がまるごと消えました。
つまり私がやっていたのは、リスクの識別と評価までで、対応の設計をしていなかった。表を作った時点で仕事をした気になっていたわけです。
このとき学んだのは、リスク管理の成果物はリスク一覧ではなく「そうなったときに誰が何をするか」の方だということでした。一覧はそこに至るための材料でしかありません。
2. リスクの識別：どこから出てくるのか
とはいえ、材料が足りなければ話が始まらないので、識別の話から書きます。
リスクとは、目標の達成を妨げる可能性のある、まだ確定していない出来事のことです。進捗、品質、コスト、スコープのどこかに効いてきます。分類しておく意味は、種類によって打てる手がまったく違うからです。
技術的リスクは、新しい技術の未成熟さ、要件の不確定さ、既存システムとの統合の複雑さなどから来ます。検証していない技術を採用して、想定していない不具合が出るというのが典型です。この種類のリスクは、事前の検証で確率をかなり下げられます。方向がはっきりしているので、実は扱いやすい部類です。
人的リスクは、キーパーソンの離職、スキル不足、情報共有の不足です。規模の小さいチームほど、一人抜けたときの影響が大きくなります。私のいる会社は人数が多くないので、ここが常に一番怖いところです。特定の人しか触れないコードや、特定の人しか経緯を知らない顧客対応があると、その時点でリスクとして数えるようにしています。
外部リスクは、法規制の変更、顧客側の体制変更、経済状況といった、自分たちでは動かせないものです。減らせないので、監視と代替案の準備が中心になります。
洗い出しの材料としては、ブレインストーミング、チェックリスト、過去の案件の記録があります。個人的にいちばん効いたのは過去の記録でした。同じ会社で似た種類の案件をやっていると、燃える場所はだいたい似ています。前回どこで詰まったかを見返すのが、思いつきで挙げるより確実です。
ここで一つ実感として書いておくと、洗い出しは一人でやらない方がいいです。私が挙げるリスクはマネジメント側の視点に偏っていて、実装している側から見た危なさが抜けます。逆にメンバーからは「あのライブラリのバージョンが上がると動かなくなる」といった、私が絶対に思いつかない粒度のものが出てきます。
3. リスクの評価：優先順位をつけるための作業
評価の目的は、深刻さを正確に測ることではありません。限られた時間と人をどこに寄せるかを決めることです。ここを取り違えると、評価そのものが目的化します。
基本は影響度と発生確率の二軸です。この二つを掛け合わせて優先度を出します。
定性的な手法としてはリスクマトリックスが手軽です。影響度と発生確率を高・中・低に分けて表に並べるだけなので、チームで共有するときの共通言語になります。私も基本はこれしか使っていません。
定量的な手法としては、モンテカルロシミュレーションや決定木分析があります。各要因に確率分布を設定して何千回と試行し、完了時期やコストの振れ幅を数値で出すやり方です。遅延要因が複数あって、累積した影響からバッファを決めたいときには筋の通ったやり方だと思います。ただ、正直なところ、私が関わる規模の案件でここまでやったことはありません。入力する確率分布の根拠が結局は勘なので、精緻に計算しても出てくる数字の信頼度が上がらないからです。
規模に合わない手法を持ち込むと、労力に見合いません。小さい案件ならマトリックス一枚で十分だと思います。
優先順位の付け方としては、次のように扱っています。
- 影響度も発生確率も高い：最優先で対応を設計する。ここだけは必ず「起きたときに誰が何をするか」まで書く。
- 影響度は高いが発生確率が低い：備えだけ用意して監視する。復旧手順を書いておく、程度で止める。
- どちらも低い：対策を打たず、定期確認の対象にだけ入れておく。
冒頭の失敗は、右上に入っていたものを二番目の扱いにしていた、ということでもあります。データ提供の遅れは影響度が高いと自分で書いておきながら、対応は「早めに依頼する」で済ませていました。
4. 対応策の選び方
対応の型は四つです。ここは教科書通りですが、選ぶ基準の方に実感を書いておきます。
- 回避：原因そのものを取り除きます。未成熟な技術がリスクなら実績のある方を選ぶ、という判断です。効果は確実ですが、その代わりに得られたはずのものも捨てることになります。
- 軽減：発生確率か影響度を下げます。検証工程を厚くする、フェーズを分けて段階的に進める、といった手です。実務でいちばん使うのはこれです。
- 転嫁：契約や保険で影響を第三者に移します。一部を外部に委託して技術的リスクを移す形もここに入ります。
- 受容：許容できる範囲だと判断して、特別な対策を取りません。何もしないことを決める、というのが重要で、決めずに放置しているのとは別物です。
選ぶときの基準は、対策にかかるコストと、リスクが現実になったときの損失の比較です。対策の方が高くつくなら受容が合理的な場面もあります。
そして、これが冒頭の反省点ですが、どの型を選んだにせよ発動条件を決めておくことが要ります。「データ提供が2週間以上遅れたら、暫定データで検証を先に始める」のように、いつ何をするかまで書いて初めて対応策になります。ここまで書いていないものは、後から見るとほぼ機能しません。
対応策の実行には人と時間が必要なので、決めた時点で関係者の合意も取っておく必要があります。追加の検証工程を入れるなら、チームだけでなく顧客側の理解も要ります。
5. まとめ
リスク管理の識別と評価でやることは、洗い出して、分類して、影響度と発生確率で順位をつけて、上位のものに対応を設計する、という流れです。
私が失敗したのは最後の一歩でした。表を作るところまでは形になっていたのに、「起きたときに誰が何をするか」を書いていなかった。リスク一覧の完成度と、実際に防げるかどうかは別の話です。
洗い出した後のモニタリングをチームの運用としてどう続けるか、そしてなぜリスク管理は分かっていても後回しになるのかはリスク管理の重要性：ITプロジェクトでのベストプラクティスに書きました。機械学習案件に固有のリスクについてはリスクマネジメントの役割とプロジェクトの成功を、リスク管理がプロジェクト全体のどこに位置づくかはITプロジェクトマネジメントの基礎とその重要性をご覧ください。