「それって、リスクがありますよね」。
「その前提、確実なんですか」。
新規事業の会議でよく出る言葉です。そして、この一言が出ると会議は止まりがちです。反論のしようがないからです。たしかに分からないことだらけですし、「いや、確実です」と言い切れる人もいません。結論は「引き続き検討」になります。
止まる理由は、言葉の使い方にあると考えています。この場面で「リスク」と呼ばれているものの多くは、正確にはリスクではありません。性質の違う2つのもの、リスクと不確実性が、混ざったまま議論されています。
本コラムでは、この2つを区別するところから始めます。リスクにつける結論と、不確実性への打ち手は別物で、混ぜたまま議論すると止まり、分けると進みます。用語解説として、検証と不確実性の関係、検証できない不確実性の扱い方、そして「リスクがありますよね」と言われる前の備えまで整理します。
リスクは分かっていること、不確実性は分かっていないこと
区別はシンプルです。
リスクは「分かっていること」、不確実性は「まだ分かっていないこと」です。
リスクの論点は、それを取れるか、許容できるかに絞られます。例を挙げます。B2Bの商材で従量課金を採用すると、利用量が事前に読めないぶん、顧客側は予算を確保しづらくなります。追加の稟議が必要になる場面も出てくるでしょう。この「買いづらさ」は、分かっていることです。分かった上で、それでも従量課金の柔軟さを取るのか、買いやすさを優先して定額にするのか。これはリスクの判断で、「リスクはあるが採用する」「このリスクは取れない」と結論づけられます。
一方、企画したソリューションがお客さんに刺さるかどうかは、企画段階では誰にも分かりません。これが不確実性です。取るか取らないかを議論できる対象ではなく、そもそも判断の材料がない状態です。だから打つ手は、検証になります。
この区別には古典があります。経済学者のフランク・ナイトは、1921年の著書『リスク、不確実性、利潤』で、確率を見積もれるものをリスク、見積もりようがないものを不確実性と呼び分けました（Knight, 1921）。リスクは保険を掛けるなどして処理できるが、不確実性はできない。だからこそ、不確実性を引き受けることが利潤の源泉になる、という議論です。「分かっている・分かっていない」という本コラムの言い方は、この整理を実務の言葉に置き直したものです。
リスクには、発生確率がついている
ナイトの線引きのとおり、リスクの側には発生確率があります。確率を見積もれることが、リスクをリスクたらしめている条件だと言ってもよいくらいです。
発生確率1%でも、リスクはリスクです。ただ、1%のリスクとは、裏返せば99%の確度でもあります。それを「リスクがある」の一言でくくると、99%の側の情報がそっくり落ちます。発生確率30%の話と1%の話が、同じ「リスク」という言葉で同じ重さに見えてしまいます。
冒頭の「リスクがありますよね」が会議を止めるのは、確率がまだ議論に載っていないからでもあります。リスクを口にするときは、どのくらいの確率で起きる見立てなのかをセットにする。それだけで、「リスクだらけだ」という総括が妥当なのか、確率の小さい話を並べて大きく見せているだけなのかを、切り分けられるようになります。
検証は、不確実性を「分かっていること」に変える
2つは固定した分類ではありません。ただ、よく言われる「検証すれば不確実性はリスクに変わる」は、少し不正確だと考えています。検証が直接つくるのは、リスクではなく「分かっていること」です。
従量課金の例で追ってみます。「従量課金でも買ってもらえるか」は、企画段階では誰にも分からないこと、つまり不確実性です。そこで見込み顧客10人に当ててみたところ、3人が「従量課金だと予算が読めないので、稟議を通しにくい」と答えたとします。この時点で手に入ったのは、「サンプル上、30%の確率で受注できない可能性がある」という事実です。検証が運んでくれるのは、ここまでです。
これがリスクになるかどうかは、次の意思決定で決まります。このまま従量課金で進むと決めるなら、先ほどの事実は「発生確率30%で受注を逃すリスク」になります。30%を承知の上で取る、という判断は十分ありえます。残りの7割には刺さっているわけですし、リスクをまったく取らない事業開発はありません。
一方で、対策を打つ道もあります。たとえば従量課金のほかに、事前パッケージ購入と完全定額を加えた3つの料金パターンを用意し、顧客に選んでもらう形にする。筋の良さそうな打ち手です。ただし、「料金パターンを増やせば30%の壁は越えられる」という見立ては、まだ検証していない対策仮説です。つまりそれ自体が、また分かっていないこと、不確実性に戻っています。だからもう一度、検証の出番になります。
不確実性は検証されて「分かっていること」になる。そのまま進むならリスクとして許容を判断し、対策を立てるならその対策仮説がまた不確実性に戻る。事業開発は、この循環を回し続ける営みなのです。
不確実性の測り方（中身と大きさ）
検証の対象になる以上、不確実性は「なんとなく不安」のままにせず、分解して測れる形にしておきたいところです。中身と大きさという2つの顔で捉えられると考えています。
中身は、まだ答えの出ていない成立条件の集合です。成立条件とは、ある仮説が成り立つために1つでも欠けてはならない条件を指します。
例を挙げます。設備保全向けのSaaSを企画しているチームが、「保全部門は点検記録の紙運用に困っている」という仮説を置いたとします。この仮説が本当に成立しているなら、それを支えているはずの条件を並べられます。
- 転記に実時間が割かれている
- 転記ミスや記録の欠落で、業務に実害が出ている
- 解決に資源を割く意思がある
- 解決の優先順位が、先方の課題リストの上位にある
企画の初期には、どの条件にもまだ答えが出ていません。この状態が、「この案件は不確実性が高い」の中身です。
大きさは、期待値の分布の幅で表せます。探索中の案件の価値は、「3年後に売上◯億」という一点の予測では捉えられません。答えの出ていない条件が残っている以上、どこかの条件で止まる未来も、すべて成立して大きく展開する未来もありえるからです。そこで、悲観から楽観までのシナリオを幅で持ち、どのシナリオがどれくらい確からしいかという分布で捉えます。答えの出ていない条件が多いほど、ありえる未来の幅は広くなります。
検証が1つ進んで条件が閉じると、その条件で止まるシナリオが消え、分布の幅が狭まります。検証とは、不確実性を下げる行為です。売上が1円も立っていなくても、幅が狭まっていれば案件は前進しています。
この「分布の幅」は、案件を評価する物差しにもなります。検証を重ねても分布が動かない案件をどう検知し、どう扱うかは、ハンドブックのゾンビ化とは何かで扱っています。仮説を成立条件に分解し、モレとムダを検査する手順そのものは、すべての根本となるスキルで動作レベルまで落としています。
検証できない不確実性がある
ここまでは、検証できることを前提に話してきました。ですが、すべての不確実性が検証で潰せるわけではありません。
たとえば新しいサービスを企画したとき、「ビッグテックが同じ領域に参入してこないとは言えない」。これは紛れもなく分かっていないことですが、確かめる方法がありません。参入の意思を先方に聞くわけにもいきませんし、仮に聞けたとしても、未来の意思決定は変わりえます。
だから、「全部検証してからでないと進めない」は成り立ちません。検証できない不確実性は、「分かっていないまま進むリスク」に読み替えて、許容できるかどうかに結論をつけます。先ほどの循環でいえば、検証を経ずに許容の判断へ直行させる扱いです。あわせて、なぜ検証できないのかを説明できる形にしておきます。理由まで言語化されていれば、あとから「詰めが甘かった」という話にはなりませんし、この言語化は終盤で扱う想定問答の材料にもなります。
不確実性は、暗黙の前提に隠れている
検証できる不確実性は、どこを探せば見つかるのでしょうか。分かりやすいのは仮説の本体ですが、見落とされやすいのは、仮説が乗っている暗黙の前提のほうです。
先ほどの設備保全SaaSの例で言えば、「保全部門は点検記録の紙運用に困っている」を検証しようとすると、目は「困っているかどうか」に向かいます。ですがこの仮説は、「保全部門が紙で運用している」こと自体を、確かめる前から事実として扱っています。その前提が客観的な事実かどうかは、意外と危ういものです。設備メーカーの標準アプリで、すでにモバイル入力への移行が進んでいる業界かもしれません。
こうなりがちなのは、注意力の問題ではありません。心理学者のウェイソンは、参加者に数列の法則を当てさせる実験で、人が自分の仮説に合う事例ばかりを試し、仮説が崩れるかもしれない事例をほとんど試さないことを示しました（Wason, 1960）。確証バイアスと呼ばれる傾向です。仮説を確かめようとするとき、人は仮説が成り立つ世界の証拠を集めに行き、前提そのものを疑う問いは後回しになります。
だから、不確実性の洗い出しは「この仮説は正しいか」だけでは足りません。「この仮説が成り立つために、事実だと決めつけているものは何か」まで問い直して、初めて暗黙の前提が不確実性のリストに載ってきます。
洗い出しには、道具がある
とはいえ、確証バイアスに素手で立ち向かうのは分の悪い勝負です。洗い出しには、使える道具があります。
ひとつめはプレモータム（pre-mortem）です。認知心理学者のゲイリー・クラインが提唱した手法で、計画の段階で「このプロジェクトは失敗に終わった」とまず仮定してから、失敗の理由をチーム全員で挙げていきます（Klein, 2007）。順番を逆にしただけに見えますが、効き目には根拠があります。クラインが引いている1989年の研究では、出来事がすでに起きたと想像してから理由を考えると、将来の結果の理由を正しく挙げられる割合が30%高まりました。確証バイアスは、仮説が成り立つ世界の証拠を集めに行く癖でした。プレモータムは先に「成り立たなかった世界」へ立たせることで、その癖の向きを反転させます。やり方は簡単で、企画を説明したあとに「1年後、この案件は撤退が決まりました。なぜでしょうか」と問うだけです。失敗の理由を挙げることが全員の宿題になるので、言い出しにくかった暗黙の前提が口に出やすくなります。
ふたつめは仮説マッピング（assumptions mapping）です。デイビッド・ブランドらが著書『Testing Business Ideas』で整理した手法で、洗い出した前提を「重要度」と「根拠の量」の2軸に並べます（Bland & Osterwalder, 2019）。検証すべきは、案件の成立にとって重要なのに根拠がほとんどない前提です。プレモータムで出てきた失敗理由をこの2軸に置けば、どの不確実性から検証するかの順番まで決まります。全部を検証するリソースはありませんから、この順番づけが実務では効きます。
「リスクがありますよね」と言われる前に
もう一度、冒頭の場面に戻ります。会議で「リスクがありますよね」と言われたとき、その場で仕分けを始めても間に合いません。指摘されたものが分かっていることなのか、検証できる不確実性なのか、検証できないものなのか。この判断には検証の設計や事実の確認が要るので、会議の数分でこなせる仕事ではないからです。
備えは、事前にやっておくしかありません。論点ごとに、検証できるものは「こう検証した」あるいは「こう検証する予定だ」、検証できないものは「こういう理由で検証できないので、発生確率をこう見立てて、このリスクとして許容したい」と説明できる状態を作っておきます。ここまで整理してあれば、指摘のたびに会議が止まることはなくなります。返す材料が手元にあるからです。
実務的な感覚も添えておきます。会議に完璧な設計を持ってくる人は、実はそれほど多くありません。差がつくのは設計の完成度そのものより、疑問にどれだけカウンターを返せるかです。検証できない不確実性は、挙げようと思えば無限に挙げられますから、全部に備えることはできませんし、その必要もありません。事業判断をする人が聞きそうな問いには限りがあります。本当に売れるのか、競合が来たらどうするのか、なぜ自社がやるのか。よく聞かれる問いに絞って、想定問答をあらかじめ用意しておけば十分です。
手元の案件で仕分ける
まとめます。リスクは分かっていることで、発生確率とセットで捉え、許容できるかに結論をつける対象です。不確実性は分かっていないことで、検証できるものは検証して「分かっていること」に変えます。分かったことを抱えたまま進むと決めれば、それはリスクになります。対策を立てるなら、その対策仮説はまた不確実性に戻り、次の検証が始まります。検証できないものは、分かっていないまま進むリスクに読み替えます。
とはいえ、自分の案件の暗黙の前提を自力で洗い出すのは、確証バイアスがある以上なかなか難しい仕事です。そこで、普段お使いのAIチャットに頼める形のプロンプトを用意しました。最初にこのコラム自体を読み込ませるので、リスクと不確実性の枠組みを共有した状態で仕分けが始まります。
出力を眺めるときは、手順3の「暗黙の前提」と手順5の想定問答に注目してください。「言われてみれば、確かめていない」が1つでも出てきたら、洗い出しは前進しています。手順5の下書きは、そのまま会議前の備えに使えます。
洗い出したあとの動きは、循環に沿って回すだけです。不確実性は、検証して分かっていることに変えていく。リスクは、発生確率を見立てた上で、許容して進めるかどうかへ結論をつける。「リスクがありますよね」で止まっていた会議は、「この確率のリスクを取るか」を決める会議に変わります。検証の設計と進め方は、ハンドブックの事業開発の進め方から読み進めていただけます。