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

MVP という言葉が一般的になりましたが、まだまだ手作業型のMVPについてはその価値がまだ伝わっていないように思います。そこで「早くローンチする、早く売る」のに最適な手作業型MVPを中心に、MVPの作り方を解説しています。

Special Thanks: 株式会社dinii

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

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

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

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

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

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

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

更なる文献

•リーンスタートアップ

•MVP を計画する方法

•MVP はプロダクトではなく、プロセスである

•どのように料理系スタートアップを立ち上げたか

•プロダクトを作る

•素早く、かつ頻繁に出荷する技術

•ローンチする方法（何度も何度も）

•プロダクトを作る、ユーザーと話す、成長する

•とにかく雑に作れ

1. Takaaki Umada / 馬田隆明 東京大学 FoundX（インセプションプログラム） https://foundx.jp/ MVP の作り方 とにかく雑に作る「手作業型 MVP」のススメ
2. 2 Minimum Viable Product 実用最小限の製品
3. MVP とは何であって何でないか Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable 3 MVP では ないもの (完成まで実用で きない)
4. MVP とは何であって何でないか Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable 4 MVP では ないもの (完成まで実用で きない) MVP (最初から最低限 実用可能)
5. 最小限とはいえ、実用できて「価値」があるのが MVP 顧客がそのサービスを受けられて（実用できて）、その価値を 少しでも感じることができるものが MVP。 5 機能性 信頼性 使い勝手 便利 心地よい MVP ではない (実用できないので価値提供ができない) 機能性 信頼性 使い勝手 便利 MVP (酷くても実用可能な状態で 最低限の価値を提供できる) 心地よい
6. 6 MVP は 仮説を検証して学びを得る ために作る 最小限の製品っぽいもののこと
7. 7 MVP は 仮説を検証して学びを得る ために作る 最小限の製品っぽいもののこと 作ることではなく 「学び」が重要
8. 8 あなたの仮説を基に 時間をかけて作った製品が まったく売れなければ超辛い
9. 9 そしてあなたの最初の仮説は 9 割 9 分 間違っている
10. 10 だからこそ 最初は MVP を使って 仮説を検証しよう
11. 11 「どうやれば最小限の努力で 自分の仮説を検証できるか？」 を頭を捻って考える そんな創造的な取り組みが MVP 開発
12. MVP を作って検証できる仮説と 実例 12
13. MVP で検証できる主な仮説の二つ MVP を作ることで検証できる仮説は主に以下の二つの仮説。 13 「価値仮説」のための MVP 「このサービスには顧客に〇〇円ぐらいの お金を払ってもらえるだけの価値はある」 という仮説。 MVP によって少しでも課題が解決されて、 それにお金を払ってくれる人がいれば、そ の課題に解く価値があることが分かる。 「市場仮説」のための MVP 「このサービスは多くのニーズがあり、市 場がある。将来成長できる」という仮説。 MVP を作ることによって、多くの人が「欲 しい」とコミットしてくれる（言ってくれ るだけではなく、登録してくれるなど）の であれば、ニーズの量が多いことが分かる。
14. まず重要なのは価値仮説のほう 14 「価値仮説」のための MVP 「このサービスには顧客に〇〇円ぐらいの お金を払ってもらえるだけの価値はある」 という仮説。 MVP によって少しでも課題が解決されて、 それにお金を払ってくれる人がいれば、そ の課題に解く価値があることが分かる。 「市場仮説」のための MVP 「このサービスは多くのニーズがあり、市 場がある。将来成長できる」という仮説。 MVP を作ることによって、多くの人が「欲 しい」とコミットしてくれる（言ってくれ るだけではなく、登録してくれるなど）の であれば、ニーズの量が多いことが分かる。 多くの場合、重要になるのは価値仮説。
15. 15 スタートアップが最初に学ぶべきなのは 多くの場合 この課題を解決することで 顧客は価値を感じるかどうか
16. 16 価値を感じてもらえる （＝顧客にお金を払ってもらえる） MVP を作って、顧客の課題を解決しよう
17. 17 （dinii チームの実例）
18. 18 （例） 忙しいビジネスパーソンのための 事前注文&事前決済で ランチの待ち時間がゼロ になるアプリ
19. ランチの事前注文事前決済のアプリの MVP を考える 事前注文、事前決済のアプリの場合、最初に必要な機能や行動 の代表的なものは以下。 19 必要な機能 普通に考えること 彼らがやったこと 事前予約機能 ユーザー向けアプリと店舗側の予約シス テムを作って交渉する。店員のトレーニ ングなども行う。 アプリっぽいものは作る。ただし予約ボ タンが押されたら、Slack で通知が来る だけの実装にしておき、店には電話で彼 ら自身が予約する。 決済機能 Stripe などの決済サービスを統合する ために、申請をしたりする。 作らない。事前にお店に 1 万円程度の お金を渡しておき、送客した人たちのラ ンチ代はそのお金から引いてもらう。 マーケティング 特定のターゲットに広告を打ってアプリ の宣伝をする。 本郷三丁目の交差点で看板を持って立ち、 興味ありそうな人にその場でアプリをイ ンストールしてもらい、使ってもらう。 近場のオフィスを全件訪問する。
20. MVP ではなく普通に作ろうとするとこうなる 普通に考えると、このようなプロセスを踏んで製品を提供し、 自分たちの製品の価値を検証しようとする。 20 必要な機能 普通に考えること 彼らがやったこと 事前予約機能 ユーザー向けアプリと店舗側の予約シス テムを作って交渉する。店員のトレーニ ングなども行う。 アプリっぽいものは作る。ただし予約ボ タンが押されたら、Slack で通知が来る だけの実装にしておき、店には電話で彼 ら自身が予約する。 決済機能 Stripe などの決済サービスを統合する ために、申請や開発をしたりする。法人 用銀行口座開設にも時間がかかる。 作らない。事前にお店に 1 万円程度の お金を渡しておき、送客した人たちのラ ンチ代はそのお金から引いてもらう。 マーケティング 特定のターゲットに広告を打ってアプリ の宣伝をする。 本郷三丁目の交差点で看板を持って立ち、 興味ありそうな人にその場でアプリをイ ンストールしてもらい、使ってもらう。 近場のオフィスを全件訪問する。
21. 予約機能は実は中身が手作業 アドバイスを有効活用して MVP を作ったチームは以下のような ことを行った。まず予約は電話でやる。 21 必要な機能 普通に考えること 彼らがやったこと 事前予約機能 ユーザー向けアプリと店舗側の予約シス テムを作って交渉する。店員のトレーニ ングなども行う。 アプリっぽいものは作る。ただし予約ボ タンが押されたら、Slack で通知が来る だけの実装にしておき、店には電話で彼 ら自身が予約する。 決済機能 Stripe などの決済サービスを統合する ために、申請や開発をしたりする。法人 用銀行口座開設にも時間がかかる。 作らない。事前にお店に 1 万円程度の お金を渡しておき、送客した人たちのラ ンチ代はそのお金から引いてもらう。 マーケティング 特定のターゲットに広告を打ってアプリ の宣伝をする。 本郷三丁目の交差点で看板を持って立ち、 興味ありそうな人にその場でアプリをイ ンストールしてもらい、使ってもらう。 近場のオフィスを全件訪問する。
22. 当時の彼らの資料から転載 株式会社 dinii の山田さんに許可を得て転載 22 時間と 人数と 料理を指定し、 事前に 決済
23. 当時の彼らの資料から転載 株式会社 dinii の山田さんに許可を得て転載 23 時間と 人数と 料理を指定し、 事前に 決済 これは顧客から 見えていた姿
24. 当時の彼らの資料から転載 株式会社 dinii の山田さんに許可を得て転載 24 時間と 人数と 料理を指定し、 事前に 決済 12:30に 1名で 唐揚げ定食1つ 田中さんという 男性の方です 裏でやっていた作業
25. 決済機能は作らず、デポジットで解決 決済機能も作らない。 25 必要な機能 普通に考えること 彼らがやったこと 事前予約機能 ユーザー向けアプリと店舗側の予約シス テムを作って交渉する。店員のトレーニ ングなども行う。 アプリっぽいものは作る。ただし予約ボ タンが押されたら、Slack で通知が来る だけの実装にしておき、店には電話で彼 ら自身が予約する。 決済機能 Stripe などの決済サービスを統合する ために、申請をしたりする。法人用銀行 口座開設にも時間がかかる。 作らない。事前にお店に 1 万円程度の お金を渡しておき、送客した人たちのラ ンチ代はそのお金から引いてもらう。 マーケティング 特定のターゲットに広告を打ってアプリ の宣伝をする。 本郷三丁目の交差点で看板を持って立ち、 興味ありそうな人にその場でアプリをイ ンストールしてもらい、使ってもらう。 近場のオフィスを全件訪問する。
26. 26 開発をするのではなく 他の良いやり方を 考えに考えて スコープを絞って 開発を最小限にする
27. スケールしないことをして顧客獲得 マーケティングはしない。スケールしないことをする。 27 必要な機能 普通に考えること 彼らがやったこと 事前予約機能 ユーザー向けアプリと店舗側の予約シス テムを作って交渉する。店員のトレーニ ングなども行う。 アプリっぽいものは作る。ただし予約ボ タンが押されたら、Slack で通知が来る だけの実装にしておき、店には電話で彼 ら自身が予約する。 決済機能 Stripe などの決済サービスを統合する ために、申請をしたりする。法人用銀行 口座開設にも時間がかかる。 作らない。事前にお店に 1 万円程度の お金を渡しておき、送客した人たちのラ ンチ代はそのお金から引いてもらう。 マーケティング 特定のターゲットに広告を打ってアプリ の宣伝をする。 本郷三丁目の交差点で看板を持って立ち、 興味ありそうな人にその場でアプリをイ ンストールしてもらい、使ってもらう。 近場のオフィスを全件訪問する。
28. スケール しないこと をしよう https://commons.wikimedia.org/wiki/File:Unclesamwantyou.jpg?uselang=ja 28
29. 29 この結果…
30. 30 開始 5 日後にローンチ 約 3 週間後の継続率 64% 24 日目にエンジェル投資決定
31. 31 開始 5 日後にローンチ 約 3 週間後の継続率 64% 24 日目にエンジェル投資決定
32. 32 開始 5 日後にローンチ 約 3 週間後の継続率 64% 24 日目にエンジェル投資決定 継続率によって サービスの提供する 基本的な価値の検証 ができた
33. 33 開始 5 日後にローンチ 約 3 週間後の継続率 64% 24 日目にエンジェル投資決定
34. 34 さらに学びを得て今は株式会社 dinii として活動中 (2021 年) https://www.dinii.jp/
35. 35 「どうやって作るか」 ではなく 「どうやれば作らずにすむか」 を考える
36. 36 最小限の努力で 何かを成し遂げたほうが スマート！
37. 37 皆さんにもできるはず！
38. 38 を作って今すぐローンチしよう
39. MVP の種類 39
40. 主な MVP の種類 (1) – ニーズ調査＆市場仮説系 ニーズの多さ（市場仮説）を調べる MVP として以下のようなも のがある。 40 ランディングページ MVP サービスはないまま、Web ページだけ作る。候補者に メールマガジンなどに登録 してもらうなど。 検証可能なこと ニーズの多さ 顧客のプロフィール デモ動画 MVP 動画で説明をする。場合に よってはまだ完成していな いフェイク (Dropbox 等) 検証可能なこと ニーズの多さ プレオーダー MVP リリース前に購入を募る。 クラウドファンディングな ど。 検証可能なこと ニーズの多さ 顧客がお金を払ってくれる か
41. 主な MVP の種類 (2) – モノづくり系 実際のモノに近いものを作る場合。目的次第で様々な仮説検証 が可能。 41 プロトタイプ MVP 実際に動くものを作ってみること。ただし コストがかかりがち。 検証可能なこと （プロトタイプの目的次第で）機能性、デ ザイン性、体験など 競合ツール応用 MVP 競合ツールを少しだけ改造したり、組み合 わせたり、そのまま使ってもらって、その 価値を検証する。 たとえば動画系サービスなら YouTube の 一部機能と別のツールを組み合わせたりす る。 検証可能なこと サービスの成果に価値を感じてもらえるか 顧客がお金を払ってくれるか
42. 主な MVP の種類 (3) – 手作業型 MVP 手作業を介するもの。主に価値仮説を検証できる。 42 オズの魔法使い型 MVP 外側だけはアプリのようにしておき、中身 の処理は人間で行うもの。 Zappos などがWebサイトだけを作り、注 文があれば自分たちで靴を買いに行って発 送していたような手法や先ほどの dinii の例。 検証可能なこと サービスの成果に価値を感じてもらえるか 顧客がお金を払ってくれるか コンシェルジュ型 MVP 製品と同じ成果を自分の手（手作業、個人 でのコンサル等）で提供する方法。製品は 作らなくても済む。 検証可能なこと サービスの成果に価値を感じてもらえるか 顧客がお金を払ってくれるか
43. MVP の種類と主に検証対象となる仮説 これまでの MVP とそれぞれの MVP が検証できる仮説をまとめ た。 43 MVP の種類 検証できる仮説 ランディングページ 市場仮説 デモ動画 市場仮説 プレオーダー 市場仮説 プロトタイプ （目的による） 競合ツール応用 主に価値仮説 オズの魔法使い 価値仮説 コンシェルジュ 価値仮説
44. 44 もしあなたがこれから MVP を作るなら…
45. コンシェルジュ型 MVP 一択 45 MVP の種類 検証できる仮説 ランディングページ 市場仮説 デモ動画 市場仮説 プレオーダー 市場仮説 プロトタイプ （目的による） 競合ツール応用 主に価値仮説 オズの魔法使い 価値仮説 コンシェルジュ 価値仮説
46. 46 最初の MVP は コンシェルジュ型 ほぼ一択
47. 47 まずは騙されたと思って コンシェルジュ型 からやってみる (多くのアイデアはコンシェルジュ型 MVP で検証できる)
48. コンシェルジュ型 MVP の例 献立を作るアプリやサービスを考えていたスタートアップ 1. 何もアプリを作らずにスーパーの前に立つ 2. スーパーで買い物に悩んでいる人たちに声をかけて、献立を 代わりに考えて、その対価を貰っていた 48
49. コンシェルジュ型 MVP の例 献立を作るアプリやサービスを考えていたスタートアップ 1. 何もアプリを作らずにスーパーの前に立つ 2. スーパーで買い物に悩んでいる人たちに声をかけて、献立を 代わりに考えて、その対価を貰っていた 機械学習を使って企業購買の最適化をするスタートアップ 1. アルバイトとして顧客の会社に入る 2. 自分たちのソフトウェアの提供する予定と同等のサービスを 人力で提供（最適な商品をレコメンドする） 49
50. スケールしないことをしよう、PRの方法 50 例） 最初は自分たちでデリバリーしていた （顧客にとっては、ドライバーが配達しようと創業者が配達しよ うと、食事が届けられるというアウトカムは同じ）
51. 51 コンシェルジュ型 MVP でも 顧客が受け取っている価値は 製品による価値とほぼ同じ （むしろ手作業で丁寧な分、製品より価値が高いかも？）
52. その他、手作業で提供する例 少し頭をひねれば、顧客にとって同じアウトカムを手作業で提 供できる。 52 機械学習での推薦 自分たちで推薦してみる。 実践例） Magic レビューサイト レビューを集めてきて提供 する。ニュースレターなど で情報を送る。 実践例）Product Hunt マッチング 自分たちでマッチングして みる。あるいは自分たちが マッチングを受けた体で働 く。 実践例）Doordash、 HomeJoy、Lugg ロボットや bot ロボットの代わりに人間が その作業をしてみたり、 LINE などで返信してみる。 機械翻訳 コンピュータの代わりに人 間が翻訳する。 実践例）IBM
53. 53 コンシェルジュ型 MVP なら 明日からでもローンチして 価値仮説を検証できる
54. 54 コンシェルジュ型の 丁寧なサービスに対して 顧客がお金を払わなければ その課題は課題ではない （というのは、多少言い過ぎなものの実際ほとんどのケースはそう）
55. 55 次点が オズの魔法使い型 MVP
56. オズの魔法使い型 MVP の例 株式会社 dinii の山田さんに許可を得て転載 56 時間と 人数と 料理を指定し、 事前に 決済 12:30に 1名で 唐揚げ定食1つ 田中さんという 男性の方です 裏でやっていた作業
57. 例）新・日本の最先端 自動改札機（ヨルタモリ） これもオズの魔法使い型 MVP の分かりやすい例と言える。 （外は機械、中は人が手作業） https://www.youtube.com/watch?v=RlF1BUp5jAw 57 動画 （YouTube などで検索してください）
58. 58 手作業や泥臭いことを 厭わない それが MVP を 早く作るコツ
59. 59 手作業型 MVP を 作ろう！ (そして価値仮説を検証しよう)
60. その他の MVP と例 60
61. 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 (作れなかった時のリスクがあるため)
62. ランディングページ MVP の例 SmartHR の初期のやり方はランディングページ MVP をうまく 使ってニーズの検証をした例。 62 当時やったことはですね、ティザーサイトをつくりました。事前告 知サイトみたいなやつですね。「事前登録募集してます。サービス 開始したらメール送るのでメールアドレス登録してください」みた いなサイトをまずはつくりました。 そしてそこにFacebook広告を2万円だけかけました。Facebook広 告ってかなり細かくセグメントが切れるようになっていて、例えば 経営者だったり、人事に興味がある人など、細かくセグメントでき るので、そこで経営者や人事に向けて広告を発信しました。 結果どうだったかというとですね、2週間125件の登録がありました。 これはBtoBではかなりびっくりするような数字で、CPA160円、つ まり1ユーザ当たり160円。 このおかげで、このジャンルは確実にニーズがあるぞという検証が できました。 「その業界を知らなくてもBtoB事業は立ち上げられる」−やり方とコツ− より引用
63. Airbnb のプロトタイプの例 Airbnb も最初は重要な機能がないものをローンチした。 63 • 決済機能ナシ（ホストとゲス トでお金の直接手渡し） • 地図の画面ナシ（ゲストが自 分たちで調べていた）
64. Reddit のプロトタイプの例 Reddit はプロトタイプが何とかなった段階で、それ以上の準備 する間もなく勝手にローンチされた。 プロダクトを作る方法 I / 画像は https://en.wikipedia.org/wiki/File:Reddit_screenshot_2005.png 64 • 6/3 ぐらいから開発開始 • 6/22 に Paul Graham が勝 手にリンクを張って無理やり ローンチ • ローンチしてからのほうが学 びが多かった
65. 65 もし開発する必要があれば 競合ツールやその他のツール をうまく使って検証しよう
66. 用途別のローンチツール 仮説が検証できたら作り直すつもりで、とにかくローンチする。 66 販売系 Shopify で OK。ア ドインを駆使すれば マーケットプレイス 型なども可能。 SNS 系 Mighty Network や Mobilize などを使 う。Discord などか ら始めても良い。 WordPress の Ultimate Member なども。 No Code No Code ツールを 探して作ってみる。 Glide や AppShet、 Bubble など。 WordPress のアド インを駆使するとい う手もある。 その他 Product hunt を漁 ると良いものが出て くることも多い。
67. 少しでも開発をするときの Tips MVP として何かを作らざるを得ないときは、以下のようなルー ルを自分に課すことをお勧めする。 MVP を計画する方法 67 時間を決める 「24 時間で作れるものを作 る」とタイムボックスをあ らかじめ決める。その範囲 で作れるものを作る。必ず その時間内でできたものを ローンチする。 スコープを絞る とにかくスコープを絞って 仕様を削る。 足すことよりも引くことの ほうが難しいので、創造力 や思考能力のいる作業。引 き算の美学を身に着けよう。 文書化する 何が顧客の課題で何を検証 したいのか、メトリクスは 何か、そのために何を作れ ば良いのかを予め文章にし てまとめる。 作り始めると機能などを作 りすぎてしまい、複雑にな ることがよくあるため。自 分を律するためにも文書化 は有効。 例) Amazonはプレスリリー スを書いて考えを整理する。
68. 68 MVP は 1 日で作るもの （その方法を考えるもの）
69. 69 そして 1 日で作れなければ 「時間をかけすぎている」 と言っても過言ではない 明日 MVP をローンチしよう！
70. 70 とにかくローンチする Launch Fast
71. 71 そして顧客から フィードバックと 学びを得よう
72. MVP 開発のダメなパターン 72
73. 73 「どうしても開発をしなければ 仮説検証できない…」 そんなときに陥りがちな罠を いくつか紹介
74. 悪い MVP 開発の例 (1) よく見かける MVP の作り方の悪い例。 74 仮説がないまま作る 「とにかく作る」ことを推したが「とにか く作る」だけでは MVP とは言えない。 何の仮説を検証したいのか、何が顧客の課 題なのかをある程度持ったうえで作らなけ れば多くの場合は無駄になる。 MVP を作った後に課題仮説もより見えてく るけれど、作る前にも仮の仮説を持ってお く。 広く重い上にスコープが変わる MVP のスコープが広くて、開発が重いうえ に、毎回のように作るべきものが変わるよ うなパターンもある。非エンジニア創業者 で、仮説が絞り切れていない場合や見積も りができない場合にありがち。 この場合、作る側のエンジニアが疲弊して、 エンジニアが抜けてチームが解散すること が多い。
75. 悪い MVP 開発の例 (2) よく見かける MVP の作り方の悪い例。 75 フルスペックで外注する スコープが絞り切れていない、非エンジニ アによくあるパターン。 ローンチまで数か月かかるうえ、お金も数 十万～数百万かかる。そして数か月後、十 中八九希望したものは出てこない。 発注するにもスキルが必要なので注意。 エンジニアの言う通りに作る チームに入ったエンジニアが作りたいよう に作って、開発に時間がかかってしまうパ ターン。非エンジニア創業者によくある。 エンジニア側がスタートアップ的なやり方 になれていない人の場合や、非エンジニア 創業者がスコープや仕様を決め切れていな いために起こる。
76. 76 ※優秀なエンジニアがいるなら 1 日のタイムボックスで 作れる幅は広がる
77. 77 けれど開発に手を出すのは 最後の手段 （たとえあなた自身が IT エンジニアであっても） まずは検証するべき仮説を 徹底的に絞り込むこと
78. 78 「最初から全部作らなきゃ」 と思うのは スコープが絞り切れていない （考えきれてない、創造性が足りない） だけかも
79. 素早く、かつ頻繁に出荷する技術 79 仮に何かを作ったとしても MVP は 「バージョン 0」 と思おう (仮説検証できたら作りなおすつもりで)
80. 80 だから 学びを得るためにも…
81. 81 とにかく 雑に 作る
82. 82 とにかく 雑に 作る
83. 83 とにかく 雑に 作る
84. とにかく雑に作れ 84 とにかく 雑に 作る
85. 85 とにかく ※ただし最低限の安全性や コンプライアンスは守ること
86. Photo by Dave Thomas, released under the Attribution Creative Commons license. http://www.paulgraham.com/bio.html 86 人がすごい成果を出せない 最大の理由のひとつは、だ さいものを作ってしまうこ とへの恐れだ。（中略） おもしろいことに、初期の 作品を厳しく見すぎる問題 の解決法は、 そういう見方 そのものが初期の段階であ ると気づくことだ。 Paul Graham “Early Work” Shiro Kawai さん訳『初期の作品』
87. Photo by Dave Thomas, released under the Attribution Creative Commons license. http://www.paulgraham.com/bio.html 87 人がすごい成果を出せない 最大の理由のひとつは、だ さいものを作ってしまうこ とへの恐れだ。（中略） おもしろいことに、初期の 作品を厳しく見すぎる問題 の解決法は、 そういう見方 そのものが初期の段階であ ると気づくことだ。 Paul Graham “Early Work” Shiro Kawai さん訳『初期の作品』
88. 88 初期のものはすべてダサい ダサいものを作ることへの 恐れを乗り越えよう
89. 89 そして雑に作れば 未練なくいつでも捨てられる （自分たちの思い入れも薄くなるし、顧客もその点を考慮して見てくれる） アイデアの変更も容易になる
90. 90 この恐れを乗り越えて とにかく世に物を出し続けた 起業家が勝つ傾向にある
91. 91 この恐れを乗り越えて とにかく世に物を出し続けた 起業家が勝つ傾向にある ＝ この恐れを乗り越えるだけで 優位に立てる
92. 92 とにかく 手作業で 雑に作る
93. Q. 93 どう雑に作れば 良いのか 分かりません……
94. A. 94 MVPの パターンを知っている人に 恐れずに聞いてみよう
95. 95 「〇〇というアウトカムのものを作り たいのですが、どうやって作れば良い でしょうか」 と VC の人などに聞いてみると ヒントをくれるかも
96. 96 「〇〇というアウトカムのものを作り たいのですが、どうやって作れば良い でしょうか」 と VC の人などに聞いてみると ヒントをくれるかも
97. 97 アウトカムとは？
98. MVP の位置づけと ロジックモデル 98
99. 99 顧客が欲しいものは 製品そのものじゃなくて 製品が生み出すアウトカム
100. ロジックモデルで MVP を整理する ロジックモデルは以下のように活動から成果までの流れを整理 する。 100 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム
101. インプット 人、物、金などのリソースがインプットとなる。 101 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム 開発された 製品や機能 製品によっ て顧客が得 る成果 (例: 時間削 減、省力化、 楽しみ) 社会的なイ ンパクト 製品開発の 作業 時間やお金、 人など
102. アクティビティ（活動） 何かしらの活動や行動、作業など。製品開発の場合、開発がア クティビティに当たる。 102 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム 開発された 製品や機能 製品によっ て顧客が得 る成果 (例: 時間削 減、省力化、 楽しみ) 社会的なイ ンパクト 製品開発の 作業 時間やお金、 人など
103. アウトプット 作業の結果出てくるもの。製品や機能そのものが生まれること が多い。 103 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム 開発された 製品や機能 製品によっ て顧客が得 る成果 (例: 時間削 減、省力化、 楽しみ) 社会的なイ ンパクト 製品開発の 作業 時間やお金、 人など
104. アウトカム 顧客やサービス受益者が得られる成果。便益的なものもあれば 感情的なものもある。 104 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム 開発された 製品や機能 製品によっ て顧客が得 る成果 (例: 時間削 減、省力化、 楽しみ) 社会的なイ ンパクト 製品開発の 作業 時間やお金、 人など
105. 顧客が欲しいのは製品ではなくアウトカム 顧客が本当に欲しいのは、製品自体ではなく製品を使って得ら れる「アウトカム」のほう。 105 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム 顧客が本当に欲しいもの
106. アウトカムが提供できる MVP であれば良い コンシェルジュ型 MVP であれば、製品と同じアウトカムを提供 できる（製品より良いアウトカムの場合もある）。 106 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム これを提供できる MVP があれば良い
107. アウトカムが提供できる MVP であれば良い コンシェルジュ型 MVP であれば、製品と同じアウトカムを提供 できる（製品より良いアウトカムの場合もある）。 107 インプット/ リソース インパクト アクティビ ティ アウトプッ ト/実装 アウトカム 作る予定の製品と同じアウトカムを提供できる アウトプットを「手作業」で行うのが 手作業型 MVP
108. 108 顧客の欲しがるアウトカムが 提供できれば どんなアウトプットであれ お金はもらえるはず
109. 109 製品と同等のアウトカムを 手作業型 MVP で提供したときに 顧客がお金を払わなければ その課題は課題ではない （というのは、多少言い過ぎなものの実際ほとんどのケースはそう）
110. 110 製品と同等のアウトカムの MVP を作って とにかく売る Sell it Fast
111. セールス アニマル https://commons.wikimedia.org/wiki/File:Unclesamwantyou.jpg?uselang=ja 111
112. 112 ローンチして 顧客と の話をしてから 本当の学びが始まる
113. 113 MVP を 明日ローンチして セールスを始めて 本当の学びを始めよう！
114. 114 ビジョンは大きく MVP は小さく
115. 115 ビジョンは大きく MVP は小さく 千里の道も一歩から 最初の一歩を MVP で踏み出そう
116. 116 Launch Fast & Sell it Fast
117. まとめ 117
118. 118 MVP は 仮説を検証して学びを得る ために作る 最小限の製品っぽいもののこと
119. MVP の作り方 コンシェルジュ型 MVP を中心に、MVP の作り方を解説した。 119 MVP の主な目的 • 価値仮説の検証 • 市場仮説の検証 MVP の種類 • コンシェルジュ型 MVP（おすすめ ⭐） • オズの魔法使い型 MVP • 競合ツールを使った MVP • No Code ツールを使った MVP • プロトタイプ MVP • スクラッチ開発 • ランディングページ MVP • デモ動画 MVP • プレオーダー MVP
120. とにかく雑に作れ 120 とにかく 手作業で 雑に作る
121. 121 Launch Fast & Sell it Fast
122. 更なる文献 • リーンスタートアップ • MVP を計画する方法 • MVP はプロダクトではなく、プロセスである • どのように料理系スタートアップを立ち上げたか • プロダクトを作る • 素早く、かつ頻繁に出荷する技術 • ローンチする方法（何度も何度も） • プロダクトを作る、ユーザーと話す、成長する 122
123. FoundX の紹介 123
124. FoundX とは 124 東京大学 FoundX は東京大学 産学協創推進本部の下部組 織です。東京大学 本郷キャンパスの近くに 3 つの施設を構 え、起業志望者向けのプログラムを複数提供しています。 投資は行いませんが、無償での個室貸与やプログラムの提 供、起業家コミュニティへの参加を支援します。 興味 情熱 Fellows (6 か月) Pre-Founders (6 か月) Founders (9 か月) ‍‍ ‍ 共同創業者 の説得 有利な 資金調達 フル コミット ビジネス 実績 初契約 初売上 製品開発 と改善 助成金や コンテス ト 賞金の獲 得 Review, Resource, School ➰ 試行 錯誤 アイデア の種 検証された アイデア 起業家の 基礎知識 ＆スキル プロト タイプ 顧客イン タビュー
125. FoundX の提供する起業家支援プログラム & リソース 主に東京大学の卒業生向けに、無償のスタートアップ支援プロ グラムや学習リソースを提供。 125 ‍‍ ‍ チーム向け Founders Program 事業と起業家の成長を、コ ミュニティを通して達成す るプログラム。個室を無償 で最大 9 か月間貸与。 Pre-Founders Program Founders Program に入る までの準備を行うプログラ ム。 個人向け Fellows Program スタートアップ的手法の実 践を通してアイデアを見つ け、育てるためのプログラ ム。 学習リソース FoundX Review 平日ほぼ毎日更新し、ス タートアップのノウハウ情 報を提供。カテゴリ別のま とめは FoundX Resource。 FoundX Online School 動画形式でスタートアップ の基礎を学べる。
126. スライド著者 & FoundX 運営 馬田隆明 (東京大学 FoundX ディレクター） University of Toronto 卒業後、日本マイクロソフトでの Visual Studio のプロダクトマネージャーを経て、テクニカルエバンジェリス トとしてスタートアップ支援を行う。スタートアップ向けのスライド、 ブログなどの情報提供を行う。 サイト: https://takaumada.com/ 126 スタートアップの 方法論の基礎 Amazon (2017年3月) 起業環境の重要性と アクセラレーター の設計方法 Amazon (2019年4月) スタートアップの 公共や規制との 付き合い方 Amazon (2021年1月) スタートアップに ついてのスライド Slideshare SpeakerDeck
127. 127 https://foundx.jp/ ご応募お待ちしています