リスク管理のやり方を知らない人は、実はそんなに多くないと思います。洗い出して、評価して、対策を決めて、監視する。この四つはどこにでも書いてあります。
それなのに、現場では続きません。私も何度も止めています。
止まる理由は手順を知らないからではなく、もっと地味なところにありました。定例会議でリスクの議題が最後に置かれていて、毎回時間切れになる。メンバーが気づいていたのに言わないまま進む。この記事では、そういう「分かっているのにやらない」側の話を書きます。
洗い出しと評価そのものの手順はプロジェクトのリスク管理：失敗を防ぐための戦略に分けたので、ここでは運用と組織の側だけを扱います。
目次
1. リスク管理が後回しになる三つの理由
自分の経験の範囲では、だいたい次の三つです。
燃えていない問題に時間を割けない。 これが一番大きいです。今日締切のものと、起きるかどうか分からないものが並んでいたら、締切の方を取ります。リスク管理は本来こちらを優先すべき性質の作業なのですが、目の前で誰も困っていないので後ろに回ります。
議題の順番が悪い。 定例のアジェンダで、進捗報告の後、その他の前あたりにリスクの項目を置くと、ほぼ確実に飛びます。進捗の議論が長引いた週から順に消えていき、三回ほど飛ばすと項目自体がなくなります。私はこれを何度もやりました。
リスクを言うと後ろ向きだと受け取られる。 「このまま行くと間に合わないかもしれません」と言った人が、その場の空気を悪くした扱いを受けることがあります。一度これが起きると、次から誰も言わなくなります。手順の問題ではなく、完全に空気の問題です。
三つ目が特に厄介で、これが起きている組織では、リスク管理の仕組みをどれだけ整えても情報が入ってきません。入力がないので、表だけが綺麗に空のまま維持されます。
2. 部下がリスクに気づいていたのに、私に言わなかった話
三つ目について、自分が管理する側で経験したことを書きます。
ある案件で、顧客に提出する予定だった集計処理の性能が、本番想定のデータ量ではまったく足りないということが、納品の3週間前に分かりました。私はその時点で初めて聞きました。
ところが、担当していたメンバーに聞くと、1か月以上前から「たぶん厳しい」と思っていたそうです。
なぜ言わなかったのか。返ってきたのは「確証がなかったので、確かめてから報告しようと思っていた」という趣旨の話でした。悪意も怠慢もありません。むしろ真面目な人ほどこうなります。確かめてから言おうとして、確かめる時間が取れないまま日が過ぎる。
このとき自分の側の問題として反省したのは、私が普段から「確認してから持ってきて」という言い方をしていたことでした。報告の質を上げるつもりで言っていたのですが、受け取る側からすると「確証がないものは持ち込むな」に聞こえます。リスクというのは定義上まだ確定していない話なので、この基準だと構造的に上がってきません。
それ以来、リスクについては「確度が低いままでいいので早く言ってほしい」と明示的に分けて伝えるようにしました。完全には直っていませんが、以前よりは早い段階で怪しい話が入ってくるようになったと思います。
報告そのものが形式的になってしまう問題については定例報告は毎回きちんと出ていたのに、納品物を一度も見ていなかったにも別の角度から書きました。
3. 監視を続けるための地味な仕掛け
空気の話は時間がかかるので、先に仕組みでどうにかなる部分を書きます。私が実際にやって、多少なりとも続いたものだけを挙げます。
リスクの議題を定例の先頭に置く。 これだけで飛ばなくなります。時間切れになるのは常に後半なので、順番を入れ替えるのが一番安く効きました。進捗報告より先にリスクを見る形にすると、そもそも進捗の議論の質も変わります。
発動条件を数字で書いておく。 「進捗の遅れが2週間を超えたら」「不良件数が週10件を超えたら」のように、線をあらかじめ決めておきます。判断を都度やらずに済むので、気づいた人がその場で上げられます。感覚で「そろそろまずい」と判断させると、人によって閾値が違うので拾えません。
リスク一覧の更新日を表示する。 最終更新が3週間前になっている一覧は、機能していない証拠として一目で分かります。中身を見なくても状態が判断できるので、これは安い割に効きました。
フェーズの切り替え時に洗い出しをやり直す。 最初に一度作って終わりにすると、途中から出てきたリスクが入りません。要件が固まった時点、実装が始まる時点など、前提が変わる場所で見直す予定を先に入れておきます。
ダッシュボードや専用ツールも選択肢としてはありますが、規模に合わないものを入れると運用の手間だけが残ります。私が関わる程度の案件では、共有ドキュメント一枚と定例のアジェンダで足りています。
4. リスクを口に出せるチームにするために
仕組みで拾えるのはここまでで、残りは受け取り方の問題です。
悪い知らせを持ってきた人の扱いを変えない。 早い段階で問題を報告した人が結果的に損をする構図になっていないかは、意識して見るようにしています。報告した人がそのまま火消しの担当になる、というのもよくある形で、これも実質的な罰になります。
確度の低い話を歓迎すると明示する。 前述の通り、確証を求めると上がってきません。「外れてもいいので早く」と言葉にして伝えないと、真面目な人ほど抱え込みます。
外れたリスクを責めない。 「あのとき心配していたことは結局起きませんでしたね」を否定的に扱うと、次から言わなくなります。起きなかったこと自体は良いことなので、そう扱う必要があります。
効かなかった対策も共有する。 うまくいった事例だけを振り返ると、次も同じ手を打って同じように外します。何が効かなかったのかは、効いたことと同じくらい材料になります。
このあたりは、マネジメント側が率先しないと変わりません。私自身、自分の言い方が原因で情報が止まっていたことに気づくまでに、それなりの時間がかかりました。
5. まとめ
リスク管理が続かない理由は、手順を知らないことではなく、優先順位の問題と、言い出しにくさの問題でした。
私の場合、効いた順に並べると、議題を定例の先頭に移したこと、発動条件を数字で決めたこと、そして確度の低い報告を歓迎すると明示したことの三つです。どれも手法の話ではありません。
逆に言えば、リスク管理の仕組みが機能していないときは、仕組みを高度にするより、情報が上がってこない理由を探した方が早いと思います。入力がない表は、どれだけ精緻でも空のままです。
洗い出しと評価の手順そのものはプロジェクトのリスク管理：失敗を防ぐための戦略に、機械学習案件に固有のリスクはリスクマネジメントの役割とプロジェクトの成功に書きました。リスク管理を含めた全体像はITプロジェクトマネジメントの基礎とその重要性を参照してください。