仮説を見出だし、仮説を検証する
東北グロースアクセラレータや、スタートアップブートキャンプなど、スタートアップを成長させるためのアクセラレータープログラム、あるいは大企業の新規事業創出プロジェクトにメンターやアドバイザーなどの立場で関わらせて頂いていると、起業家の皆様や、これからプロダクトを作ろうとしている方々にレクチャーをさせて頂く機会なども多くあります。
そんなわけで、たまにはレクチャー内容を抜粋してnoteに書いてみようかなと思っていまさ。今回のテーマはバイアスについて。
--
バイアスというのは日本語にするならば思い込みとか偏見とか、そのあたりの言葉になることが多いと思うのだけれど、いずれにしてもあまり良い意味としては解釈されないように思います。
しかしながら、当たり前の話ではあるものの、誰しもが多かれ少なかれバイアスを持っており、良いアウトプット、あるいは良いアウトカムを得るためには、このバイアスとうまく付き合う必要があるのです。
スタートアップとバイアス
スタートアップのファウンダー、つまり創業者は、彼らのプロダクトや、そのマーケットの未来を強く信じています。うまくいくかどうか確信が持てないようなアイディアに自分の大切な時間やお金を投資する物好きな人がどれぐらいいるかを考えれば、これは至極当然のことでしょう。
ところが、これも当然のことであり、よく知られた話なのですが、スタートアップの成功確率は決して高くありません。これは一体なぜなのでしょうか。
CBInsightsというアメリカの企業があります。彼らは、スタートアップがなぜ失敗するのかについて調べ、そのリサーチ結果を公表しています。さて、スタートアップが失敗する理由、第一位はなんだと思いますか？
詳細は上記リンク先を見ていただくのが良い哉と思うのですが、ざっくりとグラフを引用させて頂くと、下記のような感じになり、スタートアップが失敗する理由の第一位は「市場ニーズがなかった」と言うことなのです。
だけどこれって不思議ですよね。起業家たちは市場ニーズが無いと思われるプロダクトに時間やお金や情熱など、彼らの大切なリソースを注ぎ込むモチベーションなどあるはずがありません。
ここにあるギャップこそが、バイアスのもたらす怖さなのです。一方で、バイアスには悪い側面だけでなく、良い側面もあります。
例えば、現在、我々の通ってきた道には、そして我々の目の前には無限とも言える選択肢があります。何を勉強し、何の仕事をし、誰と付き合うか、どこに住むか、何を食べるか、何を着て、どこへ行き、何をするか。
無数の選択肢の中から選択をするためには、バイアスが必要不可欠であり、バイアスがあるからこそ我々は物事を決めて、前に進むことができると考えることもできます。つまり重要なのは、バイアスに気をつけることというよりも、バイアスと正しく付き合っていくことなのでしょう。
バイアスと正しく付き合うとはどういうことか。それにはまず自分自身がどのようなバイアスを持っているかを見つけ出すことが必要です。
仮説マッピング（Assumption Mapping）
バイアスを見つけ出す方法には様々な方法がありますがお手軽な方法として、本記事ではAssumption Mappingを紹介します。辞書によるとAssumptionとは「（証拠もなく）事実だと考えること」のような意味だそうです。
Assumption Mappingの手順
1. プロダクトに関する質問に答えます
2. 事実と仮説に関する情報を抽出し2x2でマッピングします
3. マッピングした結果から、バイアスを見つけます。
4. 何が事実で、何があなたの仮説かを明確にしましょう。
プロダクトに関する質問については自由ですが、例えば僕が実施するワークショップでは下記のような質問を使用しています。ただしプロジェクトのフェーズや、プロダクトの性質によって適切な質問は異なりますので、これをすべて使うというよりは、あくまでも参考にして頂くぐらいが良いのかなと思います。
想定顧客は誰ですか？
どのような問題を顧客は解決したがってしますか？
どのようにしてその問題を解決したがっていますか？
なぜ彼らはそれを解決できてないのでしょうか？
ソリューションを使った結果、顧客はどのような成果を望んでしますか？
顧客が我々のソリューションを使う理由はなんですか？
ユーザはどのように感じるだろうか？
ユーザーはこのサービスを使おうと思うだろうか？
ユーザーはこのサービスの使い方がわかるだろうか？
プロダクトのUIはどのような形状であるべきだろうか？
コンセプトやメッセージを伝えるために見た目は適切だろうか？
ソリューションを実現するにあたり、 どのような技術的課題がありますか？
ソリューションを実現するにあたり、 どのような法律や各種規制に触れるリスクがありますか？
プロダクト実現のために、どのようなスキルを持った人がチームに必要ですか？
必要な資金やリソースは十分ですか？不足している場合、どこから調達しますか？
顧客へのチャンネルはどうやって確保しますか？
顧客は我々のソリューションを継続して使いますか？
顧客は新しい顧客を連れてくる可能性がありますか？
このプロダクトは、自社のビジョンに沿っていますか？
最大の競合は誰ですか？
どのようにして利益を出しますか？
プロジェクトのステークホルダーは誰ですか？
プロジェクトにとって一番のリスクはなんですか？
プロジェクトが成功するとどのような状態になりますか？
これらの質問に答え、その結果をポストイットに書きながら2x2にマッピングしていきます。例えばこのようになるでしょうか。
このようにマッピングしていくと、どこから仮説検証に取り組んでいくべきかは明白になりますよね。そう、まずは右上からです。
なお、このワークは可能な限り、チームで実施すべきです。なぜなら、あるチームメンバーは事実だと思っていることが、あるチームメンバーからすると仮説にすぎないということもありますし、重要、あるいは重要でない度合いも人によってばらつきがあるためです。
このように、今後検証すべき項目を今一度書き出してチームのみんなの目に入るところに置くことで、チームが今後取り組むべき項目とその優先順位をすり合わせることが可能になります。
このマップは、プロダクトを開発する上で、常にアップデートしていくべきですし、Figmaなどのオンラインツールでデジタル管理するのも良い方法かと思います。
おわりに
スタートアップや新規事業創出の現場ではPrototyping、あるいはPoCなどの言葉が市民権を得ています。ところが、それらのPrototypingやPoCが、なんのためのものであるか、つまり何を検証するためのものなのか？という視点が疎かになっているケースが散見され、非常にもったいなぁと思います。
PrototypingやPoCとはいえ、それなりのコストや時間を投資しているわけですから「とりあえず作った！動いた！」ではなく、費用対効果を見据えながら取り組むことでプロダクト開発を加速させられると理想だなと思っています。
なお、余談ですが、本ワークショップを某所で実施したところ、参加者の1/3は彼らのアイディアにニーズがないことに気がついてプロジェクトを中断してしまったそうです。「そこからピボットなりできれば良いんだけどね…」と言うのは簡単ですが、これはまた別の話として。