MVP の作り方 🔨 とにかく雑に作る「手作業型 MVP」のススメ

Slide 1

Slide 1 text

Takaaki Umada / 馬田隆明東京大学 FoundX（インセプションプログラム） https://foundx.jp/ MVP の作り方とにかく雑に作る「手作業型 MVP」のススメ

Slide 2

Slide 2 text

2 Minimum Viable Product 実用最小限の製品

Slide 3

Slide 3 text

MVP とは何であって何でないか Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable 3 MVP ではないもの (完成まで実用できない)

Slide 4

Slide 4 text

MVP とは何であって何でないか Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable 4 MVP ではないもの (完成まで実用できない) MVP (最初から最低限実用可能)

Slide 5

Slide 5 text

最小限とはいえ、実用できて「価値」があるのが MVP 顧客がそのサービスを受けられて（実用できて）、その価値を少しでも感じることができるものが MVP。 5 機能性信頼性使い勝手便利心地よい MVP ではない (実用できないので価値提供ができない) 機能性信頼性使い勝手便利 MVP (酷くても実用可能な状態で最低限の価値を提供できる) 心地よい

Slide 6

Slide 6 text

6 MVP は仮説を検証して学びを得るために作る最小限の製品っぽいもののこと

Slide 7

Slide 7 text

7 MVP は仮説を検証して学びを得るために作る最小限の製品っぽいもののこと作ることではなく「学び」が重要

Slide 8

Slide 8 text

8 あなたの仮説を基に時間をかけて作った製品がまったく売れなければ超辛い

Slide 9

Slide 9 text

9 そしてあなたの最初の仮説は 9 割 9 分間違っている

Slide 10

Slide 10 text

10 だからこそ最初は MVP を使って仮説を検証しよう

Slide 11

Slide 11 text

11 「どうやれば最小限の努力で自分の仮説を検証できるか？」を頭を捻って考えるそんな創造的な取り組みが MVP 開発

Slide 12

Slide 12 text

MVP を作って検証できる仮説と実例 12

Slide 13

Slide 13 text

MVP で検証できる主な仮説の二つ MVP を作ることで検証できる仮説は主に以下の二つの仮説。 13 「価値仮説」のための MVP 「このサービスには顧客に〇〇円ぐらいのお金を払ってもらえるだけの価値はある」という仮説。 MVP によって少しでも課題が解決されて、それにお金を払ってくれる人がいれば、その課題に解く価値があることが分かる。「市場仮説」のための MVP 「このサービスは多くのニーズがあり、市場がある。将来成長できる」という仮説。 MVP を作ることによって、多くの人が「欲しい」とコミットしてくれる（言ってくれるだけではなく、登録してくれるなど）のであれば、ニーズの量が多いことが分かる。

Slide 14

Slide 14 text

まず重要なのは価値仮説のほう 14 「価値仮説」のための MVP 「このサービスには顧客に〇〇円ぐらいのお金を払ってもらえるだけの価値はある」という仮説。 MVP によって少しでも課題が解決されて、それにお金を払ってくれる人がいれば、その課題に解く価値があることが分かる。「市場仮説」のための MVP 「このサービスは多くのニーズがあり、市場がある。将来成長できる」という仮説。 MVP を作ることによって、多くの人が「欲しい」とコミットしてくれる（言ってくれるだけではなく、登録してくれるなど）のであれば、ニーズの量が多いことが分かる。多くの場合、重要になるのは価値仮説。

Slide 15

Slide 15 text

15 スタートアップが最初に学ぶべきなのは多くの場合この課題を解決することで顧客は価値を感じるかどうか

Slide 16

Slide 16 text

16 価値を感じてもらえる（＝顧客にお金を払ってもらえる） MVP を作って、顧客の課題を解決しよう

Slide 17

Slide 17 text

17 （dinii チームの実例）

Slide 18

Slide 18 text

18 （例）忙しいビジネスパーソンのための事前注文&事前決済でランチの待ち時間がゼロになるアプリ

Slide 19

Slide 19 text

ランチの事前注文事前決済のアプリの MVP を考える事前注文、事前決済のアプリの場合、最初に必要な機能や行動の代表的なものは以下。 19 必要な機能普通に考えること彼らがやったこと事前予約機能ユーザー向けアプリと店舗側の予約システムを作って交渉する。店員のトレーニングなども行う。アプリっぽいものは作る。ただし予約ボタンが押されたら、Slack で通知が来るだけの実装にしておき、店には電話で彼ら自身が予約する。決済機能 Stripe などの決済サービスを統合するために、申請をしたりする。作らない。事前にお店に 1 万円程度のお金を渡しておき、送客した人たちのランチ代はそのお金から引いてもらう。マーケティング特定のターゲットに広告を打ってアプリの宣伝をする。本郷三丁目の交差点で看板を持って立ち、興味ありそうな人にその場でアプリをインストールしてもらい、使ってもらう。近場のオフィスを全件訪問する。

Slide 20

Slide 20 text

MVP ではなく普通に作ろうとするとこうなる普通に考えると、このようなプロセスを踏んで製品を提供し、自分たちの製品の価値を検証しようとする。 20 必要な機能普通に考えること彼らがやったこと事前予約機能ユーザー向けアプリと店舗側の予約システムを作って交渉する。店員のトレーニングなども行う。アプリっぽいものは作る。ただし予約ボタンが押されたら、Slack で通知が来るだけの実装にしておき、店には電話で彼ら自身が予約する。決済機能 Stripe などの決済サービスを統合するために、申請や開発をしたりする。法人用銀行口座開設にも時間がかかる。作らない。事前にお店に 1 万円程度のお金を渡しておき、送客した人たちのランチ代はそのお金から引いてもらう。マーケティング特定のターゲットに広告を打ってアプリの宣伝をする。本郷三丁目の交差点で看板を持って立ち、興味ありそうな人にその場でアプリをインストールしてもらい、使ってもらう。近場のオフィスを全件訪問する。

Slide 21

Slide 21 text

予約機能は実は中身が手作業アドバイスを有効活用して MVP を作ったチームは以下のようなことを行った。まず予約は電話でやる。 21 必要な機能普通に考えること彼らがやったこと事前予約機能ユーザー向けアプリと店舗側の予約システムを作って交渉する。店員のトレーニングなども行う。アプリっぽいものは作る。ただし予約ボタンが押されたら、Slack で通知が来るだけの実装にしておき、店には電話で彼ら自身が予約する。決済機能 Stripe などの決済サービスを統合するために、申請や開発をしたりする。法人用銀行口座開設にも時間がかかる。作らない。事前にお店に 1 万円程度のお金を渡しておき、送客した人たちのランチ代はそのお金から引いてもらう。マーケティング特定のターゲットに広告を打ってアプリの宣伝をする。本郷三丁目の交差点で看板を持って立ち、興味ありそうな人にその場でアプリをインストールしてもらい、使ってもらう。近場のオフィスを全件訪問する。

Slide 22

Slide 22 text

当時の彼らの資料から転載株式会社 dinii の山田さんに許可を得て転載 22 時間と人数と料理を指定し、事前に決済

Slide 23

Slide 23 text

当時の彼らの資料から転載株式会社 dinii の山田さんに許可を得て転載 23 時間と人数と料理を指定し、事前に決済これは顧客から見えていた姿

Slide 24

Slide 24 text

当時の彼らの資料から転載株式会社 dinii の山田さんに許可を得て転載 24 時間と人数と料理を指定し、事前に決済 12:30に 1名で唐揚げ定食1つ田中さんという男性の方です裏でやっていた作業

Slide 25

Slide 25 text

決済機能は作らず、デポジットで解決決済機能も作らない。 25 必要な機能普通に考えること彼らがやったこと事前予約機能ユーザー向けアプリと店舗側の予約システムを作って交渉する。店員のトレーニングなども行う。アプリっぽいものは作る。ただし予約ボタンが押されたら、Slack で通知が来るだけの実装にしておき、店には電話で彼ら自身が予約する。決済機能 Stripe などの決済サービスを統合するために、申請をしたりする。法人用銀行口座開設にも時間がかかる。作らない。事前にお店に 1 万円程度のお金を渡しておき、送客した人たちのランチ代はそのお金から引いてもらう。マーケティング特定のターゲットに広告を打ってアプリの宣伝をする。本郷三丁目の交差点で看板を持って立ち、興味ありそうな人にその場でアプリをインストールしてもらい、使ってもらう。近場のオフィスを全件訪問する。

Slide 26

Slide 26 text

26 開発をするのではなく他の良いやり方を考えに考えてスコープを絞って開発を最小限にする

Slide 27

Slide 27 text

スケールしないことをして顧客獲得マーケティングはしない。スケールしないことをする。 27 必要な機能普通に考えること彼らがやったこと事前予約機能ユーザー向けアプリと店舗側の予約システムを作って交渉する。店員のトレーニングなども行う。アプリっぽいものは作る。ただし予約ボタンが押されたら、Slack で通知が来るだけの実装にしておき、店には電話で彼ら自身が予約する。決済機能 Stripe などの決済サービスを統合するために、申請をしたりする。法人用銀行口座開設にも時間がかかる。作らない。事前にお店に 1 万円程度のお金を渡しておき、送客した人たちのランチ代はそのお金から引いてもらう。マーケティング特定のターゲットに広告を打ってアプリの宣伝をする。本郷三丁目の交差点で看板を持って立ち、興味ありそうな人にその場でアプリをインストールしてもらい、使ってもらう。近場のオフィスを全件訪問する。

Slide 28

Slide 28 text

スケールしないことをしよう https://commons.wikimedia.org/wiki/File:Unclesamwantyou.jpg?uselang=ja 28

Slide 29

Slide 29 text

29 この結果…

Slide 30

Slide 30 text

30 開始 5 日後にローンチ約 3 週間後の継続率 64% 24 日目にエンジェル投資決定

Slide 31

Slide 31 text

31 開始 5 日後にローンチ約 3 週間後の継続率 64% 24 日目にエンジェル投資決定

Slide 32

Slide 32 text

32 開始 5 日後にローンチ約 3 週間後の継続率 64% 24 日目にエンジェル投資決定継続率によってサービスの提供する基本的な価値の検証ができた

Slide 33

Slide 33 text

33 開始 5 日後にローンチ約 3 週間後の継続率 64% 24 日目にエンジェル投資決定

Slide 34

Slide 34 text

34 さらに学びを得て今は株式会社 dinii として活動中 (2021 年) https://www.dinii.jp/

Slide 35

Slide 35 text

35 「どうやって作るか」ではなく「どうやれば作らずにすむか」を考える

Slide 36

Slide 36 text

36 最小限の努力で何かを成し遂げたほうがスマート！

Slide 37

Slide 37 text

37 皆さんにもできるはず！

Slide 38

Slide 38 text

38 を作って今すぐローンチしよう

Slide 39

Slide 39 text

MVP の種類 39

Slide 40

Slide 40 text

主な MVP の種類 (1) – ニーズ調査＆市場仮説系ニーズの多さ（市場仮説）を調べる MVP として以下のようなものがある。 40 ランディングページ MVP サービスはないまま、Web ページだけ作る。候補者にメールマガジンなどに登録してもらうなど。検証可能なことニーズの多さ顧客のプロフィールデモ動画 MVP 動画で説明をする。場合によってはまだ完成していないフェイク (Dropbox 等) 検証可能なことニーズの多さプレオーダー MVP リリース前に購入を募る。クラウドファンディングなど。検証可能なことニーズの多さ顧客がお金を払ってくれるか

Slide 41

Slide 41 text

主な MVP の種類 (2) – モノづくり系実際のモノに近いものを作る場合。目的次第で様々な仮説検証が可能。 41 プロトタイプ MVP 実際に動くものを作ってみること。ただしコストがかかりがち。検証可能なこと（プロトタイプの目的次第で）機能性、デザイン性、体験など競合ツール応用 MVP 競合ツールを少しだけ改造したり、組み合わせたり、そのまま使ってもらって、その価値を検証する。たとえば動画系サービスなら YouTube の一部機能と別のツールを組み合わせたりする。検証可能なことサービスの成果に価値を感じてもらえるか顧客がお金を払ってくれるか

Slide 42

Slide 42 text

主な MVP の種類 (3) – 手作業型 MVP 手作業を介するもの。主に価値仮説を検証できる。 42 オズの魔法使い型 MVP 外側だけはアプリのようにしておき、中身の処理は人間で行うもの。 Zappos などがWebサイトだけを作り、注文があれば自分たちで靴を買いに行って発送していたような手法や先ほどの dinii の例。検証可能なことサービスの成果に価値を感じてもらえるか顧客がお金を払ってくれるかコンシェルジュ型 MVP 製品と同じ成果を自分の手（手作業、個人でのコンサル等）で提供する方法。製品は作らなくても済む。検証可能なことサービスの成果に価値を感じてもらえるか顧客がお金を払ってくれるか

Slide 43

Slide 43 text

MVP の種類と主に検証対象となる仮説これまでの MVP とそれぞれの MVP が検証できる仮説をまとめた。 43 MVP の種類検証できる仮説ランディングページ市場仮説デモ動画市場仮説プレオーダー市場仮説プロトタイプ（目的による）競合ツール応用主に価値仮説オズの魔法使い価値仮説コンシェルジュ価値仮説

Slide 44

Slide 44 text

44 もしあなたがこれから MVP を作るなら…

Slide 45

Slide 45 text

コンシェルジュ型 MVP 一択 45 MVP の種類検証できる仮説ランディングページ市場仮説デモ動画市場仮説プレオーダー市場仮説プロトタイプ（目的による）競合ツール応用主に価値仮説オズの魔法使い価値仮説コンシェルジュ価値仮説

Slide 46

Slide 46 text

46 最初の MVP はコンシェルジュ型ほぼ一択

Slide 47

Slide 47 text

47 まずは騙されたと思ってコンシェルジュ型からやってみる (多くのアイデアはコンシェルジュ型 MVP で検証できる)

Slide 48

Slide 48 text

コンシェルジュ型 MVP の例献立を作るアプリやサービスを考えていたスタートアップ 1. 何もアプリを作らずにスーパーの前に立つ 2. スーパーで買い物に悩んでいる人たちに声をかけて、献立を代わりに考えて、その対価を貰っていた 48

Slide 49

Slide 49 text

コンシェルジュ型 MVP の例献立を作るアプリやサービスを考えていたスタートアップ 1. 何もアプリを作らずにスーパーの前に立つ 2. スーパーで買い物に悩んでいる人たちに声をかけて、献立を代わりに考えて、その対価を貰っていた機械学習を使って企業購買の最適化をするスタートアップ 1. アルバイトとして顧客の会社に入る 2. 自分たちのソフトウェアの提供する予定と同等のサービスを人力で提供（最適な商品をレコメンドする） 49

Slide 50

Slide 50 text

スケールしないことをしよう、PRの方法 50 例）最初は自分たちでデリバリーしていた（顧客にとっては、ドライバーが配達しようと創業者が配達しようと、食事が届けられるというアウトカムは同じ）

Slide 51

Slide 51 text

51 コンシェルジュ型 MVP でも顧客が受け取っている価値は製品による価値とほぼ同じ（むしろ手作業で丁寧な分、製品より価値が高いかも？）

Slide 52

Slide 52 text

その他、手作業で提供する例少し頭をひねれば、顧客にとって同じアウトカムを手作業で提供できる。 52 機械学習での推薦自分たちで推薦してみる。実践例） Magic レビューサイトレビューを集めてきて提供する。ニュースレターなどで情報を送る。実践例）Product Hunt マッチング自分たちでマッチングしてみる。あるいは自分たちがマッチングを受けた体で働く。実践例）Doordash、 HomeJoy、Lugg ロボットや bot ロボットの代わりに人間がその作業をしてみたり、 LINE などで返信してみる。機械翻訳コンピュータの代わりに人間が翻訳する。実践例）IBM

Slide 53

Slide 53 text

53 コンシェルジュ型 MVP なら明日からでもローンチして価値仮説を検証できる

Slide 54

Slide 54 text

54 コンシェルジュ型の丁寧なサービスに対して顧客がお金を払わなければその課題は課題ではない（というのは、多少言い過ぎなものの実際ほとんどのケースはそう）

Slide 55

Slide 55 text

55 次点がオズの魔法使い型 MVP

Slide 56

Slide 56 text

オズの魔法使い型 MVP の例株式会社 dinii の山田さんに許可を得て転載 56 時間と人数と料理を指定し、事前に決済 12:30に 1名で唐揚げ定食1つ田中さんという男性の方です裏でやっていた作業

Slide 57

Slide 57 text

例）新・日本の最先端自動改札機（ヨルタモリ）これもオズの魔法使い型 MVP の分かりやすい例と言える。（外は機械、中は人が手作業） https://www.youtube.com/watch?v=RlF1BUp5jAw 57 動画（YouTube などで検索してください）

Slide 58

Slide 58 text

58 手作業や泥臭いことを厭わないそれが MVP を早く作るコツ

Slide 59

Slide 59 text

59 手作業型 MVP を作ろう！ (そして価値仮説を検証しよう)

Slide 60

Slide 60 text

その他の MVP と例 60

Slide 61

Slide 61 text

MVP のお勧め順位基本的に以下のような順序でお勧めしている（特に Web, アプリ系）。 61 価値仮説の検証 1. コンシェルジュ型 MVP 2. オズの魔法使い型 MVP 3. 競合ツールを使った MVP 4. No Code ツールを使った MVP 5. プロトタイプ MVP 6. スクラッチ開発 (もはや MVP ではない) 市場仮説の検証 1. ランディングページ MVP (1 時間で作れるため) 2. デモ動画 MVP (動画制作に時間がかかるため。ただし早く作れるならOK) 3. プレオーダー MVP (作れなかった時のリスクがあるため)

Slide 62

Slide 62 text

ランディングページ MVP の例 SmartHR の初期のやり方はランディングページ MVP をうまく使ってニーズの検証をした例。 62 当時やったことはですね、ティザーサイトをつくりました。事前告知サイトみたいなやつですね。「事前登録募集してます。サービス開始したらメール送るのでメールアドレス登録してください」みたいなサイトをまずはつくりました。そしてそこにFacebook広告を2万円だけかけました。Facebook広告ってかなり細かくセグメントが切れるようになっていて、例えば経営者だったり、人事に興味がある人など、細かくセグメントできるので、そこで経営者や人事に向けて広告を発信しました。結果どうだったかというとですね、2週間125件の登録がありました。これはBtoBではかなりびっくりするような数字で、CPA160円、つまり1ユーザ当たり160円。このおかげで、このジャンルは確実にニーズがあるぞという検証ができました。「その業界を知らなくてもBtoB事業は立ち上げられる」−やり方とコツ− より引用

Slide 63

Slide 63 text

Airbnb のプロトタイプの例 Airbnb も最初は重要な機能がないものをローンチした。 63 • 決済機能ナシ（ホストとゲストでお金の直接手渡し） • 地図の画面ナシ（ゲストが自分たちで調べていた）

Slide 64

Slide 64 text

Reddit のプロトタイプの例 Reddit はプロトタイプが何とかなった段階で、それ以上の準備する間もなく勝手にローンチされた。プロダクトを作る方法 I / 画像は https://en.wikipedia.org/wiki/File:Reddit_screenshot_2005.png 64 • 6/3 ぐらいから開発開始 • 6/22 に Paul Graham が勝手にリンクを張って無理やりローンチ • ローンチしてからのほうが学びが多かった

Slide 65

Slide 65 text

65 もし開発する必要があれば競合ツールやその他のツールをうまく使って検証しよう

Slide 66

Slide 66 text

用途別のローンチツール仮説が検証できたら作り直すつもりで、とにかくローンチする。 66 販売系 Shopify で OK。アドインを駆使すればマーケットプレイス型なども可能。 SNS 系 Mighty Network や Mobilize などを使う。Discord などから始めても良い。 WordPress の Ultimate Member なども。 No Code No Code ツールを探して作ってみる。 Glide や AppShet、 Bubble など。 WordPress のアドインを駆使するという手もある。その他 Product hunt を漁ると良いものが出てくることも多い。

Slide 67

Slide 67 text

少しでも開発をするときの Tips MVP として何かを作らざるを得ないときは、以下のようなルールを自分に課すことをお勧めする。 MVP を計画する方法 67 時間を決める「24 時間で作れるものを作る」とタイムボックスをあらかじめ決める。その範囲で作れるものを作る。必ずその時間内でできたものをローンチする。スコープを絞るとにかくスコープを絞って仕様を削る。足すことよりも引くことのほうが難しいので、創造力や思考能力のいる作業。引き算の美学を身に着けよう。文書化する何が顧客の課題で何を検証したいのか、メトリクスは何か、そのために何を作れば良いのかを予め文章にしてまとめる。作り始めると機能などを作りすぎてしまい、複雑になることがよくあるため。自分を律するためにも文書化は有効。例) Amazonはプレスリリースを書いて考えを整理する。

Slide 68

Slide 68 text

68 MVP は 1 日で作るもの（その方法を考えるもの）

Slide 69

Slide 69 text

69 そして 1 日で作れなければ「時間をかけすぎている」と言っても過言ではない明日 MVP をローンチしよう！

Slide 70

Slide 70 text

70 とにかくローンチする Launch Fast

Slide 71

Slide 71 text

71 そして顧客からフィードバックと学びを得よう

Slide 72

Slide 72 text

MVP 開発のダメなパターン 72

Slide 73

Slide 73 text

73 「どうしても開発をしなければ仮説検証できない…」そんなときに陥りがちな罠をいくつか紹介

Slide 74

Slide 74 text

悪い MVP 開発の例 (1) よく見かける MVP の作り方の悪い例。 74 仮説がないまま作る「とにかく作る」ことを推したが「とにかく作る」だけでは MVP とは言えない。何の仮説を検証したいのか、何が顧客の課題なのかをある程度持ったうえで作らなければ多くの場合は無駄になる。 MVP を作った後に課題仮説もより見えてくるけれど、作る前にも仮の仮説を持っておく。広く重い上にスコープが変わる MVP のスコープが広くて、開発が重いうえに、毎回のように作るべきものが変わるようなパターンもある。非エンジニア創業者で、仮説が絞り切れていない場合や見積もりができない場合にありがち。この場合、作る側のエンジニアが疲弊して、エンジニアが抜けてチームが解散することが多い。

Slide 75

Slide 75 text

悪い MVP 開発の例 (2) よく見かける MVP の作り方の悪い例。 75 フルスペックで外注するスコープが絞り切れていない、非エンジニアによくあるパターン。ローンチまで数か月かかるうえ、お金も数十万～数百万かかる。そして数か月後、十中八九希望したものは出てこない。発注するにもスキルが必要なので注意。エンジニアの言う通りに作るチームに入ったエンジニアが作りたいように作って、開発に時間がかかってしまうパターン。非エンジニア創業者によくある。エンジニア側がスタートアップ的なやり方になれていない人の場合や、非エンジニア創業者がスコープや仕様を決め切れていないために起こる。

Slide 76

Slide 76 text

76 ※優秀なエンジニアがいるなら 1 日のタイムボックスで作れる幅は広がる

Slide 77

Slide 77 text

77 けれど開発に手を出すのは最後の手段（たとえあなた自身が IT エンジニアであっても）まずは検証するべき仮説を徹底的に絞り込むこと

Slide 78

Slide 78 text

78 「最初から全部作らなきゃ」と思うのはスコープが絞り切れていない（考えきれてない、創造性が足りない）だけかも

Slide 79

Slide 79 text

素早く、かつ頻繁に出荷する技術 79 仮に何かを作ったとしても MVP は「バージョン 0」と思おう (仮説検証できたら作りなおすつもりで)

Slide 80

Slide 80 text

80 だから学びを得るためにも…

Slide 81

Slide 81 text

81 とにかく雑に作る

Slide 82

Slide 82 text

82 とにかく雑に作る

Slide 83

Slide 83 text

83 とにかく雑に作る

Slide 84

Slide 84 text

とにかく雑に作れ 84 とにかく雑に作る

Slide 85

Slide 85 text

85 とにかく ※ただし最低限の安全性やコンプライアンスは守ること

Slide 86

Slide 86 text

Photo by Dave Thomas, released under the Attribution Creative Commons license. http://www.paulgraham.com/bio.html 86 人がすごい成果を出せない最大の理由のひとつは、ださいものを作ってしまうことへの恐れだ。（中略）おもしろいことに、初期の作品を厳しく見すぎる問題の解決法は、そういう見方そのものが初期の段階であると気づくことだ。 Paul Graham “Early Work” Shiro Kawai さん訳『初期の作品』

Slide 87

Slide 87 text

Photo by Dave Thomas, released under the Attribution Creative Commons license. http://www.paulgraham.com/bio.html 87 人がすごい成果を出せない最大の理由のひとつは、ださいものを作ってしまうことへの恐れだ。（中略）おもしろいことに、初期の作品を厳しく見すぎる問題の解決法は、そういう見方そのものが初期の段階であると気づくことだ。 Paul Graham “Early Work” Shiro Kawai さん訳『初期の作品』

Slide 88

Slide 88 text

88 初期のものはすべてダサいダサいものを作ることへの恐れを乗り越えよう

Slide 89

Slide 89 text

89 そして雑に作れば未練なくいつでも捨てられる（自分たちの思い入れも薄くなるし、顧客もその点を考慮して見てくれる）アイデアの変更も容易になる

Slide 90

Slide 90 text

90 この恐れを乗り越えてとにかく世に物を出し続けた起業家が勝つ傾向にある

Slide 91

Slide 91 text

91 この恐れを乗り越えてとにかく世に物を出し続けた起業家が勝つ傾向にある＝この恐れを乗り越えるだけで優位に立てる

Slide 92

Slide 92 text

92 とにかく手作業で雑に作る

Slide 93

Slide 93 text

Q. 93 どう雑に作れば良いのか分かりません……

Slide 94

Slide 94 text

A. 94 MVPのパターンを知っている人に恐れずに聞いてみよう

Slide 95

Slide 95 text

95 「〇〇というアウトカムのものを作りたいのですが、どうやって作れば良いでしょうか」と VC の人などに聞いてみるとヒントをくれるかも

Slide 96

Slide 96 text

96 「〇〇というアウトカムのものを作りたいのですが、どうやって作れば良いでしょうか」と VC の人などに聞いてみるとヒントをくれるかも

Slide 97

Slide 97 text

97 アウトカムとは？

Slide 98

Slide 98 text

MVP の位置づけとロジックモデル 98

Slide 99

Slide 99 text

99 顧客が欲しいものは製品そのものじゃなくて製品が生み出すアウトカム

Slide 100

Slide 100 text

ロジックモデルで MVP を整理するロジックモデルは以下のように活動から成果までの流れを整理する。 100 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム

Slide 101

Slide 101 text

インプット人、物、金などのリソースがインプットとなる。 101 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム開発された製品や機能製品によって顧客が得る成果 (例: 時間削減、省力化、楽しみ) 社会的なインパクト製品開発の作業時間やお金、人など

Slide 102

Slide 102 text

アクティビティ（活動）何かしらの活動や行動、作業など。製品開発の場合、開発がアクティビティに当たる。 102 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム開発された製品や機能製品によって顧客が得る成果 (例: 時間削減、省力化、楽しみ) 社会的なインパクト製品開発の作業時間やお金、人など

Slide 103

Slide 103 text

アウトプット作業の結果出てくるもの。製品や機能そのものが生まれることが多い。 103 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム開発された製品や機能製品によって顧客が得る成果 (例: 時間削減、省力化、楽しみ) 社会的なインパクト製品開発の作業時間やお金、人など

Slide 104

Slide 104 text

アウトカム顧客やサービス受益者が得られる成果。便益的なものもあれば感情的なものもある。 104 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム開発された製品や機能製品によって顧客が得る成果 (例: 時間削減、省力化、楽しみ) 社会的なインパクト製品開発の作業時間やお金、人など

Slide 105

Slide 105 text

顧客が欲しいのは製品ではなくアウトカム顧客が本当に欲しいのは、製品自体ではなく製品を使って得られる「アウトカム」のほう。 105 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム顧客が本当に欲しいもの

Slide 106

Slide 106 text

アウトカムが提供できる MVP であれば良いコンシェルジュ型 MVP であれば、製品と同じアウトカムを提供できる（製品より良いアウトカムの場合もある）。 106 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカムこれを提供できる MVP があれば良い

Slide 107

Slide 107 text

アウトカムが提供できる MVP であれば良いコンシェルジュ型 MVP であれば、製品と同じアウトカムを提供できる（製品より良いアウトカムの場合もある）。 107 インプット/ リソースインパクトアクティビティアウトプット/実装アウトカム作る予定の製品と同じアウトカムを提供できるアウトプットを「手作業」で行うのが手作業型 MVP

Slide 108

Slide 108 text

108 顧客の欲しがるアウトカムが提供できればどんなアウトプットであれお金はもらえるはず

Slide 109

Slide 109 text

109 製品と同等のアウトカムを手作業型 MVP で提供したときに顧客がお金を払わなければその課題は課題ではない（というのは、多少言い過ぎなものの実際ほとんどのケースはそう）

Slide 110

Slide 110 text

110 製品と同等のアウトカムの MVP を作ってとにかく売る Sell it Fast

Slide 111

Slide 111 text

セールスアニマル https://commons.wikimedia.org/wiki/File:Unclesamwantyou.jpg?uselang=ja 111

Slide 112

Slide 112 text

112 ローンチして顧客との話をしてから本当の学びが始まる

Slide 113

Slide 113 text

113 MVP を明日ローンチしてセールスを始めて本当の学びを始めよう！

Slide 114

Slide 114 text

114 ビジョンは大きく MVP は小さく

Slide 115

Slide 115 text

115 ビジョンは大きく MVP は小さく千里の道も一歩から最初の一歩を MVP で踏み出そう

Slide 116

Slide 116 text

116 Launch Fast & Sell it Fast

Slide 117

Slide 117 text

まとめ 117

Slide 118

Slide 118 text

118 MVP は仮説を検証して学びを得るために作る最小限の製品っぽいもののこと

Slide 119

Slide 119 text

MVP の作り方コンシェルジュ型 MVP を中心に、MVP の作り方を解説した。 119 MVP の主な目的 • 価値仮説の検証 • 市場仮説の検証 MVP の種類 • コンシェルジュ型 MVP（おすすめ ⭐） • オズの魔法使い型 MVP • 競合ツールを使った MVP • No Code ツールを使った MVP • プロトタイプ MVP • スクラッチ開発 • ランディングページ MVP • デモ動画 MVP • プレオーダー MVP

Slide 120

Slide 120 text

とにかく雑に作れ 120 とにかく手作業で雑に作る

Slide 121

Slide 121 text

121 Launch Fast & Sell it Fast

Slide 122

Slide 122 text

更なる文献 • リーンスタートアップ • MVP を計画する方法 • MVP はプロダクトではなく、プロセスである • どのように料理系スタートアップを立ち上げたか • プロダクトを作る • 素早く、かつ頻繁に出荷する技術 • ローンチする方法（何度も何度も） • プロダクトを作る、ユーザーと話す、成長する 122

Slide 123

Slide 123 text

FoundX の紹介 123

Slide 124

Slide 124 text

FoundX とは 124 東京大学 FoundX は東京大学産学協創推進本部の下部組織です。東京大学本郷キャンパスの近くに 3 つの施設を構え、起業志望者向けのプログラムを複数提供しています。投資は行いませんが、無償での個室貸与やプログラムの提供、起業家コミュニティへの参加を支援します。興味情熱 Fellows (6 か月) Pre-Founders (6 か月) Founders (9 か月) ‍‍ ‍ 共同創業者の説得有利な資金調達フルコミットビジネス実績初契約初売上製品開発と改善助成金やコンテスト賞金の獲得 Review, Resource, School ➰ 試行錯誤アイデアの種検証されたアイデア起業家の基礎知識＆スキルプロトタイプ顧客インタビュー

Slide 125

Slide 125 text

FoundX の提供する起業家支援プログラム & リソース主に東京大学の卒業生向けに、無償のスタートアップ支援プログラムや学習リソースを提供。 125 ‍‍ ‍ チーム向け Founders Program 事業と起業家の成長を、コミュニティを通して達成するプログラム。個室を無償で最大 9 か月間貸与。 Pre-Founders Program Founders Program に入るまでの準備を行うプログラム。個人向け Fellows Program スタートアップ的手法の実践を通してアイデアを見つけ、育てるためのプログラム。学習リソース FoundX Review 平日ほぼ毎日更新し、スタートアップのノウハウ情報を提供。カテゴリ別のまとめは FoundX Resource。 FoundX Online School 動画形式でスタートアップの基礎を学べる。

Slide 126

Slide 126 text

スライド著者 & FoundX 運営馬田隆明 (東京大学 FoundX ディレクター） University of Toronto 卒業後、日本マイクロソフトでの Visual Studio のプロダクトマネージャーを経て、テクニカルエバンジェリストとしてスタートアップ支援を行う。スタートアップ向けのスライド、ブログなどの情報提供を行う。サイト: https://takaumada.com/ 126 スタートアップの方法論の基礎 Amazon (2017年3月) 起業環境の重要性とアクセラレーターの設計方法 Amazon (2019年4月) スタートアップの公共や規制との付き合い方 Amazon (2021年1月) スタートアップについてのスライド Slideshare SpeakerDeck

Slide 127

Slide 127 text

127 https://foundx.jp/ ご応募お待ちしています