これはなに
こんにちは、レバテック開発部のもりたです。
今日、唐突に「リスク管理と不確実性管理は別物だ」ということに納得がいきました。前々からプロジェクトマネジメントの文脈などでそういう言葉は聞いていつつも話半分に思っており、いや一緒でしょ...と思ってたんですが、いやこれほんまに別物です。
今回は自分みたいに「いや一緒だが？？？」と思っている方に向けて、何が違うのか説明します。
構成
構成
以下の流れで説明します。
- 一般的な定義
- 管理方法の違い
- 目的の違い
- まとめ
リスク管理と不確実性管理は別物
一般的な定義
さてここからリスク管理と不確実性管理の違いについて整理していきますが、それに先立って議論の前提を整えるために一般的な定義を示しましょう。
経済学者のフランク・ナイトによると、それぞれ以下の通りになります。
- リスクとは、将来、価値ある何かを手に入れたり失う可能性があること。これに対して、不確実性とは、将来の出来事について定かでない状態。
- リスクは、理論的なモデルを当てはめたり、測定したり、定量化できる。逆に不確実性は、予測できず、定量的に測定できない。
- リスクは、起こりうる結果の確率を求めることができるが、不確実性は、結果のランダムさを確率で表すことができない。
上記を読んで、意味が分かりますか？ 自分は分かりませんでした。字面は理解できるんですが、その不確実性がある時点でリスクでしょ、と感じて具体的にどのような違いがあるのかピンときませんでした[1]。
また「プロジェクトマネジメントは不確実性管理だ」というような言説にも納得がいきませんでした。リスク管理と言われれば「あらかじめ不測の事態を予測し、備えておくんだな」と理解できるのですが、なぜリスク管理とは言わずに不確実性管理と表現するのか理解できませんでした。
ただその後、いくつかプロジェクトを担当するようになり、夜中[2]にプロジェクトのスケジュールを更新していたとき、急に「あリスク管理と不確実性管理って全然違うわ！！！」と気がつきました。
異なるのはその管理方法と目的です。そして、目的を考えたとき、たしかに不確実性管理の方が重要だといまは感じています。
以下に説明します。
管理の違い
リスクと不確実性は管理方法が異なります。
まずリスクはあらかじめ予測し、前もって対処することで解決します。たとえばスケジュールの遅延を見込んでバッファをつんでおくとか、人員の不足を見越して確保しておくとか、そういう感じです。
一方、不確実性はなにが起きるか分からず、対処のしようがありません。ではどうするかというと、前に持ってくることで対処します。
たとえばあるタスクがどの程度で終わるか分からないとき、とりあえず時間を区切って着手し、どんなもんなのか把握する、みたいなのが対処にあたります。分からないなら、最小工数でやってみて、明らかにするというような考え方です[3]。
この考え方を知らないと、プロジェクトを管理していても思わぬ爆弾がいたるところで爆発してスケジュール遅延を何度も起こすことになりがちです。
もりたも初めて担当したプロジェクトでめちゃくちゃな遅延を起こしたのですが、いま思うと不確実性の管理ができていなかったなと感じます[4]。
目的の違い
そして、目的も違います。この目的の違いが面白いんですけど、不確実性管理は「話を前に進めるために」行います。
どういうことでしょうか？ これはAの結果次第でその後の道が別れる、みたいな時に、早くAを確定させましょうという話なんですが、まあとりあえず具体例をいくつか出して説明します。
プロダクトのニーズが分からない
- プロダクトが世間に必要とされているか分からなかったので、とりあえずスプレッドシートで同様の機構をサクッと作ってリアクションを確認した
- 必要とされているか？ という人間の気持ちが不確実性
- それを確定させるために、雑に作って確認している
- 確定のさせ方は自由で、例えばモックで営業してみるとかも良い。ここはより前に持って来れて、計測の確度が高いものほど良いはず
見積もりが正しいか分からない
- 本当に作れるか分からずスケジュールの不確実性が高かったので、とりあえず時間を区切って作ってみた
- 本当に作れるか？ 工数が肥大化しないか？ が不確実性
- サクッと作ってみて確定させている
機能修正の影響範囲が分からない
- この修正は影響範囲が大きくて、不確実性が高いのでやめた方がいいと進言した
- どこに影響するか分からない、が不確実性
- ここでは不確実性が高いのでやめている。これは不確実性を確定させられてないので、管理できていない
- ただ、リスク管理としては一つのやり方ではある
障害の原因がどこか分からない
- 障害が発生したが、現状のログではAとBのコンポーネントどちらが問題なのか分からない。なので問題の切り分けとしてAとBの境界までリクエストが飛んでいるか確認した
- どちらのコンポーネントなのか？ が不確実性
- どちらなのか？ を確定させて対処している
大事な試験の日に寝坊しそう
- 明日は大切な試験の日だが、予定時刻に起きれるかわからない。なので目覚まし時計を二つ用意した
- 起きれるかどうかが不確実性
- 大事な試験は一度きり。不確実性を確定させたときに失敗してしまうと困るので、失敗しないような対策を立てている。これはリスク管理
- 次に進むために行うのが不確実性管理なので、次（今回なら寝過ごした状況）に行っちゃうと困る場合は使えないこともある
- 目覚まし時計で本当に起きれるかどうかを試験の一週間くらい前から試してみる、というのは不確実性管理
繰り返しになりますが、重要なのは不確実性は「話を前に進める」ために行うという点です。不確実性を前に前に持ってきて、状況を確定させることが求められます。前に持ってこれない場合、寝過ごすかもしれないと不安になりながら目覚まし時計を何個もセットすることになります。
また、どの不確実性に対処しているのか？ を考えるのも大切なんだろうなあと思います。スケジュールの不確実性だけに対処するのではなく、そもそもユーザーニーズに関する不確実性を低くできているか？ を考えるなど、自分がどの不確実性に対処しているのか振り返る機会をもっても良いかもしれません。
おわりに
最後にこれまでの内容を整理しておきます。
| リスク管理 | 不確実性管理 | |
|---|---|---|
| 目的 | 備える | 話を前に進める |
| 管理方法 | 避けようのないリスクを見越し、事前に対処する | 不確実性を特定し、即座に確定させることで次の手を考える |
このような感じです。
今まで、ゴリゴリと仕事を進める人たちを見て、彼/彼女らは「未来が見えるから進める」んだと思っていました。ただ不確実性管理がなんなのか理解したいまは、「分からないからこそ進むことができる」のだと理解できます。
ここで重要なのは「分からないことで悩んでも意味がない」ということではありません。悩んでも意味がないのはそうなんですが、不確実性はネガティブなものではなく、もっと歓迎すべきものなのだと考えています。プロジェクト管理やプロダクトマネジメントは、不確実性を突き止めて確定させるゲームなのです。自分が不出来だから分かんないんだと思ってたけど、そこは重要ではなかったのです。
唐突に理解したので、唐突に書きました[5]。
参考文献
- リスクと不確実性の違い：Risk and uncertainty
-
エンジニアリング組織論への招待
- 副題が「不確実性に向き合う思考と組織のリファクタリング」。IT分野で不確実性について言及されるときはこの書籍での定義や論調が前提とされやすい
Discussion