LEAN STARTUP OVERVIEW

Lean Startup OverviewRecruit Holdings Business Development Office Kuroda Itsuki @i2key

黒田　樹　(@i2key) <= Follow me :-) 前職ではSIerで官公庁系大規模システムのアーキテクト。 Java屋。数多くのデスマを経験。昨年度までは、全世界でシリーズ累計1400万DLのアプリcameranシリーズの開発全体責任者（開発、採用、組織構築、プロセスetc）でした。また、社内外でリーンスタートアップやアジャイルの登壇とかをたまにしています。現在は、今までの経験やノウハウを使い海外のマイナー出資先スタートアップの日本展開支援をしています。

http://99designs.jp

支援先スタートアップ

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

No business plan survives first contact with customers.

- Steve Blank

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

傷だらけになったが、そこから復活を遂げた例

出会い系サイトを作る ↓

うまく行かない ↓

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

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

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


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

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

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


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

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

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


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

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

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


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

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

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

なぜ？彼らは死なないですんだのか

失敗から学びを得ている

ビジネスアイデア全てを仮説と捉えて、それらを小さく分割して検証すること

効率よく失敗して、効率よく学ぶ考え方


効率よく失敗して、効率よく学ぶ考え方


効率よく失敗して、効率よく学ぶ考え方全部仮説全部思い込み

無駄を徹底的に省くこと・思い込みを排除し全てを仮説と捉える・コストに対する学びを最大化する・失敗による損失を最小化する　≠ 成功を保証するプロセス

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

価値観

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

ファイル同期がいかに便利か、どのように動作するのかのプロモーション動画を作成し、Youtubeにアップロード。HackerNewsに流して、事前登録者数をモニタリングでニーズを実証。

仮説を小さく実証する例①

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

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

①フィルター購入機能を3人月かけて実装する　（一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユーザーの10%に表示して確認し、本当に購入ボタンが押された回数を測定してから開発着手の判断をする。工数は2人日。（本当に購入されるのかのみを検証）

②のほうが無駄の無い判断してるぽい

仮説を小さく実証する例②

15

100円で購入

100円で購入

現在開発中です！近日リリース予定です！

＜ポップアップ＞

ユーザー全体の10%にだけ表示されるボタン

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

これはLean Startupとは関係ない

お金のかからないスタートアップ手法速いスタートアップ手法

ショートカット出来るスタートアップ手法

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

③

②

④

導入

How to

Case Study

各種ディテール

非常に参考になる書籍達⑤ビジュアルで全体ふわっと把握

顧客開発モデル

アジャイル開発{

製品コンセプト作り製品開発評価試験発売/リ

リース

製品開発プロセスウォーターフォール型プロセス

保有リスク量

時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop

ウォーターフォール型プロセス

あれ？流行らない。よし、機能追加だ！もっと豪華な

フィルターを売るぞ！

まだまだ機能が足らんぞおおお！マーケットプレイスにすべきだ！！！！

フィルター購入機能をつくるぞ！

3人月

http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop

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

顧客開発モデルによるプロセス

「ヒト・モノ・カネを散々投じた挙げ句誰も欲しがらないものを開発してしまう」という新規事業・新商品の典型的失敗を避けるためのプロセス

4つのステップで顧客相手に仮説検証を繰り返し、リスクを潰していく

[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]

時間

顧客開発モデルによるプロセス保有リスク量

2人日

結果から学ぶ

仮説の実験

結果の計測

時間

保有リスク量

2人日

全体の10%のみに出すダミー購入ボタン作る

計測した結果、全然クリックされていない

需要ないんだね、あぶなかった・・・（リスクがゼロになる）


リスク

時間顧客いる？課題あってる？解決策あってる？


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

そのためにやるべきこと

LEAN CANVAS

LEAN CANVAS

顧客は誰？課題は何？解決策は？

価値は何？圧倒的優位性は何？

コスト構造は？売り上げは？

顧客にリーチするためのチャネルは何を測る？

27

LEAN CANVAS





スタートアップ（新規事業）の初期段階における不確実性（リスク）を

一枚のシートにしたもの ※ただし銀の弾丸ではない

Product Market

LEAN CANVAS

LEAN CANVAS





① ①③②

②③

LEAN CANVAS




顧客にリーチするためのチャネルは何を測る？実証済み

実証済み実証済み

実証済み


実証済み

目指す状態

LEAN CANVAS




顧客にリーチするためのチャネルは何を測る？実証済み


実証済み


実証済み

目指す状態

新規仮説

新規仮説

新規仮説

常に変化するもの（完璧を求めない）

LEAN CANVAS





顧客は誰かその顧客は本当に存在するのか、脳内の空想じゃないかそのカスタマーセグメントである必然性はあるのかカスタマーセグメントが後付ではないかそのカスタマーセグメントとProblemが紐付いているかアーリーアダプターは誰か自分がユーザーですという場合は、自分がそのセグメントの中央にいるか

LEAN CANVAS





解決すべき深い課題かその課題は本当の課題か既存サービスに対する性能的な課題になっていないかその課題はカスタマーセグメントに紐付いているかステレオタイプに対して課題を解決しにいってないか（代替手段があるか、ある場合どうやっているかチームのケーパビリティで解決可能な課題か

LEAN CANVAS




顧客にリーチするためのチャネルは何を測る？課題に対する解決策になっているか

解決策ありきになっていないかアーリーアダプターが代替手段で解決している状況においてスイッチングコストを支払ってまで乗り換えてもらえる解決策になっているかプラットフォーマーがそれやったらどうするの？に答えられるか解決策に実現性が伴っているか（チームケーパ/技術動向/etc）

LEAN CANVAS





ユニークバリューを提供できているか。プラットフォーマーがやっ（ｒｙユニークバリューが圧倒的な○○○であるか（注意も必要）独自の価値提供をできているか。

リーンキャンバスの記述レベル。粒度って、どんくらいすか？

【良くある質問】

決まりはない！自由で良い！

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

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

ただし

Founder / Market FIT


Problem Solution Fit

Product Market Fit

Pivot

Scaling

アジャイル開発

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

実証済み

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






Product Market Fit

Pivot

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

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

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

Scaling

例）Retentionしている

時間

顧客開発モデルによるプロセス保有リスク量

2人日

結果から学ぶ

検証用開発

結果の計測

時間

保有リスク量

2人日

全体の10%のみに出すダミー購入ボタン作る

計測した結果、全然クリックされていない

需要ないんだね、あぶなかった・・・（リスクがゼロになる）


リスク

時間顧客いる？課題あってる？解決策あってる？

顧客開発モデルによるプロセスアジャイル開発一定のペースで、短い感覚で開発を繰り返す。

完璧な製品ではなく、仮説検証に必要な最低限のプロダクトを提供する。

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

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

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

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

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

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

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

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

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

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

意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

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

30

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

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

ければなりません。

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

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

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

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

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

30

いろいろなやり方


30

Dropboxの動画やフィルターのダミーボタンみたいなのをMVPと言ったりしますMinimum Viable Product 実行可能な、生存可能な、存続可能な、最小限の製品仮説を検証するために必要な最小限の何か。・プロダクト・インタビュースクリプト・説明スライド・ペーパープロトタイピング　and so on…

仮説が検証できれば別に完璧な製品である必要はない

仮説立てる->MVPをつくる->測る->学ぶ

MVP

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

つくる

測る

学ぶ

仮説たてる

ECサイトを作らずに、近くの靴屋に売れたら全額支払う&郵送は自分たちでやるといって、靴の商品写真を撮影。サイトにアップ。靴が売れたら創業者がその靴屋で靴を買い自ら顧客に郵送していた。

WordPressでGrouponスキンをかぶせてブログ形式ではじめて、運用のクーポン発行は人力でメール送信。システム化せずにニーズを検証

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

MVPの粒度ってどれくらいですか？

【良くある質問】

知らん！

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


MVPで検証する


MVPで検証する

MVPで検証する

MVPで検証する

こういう場合もあるし

1つのMVPで全ての仮説を検証する

こういう場合もある

リスク


製品開発プロセス


リスク

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


Learn

Build

Build

MeasureMeasure

リスク

時間




Product Market Fit

Pivot

Scaling

アジャイル開発


実証済み





仮説検証の設計の仕方

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

45

①仮説

②何を学ぶのか

③必要なデータは？

④どうやって計測する？

⑤必要なものは？

⑥どう構築するか？

思考プロセス

45

⑫仮説を調整する

⑪学ぶ

⑩データを元に検証

⑨データを計測する

⑧完成したMVP

⑦構築する

実証プロセス

空いているスペース（もしくは留守中の自分の家）を貸し出せば、それを使ってくれる人がいるのではないか。 ※AirBnBを題材にした本スライド用の例であり私の妄想です

大きなチャンクで実験してもツラいので仮説を分解してみる＜貸し出す側＞・そもそも貸すのか・貸す場合は、借りてがつくクオリティの状態の家がでるのか・需要に対する供給量が確保出来るのか

＜貸りる側＞・本当に借りるのか（リスクが一番高い。優先度1）・どのような部屋なら借りるのか（立地、値段、間取り・・）

例

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

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

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

④どうやって計測する？

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

⑥どう構築するか？・マッチングサイト構築・Googleアド

思考プロセス

⑥どう構築するか？ (MVP案1)マッチングサイト作って他人の家を使う (MVP案2)自分のオフィス泊まれるアド出す

もっとも効果的に学びが得られるMVPはどれか選択する・費用対効果・期間・工数・この検証方法により回避できる将来のリスク・この検証方法により逆に発生する将来のリスク

思考プロセス

⑫仮説を調整する

⑪学ぶ

⑩データを元に検証

⑨データを計測する

⑧完成したMVP

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

実証プロセス

Acquisition

獲得 Retention

継続Churn

解約

Referral

紹介

Activation

活性化Revenue

収益

AARRRモデル復習

※ChurnはAARRRには無いけど勝手に付け足しました

LEAN STARTUPを理解した上で

他流（AARRR）に目を向ける

Acquisition

Retention

Churn

Referral

Activation

Revenue

一番大事

継続して利用してくれているということは顧客の課題を解決していること

（それが想定していない課題を解決してることもあるけど）

ユーザーがプロダクトに価値を感じている状態エンゲージしている状態


継続して利用してくれているということは顧客の課題を解決していること

（それが想定していない課題を解決してることもあるけど）

ユーザーがプロダクトに価値を感じている状態エンゲージしている状態


AARRRAARRR



Product Market Fit

Pivot

Scaling

Acquisition

Retention

Churn

Referral

Activation

Revenue

一番大事

最もスループットの低い部分が、全体のスループットを決める（鎖の強度は、最も強度の弱い輪が全体の強度になる）

最もリスクの高い部分から、検証していく

LEAN CANVAS





リスク高リスク中リスク中

リスク中

リスク中リスク中

リスク中

リスク中

LEAN CANVAS

①②

②②

③⑩

⑤

⑩

⑫ ②

⑩

⑩

鎖の強度が弱い

Growth Hack(er)AARRR

LEAN STARTUPCustomer Development

メタレベルでとらえるとどれも言ってる本質は同じ

Theory of Constraints(ToC)

Agile

車を売るオフィスを引き払う

コワーキングスペースに住みつく

エンジニア雇うお金が勿体無いから自分で勉強してコードを書く

西海岸スタートアップではファウンダーは・・・

黒田「リーンキャンバスの書き方を相談したいのですが」

ファウンダーA「何それ？リーンキャンバスって何？」

500 startupsに入ってるとあるスタートアップとの会話

黒田「スティーブブランクのスタートアップマニュアルに　　　こうかいてあったんですが、どうやりました？」

ファウンダーB「何それ？へー、そんな本あるのか」

500 startupsに入ってるとあるスタートアップとの会話

資金のバーンダウンしていく速度をいかに遅くしてなおかつ学びを得るか、そして成功するか

Growth Hack(er)AARRR

LEAN STARTUPCustomer Development

メタレベルでとらえるとどれも言ってる本質は同じ

Theory of Constraints(ToC)

Agile

無駄を徹底的に省くこと・思い込みを排除し全てを仮説と捉える・コストに対する学びを最大化する・失敗による損失を最小化する　≠ 成功を保証するプロセス

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

価値観

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


Product Market Fit

Scaling

実証済み

顧客/課題存在するか

解決策あってるか

解決策に顧客はお金はらうか





リスク


ウォーターフォール型プロセス


Learn

Build

Build

MeasureMeasure

リスク

時間


リスク

時間カスタマ課題 UVP/解決策






No business plan survives first contact with customers.

- Steve Blank

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

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

LEAN STARTUP OVERVIEW

Business

Transcript of LEAN STARTUP OVERVIEW