ビジネスの仮説検証と実験の考え方 🧪 スタートアップの仮説思考 (4)

仮説思考シリーズの4つ目のスライドであり、仮説思考以外のスライドも含めた総集編的なスライドです。これまでのスライドの内容を活かしながら、良い仮説検証を行うための Tips を紹介しています。

Takaaki Umada の Web サイト

東京大学 FoundX の各種リソース

•FoundX Review - 起業家向けノウハウ情報

•FoundX Resource - 整理された記事の紹介

•FoundX Online School - 30以上の学習ビデオ教材

•FoundX Founders Program - 個室の無償提供とコミュニティ

•FoundX Pre-Founders Program - 起業準備プログラム

•FoundX Fellows Program - アイデア探しの支援プログラム

更なる文献

•MVP の作り方 🔨

•スケールしないことをしよう 👊

•解像度を高める

•カスタマーマニアになろう

•スタートアップのメトリクス

•仮説思考入門

•仮説生成力を鍛える

•仮説を選ぶ技術

•仮説思考

•イシューからはじめよ

•実践デザイン #05 「MVP の仕様」

Transcript

1. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ スタートアップの仮説思考 (4) ビジネスの仮説検証 と実験の考え方 🧪
2. 2 ビジネスにおける仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力
3. 3 ビジネスにおける仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力 （アンラーニング）
4. 今回は「仮説検証」について解説する 仮説検証は仮説思考の全体の流れの中で三つ目に位置するもの。 既に良い仮説が生成・選択できている前提で進める。 4 1. 仮説生成 2. 仮説選択 3. 仮説検証 4. 意思決定
5. 5 全体像の詳細は「仮説思考入門」で https://speakerdeck.com/tumada/jia-shuo-si-kao-ru-men-sutatoatupufalsejia-shuo-si-kao-1
6. なぜ仮説検証が重要か 7
7. Q. 8 なぜ仮説検証は重要か？
8. A. 9 学び が得られるから
9. 学びとして得られるもの：仮説の確度と新たな情報 10 仮説の 確度 新たな 情報
10. 良い学びは意思決定へとつながる 「仮説の確度」と「新たな情報」について学びが生まれたあと、 もし仮説の確度が高ければ「進める」という意思決定ができる。 11 仮説生成 (仮説探索) 仮説選択 仮説検証 意思決定 実行 もしくは 次の仮説 の検証 学びが生まれる
11. 仮説を修正・棄却する、という意思決定を行う場合も もし確度が低ければ、検証で得た情報を用いて仮説を修正して （進化させて）新たな仮説を生成する。 12 仮説生成 (仮説探索) 仮説選択 仮説検証 意思決定 仮説の修正や棄却 (仮説の進化) 実行 もしくは 次の仮説 の検証 学びが生まれる
12. (1) 仮説の確度 得られる学びの一つとして、仮説の確からしさ（確度）がある。 13 仮説の 確度 新たな 情報
13. 仮説の確からしさ（確度）は 0 or 1 ではない 15 100% 0% 仮説の確からしさ
14. 例）課題仮説の確からしさ（確度） 検証を通して自分の仮説が「どの程度確からしいか」を学ぶこ とができる。 16 100% 0% 40% お金を払う 約束を覚書で してくれた 80% 顧客が宣伝 してくれて いる 60% 想定していた 金額を払って くれた 90% 想定していた 以上の金額を 払ってくれた 25% お金を払う 約束を書面で してくれた 5% 欲しいと 言ってくれた 10% 使う約束 をして くれた 仮説の確からしさ
15. (2) 新たな情報 得られる学びの一つとして、新たな情報もある。 17 仮説の 確度 新たな 情報
16. 仮説検証プロセスを通して新たな情報を得る 確度を検証できるだけではなく、そのプロセスを通して新たな 情報や気付きを得ることができる。 THE SCIENTIFIC METHOD (AGW Falsified) by Dr. Vincent Gray 18 現象 観察 仮説 生成 実験⇒ データ データ 分析 仮説の 検証 仮説の 確認 仕組み 化 一連のプロセスの中で新たな情報が生まれる 例） • 顧客からの新たなコメント • 顧客からのフィードバック • 顧客の行動から生まれたデータ などなど
17. 新たな情報を得て仮説を洗練させる そして検証のプロセスを通して得られた新しい情報を用いて仮 説を洗練させることができる。 THE SCIENTIFIC METHOD (AGW Falsified) by Dr. Vincent Gray 19 現象 観察 仮説 生成 実験⇒ データ データ 分析 仮説の 検証 仮説の 確認 仮説の 反駁 仮説の 洗練 仕組み 化 新たな情報を用いて仮説を洗練させる
18. 20 自分の仮説では説明できない 変則的な情報 に焦点を当てること
19. 変則的な情報を得たときの良くない反応 変則的な情報を拒否する人もいるが… Chinn & Brewer (1998) An empirical test of a taxonomy of responses to anomalous data in science 21 ❌ 情報を拒否する たとえば「この製品は要らない」と言われ たときに、以下のような拒否反応をする場 合もある。ただしこれらは悪いサイン。 1. この情報は無視しよう 2. この情報は信じられるか分からない 3. この情報は保留にしておこう 4. この情報を再解釈するとこういう意味 だから問題ない
20. 変則的な情報を得たときの良い反応 新たな情報を拒否するのではなく、新たな情報で仮説を修正す るように心がける。 Chinn & Brewer (1998) An empirical test of a taxonomy of responses to anomalous data in science 22 ❌ 情報を拒否する たとえば「この製品は要らない」と言われ たときに、以下のような拒否反応をする場 合もある。ただしこれらは悪いサイン。 1. この情報は無視しよう 2. この情報は信じられるか分からない 3. この情報は保留にしておこう 4. この情報を再解釈するとこういう意味 だから問題ない ⭕ 新情報で仮説を修正する 変則的な情報を説明できるような仮説を修 正することができる。 たとえば「要らない」と言われたら、どう すれば「欲しい」と言ってもらえるかを考 えたり、「ターゲット顧客が違ったのかも しれない、別のターゲットにしてみよう」 という風に考えて、仮説を修正したり、新 たな仮説を生成する。
21. これらが学びに繋がるだけではなく… 25 仮説の 確度 新たな 情報
22. 仮説検証は自分自身のアンラーンを促して 前提や思い込みを問い直すことにも繋がる これら二つは自分のアンラーンのための情報にもなる 26 仮説の 確度 新たな 情報
23. Q. 27 なぜ仮説検証は重要か？
24. A. 28 学び が得られるから
25. A. 29 学習棄却 もできるから
26. 30 学習棄却（アンラーニング）とは 学んだことを一度忘れること 思い込みや信念をほぐして 新たな学びへの準備を行うこと
27. 32 仮説検証の結果は 私たちの思い込みや間違いを 修正するきっかけと 正しい仮説に辿り着くための 情報を提供してくれる
28. Q. 33 仮説検証の失敗とは？
29. A. 34 正しい仮説だと 検証できなかったのが失敗
30. A. 35 正しい仮説だと 検証できなかったのが失敗
31. A. 36 学びやアンラーンが少ない 仮説検証が失敗 （＝仮説の確度についての情報や新情報が得られなかった時が失敗）
32. 37 仮説検証の成否は 学習と学習棄却の量で決まる 「仮説が合っているから成功」 というわけではない （単に仮説の正しさが確認できただけなら、仮説検証の必要はなかったかもしれない＝検証自体無駄だった）
33. 41 得られた学習と学習棄却で より良い意思決定ができる 仮説が間違っているのは 常に悪いことではない😊 （※最終的には仮説も合っている必要があるが、その前に学習と学習棄却が大事）
34. 仮説検証の方法 44
35. 仮説検証の主な三つの方法 ビジネスの仮説検証においては「サーベイ・分析」「インタ ビュー・議論」「実験」と言った大きく三つに分かれる。 45 サーベイ ・分析 インタ ビュー・ 観察・ 議論 実験 一人でできる 誰かが必要 何かを作る必要
36. まずはサーベイ・分析について 46 サーベイ ・分析 インタ ビュー・ 観察・ 議論 実験 一人でできる 誰かが必要 何かを作る必要
37. (1) サーベイ・分析による検証 多くの人はサーベイや分析が足りていない。調べればすぐに仮 説検証できることも多い。 47 資料調査 仮説の一部は過去の仮説が そのまま棄却されるときも ある。 関係のある書籍は可能な限 り目を通して、できるだけ 論文なども読むようにする こと。 競合調査 既存の競合を調べてみるこ とで。多くのアイデアの場 合、同じことを考えている 人はいて、試している。 もしすでに誰かが試してい て成功していないのであれ ば、既存の競合とは違う仮 説を考える必要がある。 分析 分析だけで検証できること もある。例としては以下。 解決策の仮説の場合：どう 考えても技術的に実現不可 能なことが分かる。 市場の仮説の場合：自分の 仮説を基にビジネスのアッ プサイドを計算したときに、 スタートアップのアイデア ではないことが分かる。
38. 48 ちゃんと Google 検索するだけでも 検証力に差をつけられる 😅
39. 次にインタビュー・議論 49 サーベイ ・分析 インタ ビュー・ 観察・ 議論 実験 一人でできる 誰かが必要 何かを作る必要
40. 誰かと一緒に行う仮説検証：インタビュー、議論 各種インタビューや議論を通して仮説が検証できることもある。 作らなくてよいので比較的手軽な手法。 50 インタビュー 顧客インタビューを通して 仮説検証ができる。また専 門家インタビューをするこ とで、基本的な仮説の検証 も可能（ただし専門家であ るがゆえに見逃している点 もある）。 これらは仮説生成にも有効 な手段の一つ。 観察 顧客の様子を観察して仮説 を検証することもできる。 仮説生成にも生きてくる。 議論・壁打ち 共同創業者や信頼できる人 に話してみることで、仮説 の弱いところなどが検証で きることもある。
41. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ カスタマーマニアに なろう 顧客インタビュー・現場現物現実・顧客との同化 「カスタマーマニアになろう」 のスライドを参照
42. 最後に「実験」 52 サーベイ ・分析 インタ ビュー・ 観察・ 議論 実験 一人でできる 誰かが必要 何かを作る必要
43. 53 実験は学びが多いけれど コストがかかる 💴⏲ 「本当に実験という手段しかないか」 を見極めてから実施する （※コスト低く実験できるならさっさと実験するのもあり）
44. 実験の立ち位置 仮説思考のスライドの中で紹介した一連の流れの中で、実験は 以下の立ち位置となる。 54 現象 観察 仮説 生成 実験⇒ データ データ 分析 仮説の 検証 仮説の 確認 仮説の 反駁 仮説の 洗練 仕組み 化
45. 実験の大まかなサイクル ビジネスので実験は主にアイデア→製品→データのサイクルを 回す。 55 アイ デア 製品 データ
46. 実験の大まかなサイクルの注意点 56 アイ デア 製品 データ これらは目に見える「成果物」だけの視点 実際の私たちの頭の中で行われていることは…
47. 活動としては Build-Measure-Learn が行われている 活動としては「Build」「Measure」「Learn」が行われている。 57 アイ デア Build Learn Measur e 製品 データ
48. この BML ループをより早く回す思考が Lean Startup リーンスタートアップでは以下のような形で紹介されている。 58 アイ デア Build Learn Measure 製品 より速く構築 MVP ユニットテスト ユーザビリティテスト 継続的インテグレーション クラウド などなど より速く計測 スプリットテスト ファネル分析 コホート分析 より速く学習 顧客開発 5 つの 学び 反証可能な仮説 など データ
49. 実行時は Build から始まり、Measure から 59 実行時の流れ: B->M->L B L M
50. 計画時は「何を学びたいか (Learn)」から計画する 最初に何を学びたいかを特定する。そしてそこから学びを得る ための計測方法、そして最適なものを作る (Build) という順序。 60 実行時の流れ: B->M->L 計画時の流れ: L→M→B B L M B L M
51. 61 学びたいことをまず決める アイ デア Build Learn Measure 製品 データ
52. 62 (1) Learn のコツ アイ デア Build Learn Measure 製品 データ
53. 「今、何を学べば良いか」の解像度をとにかく高める 「意思決定のためには今どのよ うな学びや情報が必要か」につ いての解像度を高められれば、 最適な仮説検証の設計ができる。 学べば良いことについての解像 度が粗いときは、仮説の解像度 も粗い傾向にあるので注意する。 （※仮説が一般的な言明の場合 は粗い傾向にあるので注意） 63 学び 1 学び 1.1 学び 1.1.1 学び 1.1.1.1 学び 1.1.1.1.1 学び 1.1.1.1.2 学び 1.1.1.1.3 学び 1.1.1.2 学び 1.1.1.2.1 学び 1.1.1.2.2 学び 1.1.1.3 学び 1.1.2 学び 1.1.2.1 学び 1.1.2,2 学び 1.2 学び 1.2.1 学び 1.2.1.1 学び 1.2.1.2 学び 1.2.1.3 学び 1.2.2 学び 1.2.2.1 学び 1.2.2.2 学び 1.2.2.3 学び 1.2.2.3.1 学び 1.2.2.3.2 学び 1.2.3 学び 1.2.3.1 学び 1.2.3.2 学び 1.2.3.3 学び 1.2.3.4 これを学べば 事業が最も進 むはず
54. 66 「この実験で何を学びたいですか？」 という問いに明確に答えられなければ 良くない兆候 😂
55. 67 仮説や学びたいことが曖昧で 検証がうまくいかないことは かなり多い😭
56. 解像度が低いときは良い学びが得られない 68 多くの人の 「学び」の解像度
57. 何を学べば良いかの解像度をもっと高くする 何かを学びたいと思ったときは もっと解像度を高められないか 立ち止まって考えてみる。 69 本来持つべき 学びの解像度
58. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ 解像度を高める 🔬 「解像度を高める」のスライドを参照
59. 71 (2) Measure のコツ アイ デア Build Learn Measure 製品 データ
60. Measure の設計 単に計測をするだけではなく、そのあとに来る Learn がしやす いよう準備を整えておくことが重要。 72 📊 計測方法 計測方法をあらかじめ決め てから Build する。たとえ ば継続率なら継続率を確認 するツールを入れる。 なお、計測コストは十分に 低いものを選ぶ。基本的に は売り上げがお勧め。 🎯 目標設定 どの数値を達成すれば「検 証できた」と言えるかどう かを予め決めておく。例： • このマーケティング手段 で1週間で100人登録し たら、この手段の有効性 は確度は十分と見做し、 次のステップに進む • 売上100万円以上ならOK 🤝 関係者での合意 ステークホルダー（主に チームメンバー）間で、こ れらのバーを合意しておく。
61. 73 計測結果の解釈を チームで事前に 準備・合意しておくことで 後の議論が不要にできる 👍
62. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ モメンタムを死守する (2) スタートアップの メトリクス 📊 「メトリクス」のスライドを参照
63. 75 (3) Build アイ デア 1. Build 3. Learn 2. Measure 製品 データ
64. 76 Build のコツ 極力作らなくても 良い方法を考える
65. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ MVP の作り方 🔨 とにかく雑に作る「手作業型 MVP」のススメ 「MVP の作り方」のスライドを参照
66. 78 基本は 「スケールしないこと」 で Build して検証する
67. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ スケールしないこと をしよう 👊 「スケールしないことをしよう」 のスライドを参照
68. BML ループを素早く回す これらの活動を素早く回すことで、確度の高い仮説に行きつく。 80 アイ デア Build Learn Measur e 製品 データ
69. 10 回に 1 回成功するつもりで BML ループを回す 一度の実験でうまくいくことはほとんどない。この BML ループ を何度も回すことが大事。 81 Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct Ide as Build Learn Da ta Measur e Pro du ct 🏆
70. 82 何度も回すからこそ、仮説検証は 速度 が大事 （学びを得るまでの速度を最大化する）
71. BML ループのミス ミスをしないように注意して進める。 83 Learn のミス • そもそも学びたいことが 明確ではない • 顧客の発言をそのまま学 びとしてしまい、顧客の 発言の本当の ”原因”にま で深堀りできていない • メトリクスの設定を間 違って、良い学びが得ら れない Measure のミス • 何を Measure するかを 決めずに Build を始めた • 測定のコストや存在を無 視してしまい、想定以上 に時間とコストがかかる • 測定の段取りが下手で、 時間がかかりすぎている （解析ツールを後から入 れるなど） Build のミス • MVP のサイズが大きす ぎて Build に時間がかか りすぎる • 複数の目的の MVP を 作っていてフォーカスが ぶれている • Viable (実用的) である ことを低く見すぎる
72. 84 上手に実験を行うために 気を付けておきたい トレードオフ
73. 鉄の三角形（トレードオフ） プロジェクトには「スコープ」「コスト」「時間」の三つの変 数があり、どれかは下げざるを得ないことが多い。 85 スコープ 金銭的 コスト （お金） 時間
74. どの変数を制約条件にするか いずれかを制約条件にした場合、変更できるのは残り二つとな る。 86 制約条件：スコープ 必要なものをすべて作り切 る場合。 お金をどれだけでも使い （必要であれば調達し）、 時間は伸びても構わない、 という風になる。 制約条件：お金 一定のお金で行う場合。 スコープを変えたり、時間 が伸びても良い場合はこち ら。 お金が最も希少なリソース の場合はこのケースになる。 制約条件：時間 一定の時間で作れるものを 作る場合。 スコープを変えるか、お金 を大量に投入することで何 とかする。 時間が最も希少なリソース の場合はこのケースになる。
75. 87 最も重要なものを 制約条件にする
76. 88 スタートアップに 最も大切なものは 時間⌛
77. 89 基本的には 時間⌛ を制約条件にする
78. 90 次に コスト💰 を制約条件にする
79. 91 スタートアップでは スコープ を最も変えやすい
80. 92 最大限の学びとアンラーンを 最小限の時間とコストで得られる 最小のスコープを設計するのが 腕の見せ所 💪
81. 「学びの量と質」と「努力やコスト（スコープ）」 以下のように軸を二つ持ってみる。 94 スコープ （努力やコスト） 学 び の 量 と 質
82. フルスペックの製品を作る場合 「売れるかどうか」という一点において、フルスペックの製品 を作ればおそらく検証できるし、学びも多い。 95 学 び の 量 と 質 フルスペックの 製品を作る 企画している製品が「売れるかどうか」の学びを得たい場合 スコープ （努力やコスト）
83. 作る前に売る場合 作る前に売る、というスコープにすると、今すぐできる。 96 学 び の 量 と 質 製品を作る 前に売る 企画している製品が「売れるかどうか」の学びを得たい場合 スコープ （努力やコスト）
84. スコープを設定によって、小さなコストで同量の学び 両者のやり方でもほぼ同じ量の学びを得ることができる（※ただし売 れるかどうかについての学びに限る） 97 学 び の 量 と 質 フルスペックの 製品を作る 製品を作る 前に売る スコープ （努力やコスト） コストは違っても 同量の学び
85. フルスペックの製品を作ろうとして失敗することも… それにフルスペックのものを作り切れるとは限らない。その場 合、努力やコストの割に学びがほとんどないことすらある。 98 スコープ （努力やコスト） 学 び の 量 と 質 フルスペックの 製品を作ろうとしたものの… 長い時間をかけても 中途半端なものしか完成せず 学びがほとんどない というパターンは多い 😅
86. 99 「努力の量」と「学びの量」が 比例するとは限らない
87. 100 自分の持てるリソースを鑑みて スコープを設定する （スキルやお金）
88. （一定の時間内での）スコープの限界値を考える たとえばリソースも開発スキルもあれば、一定時間に作れるも のは多いのでスコープは伸ばせる。 101 開発者 お金 大 大
89. リソースが足りない場合 開発者はいるけれどお金が足りない場合は短くなる。その場合 は資金調達をしてスコープを伸ばせるかもしれない。 102 開発者 お金 大 大 大 小 資金調達をすれ ばスコープを伸 ばせるかも
90. 開発スキルが足りない場合 お金はあるけれど開発者が少ない場合もスコープは短くなる。 103 開発者 お金 大 大 大 小 小 大 開発者がいれば スコープを伸ば せるかも
91. 全部足りなければスコープを工夫して実績を作る 持っているリソースが少なければ、その範囲でできる最適なス コープを見つけて、実績を作ってから開発者やお金を獲得する。 104 開発者 お金 大 大 大 小 小 大 小 小 実績を出せば リソース獲得 できるかも
92. 105 良いスコープの設定の仕方は 周りに聞くのも一つの手 検証コストが低くてしかも早いやり方を 提案してくれるかも （その前に学びたいことを決めておくのは大事！）
93. そして BML ループの実験を回し続ける 学びたいことを最低限のコストで実現できるスコープをうまく 設定できれば、素早く BML ループを回すことができる。 106 アイ デア Build Learn Measur e 製品 データ
94. 仮説検証のコツ 107
95. 仮説検証の 4 つのコツ 仮説検証をするときに心がけたい 4 つのコツについて解説する。 108 仮説を反証する 仮説に負荷を かける 必要な検証の 程度を見極める 検証時間を 最小化する
96. (1) 仮説を反証するという態度 109 仮説を反証する 仮説に負荷を かける 必要な検証の 程度を見極める 検証時間を 最小化する
97. 110 仮説検証では 自分の仮説が 正しい ことを検証する
98. 111 仮説検証では 自分の仮説が 正しい ことを検証する
99. 112 自分の仮説が 間違っている ことを検証する
100. 仮説の正しさの検証と誤りの検証 113 仮説の「正しさ」の検証 自分の仮説が正しいことについてのデータ や顧客の声を集める。 自分の仮説に合わないデータや顧客の声を 無視して「正しさ」を 確証バイアスもあってやりやすいが、学び は少なくなる傾向にある。 仮説の「誤り」の検証 仮説の間違っている部分を検証していく。 仮説が否定されることでその仮説自体は棄 却されるが、「この課題はないかも」や 「この顧客セグメントではないかも」など が分かっていく。 仮説を修正して仮説の誤りが減っていくこ とで、「この顧客セグメントにはこの課題 がある」といった正しい仮説へと辿り着く。
101. 114 人は自分の仮説と恋に落ちて 盲目になってしまう （相手/仮説の悪いところが見えなくなってしまう）
102. 115 その仮説と結婚して 多くの時間とお金を使う前に…
103. 116 実験🧪してみよう
104. 117 仮説検証で 自分の正しさを 証明すること （勝つこと）
105. 118 仮説検証で 自分の正しさを 証明すること （勝つこと）
106. 119 仮説検証で 自分の正しさを 証明すること （勝つこと） 学ぶこと （& アンラーンすること）
107. 120 仮説検証で 自分の正しさを 証明すること （勝つこと） 学ぶこと （& アンラーンすること） 目的は「勝つ」ことではなく 「学ぶ」ことであることを忘れない
108. 121 自分の間違いが分かることは もっと賢くなれるということ 決して悪いことではない 😁
109. (2) 仮説に負荷をかけるという態度 122 仮説を反証する 仮説に負荷を かける 必要な検証の 程度を見極める 検証時間を 最小化する
110. 123 仮説に負荷をかけることで 確からしさはより上がる
111. 仮説への負荷が低いとき たとえば「欲しい」と言ってくれる人を集めるだけだと負荷が 低く、本当にその仮説が確かかどうか分からない。 124 100% 0% 5% 欲しいと 言ってくれた 仮説の確からしさ
112. 仮説への負荷が高いとき 覚書を求めることなどで仮説に負荷をかけると、その仮説の確 からしさが上がる。 125 100% 0% 40% お金を払う 約束を覚書で してくれた 5% 欲しいと 言ってくれた 仮説の確からしさ
113. 126 淘汰圧をかけて 仮説を進化させるつもりで 仮説に負荷をかける
114. 128 仮説検証による学びで 仮説の進化 を促す
115. 129 負荷をかけることで 仮説の墓標が多く立つのは 仕方がない 😥
116. 130 自分の仮説と恋に落ちていると 仮説に負荷をかけにくい 😥
117. 131 一個一個の勝負（仮説検証）に 勝つのではなく 最終的な勝利が重要 👍 （※ただし時間内での勝利であること）
118. (3) 必要な検証の程度を見極める 132 仮説を反証する 仮説に負荷を かける 必要な検証の 程度を見極める 検証時間を 最小化する
119. 133 “仮説の確度がどの程度必要か” は状況によって異なる
120. Photo by Steve Jurvetson CC BY 2.0 134 おそらくほとんどの 決定は、あなたが 持っていたい情報の 70％程度で行われ るべきです Jeff Bezos (Amazon, Founder) 2016 年の株主への手紙
121. 135 意思決定のためには 100% の確度は必要ない
122. 意思決定のためにどれだけの学びが必要かを見極める 意思決定のために必要なだけの学びを見極めて、確度を高める 作業をどこかで打ち切る必要もある。 136 仮説生成 (仮説探索) 仮説選択 仮説検証 意思決定 実行 もしくは 次の仮説 の検証 仮説の修正 (仮説の進化) 学び
123. 5% だと次に行くのは早すぎるかもしれないけれど… 137 100% 0% 5% 欲しいと 言ってくれた 仮説の確からしさ
124. 40% 程度までいけば意思決定ができるかもしれない それなりの確度になれば、次に不確実な仮説を検証したり、あ るいは仮説に基づいて実行することをしてもいいかもしれない。 138 100% 0% 40% お金を払う 約束を覚書で してくれた 仮説の確からしさ
125. 仮説検証の天秤：お金 or 時間 どの程度の仮説検証を行うかどうかは、コストと時間との兼ね 合いで決める。 139 間違えば 大きなコスト （人・物・お金・時間） が発生する 💴 今すぐ 始められて 機を掴む ⏰
126. 140 ただし確度が低い仮説に 基づいて事業を進めると 無駄 が発生するかもしれない
127. 確度が低い状態で進めたときに起こりうる無駄 仮説を検証せず、確からしさが低いまま進めてしまったときに は、様々な無駄が発生する可能性が高まる。 141 時間の無駄 たとえば顧客が欲しがると 思って、半年間を使って 作った製品が使われなかっ たとしたら、その半年間の 時間が無駄になる。 時間の無駄は、寿命が短い スタートアップにとっては 一番痛い無駄。 お金の無駄 その製品を作ったのにつか われなかった場合、製品開 発にかかったコストは大き なお金の無駄になる。 人の無駄 採用した人のスキルが十全 に活かさなかったりするこ とは、才能の無駄使いにな る。
128. 142 初回の起業家は 自分の仮説の確度を 甘く見積もりがち （既に仮説の確度が高いと思って大きな資金調達などを目指してしまう） 😂
129. 143 それに検証せずに “今すぐ” やらなければならない 場合はそこまで多くない
130. 144 ほんの少しのコストで 仮説検証（リスク検証） ができるのであれば やった方が良い 😀
131. (4) 検証時間を最小化する 146 仮説を反証する 仮説に負荷を かける 必要な検証の 程度を見極める 検証時間を 最小化する
132. 速さの計算：「みはじ」の式 以下のような式を思い出してみる。これをスコープなどに置き なおすと… 147 みちのり はやさ じかん ÷ ÷ ×
133. みちのり＝スコープ、はやさ＝実行速度 みちのりはスコープ、はやさは実行速度で表せる。 148 みちのり （スコープ） はやさ （実行速度） じかん
134. 時間が最も大事 → 時間を最小化しようとする 大事なのは時間なので、これを最小にするようにしようとする と… 149 みちのり （スコープ） はやさ （実行速度） じかん
135. 「スコープを最小化する」「実行速度を上げる」の二択 時間を最小化しようとすると、以下の二つの変数を変えるしか ない。 150 みちのり （スコープ） はやさ （実行速度） じかん スコープを 最小化する 実行速度を 上げる
136. 仮説検証の速度を上げるためにできること この二つの両方を意識しながら検証を進める。 151 スコープの最小化 道のりを最小化する。 得られる学びは同量でありながらも最小限 のものを作ろうとすることで、道のりは短 くなり、かかる時間も短くなる。 実行速度の最大化 実行速度を上げることで、検証にかかる時 間は最小化される。どれだけうまくスコー プが設定できても、実行速度が遅ければ （たとえば開発などが遅ければ）仮説検証 を短時間に終わらせることはできない。
137. 仮説検証の 4 つのコツ 仮説検証をするときに心がけたい 4 つのコツについて解説した。 152 仮説を反証する 仮説に負荷を かける 必要な検証の 程度を見極める 検証時間を 最小化する
138. まとめ 153
139. 154 仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力
140. 155 仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力 （アンラーニング）
141. 156 仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力 （アンラーニング） 仮説検証の 目的
142. 157 仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力 （アンラーニング） 仮説検証は 速さが大事
143. 158 仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力 （アンラーニング） 最速にする ためのコツ
144. 159 仮説検証力とは 仮説についての 最大の学習と学習棄却を 最適なスコープ設計と実行により 最速で行う力 （アンラーニング）
145. 良い学びを得て、意思決定へとつなげる 160 仮説生成 (仮説探索) 仮説選択 仮説検証 意思決定 実行 もしくは 次の仮説 の検証 学びが生まれる
146. 仮説検証で意識すると良いこと 161 学習と学習棄却 学びを得たり、アンラーン をして、意思決定に役立て るのが仮説検証の目的であ り、仮説が合っているかど うかは最重要ではない。 学びにフォーカスして仮説 検証を進めること。 スコープを最適化 同量の学びが得られるス コープを設定することで、 早く仮説検証を行うことが できる。 MVP なども最大の学びが得 られる最小のスコープの MVP を作ること。 コツ • 学びたいことを解像度高 く把握する • 反証する • 負荷をかける（淘汰圧を かける） • 意思決定に必要な確から しさを定める • 実行を早くする
147. 更なる文献 • MVP の作り方 🔨 • スケールしないことをしよう 👊 • 解像度を高める • カスタマーマニアになろう • スタートアップのメトリクス • 仮説思考入門 • 仮説生成力を鍛える • 仮説を選ぶ技術 • 仮説思考 • イシューからはじめよ • 実践デザイン #05 「MVP の仕様」 162
148. FoundX の紹介 163
149. FoundX とは 164 東京大学 FoundX は東京大学 産学協創推進本部の下部組 織です。東京大学 本郷キャンパスの近くに 3 つの施設を構 え、起業志望者向けのプログラムを複数提供しています。 投資は行いませんが、無償での個室貸与やプログラムの提 供、起業家コミュニティへの参加を支援します。 🔥 興味 情熱 Fellows (6 か月) Pre-Founders (6 か月) Founders (9 か月) 👨‍👩‍👧 ‍👦 共同創業者 の説得 💰 有利な 資金調達 🤝 フル コミット 🏆 ビジネス 実績 📝 初契約 初売上 💻🤖 製品開発 と改善 💲 助成金や コンテス ト 賞金の獲 得 Review, Resource, School ➰ 試行 錯誤 🌱 アイデア の種 💡 検証された アイデア 📚 起業家の 基礎知識 ＆スキル 🔨 プロト タイプ 🙎 顧客イン タビュー
150. FoundX の提供する起業家支援プログラム & リソース 主に東京大学の卒業生向けに、無償のスタートアップ支援プロ グラムや学習リソースを提供。 165 👨‍👩‍👧 ‍👦 チーム向け Founders Program 事業と起業家の成長を、コ ミュニティを通して達成す るプログラム。個室を無償 で最大 9 か月間貸与。 Pre-Founders Program Founders Program に入る までの準備を行うプログラ ム。 🧑👧 個人向け Fellows Program スタートアップ的手法の実 践を通してアイデアを見つ け、育てるためのプログラ ム。 📚 学習リソース FoundX Review 平日ほぼ毎日更新し、ス タートアップのノウハウ情 報を提供。カテゴリ別のま とめは FoundX Resource。 FoundX Online School 動画形式でスタートアップ の基礎を学べる。
151. スライド著者 & FoundX 運営 馬田隆明 (東京大学 FoundX ディレクター） University of Toronto 卒業後、日本マイクロソフトでの Visual Studio のプロダクトマネージャーを経て、テクニカルエバンジェリス トとしてスタートアップ支援を行う。スタートアップ向けのスライド、 ブログなどの情報提供を行う。 サイト: https://takaumada.com/ 166 スタートアップの 方法論の基礎 Amazon (2017年3月) 起業環境の重要性と アクセラレーター の設計方法 Amazon (2019年4月) スタートアップの 公共や規制との 付き合い方 Amazon (2021年1月) スタートアップに ついてのスライド Slideshare SpeakerDeck
152. 167 https://foundx.jp/ ご応募お待ちしています 😊