リスクの考慮漏れを失くす、効果的な特定方法とは？
お疲れ様です。ゆとりのひとりです。
先日、リスクの特徴についてまとめました。
「リスク」の特徴をおさらい
リスクイベントには「発生確率」「インパクト(影響の大きさ)」「発生タイミング」の要素があり、リスクイベントの見積もりには担当者の経験が必要である。よって、リスクイベントの洗い出しにはチームを横断して参加者をアサインする必要があり、かつ、上層部による経営判断も必要であると書きました。
今回は、リスクイベントの特定にあたって考慮漏れを失くす効果的な手法をご紹介します。
・参加者が持っている情報は何かを整理する
まずはリスクイベントを洗い出すためにふさわしい参加者を収集します。そして、参加者が持っている情報や知識に偏りがないか、不足はないか、また、闊達な議論を妨げないか、という検討が必要です。
主に以下のような項目を検討し、情報が不足している場合は参加者の入れ替えや、改めて情報収集をする必要があります。
・所属チームは網羅されているか？
（アプリ、インフラ、ネットワーク、ユーザー、PM・・・等）
・WBS(作業内容、担当者、スケジュール)は決定しているか？
・業務プロセスは決定しているか？
・契約内容は明示されているか？
振り返りになりますがリスクイベントを正しく捉えるには、「発生確率」「インパクト(影響の大きさ)」「発生タイミング」の要素が必要ですから、いつ、どのくらいの大きさの損害が発生するのか、を想像できるだけのインプットが必要です。
例えば「明日の朝（発生タイミング）、目玉焼きを作ろうとしたら、たまごがなくて（卵がない確率）、すごくがっかりする。（インパクト）」というリスクイベントを特定するためには、明日の朝の献立には、目玉焼きがあることを誰かが知っていなければならないし、今日の時点ではたまごがあるのか、ないのか、を知っていなければなりません。
明日の朝は、ごはんと味噌汁だと知っていれば、発生確率はゼロですし、今日の時点でたまごがあれば、明日の朝の時点でたまごが無い確率は低くなります。たまごが残り1個だと、確率は高いかもしれません。
・・・朝ごはんの例は微妙かもしれません。汗
・リスクカテゴリー別に洗い出す
リスクイベントは漠然と想像しても洗い出せないことが多いでしょう。以下のようなカテゴリーに分けて検討してみることをオススメします。
・スケジュール
明らかに短い納期であるか？甘い見積もりであるか？外注とのやり取りでロスするか？先行、後続関係はあるか？などなど。
・コスト
コストに大きな影響を与える事項は何か？甘い見積もりであるか？コスト超過は継続して発生するか、一過性のものであるか？他リスクイベントの払拭に伴って、コストが増加するか？などなど。
関係性は悪いか？暗黙の期待が隠れているか？契約内容を合意しているか？遵守できない可能性があるか？などなど。
・クオリティ
技術的な問題はあるか？暗黙の期待が隠れているか？基準が不明瞭であるか？過剰な品質を要求されているか？などなど。
・変更要求
変更要求の頻度はどのくらいか？過剰な規模での要求が予測されるか？管理規定が不明瞭であるか？変更されるとしたら何か？
また、カテゴリ毎の検討には思考のツールを利用することをおすすめします。代表的なのは、ブレーンストーミング、NGT、マインドマップ、ポジショニングマップなどが有効です。（思考ツールの説明については、他の記事や文献に任せます。）
・クリティカルパスを分析する
スケジュール上のリスクイベントは、ほとんどがクリティカルパス上のタスクによって引き起こされるでしょう。工程遷移の際に、何が起こるとプロジェクトの遅れに繋がるかを検討しましょう。
スケジュールの始めから終わりまでなぞるようにリスクイベントを想定し、ホワイトボードに張り出したり、プロジェクターで参加者全員が参照できるようにします。
・ウィークリンク（Weak Link）を分析する
作業をチームや部門間で引き渡すとき、あるいは責任の所在が移るとき、ステークホルダ間で認識の相違によって、スケジュールが遅延したり、品質が低下することがあります。
こういった繋がりの弱い分をウイークリンク（Weak Link）といいます。どうしても自分の責任範囲のみをスコープとしてリスクの洗い出しをしてしまいがちですが、ウイークリンクについても検討すべきです。
特にクリティカルパス上にあるウイークリンクは、最優先で対応する必要があります。
・リスクイベントを評価する
リスクイベントを全て洗い出せたとしても、全てに対応することは不可能です。発生確率とインパクトから「優先順位」を決めて、対応すべきリスクイベントを選択します。
発生確率とインパクトの評価は、参加者の経験や知識量によってバラつきがでます。最も高い評価を下した人と、最も低い評価を下した人の根拠を明示し、全員で検討を繰り返します。
そして「優先順位」を決める基準を明確化します。多くの場合は、インパクトが大きい場合に優先度が高くなるでしょう。もしも、発生した場合には、リスク対応よりも大きな損害が発生するようなイベントです。
別の記事で取り上げますが、「優先順位」が高いリスクイベントに対しては、イベントが起こる前の予防策と、イベントが起こった後の対処を両面から考える必要があります。
まとめ：リスクイベントの特定には思考のフォーマットを用意して、塗り絵をするような感覚で洗い出しましょう。
いかがでしたでしょうか？
考慮漏れを失くすために重要なのは、漠然としたイメージや、過去の経験からリスクイベントを純粋想起してはいけない、ということです。
とは言え、収集された参加者達にリスクイベントの本質を説明したり、知ってもらう時間はありません。考慮漏れを失くすプロセスや、会議、レビューのフォーマットを定めて「仕組み化」することでチーム全体での考慮漏れを防ぎましょう。
以上！
