ひとつ、思考実験をしてみます。
まったく同じ企画を、2つのチームがそれぞれ事業化を目指しています。
企画は「製造業の保全部門向けに、紙で残っている設備の点検記録をデジタル化し、故障の予兆をつかめるようにするサービス」です。違うのは進め方だけです。
どちらが先に出口（撤退・ピボット・移譲など）を意思決定できるでしょうか。
Aチーム
まずは市場調査から入りました。市場規模のレポートを集め、競合サービスを一覧にし、事業計画書に落とし込みます。並行してプロトタイプの開発に着手し、展示会への出展も決めました。毎週の定例では、資料のアウトプットも増え、動くようになっていくデモが作られています。
Bチーム
まずは企画を成立条件に分解するところから入りました。
- 保全部門は点検記録の紙運用に困っている
- その困りごとには予算がつく
- 予兆がつかめれば、現場は動き方を変えられる
いずれかが成立しないなら方向性の修正が必要、反証が出なければ当初の仮説があたっていたと言えるだけ、という考え方です。
考え方1つで判断までの効率に大差が生まれる
Aチームの進め方は、一見それらしく見えます。調査も、資料も、開発も、事業開発でイメージされる活動そのものだからです。ですが、それらしい活動が積み上がることと、事業に近づくことは別物です。
半年が経ち、資料は立派になり、デモは滑らかに動きます。ですが「このサービスに顧客はお金を払うのか」と聞かれると、誰も答えられません。作ったものはたくさんあるのに、進むとも止めるとも決められない。会議の結論は毎回「引き続き検討」です。
Bチームは、最初の1ヶ月は、開発をせずに保全部門の担当者10人に会いに行きました。会う前に「10人中◯人が、紙運用を自分の言葉で困りごととして語ったら次へ進む」と決めてあります。プロトタイプは、画面を印刷した紙芝居で足りました。
3ヶ月もすると、Bチームは「課題は実在するが、予算の出どころが想定と違う」ことをつかみ、売り先を変える判断をしました。
Aチームの進め方でうまくいって結果よかったとしても、偶然の産物になってしまいます。一人ひとりがさまざまな案件を取り扱う中で、できるだけ最高効率で進み続けるには、確かめられる部分は確かめ、賭けの範囲を減らしていく必要があります。
アウトプットをまとめて進んだ気になったり、検証を軽視して進んでしまったり、無意識の前提に基づいてしまったりすると、それらは後から補うことのできない問題として襲いかかってきます。
差は、意思決定が起きているかどうか
2つのチームの差は、能力でも熱意でもありません。不確実な企画の可能性を判断するためにアクションプランを設計できているかどうかです。
なぜAチームは決められないのでしょうか。
これは詰めが甘いからではなく、「何が確認できたら決められるのか」を先に設計していないからです。これは個人の資質ではなく、進め方の問題です。同じ進め方をすれば、誰がやってもほとんど同じ状態に落ちます。
例えば、先述の「保全部門は点検記録の紙運用に困っている」を成立させる条件が「10人中◯人が、自分の言葉で困りごととして語る」なら、どう検証をすべきかはおおよそ決まってきます。検証自体の工夫はあれど、結果としては、成立したかしなかったか、だからこう言える、だけです。
判断材料が何であるべきかを考え、判断材料を作り出すことをしなければ、どれだけ丁寧でスピードがあっても検証ができません。
そして、判断ができず、開発が進まないのです。
事業開発とは、検証の連続にすぎない
前述までの主張をまとめると、
- 事業開発を進めるためには、最高効率での判断が必要
- 判断をするためには、適切な検証が必要
となり、言い換えると、事業開発とは検証の連続であると言えます。
事業開発と聞くと、プロダクトを作る、計画を作る、売り先を作る、など何かを作り出すことを想像されがちですが、それらは手段に過ぎません。
顧客も課題も解決策も、どれも「かもしれない」の仮説です。
この企画の成立条件は何か？必要十分か？、と思考を巡らせ、一つずつ検証することで、不確実性が減っていき、「こういう建付けで、こういう売り方で、こういう機能があれば売れる」という事実ができあがっていきます。
もともと描いていたロマンあるトップラインからは遠ざかっていくかもしれませんし、全然別の商材になっていることもあるでしょう。
しかし、この企画の可能性を確からしくしていく（＝無数の可能性を閉じていく）検証ループの先にのみ、事業と言えるものが生き残るのです。
作ることは、このループを回すための手段のひとつです。プロトタイプも資料も、確かめたい前提に答えを出すために作ります。
本書が、特別なフレームワークやスキルを前提にしていないのは、事業開発に重要なのが「事業開発が検証の連続であるという理解」だからです。何をどう検証すべきか、によってどんなフレームワークを用いるか、その場その場で調べながら使えばいいのです。
検証の正しさより十分な材料を作れるか
研究の世界では、検証は必須のプロセスと言えます。
いかなる理論も、仮説があり、どう言えれば仮説が正しいと言えるか成立条件を立て、それらを確かめるために検証をします。
さらには論文という形で掲載するには、第三者が追試できる形で記録します。
属人的な手応えや実験環境への依存、観察者の解釈ではなく、誰が見ても同じ結論に至れる・再現するから、理論として認識されるようになります。
このプロセスは、事業開発における検証と何ら変わりがありません。
ただ、研究の世界でも予算や制約があるように、時間も予算も会える顧客の数も限られています。無限にリソースを使えるなら検証方法の選択肢も増えるものですが、事情や都合と背中合わせなのです。サンプルを十分に取ったり、論理的に絶対正しい状態を作るのは難しくなってきます。
大切なのは、論理的な正しさそのものより、判断材料として十分か、です。
もちろん、正しい状態に近いほど良いですが、それには時間がかかる以上、Quick & Dirty（クイックアンドダーティー） が重要です。
例えば、AとBが成立している必要がある時、以下のような分類にできます。
- AとBが100%検証済み：時間がかかりすぎる
- どちらも50%検証済み：Quick & Dirty
- Aは100%、Bは検証なし：単なるモレ
サンプル数やプロトタイプの完成度などに置き換えるとわかりやすいと思います。崩してよいのは検証の精度であって、検証項目ではありません。
検証デザインの三原則
これらの思想に基づいた検証デザインでは三原則に集約されます。
- 完了条件を、検証方法より先に決める — 「どう検証するか」より先に、「何が確認できたら検証済みとするか」を決めます。順序を逆にすると手段が目的化し、インタビューを10件やること自体が計画になります。完了条件が先にあれば、手段は後から自由に選べます。
- 最大の不確実性から順に潰す — 着手しやすい論点からではなく、外れたら計画全体が崩れる前提から検証します。「顧客は本当に困っているか」「法対応が必要か」など、そもそも考えたこともなかった暗黙の前提に潜んでいます。
- バイアスチェックと反証性 — 聞きたい答えに誘導する質問、都合のよいサンプル、解釈の余地が大きい観察は、ただのでっち上げです。あえて自分の仮説を疑ったり、揚げ足を取ってみることから始まります。
ただし、どんな計画にも穴はあるため、穴探しを差し戻しの根拠にすると、理論上すべての計画が差し戻せてしまいます。検証結果を見てリスクを認識して合意することで、議論は「穴があるか」ではなく「合意した基準の内側か外側か」に変わり、どちらでも前進できるようになります。
三原則の本質は、何が確認できたらゴールなのかを、着手より先に想像しきること。次章すべての根本となるスキルで、その中身を手順に分解します。