前回は、システム構築のリスクマネージメントの観点に立って、過去の経験からのお話をさせていただきました。リスクマネージメントでは、「リスク特定」「リスク分析」「リスク評価」を実施することでリスク管理簿を完成させ、それを基に、リスクマネージメントを継続的に実施します。
今回は、リスクマネージメントを実施していく上で初段となる、リスクの特定に関してご説明します。ここでの活動が後段の「リスク分析」のインプットとなりますので、リスクだと認識できるものを、きっちりと挙げていくということが重要です。コントロールを実施する際、何をリスクと考えて行動するのか？という点が、すべての基本です。完全な管理は難しい面もあるため、どのような点に気をつけながら進めていくべきかと言った点をお話できればと思います。
リスク特定とは
リスク特定とは、実際にどの様な作業を実施する必要があるのか。私の過去の経験・認識から、以下のような流れで行うべきだと考えています。
「計画段階」で将来「発生する可能性のある問題」を認識して「記録する」
そのリスクによって、「発生する影響と原因の識別」を実施する
ポイントを分解して説明していきます。
「計画段階」
計画段階と書いてしまうと、ウォーターフォールでないと無理ではないか？と思われるかもしれませんが、そういうことではありません。実際の開発進行において、なんの計画もなく進めるというプロジェクトは存在していないかと思います。（きっと・・・・）また、アジャイル開発と言っても、計画なしに実施するわけでははないですし、全体としての管理は実施する必要があります。
超大規模プロジェクトで、簡単な変更なども許されないという場合は除き、規模の大小・期間の長短はあれど随時計画を見直しながら進行されていくことがほとんどかと思います。そういった、見直しのタイミングで
- リスクが生まれていないか
- リスクが解消しているか
を見直しを行うこともリスク特定「計画段階」の一つです。走りながら考えるな！ということではなく、「考えるなら、先のことを考えましょう」という認識で、次のステップへ進みます。
「発生する可能性のある問題」
「発生する可能性のある問題」はこれまでの経験上も、どこまでを考慮するのか？という点で、毎回議論が巻き起こります。各メンバーの経験や立場などにより、問題の考え方も様々です。ここでのポイントは、「もれなく」挙げていくということが大切ということです。
例えば、「これは可能性低いからあげなくてよいかな」とリスクとして挙げなかった点が、後々、重要だったということがわかったり、別のメンバーがその項目を見ることで、重要な気付きに繋がることは多く見られます。また、実際にリスクを記載するためには、現実的な範囲を定義し、その上で、問題を洗い出すことが重要となります。例えば、「隕石が落ちた場合」といった前提は、そもそもプロジェクトの課題として管理されるべきものではないことは明白であり、問題外です。リスクとして検討する範囲は、現実的な範囲となるよう、各メンバーの認識を合わせてから実施することが重要です。
「記録する」
先述の通り、メンバーの経験や立場により、リスクへの考え方や取り組み方は差が出てきます。そのため、プロジェクト内部のメンバーでの共有が重要となります。実際のリスクの特定においては、リスク管理簿などといったドキュメントの作成が必要です。まず記録として残せる状態を作り、各メンバーの意見などを集約することで、実際のリスク管理プロセスを実施していくための大元となる資料となり、共有が容易になります。
また、この段階では、いわゆるMECEにこだわる必要はありません。前述のように視点は多岐にわたるため、同じ記録に見えても、そのリスク原因は違っている場合があります。そのため、この段階では、プロジェクトメンバーがリスクであると考えられる内容を、前述の検討すべき範囲に沿って、「もれなく記録する」を主題として実施することが重要となります。
「発生する影響と原因の識別」
実際にリスクによる影響を洗い出すプロセスです。後段として「リスク分析」「リスク評価」といった点で詳細は実施しますが、ここではその元データとするための最低限の情報を収集する必要があります。影響及び、そのリスクの発生元となる原因の洗い出しを実施するため、前段のタスクとしては、MECEな状態である必要がない理由となります。今までの経験上、「原因の洗い出し」「影響範囲の洗い出し」に関しては、プロジェクトメンバーとのディスカッションを通じての実施が望ましいです。
原因、影響範囲に関しては、各メンバーの知見を集約することで、漏れを少なくすることができます。この段階で、「リスク項目」「原因」「影響」の3点をもとに、MECEなリストを作成し、後続のリスク管理プロセスに進みます。
リスク特定を実施するには
実際にリスク特定の作業は、現在の状況やメンバーの立場により、軽視や紛糾してしまうことが多いと感じます。プロジェクトオーナ（発注者）視点では、プロジェクト全体の問題もしくは業務に関わる問題は、重要な課題と認識されます。反面、各製造フェーズの問題は、ベンダーの問題でしかありません。ベンダーのPMからすれば、各製造フェーズがうまく行かないということは最大の関心事になりがちです。ベンダーの作業者からすれば、もう少し細かい、実際の作業ができないことが大きな問題になります。
上記のような立場を超えて、リスクの事象に囚われすぎず、まずは「なぜそのリスクが発生すると考えられるのか」といった、原因を見ていく必要になります。詳細な分析に関しては後段のプロセスである、「リスク分析」で実施しますので、この段階では、リスクとして管理すべきか、またその理由はなにか？といった観点での整理が重要になります。
リスク特定の段階では、ドキュメントレビュー、SWOT分析など様々な方法・ツールが利用できるので、積極的に採用していくことにより、業務が軽量化されます。プロジェクトの見える化の議論がなされることは多いですが、まずは、今関わっているプロジェクトでの、睡眠時間を削る要素を見つけ出すことを、第一歩として実施するのはいかがでしょうか。
