リーンスタートアップ概論

LEAN STARTUP OVERVIEWRecruit Holdings Recruit Institute of Technology Media Technology Lab Itsuki KURODA @i2key <- Follow me Plz :-)

LEAN STARTUP顧客開発モデルアジャイル開発仮説検証学習のサイクル

リーンに進める際のポイント

No business plan survives first contact with customers.

- Steve Blank

いかなるビジネスプランも顧客と対話すると無傷ではいられない

無傷ではなかった中で、そこから学びを得て成功した例

出会い系サイトを作る ↓

うまく行かない ↓

動画共有機能は良く使われている ↓

動画共有サイトにピボット

位置情報チェックインアプリを作る ↓


写真共有機能は良く使われている ↓

写真共有サイトにピボット

オンライン募金サービスを作る ↓


共同購入機能は良く使われている ↓

共同購入サービスにピボット

オンラインゲームを作る ↓


写真共有機能は良く使われている ↓

写真管理共有サービスにピボット

PDA暗号セキュリティサービスを作る ↓


Web向け送金機能は良く使われている ↓

ネット決済サービスにピボット

世の中の成功してるサービスの60%以上が、最初のビジネスアイデアを捨てている。市場にだして顧客に聴いてみないと分からない。

そこで使える考え方がこれ

一般的には・・・・科学的アプローチによる起業プロセス・仮説構築学びのサイクルを回すこと・・・etc

もう少し噛み砕くと

究極のところは、意思決定をする際に「最も効果的な判断しているかどうか」を必ず問うこと

本講義の結論

ここで言う効果的とは無駄を徹底的に省くこと !

・コストに対する学びを最大化する・失敗による損失を最小化する　≠ 成功を保証するプロセス !

そのために、効率的(例:小さく/短く/安く)に仮説を検証して学びを得る（ことが多い）

本講義の結論

ビジネスアイデア全てを仮説と捉えて、それらを小さく分割して検証すること（大きくやって大きく失敗するの効率悪いよね！！）

本講義の結論

例）写真加工アプリにスタンプ購入機能を作ろう！！やりたいことの実装工数は3人月くらいかかりそうです。 !

あなたがこのプロダクトのオーナーならどうしますか？ !

①決済機能や豪華なマーケット機能を3ヶ月かけて実装しよう！ ②スタンプ購入するボタン（ダミー）を用意して、全体のユーザーの10%で確認して、本当に購入ボタンが押されたら開発に着手する。 ③毎日使い続けてくれているコアユーザーにインタビューしてみる。

ただし、あくまで事例でありテクニックではないので、何でもダミー画面で検証するとかではない。その価値観を学ぶことが大事。

ここで15分くらいならOK

非常に参考になる書籍達①

② ②

③②

④

まとめ

こうやるとよいかも

やってみた

顧客開発モデル

アジャイル開発{

顧客開発モデルについてベンチャーが新規事業を立ち上げるに際に、「革新的な技術」や「アントレプレナーとしての夢」を具現化するために、一生懸命革新的な製品の開発に邁進する。そうした「革新的な製品」って、顧客から求められているものなんだっけ？というところがないがしろにされたまま開発が進むことへのリスクに着目した「製品の開発と並行して顧客の開発を忘れるな」というスティーブ・ブランク氏の主張。

顧客の開発とは

“スタートアップの仕事はイケてる薬を作ることではありません。多くの人が「自分のことだ」と自覚できる病気を作り出すことです。”

http://leanstartupjapan.org/?p=613

・製品開発段階から、「ニーズの存在」、「売れること」、「顧客へのリーチ」を確認する。・顧客志向。顧客をもって確認する。・手戻り、ピボットが前提。

顧客セグメントを明らかにする市場タイプを選ぶ顧客との関係キーパートナー売上/プライシング顧客理解トラフィック/競合分析顧客の行動測定アドバイザリーボードメンバーの選定開始　　　　　：　　　　　：

そのためにやるべきこと

LEAN CANVAS

Product Customer

LEAN CANVAS

①② ③④ ⑤

⑥⑦

⑧ ⑨

リスクの高い順に実証していく（この順番はあくまで例）

実証済み⑤

⑥⑦

⑧ ⑨

リスクの高い順に実証していく（この順番はあくまで例）

実証済み実証済み

実証済み

■よくある質問リーンキャンバスの記述レベル。粒度について。 →特にない。自由で良い。 !

ただし、そのドメイン知識がある人と無い人では出来上がったものは全く違う。自分の戦うドメインの知識が充分にあることが前提。それが無い場合は、顧客に会う、聴く、勉強する。顧客理解を深めると自ずとキャンバスの記述レベルが深くなるし、具体性が増す。これこそが顧客開発でもある。 !

あっさりしたものしか書けない場合は、そのドメインの知識が浅いのかもしれないと一度立ち戻ることも必要。

顧客発見顧客実証顧客開拓組織構築

Problem Solution Fit

Product Market Fit

Pivot

Scaling

アジャイル開発

実証済み実証済み実証済み実証済み

実証済み

実証済み実証済み実証済み






Product Market Fit

Pivot

ユーザーの深い課題/ニーズを把握し解決策を提示しそれが刺さっている

ビジネスモデルの成立することが実証できている

（Engine of Growthが装着できている）例）CAC < LTV

Scaling

例）Retentionしている

Acquisition

Retention

Churn

Referral

Activation

Revenue

余談：AARRRモデル

引用 - Lean Entrepreneur P163

P/S Fitしてない何か

ウォーターフォールではない何か　≠　アジャイル

アジャイル宣言の背後にある原則

http://agilemanifesto.org/iso/ja/principles.html

アジャイルソフトウェア開発宣言

http://agilemanifesto.org/iso/ja/

アジャイル宣言の背後にある原則 !

私たちは以下の原則に従う: 顧客満足を最優先し、

価値のあるソフトウェアを早く継続的に提供します。 !

要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

!動くソフトウェアを、2-3週間から2-3ヶ月という

できるだけ短い時間間隔でリリースします。 !

ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

!意欲に満ちた人々を集めてプロジェクトを構成します。

環境と支援を与え仕事が無事終わるまで彼らを信頼します。 !

情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

動くソフトウェアこそが進捗の最も重要な尺度です。 !

アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

!技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

!シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

!最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

!チームがもっと効率を高めることができるかを定期的に振り返り、

それに基づいて自分たちのやり方を最適に調整します。

「リーン開発の現場」より

どうやって仮説を検証するの？？？ !

MVPってのがあってな

ここで30分ならOK

MVPとはMinumum Viable Product（検証可能な最小限の製品）。 Productと言ってるけど製品じゃなくてよい。目的である仮説を検証できればよいので、それができるものならなんでもMVPと言ってよい（と思う）

Build->Measure->Learn

MVP

ビジネスアイデアを仮説として捉えて検証するためのプロセス。仮説検証のためのMVPをBuildしてそれを元にMeasureし、その結果得られたデータからLearnする。

ファイル同期がいかに便利か、どのように動作するのかのプロモーション動画を作成し、Youtubeにアップロードして、自分のソーシャル上で拡散する事前登録サービスへのリンクを掲載しておき、事前登録してもらえるようにしておく。

WordPressでGrouponスキンをかぶせてブログ形式ではじめて、運用のクー

ポン発行は人力でメール送信。システム化せずにニーズを検証

サンフランシスコにある自分のオフィスのMTGルームを人が泊まれるようにして、Googleに広告を出して、人が応募してきて、お金を払って、泊まるのかを検証して、泊まった人にインタビューしてみる

MVPで検証するMVPで検証する


MVPで検証する


MVPで検証する

MVPで検証する

MVPで検証する

つまり、こういうこと



Product Market Fit

Pivot

Scaling



実証済み





■良くある質問 MVPとは言え、完成品と比べると不完全になってしまうが、それでもユーザーは理解してもらえるのか !

→だからアーリーアダプターで実験する。彼らは製品にかけている部分は脳内で補完してくれる存在。

とはいえ、MVPの粒度どうすりゃいいの？ →場合によります。 !

既存領域にフォロワー戦略で参入するような場合は、どうしても最低限品質が競合と同等になるため大きくなりがち。しかし、そこまでして既存市場に参入するならすればよい。また、例えばゲームを作るのであれば、通常のサービスよりも大きくなる。UIの使い心地などのディテールでUXに差が出易い領域。

このように状況や仮説に応じて色々な検証の仕方ががある。ただし共通する考え方として仮説は検証可能な状態に設計することが大事。（エンジニア向けに説明をすると、テスタビリティの高いコードと似ている。テストコードを書くと自然とテストし易い実装になっていく。） !

コンシェルジュ型人力型（Groupon）クラウドファンディング型（KickStarterで募集）労働力とかでいうと、ランサーズで発注してバリデートダミー型 LP型…etc

ここで45分ならOK

仮説検証の設計の仕方 !

仮説検証のサイクル（BUILD-MEASURE-LEARN）をまわすためには、下記の流れで検証の設計をします。（１）仮説は何か（２）仮説を実証するために、何を学ぶか（３）そのために必要なデータは何か（４）そのデータをどう計測するか（５）計測するために何が必要か（６）それをどう構築するか（複数案考える）　　　その中で最も効果的な方法は何か選択する

①仮説

②何を学ぶのか

③必要なデータは？

④どうやって計測する？

⑤必要なものは？

⑥どう構築するか？

思考プロセス

⑫仮説を調整する

⑪学ぶ

⑩データを元に検証

⑨データを計測する

⑧完成したMVP

⑦構築する

実証プロセス

空いているスペース（もしくは留守中の自分の家）を貸し出せば、それを使ってくれる人がいるのではないか。 ※AirBnBを題材にした本スライド用の例であり私の妄想です !大きなチャンクで実験してもツラいので仮説を分解してみる＜貸し出す側＞・そもそも貸すのか・貸す場合は、借りてがつくクオリティの状態の家がでるのか・需要に対する供給量が確保出来るのか !＜貸りる側＞・本当に借りるのか（リスクが一番高い。優先度1）・どのような部屋なら借りるのか（立地、値段、間取り・・）

例

①仮説・人の家でもお金を払って借りる

②何を学ぶのか・本当に借りるのか・いくらなら借りるのか

③必要なデータは？ 1回以上の利用応募数

④どうやって計測する？（特になし）

⑤必要なものは？集客する装置

⑥どう構築するか？・マッチングサイト構築・自分のオフィス使う

思考プロセス

⑥どう構築するか？ (MVP案1)マッチングサイト作って他人の家を使う (MVP案2)地域を絞って実験する (MVP案3)オフィスを使うもっとも効果的に学びが得られるMVPはどれか選択する・費用対効果・期間・工数・この検証方法により回避できる将来のリスク・この検証方法により逆に発生する将来のリスク

思考プロセス

⑫仮説を調整する

⑪学ぶ

⑩データを元に検証

⑨データを計測する

⑧完成したMVP

⑦構築する (MVP)オフィス

実証プロセス

余談（でも一番言いたいスライド）・プロセスまねたからリーンか？・US西海岸事例（家捨ててコワークスペースに棲む。車売る。　エンジニアリング出来なくても勉強して自分でやる。＝リーンキャンバスなくてもリーン）・でも、取っ付きとしては型があったほうが分かり易い。だから使う。（武道も型を覚えて、そこに心が宿る。　＝　守破離　）

守破離

実証済み⑤

⑥⑦

⑧ ⑨

既にインタビュー、モック、プロト等のMVPによって何処まで実証できているか


実証済み

CUSTOMER SEGMENT ・顧客の想定は明確か　-　セグメント・ペルソナに納得感があるか。・理想的な顧客（アーリーアダプター）の見立てが正しいか　-　リアルにその顧客が顧客の中でのアーリーアダプターに属するか。 !

★想定している顧客が実際にいるか、いる場合のエビデンスもしくは実証実験結果はあるか ★その精度はどれくらいか。

PROBLEM ・想定顧客が抱える課題を構造的に把握し、優先順位が立てられているか。・その課題は深い痛みがあるか。解決すべき課題か。・その想定顧客の現状の代替手段が明確に想定できているか。 !

★その課題の存在を実証できているか ★その精度はどれくらいか。

UNIQUE VALUE PROPOSITION & SOLUTION ・課題に対する解決策が明確かどうか。・アーリーアダプターが既に代替手段で解決している状況において、スイッチングコストを支払ってまでやるべき解決策になっているか。（Facebookでいいじゃん、LINEでいいじゃん、○○でいいじゃんに答えられるか。プラットフォーマーがやったらどうするの？に答えられるか。）・解決策に実現性があるか。（チームのケーパも含む） !

★その解決策によって、課題を本当に解決出来ることを実証出来ているか。 ★その精度はどれくらいか。

★検証精度の高さとは？例えば、「送った写真が１０秒で消えるコミュニケーションアプリが欲しいかまわりの人１０人に聞いて、６人が欲しいと言いました！このソリューションは的を得ています！」という仮説検証結果と、 !

「実際に１０秒で写真が消えてしまうアプリのプロトタイプをつくり、大学の１００人限定で使ってもらったところ、継続率が50％、フリークエンシーが25回/週でした！このソリューションは的を得ています！」という仮説検証結果では、後者の方が検証精度が高い。

究極のところは、意思決定をする際に「最も効果的な判断しているかどうか」を必ず問うこと

本講義の結論

ここで言う効果的とは無駄を徹底的に省くこと !

・コストに対する学びを最大化する・失敗による損失を最小化する　≠ 成功を保証するプロセス !

そのために、効率的(例:小さく/短く/安く)に仮説を検証して学びを得る（ことが多い）

本講義の結論

ビジネスアイデア全てを仮説と捉えて、それらを小さく分割して検証すること（大きくやって大きく失敗するの効率悪いよね！！）

本講義の結論



Product Market Fit

Pivot

Scaling



実証済み





No business plan survives first contact with customers.

- Steve Blank

いかなるビジネスプランも顧客と対話すると無傷ではいられない

ご清聴ありがとうございました！

リーンスタートアップ概論

Documents

Transcript of リーンスタートアップ概論