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%以上が、最初のビジネスアイデアを捨てている。 市場にだして顧客に聴いてみないと分からない。

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

失敗から学びを得ている

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

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

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

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

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

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

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

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

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

価値観

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

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

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

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

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

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

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

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

15

100円で 購入

100円で 購入

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

＜ポップアップ＞

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

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

これはLean Startupとは関係ない

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

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

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

③

②

④

導入

How to

Case Study

各種ディテール

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

顧客開発モデル

アジャイル開発{

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

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

リース

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

保有リスク量

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

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

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

フィルターを売るぞ！

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

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

3人月

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

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

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

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

アジャイル開発

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

実証済み

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

実証済み 実証済み

実証済み実証済み

実証済み 実証済み

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

Problem Solution Fit

Product Market Fit

Pivot

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

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

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

Scaling

例）Retentionしている

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

時間

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

2人日

結果から学ぶ

検証用開発

結果の計測

時間

保有リスク量

2人日

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

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

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

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

リスク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30

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

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

ければなりません。

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

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

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

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

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

30

いろいろなやり方

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

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で検証するMVPで検証する

MVPで検証する

MVPで検証する

MVPで検証する

こういう場合もあるし

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

こういう場合もある

リスク

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

製品開発プロセス

リスク

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

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

Learn

Build

Build

MeasureMeasure

リスク

時間

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

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

Problem Solution Fit

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

一番大事

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

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

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

Problem Solution Fit

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

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

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

Problem Solution Fit

AARRRAARRR

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

Problem Solution Fit

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

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

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

価値観

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

Problem Solution Fit

Product Market Fit

Scaling

実証済み

顧客/課題 存在するか

解決策 あってるか

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

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

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

実証済み 実証済み

実証済み 実証済み

リスク

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

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

Learn

Build

Build

MeasureMeasure

リスク

時間

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

リスク

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

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

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

実証済み 実証済み

実証済み 実証済み

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

No business plan survives first contact with customers.

- Steve Blank

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

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