あなたがシステム開発プロジェクトにおいてリスク管理を担当した経験があるなら、ふと手を止めてつぶやいたことはありませんか？
「これ、どこまでやるの？」
リスクとは「不確実性」のことです。そう考えると、世の中のすべての事柄にはリスクが存在します。
朝起きること、職場に定時につくこと、取引先にメールを送ること。
これらの行動にともなうリスクは、リスク風に言い換えるだけで簡単に洗い出すことができます。
「朝起きられないリスク」「職場に定時につかないリスク」「メールが送信できないリスク」という具合です。
さらに、すべての事柄は構成要素に細分化できます。
たとえば「職場に定時につく」という行動は、靴を履く、家を出る、駅まで歩く、電車に乗る、という細かな行動に分けることができます。
そしてその行動ごとにリスクを見つけることができるのです。
リスクを考えるということは対策を考えることに他なりませんが、大きな粒度のリスクでは効果的あるいは網羅的な対策を考えることができません。
「職場に定時につかないリスク」といったとき、実際は朝起きられなかった、家にスマホを忘れた、電車が止まった、など複数のリスク因子があります。
これらのリスク因子への対策はそれぞれ異なります。
ですから、リスク因子は細かく洗い出すに越したことはない。それは誰もがわかっているはずです。
わかっているのにできない、やらないのはなぜでしょうか。
洗い出せば出すほど手に負えなくなる現実
多くのプロジェクトは、リスク因子ごとに影響度と発現率とでリスク度合いを評価し、対策を考えるというリスク管理を行っているかと思います。
リスク管理の教科書にも必ず登場する基本的な手法です。
当然ながら洗い出したリスクの数だけ時間がかかります。
そのため、リスク管理担当者は、洗い出せば洗い出すほど評価するための時間が増えて手に負えなくなってくるというジレンマに陥るのです。
プロジェクト開始時には意気込んでどこまでも細かくリスクを洗い出しがちですが、その結果、それぞれのリスクを評価し、対策を考えなければならない。
リスク管理担当者の作業負荷は際限なく増えていきます。
システム開発においてリスクを「どういう粒度で洗い出してよいか迷う」というのはこういうことです。
細かく洗い出すべきだとわかっていても、どこかで折り合いをつけなければならないという現実があるのです。
「切り口」と「アプローチ」で構造化する
リスクは具体的であればあるほど対策も具体的になるので、細かく洗い出すべきです。
それはわかっているのだが、どこかで折り合いをつけなければならない。
そんなときに有効なのが、「切り口」と「アプローチ」を意識した洗い出しです。
カテゴリと工程で切り分ける
「切り口」というのは、カテゴリと工程で切り分けて考えるということです。
まず「カテゴリ」です。
システム開発を取り巻く森羅万象すべてはリスクですから、漫然と洗い出していては尽きることはなく、また粒度もまばらで網羅感がありません。
おそらく皆さんも自然と実践しているように、何らかのカテゴライズをする必要があります。
たとえば組織、人材、採用技術、外部環境のように枠を決めて、そのカテゴリごとに洗い出す。
こうして切り出すことにより考えが構造化され、ある程度の粒度感が保ちやすくなります。
このカテゴリについては、別の機会に詳しく取り上げたいと思います。
※考える時間がない、リソースがないから、もっと手軽にクイックにリスクを洗い出したいという方には、「接合点に焦点」をあてるというアプローチもおすすめです。
詳しくは以下のJQ NOTEを参照ください。
プロジェクト開始時のリスク抽出が形骸化する理由
カテゴリごとに洗い出すということをしても、「なぜなぜ」と深掘りしていけば、どんどん細分化していくことができてしまいます。
ここで有効なのが「工程」の切り出しです。
数か月で終わるプロジェクトであれば別ですが、数年に及ぶような大規模なプロジェクトでは、はるか先のリリースまでのリスクを一度に洗い出そうと思ったら時間がいくらあっても足りません。
また洗い出したところで「ようすをみる」といった選択肢しか取りようがない場合が多く、工数対効果に合いません。
これまで述べた通り、広く薄く大ぶりなリスクを洗い出すことは具体的な対策につながりづらいのです。
それならば、直近の工程に範囲を絞り、その範囲を重点的に深掘りするほうが大いに有効です。
ブレイクダウンとボトムアップを使い分ける
続いて「アプローチ」というのは、ブレイクダウンアプローチか、ボトムアップアプローチをとるかということです。
ブレイクダウンアプローチは、大きなものをさらに小さなものへ分割していくアプローチです。
前述の「職場に定時につかない」というリスクを例にすると、朝起きられないリスク、スマホを家に忘れるリスク、電車が遅延するリスクというように、さらにその原因となりうるリスクにどんどんと細分化していくということです。
この考え方に慣れると効率よくリスクを洗い出していくことができます。
一方でこれもまた際限なくブレイクダウンしていくことも可能なので、ある程度で割り切って打ち切る必要があります。
もうひとつのボトムアップアプローチは、実際の経験や知識から具体的なリスクを取り上げていくというものです。
システム開発では不思議といつも同じところで問題が顕在化します。
そのため採用技術や業界などの前提条件が共通する過去プロジェクトがあれば、そこでの失敗例はリスク管理の有用なインプットとなります。
ただし、網羅感がどうしても乏しいので、小規模なプロジェクトでかける時間もコストもない場合は別として、ブレイクダウンアプローチへの補強として採用するのがよいでしょう。
影響度×発現率×コントロール可否で絞り込む
ここまで洗い出し方について述べてきましたが、次は絞り込みについてです。
丁寧な仕事をする人であればあるほど、網羅的にリスクを洗い出すと抑制気味にしたとしても相当数のリスク件数になることでしょう。
それでも潤沢な時間と手数があればいいのですが、リスク管理にそこまでコストをかけられるプロジェクトが少ないというのが実態です。
このため洗い出したとて、必要性の低いものは切り捨てていく必要があります。
このときに「影響度×発現率×コントロール可否」で採用要否を判断します。
リスク管理のセオリーとしては、影響度×発現率で評価するというのは聞き慣れているのではないかと思います。
「影響度」は起こった時の深刻さであり、「発現率」はそのリスクが顕在化する確率のことです。
極端なことをいえば、起こっても影響が軽微すぎてどうでもよいこと、めったに発生しないことは放っておこう、と考えます。
職場に着くまでのリスクとして、靴の紐がほどけることは結べばよいのでどうでもよいですし、大きな風呂敷を背負って階段の前で立ち往生するおばあさんに出会うのはめったに発生しないことですので、考えるリストにあげることすら時間の無駄です。
こうして取り扱うべきリスクを取捨選択しますが、ここに加えたいのが「コントロール可否」です。コントロールできないものは考えても仕方ない、ということです。
また職場に着くまでのリスクを例にとると、大地震が起こる、行く手のビルで火事が起こる、ということはリスクはゼロではありませんが、我々がどうこうしようがリスクを上げ下げできませんし、起こった影響を避けることも困難です。
思考停止しないための注意点
この絞り込みを実践する上で、重要な注意点があります。
「コントロールできない」と早々に思考停止してしまわないことです。
あくまでプロジェクトが停止するような破壊的な影響を伴うようなリスクだけを省くようにしてください。
たとえば、「ベンダーのキーマンが急に退職する」というリスクは、完全にコントロールできないわけではありません。
定期的なコミュニケーションや契約条件の工夫、知識の共有体制の構築などで、発現率を下げたり影響度を軽減したりすることは可能です。
「どうしようもない」という判断は慎重に行う必要があります。一見コントロールできないように見えても、発現率を下げる対策や、影響を軽減する対策が取れる場合が多いのです。
また、工程を区切ってリスク洗い出しを行う場合、工程が進むたびに改めてリスクを見直すことも重要です。
直近の工程に絞り込んで深掘りするということは、次の工程に進む際には改めて洗い出しを行う必要があるということです。
一度洗い出したら終わり、ではなく、継続的な活動として位置づけることが大切です。
リスク洗い出しは構造化と割り切りの両立
リスクを認識すること自体が重要ですが、これに対してどうするべきかを考えること、これを継続することが、より重要です。
リスクの洗い出しで「どこまでやるの？」と手が止まってしまうプロジェクトは、粒度の判断基準を持たないまま漫然と洗い出しを進めようとしています。
「切り口」で構造化し、「アプローチ」で効率化し、「影響度×発現率×コントロール可否」で絞り込む。この3つの視点を持つことで、限られた時間とコストの中で実効性の高いリスク管理が可能になります。
完璧な正解はありません。
しかし、構造化と割り切りを両立させながら、プロジェクトの現実に即したリスク管理を実践する姿勢こそが、プロジェクトを成功に導く重要な要素なのです。
