- Startup Science 2018 完全版のまとめである
- 読んだスライドを要約し、後から有効に使えるようにすること
- なるべく短めにまとめること
- とはいえ現状写経になっているのは否めない...
- 名言系は、これは確実に使えそう、という厳選したもののみとすること
Last active
May 8, 2018 08:42
-
-
Save hamakn/a30a9fa39ea0239260bbc0719cf79b12 to your computer and use it in GitHub Desktop.
Startup Science 2018 完全版のまとめ（あるいは写経）
- スタートアップの93%は失敗する（ただし、成功失敗の定義は書かれていない）
- スタートアップが死ぬ理由は1つ: カスタマーが欲しがるものを作らないから
- 市場を満足させるプロダクトを提供すること = Product-market-fit(PMF)が重要
- 「人が欲しがるものを作れ」 - Paul Graham
- Product-market-fitに銀の弾丸はない
- しかし、ノウハウ・知識を身につけることによって、失敗リスクを下げることはできる
- 成功するスタートアップを作り上げていくセオリーを習得する
- 正しい方向に進んでいるかのコンパスを提供する
- Startupは、開始してからPMFに到達するまでどのぐらい進捗しているかを測ることが容易ではない
- 本スライドでは、各Stageにおけるガイドライン・チェックリストによりStartupが正しい方向に向かっているかが検証できる
- 時期尚早な拡大(Pre-mature scaling)を防ぐためのガイドラインを提供する
- Startupは時期尚早な拡大をしてしまう傾向がある
- 失敗するスタートアップは時期尚早なスケールをする
- 74%のスタートアップがPre-mature Scalingで死んでしまう
- 失敗するスタートアップは時期尚早なスケールをする
- ガイドライン（やるべきこと、やるべきでないことの基準）を持つことで時期尚早な拡大を防ぐことができる
- 結果としてStartupが失敗する可能性を下げることができる
- Startupは時期尚早な拡大をしてしまう傾向がある
- 各ステージでの具体的なアクションのためのツール・ノウハウを提供する
- 網羅的なハウツー/ノウハウ、フレームワーク、チェックリスト、フローチャート
- 包括的な情報を提供する
- スタートアップに関する数多くの書籍・ブログ・動画があるが、包括的にまとまっていない
- スタートアップに必須の知識であるファイナンスを身につける
- 多くのスタートアップが初期のファイナンスや資本政策を間違ったために失敗する
- 全20ステップ
- ⅰ. Idea Verification: 良いスタートアップのアイデアとは？
- ⅱ. Customer-Problem Fit: 本当に問題が存在するのか？
- 5. 課題仮説の構築: カスタマーの抱えている課題が何かを言語化する（ペルソナシート、Empathy map、カスタマージャーニーなど）
- 6. 前提条件を洗い出す: ジャベリンボードを使って課題の前提条件を洗い出す
- 7. 課題〜前提の検証: カスタマーが本当に課題を持っているかを明らかにする
- Founder-Issue Fit: 創業メンバーとイシューが合っているかを見極める
- ⅲ. Problem-Solution Fit: 問題に対してソリューションは適切か？
- 8. UXブループリントを作成する: カスタマーがそれをどのように解決したいかを明らかにする
- 9. Build Prototype: ブループリントをベースにプロトタイプを作る
- 10. Productインタビュー: プロトタイプを実際に使ってもらいインタビューを行う
- 創業期ファイナンス: 創業期のファイナンスを身につける
- Forming team: 核となるメンバーをFixしていく
- ⅳ. Product-Market Fit: ソリューション（プロダクト）に市場は存在するか？
- 11. ビジネスモデルの設計をする: MVPタイプビジネスモデル、KPIの設計をする
- 12. MVPを構築する: MVPのタイプを選び、必要最低機能を持ったプロダクトを作る
- 13. MVP/プロダクトをカスタマーに届ける: エバンジェリストカスタマーに自らデリバリーして学ぶ
- 14. 定量的計測と定性的計測を行う: innovation metricsによる定量計測、カスタマー対話による定性計測を実施する
- 15. プロダクトイテレーションを実施してローンチする
- 16. カスタマーをハマらせるプロダクト/UX施策を実装してローンチする: Hooked modelを使い施策検討し実施する
- 17. ビジネスモデルのPivotを行う
- 資本政策を行う、ベンチャーファイナンスの型を身につける
- PMFを達成するための順応性の高いチーム/ビジネスモデルを作る
- ⅴ. Transition to Scale: スケールするための変革
- このコンテンツは万能ではない
- このコンテンツは、どのスタートアップにも適用できる守破離の守、基本的な型やセオリーを提供する
- 「成功するスタートアップを作るのはArtである、失敗しないスタートアップを作るのはScienceである」
- このコンテンツは一度読んだら終わりではなく、定期的に読み返しナビゲーションとして活用すべき
- スタートアップを始めたい人
- 企業内スタートアップ（イントレプレナー）を始めたい人
- 投資家やエンジェルとして、適切なスタートアップに投資したいと思っている人
- 1. アイデアに気付く: どういう課題を解決するかを明確にする
- 2. スタートアップのメタ原則: 常識とは異なるスタートアップの原則を知る
- 3. アイデアの検証: スタートアップとしての潜在性を検証する
- 4. Plan Aの作成: リーンキャンバスを用いてPlan Aを作る
- サイドプロジェクトで始める
- スタートアップにとって良いアイデアとは何かを理解する
- 一般の企業活動とは異なるスタートアップのメタ原則を理解する
- 変化する外部環境の中で、どの市場を狙うべきかを明らかにする
- リーンキャンバスを使いPlan Aを作成する
- スタートアップのメタ原則を理解できたか？
- 狙うべき市場の検証をしPlan Aを作成できたか？
- スタートアップの原則理解
- 市場の理解
- アイデア検証
- Plan Aの作成
- 課題ドリブン
- 避けるべきことリスト
- PEST分析
- イノベーション理論
- ビジネスアイデアの型
- リーンキャンバス
- リーンスタートアップ
-
良いビジネスアイデア: 「ソリューションではなく課題（issue）にFocusしている」
-
良いビジネスアイデアの見つけ方
- 課題の質を高める
- ソリューションの質を高める
-
ソリューションの質を高めてから、解決する課題の質を高めるというパスは存在しない
- 失敗例
- Google Glass
- スマートウォッチ
- Airtime
- 失敗例
-
発見できる課題の質を高めるもの
- 高い専門性
- 業界（現場）の知識
- 市場環境変化（PEST）の理解
-
ソリューションの質を高めるもの
- あなたしか知らない秘密
-
どれぐらい狂っているか
- スタートアップの最大の競争優位性
- 例: 赤の他人の家に寝泊まりする（AirBnB）
-
99%の人から見たらunsexy、実はsexyなアイデア を考える
- ← 一見悪そうだけど良いアイデア（ただし他の人も知っている）
- ← 誰が聞いても良いアイデア
- ← 一見悪そうだけど良いアイデア（ただし他の人も知っている）
-
誰が聞いても良いアイデア
- 他の企業も検討している
- リソースが多い大企業が有利
- スタートアップは負けてしまうので、選ぶべきではない
- 例: 長持ちするモバイルバッテリーを開発する
-
ただし、悪いように見えるアイデアのほとんどが、ただ単に悪いアイデアである
-
スタートアップアイデアの基準: 人に話すときに恥ずかしいか？
-
「アイデアを出していく上で最も難しいこと、それは優れたアイデアを考えついたときには、最もくだらないアイデアに思えることだ」 - Sam Altman
-
なぜクレイジーなアイデアが求められるか
- ノンコンサンプション（顧客が代替案を持たない状態）をターゲットにすると、シンプルで安価な製品が受け入れられるので、成功しやすいから
- フィードバックが高速化しているから
- プロダクトやサービスの旬な時期がどんどん短くなっている（パラダイムシフトのスピードが上がっている）
- スタートアップがユニコーンに達するスピードが上がっている
- 最初から良いようにみえる
- 既出の誰が聞いても良いアイデア
- 例: ペットのSNS
- ニッチすぎる
- 将来的に成長がない市場である
- 自分が欲しいものではなく作れるものを作っている
- 誰も欲しくない
- 想像上の課題である
- 誰も欲しくない
- 分析からのみ生まれたアイデアである
- 誰も欲しくない
- 激しい競争に切り込んでいくアイデアである
- 一言で説明できないアイデアである
- 誰がその製品を心の底から欲しがっているのか？
- 「ベストは起業家自身であることで、2番目はターゲットユーザをものすごく理解しているのがわかる回答だ」 - Sam Altman
- 自分自身が欲しがっていることは、既出の"発見できる課題の質を高めるもの"に話がつながる
- 世界を見て回ることが関係するかもしれない
- デメリットとして、客観性が失われることに注意する
- スタートアップとスモールビジネスの違いを知る
- 一般企業の常識は忘れる
- スタートアップは常識に反する
- 成功したら巨額のリターン <=> 着実にそこそこのリターン
- 不確実な市場変化に依存しタイミングが重要 <=> 市場は既に存在し市場環境の変化は少ない
- VC <=> 銀行
- 破壊的イノベーション <=> 持続的イノベーション
- アイデアの発見・検証から始める <=> すでにプロダクト・ビジネスモデルの検証が終わっている
- 急成長するようにデザインされた一時的な企業
- 起業のほとんどがスタートアップではない
- 特定の取引先との関係に依存している
- 採算性の健全化から始める（このスライドの20ステップのうち、18.Unit Economicsを計測する から始める）
- 一般企業にとって良しとされる活動が初期のスタートアップにとっては必要がない、むしろ弊害である
- 詳細なビジネスプランを作成する（経営企画経験者にありがち）
- 多くの人から"まぁまぁ好かれる"プロダクトを作る
- 詳細な仕様書を作って開発する（エンジニアにありがち）
- 最初に想定したビジネスモデルに執着する（過去にビジネスの成功体験がある人にありがち）
- 競合を意識し過ぎる、追随しようとする
- 差別化を意識し過ぎる（マーケティング経験者にありがち）
- 正確なFinancial Projectionを作ろうとする（財務経験者にありがち）
- 精緻な会計レポートを作る（会計・監査業務経験者にありがち）
- 精緻なパフォーマンスレポートを作る（マネージャー経験者にありがち）
- Nice-to-haveな機能をプロダクトに追加する（エンジニア経験者にありがち）
- 最初からプロダクトデザインやユーザビリティの高さにこだわる（デザイナにありがち）
- 最初からシステムの自動化・最適化を行う（バックエンドエンジニアにありがち）
- 特定スキルに特化しているエンジニアやスペシャリストをフルタイムで雇う、株を渡す（Pivotするとそのスキルが必要でなくなる）
- 直接関係のないネットワークイベント・飲み会に参加する（営業・事業開発経験者にありがち）
- ビジネスモデルができ上がる前に人を雇う（人事業務経験者にありがち）
- 経歴が立派な営業責任者や事業開発責任者を雇う（自ら顧客と話すべき）
- Doerではなくマネージャーを雇う
- ビジネスモデルの検証が終わる前にパートナーシップを組む（特にカスタマイズが必要な業務提携を行ってはならない）
- 少数の大手企業と独占排他的な契約を結んでしまう（関係依存モデルになってしまう）
- セールスよりもマーケティングにフォーカスする（とはいえ初期カスタマー獲得は必要）（マーケティング経験者にありがち）
- 予算実績の進捗管理を厳密に行う
- Public Relationに積極投資する（PR・広報経験者にありがち）
- 仕事の役割を厳密に設ける（初期メンバーは何でもやる必要がある）
- NDAを交わすことに執着してしまう
- 開発やコラボをするために最新のソフトウェアツールを揃えようとする
- その業界の専門家からのアドバイスに頼る
- キャッシュフローを健全化するために受託開発を必要以上に受けてしまう（Burn-outしないための最低限の受託開発は正当化できる）
- VCに積極的にアプローチする（イケてるスタートアップはVCからアプローチする）
- 資金調達のピッチにリソースを使い過ぎてしまう（ピッチの質は自然に高める）
- 「正しい問題に取り組むほうが、一生懸命に取り組むことよりもはるかに重要です」 - Caterina Fake
- カスタマーの抱える課題の専門家になり、カスタマーに愛されるプロダクトを作る
- 解答用紙に正しい答えを埋めるゲームを忘れる
- 社内で高評価されて、給料をもっともらうために、上司に上手くレポートするゲームを忘れる
- 多くの人に好かれようとするゲームを忘れる
- 少しずつ改善するゲームを忘れる（初期段階では小さな改善よりもPivot/イテレーションにフォーカス）
- 大勢と戦って一番になるゲームを忘れる（競争相手は少なければ少ない方がよい）
- 一定期間内に予算を消化するゲームを忘れる
- 一つの関係性/一つのプラットフォームに依存し続けてビジネスを拡大しようとするゲームを忘れる（スケーラビリティと再現性がない）
- 最初から多くの顧客を獲得して市場シェアの拡大を狙っていくゲームを忘れる（最初はスケールしないことにフォーカスする）
- うまくいかなかったことをチームメンバーの責任にするゲームを忘れる（うまくいかない場合、whoではなくwhyを問う）
- スタートアップに最も大事な要因
- タイミング > チーム（実行能力） > アイデア > ビジネスモデル > 金
- 「なぜ2年前でもなく、2年後でもなく、今そのスタートアップを行っているのか？」 - Micheal Moritz
- 早すぎたプロダクトの例
- ガラケーの位置情報サービス
- セカンドライフ
- プロダクトの進化が止まっている領域はあるか？
- 車椅子
- 日焼け止めクリーム
- 海外送金
- あなたのスタートアップのアイデアは市場を再定義できるか？
-
PEST分析
- P(Politics、政治)、法律・政治・条例の動き、市場ルールを変化させるもの
- E(Economics、経済)、経済の動向、所得や消費の動き、バリューチェーンに影響するもの
- S(Society、社会)、人口動態の変化、文化・流行の推移、需要構造に影響するもの
- T(Technology、技術)、技術革新の進み方、Amazon/Google/Appleなどの動向、競争ステージを変化させるもの
-
変化@2018
- P: ストレスチェックの義務化
- P: トランプ政権による国粋主義への回帰
- T: ガートナーの予想曲線
- T: VR, AI, mobile
- T: Google Home, テスラ3
- S: 日本における介護、IT人材不足
- S: MillennialsからGeneration Zへ
-
新しいイノベーションカーブ
- mobileの進化によるフィードバックの高速化、バーストマジョリティの出現
- パラダイムシフトが起きた直後は、情報が玉石混交である
- 知見を持った人に直接会って、多くの一次情報を集めよう
-
持続的イノベーション
- 既存のカスタマー
- 顕在化したニーズ
- 顕在化したビジネスモデル
- より効率的なサービス/プロダクト
- 過剰品質になりがち
-
例: 電気ケトル vs 既存のポット
-
破壊的イノベーション
- 新しい価値
- 破壊的技術
- 新しい市場
-
Classic Disruption Cycle
- 破壊的イノベーションが勝つ際のよくあるフェイズ進行
- 例: iPhone vs Blackberry
- Overconfidence 過剰な自信
- Sudden Collapse 急降下
- Too little to late 遅過ぎる
- Ongoing decline 撤退
-
なぜ多くの企業は破壊的イノベーションを起こすことができないのか（イノベーションのジレンマ）
- 組織の持つ合理性ゆえ
- 大企業は優秀であるが故にスタートアップに負ける
- 大企業は、機能が最適化という大義のもと分断される
- イノベーション部門が、直接カスタマーと話すことが許されない
- イノベーション部門が、経理の承認無しに予算割当できない
- 予定通りに事業を進めるには、既存顧客により性能の優れた製品を提供する発想に陥る
- スタートアップがアイデアを考える視点: "優秀で合理的な"大企業が狙えない領域はどこか？
-
コラボレーティブなイノベーション
- 既存サービスやそのリソースを活用する
- 破壊的なイノベーションでなくても、組み合わせによって持続的イノベーションを越えることがある
- スタートアップのファウンダはカスタマーと直接話しながらプロダクトを作ることができる
- 例3つ
- スタートアップ最大の競争優位性: 機能によって組織を分断しない
- カスタマーコミュニティと一体化することができる
- 他人が知らないカスタマーインサイトがわかる
- 中間プロセスの排除(Dis-intermediation)
- 中間マージンを得ているプレイヤーを飛ばしてビジネスを再構築する
- 例: アメリカにおけるUber（タクシーのライセンス登録を飛ばす）
- バンドルのアンバンドル化(Unbundle of bundled)
- 機能がバンドルされ過ぎていて価値伝達が非効率になっているものをアンバンドルする
- 例: 新聞をキュレーションメディア、クラシファイド広告、ブランド広告にアンバンドル
- 例: Fintech（銀行の機能（貯蓄、投資、融資、保険、帳簿...）のアンバンドル）
- アンバンドルするときは、10-20%の改善ではなく、10倍(10x)の改善を
- バラバラな情報の集約(Defragment of Fragmented)
- フラグメント化した情報や機能を一つの場所に集約することによって価値を提供する
- 例: 価格.com（ECサイトにフラグメント化した価格情報の集約）
- 使われていないリソースの活用(Under utilized resource)
- 休眠資産を活用することで売上を発生させるモデル
- 例: Airbnb（使われていないゲストルームの活性化）
- 戦略的自由度
- 既存のフレームワークや、競合とのベンチマークを避ける
- 例: snapchat
- メッセージを開けた時のサプライズ、メッセージの消去期間の設定
- アービトラージ
- リソースの需要と供給の格差を用いて価値を提供する
- 例: レアジョブ（日本では英語の学習者の需要が高く、フィリピンでは英語の講師の需要が高い）
- 新しいコンビネーション(New Combination)
- これまでまったく違う領域で活用されていたものを組み合わせて価値を提供する
- 例: airCloset（スタイリスト + フリーシッピング + フリークリーニング + フリークローゼット）
- タイムマシン
- 別の市場ですでに検証されているモデルやプロダクトを他の市場に持ち込む
- 例: インドネシアのバイクのオンデマンドサービス（Uberのインドネシア化）
- ローエンド破壊
- 既存製品の過剰な部分をそぎ落とした安価な製品を提供する
- 例: ケアプロ（ワンコインから可能な健康診断）
- As-a-Service化
- これまでサービスとして提供されていなかったものをサービス化する
- 例: Whim社（フィンランド、様々な交通手段を連携してサービスとして提供する）
- 例: Clarifai（ディープラーニングのSaaS）
- 例: Hachidori（chatbot as a Service）
- YCのdemo dayでピッチしたスタートアップを参照する
- 3-5年後の市場トレンドを反映している
-
Total Addressable Market（対応可能市場）
- さまざまな条件が満たされたときに実現される、あるプロダクトの最大の市場規模
- = エンドユーザ人数 x その人が商品（サービス）に年間に支払う金額
- 100億円以上が望ましい
-
マーケットシェアと、対応可能市場の大きさ、どちらが優先されるか？
- "大きな市場の1%をとっていくというのは、起業家が犯してしまう典型的なミスである" - ガイ カワサキ
- 例: 航空業界
- 顕在化している大きな市場の1%を取ることは非常に難しく、多くのリソースを要する
- 注目されていない限定的な市場で大きなシェアを取ることの方が遥かにハードルは低い
- "小さくてもよいので市場を独占せよ。競争は負け犬のすることだ" - Peter Theil
- つまり先の問への答えは、「まずはエントリー市場で、マーケットシェアを独占すること」
-
エントリー市場とは
- 最初にターゲットにする市場のこと
- ここに属する顧客は、課題を認識し、積極的にソリューションを探しているアーリーアダプター
- エントリー市場で高いシェアを取ってから、周辺市場を攻める
- 例: Amazonが最初に始めた書籍領域
- 書籍ならカタログ化できるし、形状が似ているので発送しやすい
- ベゾスはコンピューターソフトウェア、事務用品、アパレル、音楽など候補となる20種類をリストアップした、結論「書籍が一番いい」だった
- 例: 初期のAirbnbはイベント（大規模コンベンション）をターゲット
- イベントがあると需要に比べてホテルの供給が足りなくなる
- その中でネットワークやノウハウを蓄えた
- 例: 初期のFacebook
- アイビーリーグで局地戦
-
Small Massを狙う
- Small Mass = 現在の市場規模が存在しないほど小さく、市場の成長性にも気づかれていない = 市場に目をつけている人はいない（少ない）が、潜在的に大きな市場
- 既に大きくなっている市場を狙うと、スタートアップは負けてしまう
-
リーンキャンバス
- Running Leanの著者 Ash Mauryaが考案した、スタートアップビジネスモデルをビジュアル化するツール
- 利点
- 高速性: すぐ書ける
- 簡素性: プロダクトの本質を簡単に描ける
- 携帯性: 更新と共有が簡単にできる
-
Plan A（最もハイレベルな想定）としてリーンキャンバスを描いてみる
- Business Plan（事業計画書）はいらない
- ビジネスモデルキャンバスもいらない
- ビジネスモデルキャンバスは、PMFが達成できた企業向け
- Key Parthnership: このフェイズではフォーカスすべきでない
- Key Resources: このフェイズでは時間
- Customer Relationship: このフェイズではカスタマーと話すこと
- Key Activity: このフェイズではカスタマーと話してプロダクトを作ること
- ビジネスモデルキャンバスは、PMFが達成できた企業向け
- リーンキャンバスによるPlan Aは継続的に見直す
-
リーンキャンバスの書き方
- 最近のキャンバスは書く順番がだいたい書いてあるので、それに従うこと
- 基本的には、アーリーアダプター（エバンジェリストカスタマー）が、Plan Aのビジネスモデルを決める
- "想定カスタマーが実際に課題を抱えているか" が一番不確定要素が高い
- そこにフォーカスする!!
- "想定カスタマーが実際に課題を抱えているか" が一番不確定要素が高い
- 初期は1.〜3.が最も重要
- 1.課題 は、上位3位まで書くとよい
- 4.~9.はプロダクトリリース後に変更されるので、簡潔に
- 4.ソリューション は、このフェイズでは本当に課題が存在するかを検証していないので、現時点で想定できる簡素なものでよい
- 5.チャネル は、この時点では選択肢はそれほどない。自分が直接話のできるカスタマーをどう集めるかが重要
- 6.収益モデル は、最初はあまり意識しなくて良いが、できれば無料ではなく値段をつけて売る
- 7.コスト構造 は、将来のコストを正確に計算することはできないので、現在の基準で書く
- 8.主要指標 は、デーブマクルーアの海賊指標（後述）を使うことを推奨
- 9.圧倒的な優位性: 埋めるのが難しい。内部情報、専門家の指示、ドリームチーム、ネットワーク効果、コミュニティー、既存カスタマーなど
-
Double-sided market
- ネットワーク効果が強く、両サイドのカスタマーが増えれば増えるほど、お互いに与える価値も比例して増えていくビジネスのこと
- 例
- オンデマンド型のサービス
- C2Cのマーケットプレイス
- シェアリングエコノミー
- User Generate Contents型のメディア
- 具体例
- Airbnbの場合、貸す側（ホスト）と、借りる側（ゲスト）のダブルサイドになる
- 例
- Double-sided marketのリーンキャンバスは、2種類色を分けて書く
- その両者と、スタートアップ自身の3者が3方良しになるかを検証する
- ネットワーク効果が強く、両サイドのカスタマーが増えれば増えるほど、お互いに与える価値も比例して増えていくビジネスのこと
-
共通言語（リーンキャンバス）をベースに効率的なコミュニケーションを取ることができるから
-
共通の理解 + 納得感
-
リーンスタートアップとは
- 新製品やサービスの事業成功の確度を高める手法
- 新たなアイデアやコンセプトを素早く形にする（MVPを作る）
- 実際のカスタマーの反応を見ながら構築(build)-計測(measure)-学習(learn)のサイクルを反復する
- その中で起業家や開発者の持つ仮説検証を行い学ぶ(validated learning)
-
大多数のスタートアップがピボットする（66%とも）
- ウォーターフォール的なやり方では時間を有効に使えない
- "ピボットとはビジョンを変えずに戦略を変えることである" - Eric Ries @Lean Startup
- = 戦略はピボットできる、ビジョンはピボットできない
- リーンキャンバスを活用して、何をPivotするかチーム全体で納得しながら進めていく
-
スタートアップとはチームプレーである
- チームメンバーの納得感がないピボットは組織の崩壊のきっかけになる
- Easy way to death
- 自分が作りたいプロダクトを作り、リリースして、自分の思い込みを正当化するため計測を行い、PMFを達成する前にBurn-outする
- 注) 1. アイデアに気付く の通り、自分自身が欲しがっていることを出発点にすること自体は良く、そのままプロダクトにしてしまうことが問題(?)
- Hard way to PMF
- カスタマー課題の仮説を立て、直接カスタマーと話してカスタマーの課題について学び、プロダクトをリリースし続け、ピボットして、Burn-outする前にPMFを達成すること
- "スタートアップのアイデアを得る最良の方法は、スタートアップのアイデアを考えようとすることではない" - Paul Graham
- "まず初めにするべきはアイデアを練ること、スタートアップを始めるのはその次です" - Sam Altman
- 良いスタートアップは、サイドプロジェクトから生まれることが多い
- 71%のスタートアップのアイデアが、スタートアップファウンダーが定職に就いているときに生まれている
- サイドプロジェクトのメリット（<=> 定職）
- 好奇心（義務感）
- 自分自身を演じる（会社での役割を演じる）
- 重要性にフォーカス（緊急性にフォーカス）
- 箱の外から考える（箱の内、制約条件から考える）
- 業務上の制約を外す（業務連鎖で考える）
- 未来志向（現在志向）
- 新規ソリューションベース（既存ソリューションベース）
- 未来からの逆算（現行の商習慣）
- 失敗しても次を試せる（失敗を恐れ躊躇する）
- 固定費を極端に減らせる（固定費がかかる）
- サイドプロジェクトで成功した会社の例
- Facebook, Yahoo, Apple
- サイドプロジェクトによる（スタートアップ）適正の見極めをする
- ブレスト / Plan Aの作成などをしながら、お互いの相性や補完性を見極めていく
- メンバーに上下関係なく、フラットな関係で話し合いを進めている状態
- プロジェクトベースでチームを組成する
- 事務作業、コスト
- 株の適切な配分ができないリスク
- 会社の維持が目的になる
- 5. 課題仮説の構築: カスタマーの抱えている課題が何かを言語化する（ペルソナシート、Empathy map、カスタマージャーニーなど）
- 6. 前提条件を洗い出す: ジャベリンボードを使って課題の前提条件を洗い出す
- 7. 課題〜前提の検証: カスタマーが本当に課題を持っているかを明らかにする
- Founder-Issue Fit: 創業メンバーとイシューが合っているかを見極める
- フレームワーク/ツールを活用して課題仮説を作成する
- 課題仮説を検証するために、エバンジェリストカスタマーと対話する
- 対話を通じて、課題仮説を磨き込みフォーカスするべき課題を明確にする
- 創業メンバー候補と課題がフィットするか見極める
- エバンジェリストカスタマーとの対話を通じて、質の高い課題仮説を言語化できたか？
- 課題仮説の構築
- 課題仮説の前提条件、真因の洗い出し
- 顧客と話をする
- 創業メンバーと課題がFitするか見極める
- ペルソナ
- カスタマーストーリー
- ジャベリンボード
- エバンジェリストカスタマー
- 課題インタビュー
- KJ法
- ジョブシャドーイング
-
1.アイデアに気付く の再掲
- 良いビジネスアイデアの見つけ方は、先に課題の質を高めること
- 失敗するスタートアップは、課題の発見・検証をする前に、プロダクトの検証を始めてしまう
- 悪いように見えるアイデアのほとんどが、ただ単に悪いアイデアである
-
最も重要な質問: 想定したカスタマーに課題は"そもそも存在するか？"
- ソリューションを作るのは楽しい、しかし、"楽しい"という罠にハマり"作りたいプロダクト"から始めるのはNG
- "カスタマーはあなたのソリューションに興味はない、興味があるのはカスタマー自身の課題だ" - dave mcclure
- リーンキャンバスで言う両端、課題と顧客セグメントにフォーカスする
-
多くのスタートアップが、"そもそもカスタマーの課題は存在するか？"という問いをスキップしてしまう理由
- "自分が認識している課題は、他の人も同様に認識している課題である" という思い込み（偽の合意効果）
- 人は仮説を支持する証拠だけを探し、反証する証拠を探そうとしない傾向がある（確証バイアス）
- 起業家の確証バイアス = 自分が作るソリューションを使えば、必ずカスタマーの課題は解決できる
- 起業家になる人は、普通の人に比べて、より強い確証バイアスを持つ傾向があることを心に留める
- 特に成功体験がある人
-
"自分自身が物事や課題をどう認識しているか"を、客観的に可視化・言語化する
- 創業チーム間の認識のズレ/過度な思い込み/納得感のないピボットはスタートアップの崩壊につながる
- ドキュメントの共有は、共通の理解ではない
- プロセスや志向・仮説のビジュアル化が、納得感のある共通の理解につながる
- リーンキャンバスのよいところ（4. の再掲）
-
リーンスタートアップにおいても、課題やソリューションの検証をスキップしてとりあえずMVPを作るわけではない
-
創業者に必要な力: カスタマーの目線で、ストーリーをありありと語ること(p.2-58)
-
カスタマーの体験に寄り添う
- 体験は主観的なので数値化が難しい
- ペルソナ、カスタマーストーリ、カスタマージャーニーなどのフレームを使うと、言語化/形式化/因果関係の明確化などができる
-
カスタマーの感情に寄り添う
- 特定の不満や苦悩を探り当てることが大事
- 人は往々にして、自分がやりたいと思っていることではないことを実際にはやってしまう
- この矛盾した行動に焦点を合わせれば、それを探り当てることができる
- 様々な行動を行っているときに、どのような感情を抱いているかを考えてみる
-
なぜ仮説を構築するのか？(p.2-95)
- 仮説を構築する前: 何がわかっていないのか、わかっていない状態
- 仮説を構築した後: 何がわかっていないのか、わかっている状態
- 仮説構築〜検証をすることで、Unknownを減らしていく
-
課題を抱えるカスタマー（ペルソナ）を想定し、その心情や行動にフォーカスする
-
課題に大きな痛みを感じているリアルな人物像を書き出す
-
ペルソナの要素
- 名前、年齢、職業、性別、年収、趣味、生活スタイル、居住地
- 何を課題に感じているか
- どういう印象、どういう性格の人か
- 何を達成したいのか
- どういった業務や仕事をしているのか
- 行動の特徴、ITやスマホのリテラシーは？
-
ペルソナを使う目的
- プロダクト設計プロセスを、より人間中心/課題中心にすること
- 具体的なペルソナを想定することで、"あらゆる人々に気に入られなくてはならない"という無駄な考えを捨てられること
- デザインや機能に一貫性を持ち、UXを高められるため
- カスタマーに対する作り手の思い込みを払拭しやすくなるため
-
ペルソナ構築のtips
- 最初は間違って、後から修正しても良いのでペルソナを定義する（想定するペルソナが多いスタートアップは検証がスムーズに進まないため）
- 特定の場所、時間、イベントというコンテキストを加えて絞り込むことも有効
- 需要に対して供給が少なくなる状況（場所、時間、イベント）では、ユーザが頭を悩ませていることが多いため
- 例: Airbnbは最初にリリースする際にペルソナをデンバーで開催されるコンベンションに参加する人にした、ホテルの部屋が足りなくなることがわかっていたため
- 需要に対して供給が少なくなる状況（場所、時間、イベント）では、ユーザが頭を悩ませていることが多いため
-
例: ホンダスーパーカブのペルソナ
- 蕎麦屋の配達員
- 配達で手がふさがるので、足だけで変速できるクラッチが必要
- 蕎麦を落とさないように、またぎやすいデザインが必要
-
エンパシーマップ（共感図, Empathy Map）とは
- カスタマーをよく理解するためのツール
- 観察結果を合成することで、期待していなかったインサイト（洞察）が得られる
-
エンパシーマップの構成
- THINK AND FEEL: 何を考えているか？どういうことを普段心配して、望んでいるか？
- HEAR: 何を聞いているか？周りの人や上司、影響力のある人は何と言っているか？
- SEE: 何を見ているか？生活環境はどんな感じか、市場をどう見ているか？
- SAY AND DO: 何を言っているか？他の人に対する振る舞いはどうなっているか？
- PAIN: 痛み、恐れ、障害、フラストレーション
- GAIN: 欲求、欲しいもの、必要なもの、成功指標
-
エンパシーマップのtips
- 性悪説を意識しながらエンパシーマップを書くと、よりリアルな人物像に迫ることができる
-
カスタマーストーリーとは
- 現在カスタマーがどのような心理状態で、どのようなステップを踏み、ある行為を完遂しようとしているのかを明らかにするもの
- ペルソナのみだと、ある意味"柔軟過ぎる"
- そのため、想定された結論を補強する役回りを演じさせられてしまうリスクがある
- そこで、カスタマーストーリーを使って具体的な行動に落とし込む
-
カスタマーストーリーを作るメリット
- 手を動かすと思いもよらないアイデアが生まれる
- コト作りというコンテキストで刺さるプロダクトを作れる
- チームでの共通理解が深まる
- ストーリー化することで思考の穴が見つかる
- 優れたカスタマーストーリーを作ることができれば、カスタマーの多様な行動を的確に俯瞰できるようになる
-
カスタマーストーリーの作り方 0. リーンキャンバス、ペルソナ、エンパシーマップを確認・用意する
- ステップ、タッチポイント（登場する人、店、Webサイト、システムなど）、行動、思考、感情、現状の姿の課題点 に分ける
- このペルソナはどういった目標を達成したいのか？その理由は何かを明確化する
- 「わたしは、oooという目標を達成したいと思っています。なぜならxxxだからです」
- 想定したペルソナが体験するステップを、おおまかに書き出してみる
- 想定したペルソナが体験する、詳細の行動を書き出してみる
- 行動の裏にあるペルソナの思考を書いてみる
- ステップごとにタッチポイントを書いてみる
- スマホ/SNSがデファクト化したことに留意する
- ステップごとのペルソナの感情の浮き沈みなどを書いてみる
- ペイン、怒り、不満
- 表面化されるステップ/行動の奥にある、本音（深層心理）を考える
- このストーリーを俯瞰して現状の課題点を書き出す
-
カスタマーストーリーのtips
- アイデアについて、考えた直後にアイデについての単語を書き留めておく
- ポストイットを並べる
- 完全なものを作ろうとしない
- 定期的に更新する
- カスタマーのペインポイントを見つけるツールであり、万能ではないことを認識する
- ユーザを頭で理解すると同時にユーザを感じる
- カスタマーが復数のステークホルダーで構成されるならば、そのステークホルダーのストーリーを書き出してみる
- Double-sided market（既出）の場合は、サービス提供者と消費者の両者のストーリーを書き出す
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment