No.42: そのリスクは見える化できているか

　プロジェクトは、それまで実現されたことがないシステム、製品、サービス等独自的な”もの”や”こと”を目標とするもので、そこには必ず実現に向けたリスクが存在します。プロジェクトの計画段階においては、どれだけリスクを想定できるか、言い方を変えればどれだけ想定外を無くせるかが重要であり、リスクに対する取り扱いを予め検討し、できるだけ定量化して準備する必要があります。プロジェクトの過程において「想定外のことが起きた」と言うことは、イコール事前の計画が不十分だったと認めることに他なりません。

　あらゆるリスクを想定し、それらのリスクが顕在化するおおよその確率と顕在化した時のプロジェクトへのインパクトを推測し、顕在化確率とインパクトを組み合わせて評価したときにプロジェクトへの影響が多大となりそうなことについては、事前に何らかの手を打っておく必要があります。これを含めた計画でなければなりません。

　時々、”課題”と”リスク”を混同している言説を見かけますが、”課題”は既に発生していて目の前にあるものであるのに対し、”リスク”はまだ発生していないが発生する可能性のあるものです。課題は解決しなければならないものですが、リスクは発生してから解決します。従いまして、リスクとは発生したらどうするかということを事前に考えておくものなのです。また、リスクという用語にはネガティブな印象が伴いますが、リスクにはネガティブとポジティブの両方があり得ることを付け加えておきます。

　ここで、”リスクが発生する”という表現に注意を促したいと思います。まだ発生していないが発生する可能性があり、発生するとプロジェクトに影響に及ぼす事象をAとします。プロジェクト開始当初は事象Aが発生する可能性はゼロだったが、プロジェクトの外部環境に変化が発生し事象Aが発生する可能性が出てきたとします。この新しいリスクが発見された状況を、”リスクが発生した”と表現することができます。一方、このリスクが対象とする事象Aが実際に起きた状況を”リスクが発生した”と表現することもできるのです。これらの誤解を避けるため、私は前者を”リスクの認識”、後者を”リスクの顕在化”として区別しています。

　さて、リスクについては事前にどの様なことを検討しておけばよいでしょうか。まず、リスクの顕在化する確率を予想しておくことです。通常あまり考えたくないこととして、主要メンバが健康を壊し離脱するとか、震災が発生し開発拠点が被害を受ける、という様なことがあります。これらの確率はそう大きいものではありませんが、まず起こらないだろうという安易な判断が、いざ起きてしまった時に”想定外だった”を連発して右往左往する事態を招くことになります。

　確率の次には、それが顕在化した時のプロジェクトへの影響度を予想することです。主要メンバが離脱してしまった場合、その代替に要する期間・コストはどのくらいか、大体に伴う要員シフト等で他の業務やプロジェクトへの影響はどの程度かということです。

　そして、この顕在化の確率とその影響度を掛けることにより、それぞれのリスクの重要度を評価します。この重要度を、どのリスクへの対応を優先させるかの目安に使用するわけです。

　よく知られるリスクが顕在化した時の対応策には、回避、転嫁、軽減、受容の4つがあります。それぞれのリスクの重要度によって、どの対応策を取るか決めることになります。例えば” 震災が発生し開発拠点が被害を受ける”というリスクに対しては、”受容”という判断でプロジェクトを中断するという選択をするかもしれませんし、社運を賭けたプロジェクトなので止められないという場合は支社や他の施設に開発拠点を移動させるという選択もあるでしょう。

　重要なプロジェクトであればあるほど、事前にリスクを漏れなく抽出、認識し、それらに対して対応策を十分検討し、いわゆる見える化をしておいて、プロジェクトの過程でどの様なことが起きても右往左往せず冷静に対処できる様にしたいものです。皆さんは、リスクの見える化、できているでしょうか。

　最新の提言を、メールマガジン(無料)で配信しています。是非ご登録ください。