前回、前々回と、システム構築のリスクマネージメントの観点よりお話をさせていただいています。リスクマネージメントは、「リスク特定」「リスク分析」「リスク評価」を実施することでリスク管理簿を完成させ、それを基に、リスクマネージメントを継続的に実施していくこととなります。今回は、リスク分析についてお話させていただきたいと思います。様々な手法が存在するため、基本的な事象及び私の過去の経験からの、経験談としてお話できればと思っています。
プロジェクトのリスクマネージメント(1)
プロジェクトのリスクマネージメント(2)
リスクマネージメントの実施を考えた場合には、前段で特定されたリスクがどのようなものなのか、またそのリスクによりどのような事象が発生するのか？といったことを明確化していくことが重要なポイントです。リスク分析のプロセスを通じて、リスクの内容を明確化するとともに、プロジェクトチーム内でのリスクに対しての統一された基準を整えることが重要になります。
リスク分析とは
リスク分析の定義とは何でしょうか。
一番簡単な定義では、
リスクの特質を理解し，リスクレベルを決定するプロセス（ISOガイド73:2009）
となります。
リスク分析で検討すべき項目は、以下のような要素で検討を実施することが必要です。
- リスクの発生確率と結果
- 結果の性質と大きさ
- 複雑さと結合度
- 時間に関係する要素と変動性
- 既存の管理策の有効性 (ISO 31000:2018より)
上記の要素を検討に入れて、実際にリスク識別で識別されたリスクを分析します。
リスク分析のアウトプット
プロジェクト管理上のリスクは様々なものがありますが、最終的にはすべてのリスクに対して対応を行っていくということは現実的では有りません。そのため、リスクには優先順位を設定しより優先順位の高いものから着手していく事となります。リスク分析の結果として、優先順位をつけられるように各タスクの重要度をつけていく作業が必要になります。よく用いられるものとして、リスクマトリクスが用いられます。リスクの評価を、以下の2点で表します。
- 影響度
- 発生可能性
影響度と、発生可能性の組み合わせで重要度を求める手法です。下記のようなイメージは様々な場で目にされていると思います。
発生確率、影響度を何段階化に分類し、このような表にプロットします。この表では、優先順位は、「2 → 1、4 → 3」となります。実際には、発生確率、影響度はもう少し細かく設定し、以下のような計算式で順位付けを行うのが一般的かと思います。
重要度 = 発生確率 × 影響度
実際に分析をするために
実際に、分析を進めるとなった際のポイントをいくつか上げていきたいと思います。様々な方法論もありますので、あくまで参考という程度に読んでいただければと思います。
リスク内容を、各自の視点から確認する
リスク管理簿の分析を実施する場合には、基本的には各担当者の全員が確認するようにすることが必要です。前述の分析の検討要素は、その要素を各プロジェクトメンバーからの視点で確認することが望ましいと思います。自身の担当だけではなく、担当外の内容に関しても各メンバーがそれぞれの立場でしっかりと確認していくことが重要になります。
それにより、分析の結果をより精度の高いものとすることができます。特に、リスクとしてあげられていた項目の原因や、もたらす結果に関しての漏れなどは多発する傾向がありますので、その点に関して、プロジェクト参加メンバの視点で検討を進める必要があります。
共通の視点・判断基準を準備する
前項で各自の視点で確認すると記載しましたが、各自の視点でしっかり情報を整理し内容を分析し、その結果を関係者で合意して、分析結果とする必要があります。プロジェクト似参加しているメンバー立場やバックグラウンドは様々です。途中からプロジェクトに参加して、火消しを行うなどと言った経験も多いため、すでに参加しているメンバーとの視点が合わない場合がよくあります。視点のズレは、いろいろな側面で発生します。
- 過去の経緯から意見の相違
- 情報量の違い（ドキュメント化されていない情報などの存在）
- 立場の違い
プロジェクト参加者によって、リスクに対しての認識は大きく食い違うことは、よく発生しますし、何度も経験しています。よくあるパターンとして、以下のような傾向があるのではないかと思います。
- プロジェクトオーナー
- 技術者
技術的リスクなど、実装面でのリスクを軽視しがち（実装上で、なんとか解決できるであろうと考えている）
実装上の細かいリスクを、課題に評価しがち（直接のリスクが降りかかるため）
これは、プロジェクトの上流にいるメンバーと、下流工程にいるメンバーの見ている範囲の違いや、実際にプロジェクトに影響を与えるであろう事象への評価方法の違いが関係していると思います。（私は、実装よりのPMとして動くことが多くあったため、プロジェクトオーナ側の認識と、実装側の認識の調整で、四苦八苦した経験が何度もあります。）
ここで重要なのは、各種のリスクを分析していく際に、各プロジェクトメンバーの視点を理解しつつ、お互いが理解できる共通の前提を作っていくことが重要になると考えます。プロジェクトマネージャといった役職がその点を理解し、全員を誘導することで、リスクの分析を建設的なプロセスに変えられると思います。
さいごに
リスクを分析して、その影響度を正しく把握していくというのは、どのプロジェクトでも難しい作業になると思います。定量的に評価すると言ったことも、非常に難しく、難航しがちです。そのため、定量的な解析だけでなく、定性的な解析も踏まえるなどと言ったことも必要になりますし、個人的には、現場の肌感といったものも、生かしていく必要があります。
ここでの分析結果をしっかりとプロジェクトオーナに伝え、その結果を持って、対応計画を立てていくことがプロジェクト成功に向けた大きなポイントとなると思います。先入観や、自分の視点にとらわれず広く情報を収集していくことで、プロジェクト終盤の混乱に立ち向かいことができると思いますので、PMの腕の見せどころかなと思っております。皆様の睡眠時間が守られますよう、お祈りして、終わりとさせていただきます。
