Startup Science 2017 拡大版（1750page）8/10

1750ページ拡大判
Startup Science 2017 ⑧
アイディア作りからスケールまで
スタートアップの作り方
20ステップを徹底解説

Product-market-fit
MVP/プロダクトを
カスタマーに届ける
ビジネスモデル
の設計をする
MVPタイプ
KPIの設計をする
MVPのタイプを選び、
必要最低機能を持った
プロダクトを作る
エバンジェリスト
カスタマーに
自らデリバリー
して学ぶ
innovation
metricsによる定量計測
カスタマー対話による
定性計測を実施
Hooked model
を使い施策検討し実装
カスタマーをハマらせる
プロダクト/UX施策
を実装してローンチ
カスタマーに価値を届ける
イテレーションを実装
プロダクト
イテレーションを
実装してローンチ
定量的計測と
定性的計測を行う
MVPを
構築
PMFを達成
するまで
回し続ける
ビジネスモデルをpivotする
ビジネスモデルの
Pivotを行う
Copyright 2017 Masayuki Tadokoro All rights reserved
Startup Science 2017
PMFを達成するための
順応性の高い
チーム/ビジネスプロセス
を作る
必要に応じて
Seedの資金調達を
行う

”我々は神を信じる
神じゃない人間は
データを持ってこい”
-エドワード・デミング

新たなアイデアやコンセプト
を素早く形にして（MVPを作る）
実際のカスタマーの反応を見ながら
構築(build)－計測(measure)－学習(learn)
のサイクルを反復する。
その中で起業家や開発者の持つ仮説検証を行い
検証による学び（validated learning）
を通じて新製品やサービスの
事業成功の確度を高める手法
リーンスタートアップ：
Build
Ideas
Product
Mea
sure
Data
Learn
データを計測しながら
次に活かしていく

”定性的に発見をして、
定量的に証明しましょう”
- Alistair Croll
Lean Analytics 著者

”計測できないものを
管理することはできない”
P.F. ドラッカー

質問
❓
初期のスタートアップ
は何を計測するべきだ
と思いますか？

AARRRR(海賊指標）を導入する
Acquisition: 獲得
Activation: サインアップして、
最初の体験に満足する
Retention: 継続利用
Revenue: 売り上げ上げる
Referral: 他のカスタマーの紹介
AARRRはカスタマー獲得から獲得したカスタマー
が収益を生み出すまでの一連の流れを、
5段階に分けて活動を進めるフレームワーク
AARRR！

マーケティングにリソースを導入した
分しか、レベニューが伸びていない
マーケティング費用を５倍かけて
５倍のカスタマー獲得を行う

Product-market-fit
(人が欲しいものを作れる状態）
の前に、プロダクトの口コミや
カスタマー獲得を積極的に促進しても意味がない
むしろ、ネガティブな結果になる
PMFを達成する前に
Referralやカスタマー獲得にこだわるな！

大勢のユーザーをハッピーにする前に、
一人のユーザーを完全にハッピーにするには
どうすればよいのかを考える

多い
少ない
最初は
ユーザー数を
増やすのではなく
エンゲージメントを
高める！
ユーザー数
(Traction)
プロダクトに対する
ユーザーエンゲージメント
大ファンそこそこ
好き

１００万人のユーザーが、
そのサービスを”そこそこ好き”と言っている
その１００万人を
大ファンにするのは非常に難しい

ユーザー数
(Traction)
好き
X
この
パスは存在しない
多い
少ない

百人に愛されれば
その百人が、それぞれが知人百人に
プロダクトを薦めてくれる

エンゲージメントを
高めてから
ユーザー数を増やす
ユーザー数
(Traction)
好き
多い
少ない

バックログ仕掛り中完了検証
バックログ
ストーリー
このイテレーション
で学習したい
ストーリーを抽出
構築
構築完了
ローンチ
定量検証
（スプリットテスト
、コホート分析）
カスタマーと話して
定性検証/
内省する
ストーリーカンバンボード
Activation/
Retention/
Revenue
を計測する
MVP
ストーリー
ストーリー
１−１
ストーリー
１−２

Retention（定着率）
はカスタマーが
あなたのプロダクトを
どの程度愛しているかを示す指標である

登録後三日以内の
ログイン率
ユーザー一人あたりの
１日平均広告視聴回数
登録者画面に
きたUU数
一連の作業を
最後までやった
ユーザー割合
KGI
登録画面
に初めて来る
メニュー
画面
広告視聴
開始
広告視聴
完了
wifi使用
開始画面
wifi使用
開始
再ログイン
画面
メニュー
画面
広告視聴
開始
広告視聴
完了
Acquisition Activation Retention Revenue
KPI 登録者画面に
きたUU数
メニュー
画面の
離脱率
視聴
開始率
視聴
完了率
使用
開始率
ログイン画
面の
離脱率
メニュー画
面の
離脱率
サイン
アップ率
サイン
アップ率
Anytime onlineのMVPローンチして
その結果（AARRR)を計測する

ログイン率
登録者画面に
きたUU数
一連の作業を
最後までやった
ユーザー割合
KGI
登録画面
に初めて来る
メニュー
画面
広告視聴
開始
広告視聴
完了
wifi使用
開始画面
wifi使用
開始
再ログイン
画面
メニュー
画面
広告視聴
開始
広告視聴
完了
Acquisition Activation Retention Revenue
KPI 登録者画面に
きたUU数
メニュー
画面の
離脱率
視聴
開始率
視聴
完了率
使用
開始率
ログイン画
面の
離脱率
メニュー画
面の
離脱率
サイン
アップ率
サイン
アップ率
Anytime onlineのMVPローンチして
その結果（AARRR)を計測する
結果 335人 302人 93人 23人
4.2回
（合計96回）

MVPの
計測結果（実数）
MVPの
計測結果（割合）
アクイジション
（訪問者）
３３２人 100%
アクティベーション
（登録）３０５人 90%
（作業完了）９３人 30%
Retention
(三日以内再訪）２３人 25%
Revenue
（ユーザー一人あたりの
１日平均広告視聴回数）
4.2回 4.2回
結果を定量的/ 割合で表す
比率で
表現する

なぜ、計測することが重要なのか？
目標に向かって自分たちが、
どこにいるのかを
正しく認識するため
目標と現状のギャップを
認識した上で、そこを埋める
アクションアイテムを導く
KPIはステークホルダー間で
の共通言語になる

目標と現状のギャップを
認識した上で、そこを埋める
アクションアイテムを導く目標
MVPの
MVPの
目標値
（訪問者）
３３２人 100% 100%
（登録）３０５人 90% 95%
（作業完了）９３人 30% 80%
Retention
(三日以内再訪）２３人 25% 80%
Revenue
4.2回 4.2回１０回

優れた指標とは？
優れた指標は
チェックしやすい
優れた指標は
わかりやすい
優れた指標は
行動につなげやすい
（アクション出来る
適切な粒度にする）
優れた指標は
因果指標である
（他の指標の変化を
引き起こす指標）

KPI設定する際にありがちな罠
結果指標しか見ていない：
UU, PV, 売り上げ、CPA
など
相関指標を見る：
因果関係でなく
相関関係を見てしまう
アクションできない指標を見る
粒度が荒い新規率、リピート率
を指標にして、
など次の行動が思いつかない

KPIの設定はよく間違う
ビジネスにとって
そのステージで
適切なKPIを計測しているのかを
継続的に検証する

ただし、虚栄の指標を捨てる
ページビュー：ページを踏んだ数、アド広告やバナーなどを
設定していなければ意味が無い指標である。
訪問数：誰がどれくらいの頻度で来ているのかが
わからないので意味の無い指標である
ユニークな訪問者：サイトに来て何をしたかがわからない
ページにとどまったのか、離れたのかが検証できない
ページの滞在時間：どのページに滞在していたかを計測しないと意味が無い、
サポートページやFAQにいたら、カスタマービリティーが
悪いことを示唆している
メールサインアップ数：プロモメールを打ってみて実際に
どれくらいの数がオープンされたか
わからないと意味がない。
Follower, Fan, Like：数だけだと意味がない、
重要なことは何かを売り込んだ時に、
どれくらいの人がアクションをしてくれるか

So
What ?
虚栄の指標は、現状の姿を現している
が、”だから何？”というもので
行動に結びつかない

”Vanity Metrics（虚栄の指標）
はあなたを安心させるが
何をするべきか明確な
ガイダンスを提供しない”
- Eric Ries
Lean Startup

計測を続ければ、右肩あがりの指標
（確証バイアスを正当化する指標）は見つかる
売り上げは
上がっていない
Page view
を計測すれば
上がっている
time
Page
View
page view
revenue

自分の見たいものだけを
見る傾向がある
人間は現実湾曲空間の中
で生きている

自分たちのプロダクトがイケてる、
と勘違いしてしまうVanity Metricsは
至るところにあるので要注意
Wantedly のランキング、
Facebookのフォロワー、
Product huntでのランキング、
インフルエンサーにプロダクトが
tweetされたことなど

学習したいこと
学習するために検証するストーリー検証するためにどの指標を計測するか？
何を構築するか構築にかかる
コスト・時間
定量的な結果定性的な結果
得た学びは
次回以降のスプリントで学習したいこと
カスタマーはwifi使用容量を増やし、
その使用容量を活用できるか？
カスタマーがアプリ起動、サインアップする。
広告視聴を行い、貯めた容量を活用する
Activation: 登録率、一連操作完了率
Retention:三日以内再訪問率
Revenue:１日あたりの１日平均広告視聴回数
20人日/２週間
イテレーションキャンバス
Activation: 30%
Retention:25%
Revenue: １日４回
(Product面の学び) (Sales面の学び)

数字の裏にいる
人の話を聞こう

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
カスタマーの
話を聞く
MVP
ストーリー
ストーリー
１−１
ストーリー
１−２

ユーザーが体感することは
ユーザーの主観で成り立っている。
定量的データだけでは、
主観的なインサイトが
削られてしまっている。

MVPを実際に使った
カスタマーにインタビューをする

・このプロダクトを使って価値を感じましたか？
・もっとも価値を感じることができたフィーチャーの
Top3はなんですか？
・なぜそれらのフィーチャーに価値を感じることができ
たのですか？
・使わなかったフィーチャー、価値を感じることができ
なかったフィーチャーはなんですか？
・なぜ、それらのフィーチャーの価値を感じることがで
きなかったのですか？
・このプロダクトを家族や仲の良い友人に勧めますか？
MVPインタビューの質問例

カスタマーからの
フィードバックは
”事前の仮説を覆すもの”
”耳がいたいものほど”
重要である

ビッダーズ初期のメール
やり取りはすべて目を通し、
特に大きな問題や厳しい叱咤、
常軌を逸したクレームには
カスタマーサポートに変わって、
創業者である南場がメールを書いた
”不恰好経営”より

Start-up Founderはカスタマーと直接話しながら
プロダクトを作ることができる
スタートアップの競争優位性

カスタマーとの対話
（Voice of Customer）から
インサイトを引き出す

カスタマーの声そのものは
カスタマー自身の素人分析や
表面的であることが多い
ただ単に
カスタマーの声を聞くだけはNG

カスタマーの声を
KJ法で定性的に検証
①インタビュー
データを集める
②データを
細かい単位に
分ける
③カードを
平面上に
展開して
グループ化する
④ひとまとめした
カード群にその
グループを適切に
表す表札をつける
⑤グループ相互の
関連性を最も
論理的に説明できる
ようカードを並べる
⑥カスタマーの成功
の本当の要因（真因）
を言語化する
カスタマーの成功
要因
要因
真因

カスタマーの言葉
インサイト
インサイト
最も深い
インサイト
カスタマーインサイトの検証
つまり、
どういうことか？
つまり、
つまり、

インタビュワー：本日はお時間ありがとうございます
キャサリン（カスタマー）：どういたしまして。
インタビュワー：１週間ほど、弊社のサービスを活用いただいて
ますが、いかがでしょうか？
キャサリン（カスタマー）：満足しています。広告を視聴するこ
とで、使用できるwifiの使用量が増えるのはとても便利です。
インタビュワー：なるほど、なぜ、便利に感じるのですか？
キャサリン（カスタマー）：私は、いつでも、どこでもYoutube
を見たいと思っているので、使用量が減ってきたら、また広告を
みて容量を足すことができるからです。
カスタマーと話す

インタビュわー：なるほど、Youtubeを見るので、常に容量が
減っていくので、継続的に広告を見て容量を足したいというこ
とですね。
キャサリンさん（カスタマー）：そうです。だいたい、
Youtube５分みると10MBを使い切ってしまいますので、また、
広告視聴に戻って、10MB足すという行為を繰り返しています
。
インタビュワー：なるほど、興味深いですね。その時はどんな
気持ちになっていますか？
大久保さん（カスタマー）：正直、少し面倒くさいと感じてい
ます。一気に、もっと容量を増やすことができれば、使い勝手
が向上すると思います。

カスタマーの声：とても便利である
インサイト：動画を見るために
容量を継続的に加算できる
インサイト：広告を見て
動画をみるというのは少し面倒くさい
一回あたりの
使用容量を
増やしたら
使い勝手が上がる
Anywhere Onlineの事例
つまり、
つまり、
つまり、

コスト・時間
得た学びは
20人日/２週間
Activation: 30%
Retention:25%
使い勝手に、難があるが
カスタマーは価値を感じながら
ソリューションを使っている

もしCRM
システムがあるなら
貯めていく

MVPにすぐに見切りを
つけるのはNGである
一定期間辛抱する
十分な定量データ、定性フィードバック
を獲得にしておく

コスト・時間
得た学びは
20人日/２週間
Activation: 30%
Retention:25%
プロダクト面
の学び

MVPで学んだことをチームで
言語化・検証していく
チーム
”MVPを通じて学んだこと”

チーム内で検証すること
・カスタマーはなぜプロダクトを使ったのか？
・カスタマーはプロダクトのどのフィーチャーに価値を感じたのか？そ
れはなぜか？
・カスタマーはなぜプロダクトを使わなかったのか？
・カスタマーはプロダクトのどのフィーチャーに価値を感じたのか？そ
れはなぜか？
・自分たちの立てたプロダクトの価値仮説はどこが正しくて、どこが間
違っていたのか？
・カスタマーの考えるプロダクトの評価基準と、自分たちの想定したプ
ロダクトの評価基準は合っていたか？ずれていたか？
どこが合って、どこがずれていたか？
・MVPからの最大の学びは何か？
・どの既存フィーチャーの改善が必要か？どの既存のフィーチャーを
廃止する必要があるか？どのような追加フィーチャーを加える必要があ
るか？

コスト・時間
得た学びは
20人日/２週間
Activation: 30%
Retention:25%
Sales/提案
の学び

Sales面/Channelでの学びを検証する
(特にB2Bプロダクトでは有効）
・プロダクト購入の検討に登場する人物は誰か？
（B２Bの場合）
・もし複数の人が存在するならば、どういった組織相関図に
、どういった価値提案をすればよいか？
・どの階層の顧客を入り口として開拓すればよいか？
・納得して購入してもうためにはどのような方法が有効か？
・営業を走らせてみて、一連のプロセスの中で、どのタイミ
ングが一番リスクが高いか？
・どういった反対勢力が想定されるか？その反対勢力が
反対する理由は？（Total cost of Ownership, 現状変革initiaか
？）

組織的な知識創造をプロセス化する
暗黙知暗黙知
暗黙知暗黙知
形式知形式知
形式知形式知
個人個人 G
個
個
個
個
個
個
個人
G
G G
G
身体や五感を駆使、
直接経験を通じた
暗黙知の獲得
対話、施策、比喩
による概念の仮説の
創造
形式知の組み合わせに
よる知識の体系化
形式知を行動を
通じて具現化
新たな暗黙知として
理解する

新たな知（＝インサイト）は、
経験に基づいて暗黙のうちに持つ
主観的な「暗黙知」と、
言葉で表現できる客観的な「形式知」が、
対話を通して相互に変換し、
スパイラルに循環していくなかで生まれる。
野中郁次郎
一橋大学名誉教授

カスタマー
からの定性的
フィードバック
チーム
定量的なデータ
社内の
学びとして
蓄積していく
学びの蓄積

大手の無印良品も顧客からの声を聞き、
プロダクトに活かしている（年間で17万件！）
http://lab.muji.com/jp/ideapark/
顧客からの
要望

顧客の声をベースに商品化

店頭やネットで
購入することができる

次のステップを
どうやって決めるか？

このフローチャートは
あくまでレファレンスである
起業家はすべてのこと
（UX改善、Productのイテレーション、
Pivotの検討、顧客と話すこと）を
同時に進めると必要がある

専門性特化型
エンジニア
技術志向エンジニア
P/S
Fit
共同創業
メンバー
Fix
実験/MVP構築
Pivot
プロダクト構築
ユーザー
獲得
グロース
マネージメント
Ideation/
Plan A 作成
C/P
Fit
共同創業
メンバー
フィルター
Ideation P/M
Fit
チーム組成
(10〜名）
創業メンバー
プラスα
３-10 名程度
s
スタートアップのステージによるチームの編成
サイド
プロジェクト
で始まる
UX
デザイン
Vision Selling/Team Building
Transition to
Growth
Stage
リソース
配分
Team
起業家はあらゆることを
同時に進めていく
必要がある
資金調達

起業家は同時並行に
すべてのことを
やる必要がある
ガイカワサキ

ただし、何の基準もなく進めると
ぐちゃぐちゃになってしまい
チームが崩壊するリスクが高まる
（例えば、主観的なピボットや、
データに基づかない
プロダクトイテレーションなど）

Pivotやプロダクトイテレーション
のような重要な意思決定は
行動ガイドラインが必要になる

No
Yes
ストーリーカンバンボードに
ストーリーとして追加
プロダクト（MVP)を
ローンチして定量・定性分析する
PMFを達成できたか？
同じビジネスモデル
で改善続ければ達成できそうか？
スケールするために
組織をトランジションする
Yes
Pivotを検討
No
Yes
No
次のステップを決定するフローチャート
Yes
No
タスクカンバンボードに
フィーチャーとして追加
大きなフィーチャー /
工数はかかるか？
Yes
No
大きなフィチャー/
既存フィーチャのUX/機能改善
を検討
プロダクトの既存フィーチャーの
みで十分な価値を提供しているか
？
フィーチャー追加による
プロダクトイテレーションを検討

Product-market Fitは
達成できたか？

”PMFがないと、製品の価値が顧客につたわならい
口コミが広がらない、利用が加速しない。
メディアの評判が最低、販売サイクルに時間がかかる。
PMFがあるとすぐにわかる。
製品を作ると顧客が買いに来る。
サービスを追加すると利用が拡大する。
営業や顧客サポートのスタッフが雇える。
記者から連絡がある。”
- マークアンダリーセン
“Traction”より

PMF達成基準
チェックシート
・高いリテンションを保てるか？
・カスタマー獲得から売り上げを上げるまで再
現可能なパターンがあるか？
・リーンキャンバスの全体をみて成立している
か？

ショーン・エリス
４０％以上のユーザーが
“プロダクトがなくなったら非常に残念”
と答えたのであれば、
そのプロダクトは今後も継続的に
顧客を獲得できる。
“Traction”より

Product-market-fitが
達成できていないならば、
達成するための”次の施策”を考える

Product-market-fit
MVP/プロダクトを
カスタマーに届ける
の設計をする
MVPタイプ
KPIの設計をする
MVPのタイプを選び、
必要最低機能を持った
プロダクトを作る
エバンジェリスト
カスタマーに
自らデリバリー
して学ぶ
innovation
metricsによる定量計測
カスタマー対話による
定性計測を実施
Hooked model
を使い施策検討し実装
カスタマーをハマらせる
プロダクト/UX施策
を実装してローンチ
カスタマーに価値を届ける
イテレーションを実装
プロダクト
イテレーションを
実装してローンチ
定量的計測と
定性的計測を行う
MVPを
構築
PMFを達成
するまで
回し続ける
ビジネスモデルをpivotする
ビジネスモデルの
Pivotを行う
順応性の高い
チーム/ビジネスプロセス
を作る
次のステップを
検討する
次の施策を検討する

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
プロダクトの既存フィーチャーは
十分な価値を提供しているか？
次の決定を
する際に参考にする

Business Model 1 Business Model 2 Business Model 3
時間
MVP Version2 Version4Version3 Version6Version5
改善改善改善改善改善改善改善
改
善
改
善
改
善
Pivot Pivot
同じモデルを保っても
PMFが達成できない場合
はPivotを行う

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
同じモデルを保っても
PMFが達成できない場合
はPivotを行う

Co-founder
Vision
Strategy/
Business model
Product/
Feature
UX
変更頻度
多い
変更による
事業インパクト
極大
小
（会社設立後は）
ほとんどなし
Pivotのインパクトは
大きいので慎重に行う
べきである

Stage
Customer
Problem-fit
Problem
solution-fit
Product
Market-fit
Scaling
Lean
Canvas
MVP
ローンチ前
MVP
ローンチ後
現状のモデル
カスタマー
セグメント
Pivot
カスタマーニーズ
Pivot
Zoom-in Pivot
Zoom-out Pivot
Platform Pivot
Channel
Pivot
Pivotのタイプによってインパクトは変わる
事業構造Pivot
影響力大
影響力中
影響力小
影響力最大

時間
改
善
改
善
改
善
Deploy Deploy Deploy Deploy Deploy Deploy Deploy Deploy Deploy
UX/機能改善は
継続的に
デプロイメントする

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
UX/機能改善は
継続的に
デプロイメントする

Co-founder
Vision
Strategy/
Business model
Product/
Feature
UX
変更頻度
多い
変更による
極大
小
ほとんどなし
継続的に
改善・
デプロイする

時間
改
善
改
善
改
善
Iteration Iteration Iteration Iteration Iteration
学びをベースにした
プロダクトイテレーション
を回していく

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
学びをベースにした
プロダクトイテレーション
を回していく

Co-founder
Vision
Strategy/
Business model
Product/
Feature
UX
変更頻度
多い
変更による
極大
小
ほとんどなし
定量と定性の
検証をベースに
改善・デプロイする

Co-founder
Vision
Strategy/
Business model
Product/
Feature
UX
変更頻度
多い
変更による
極大
小
ほとんどなし
スタートアップの
土台であり、
基本変更はしない

プロダクト（MVP)
のイテレーションを検討する
プロダクト（MVP)の
既存フィーチャーは十分な価値を
提供しているか？

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討

既存のプロダクトフィーチャーで
十分な価値を提供できそうか？

追加フィーチャー検討よりも
既存フィーチャーの磨き込みを優先する
多くの場合、追加機能は無駄になってしまう
*プロダクトの全機能のうち２０％がよく使われる
機能追加には基本的にNoから始める
*機能の追加には隠れたコスト（テスト、調整、複雑性、注意散漫）が増える

13%
7%
16%
19%
45%
使わない
よく使う
いつも使う
時々使う
たまに使う
よく使われるフィーチャーは全体の
２0%である

追加フィーチャーよりも
フィーチャーを削減することを考慮する

“Kill the feature -
イケてない機能があったら
見つけて、削除（Kill）しろ”
Dave McLure
Founder of 500 Startup

普通の人は製品に不備がなければ、
そのままで良いというが、
エンジニアは不備がない場合でも、
機能追加をしたがる

失敗するスタートアップは
プロダクトを作り込みすぎる
プロダクト
の検証ステージ
プロダクト
最適化ステージ
成功したスタートアップ
失敗したスタートアップ https://s3.amazonaws.com/startupcompass-public/StartupGenomeReport2_Why_Startups_Fail_v2.pdf
書かれた
のコードの量 3.4倍
2.25倍
多い
少ない
ステージ

13%
7%
16%
19%
45%
使わない
よく使う
いつも使う
時々使う
たまに使う
使わないフィーチャーを
削除する！

追加フィーチャーを
考慮するケース

次のイテレーションで
検討したい課題仮説は何か？
ユーザーに価値をもたらすストーリーは
何かをきちんと検証する

・顧客にとって価値があるかどうか？
(顧客が聞いたらワクワクする要素があるか？顧客はなんというか？）
・ユーザー目線でのSizzle感、臨場感があるか？
・このストーリーを加えて、UXが複雑、煩雑にならないか？
・テクノロジーの言葉で表現しない
・大きすぎず小さすぎないスコープ
（機能単位では小さすぎる）
・テストができる
(定量テスト、定性テストができるか？）
よいストーリーの条件とは？

男性に比べて、女性の方が圧倒的に
ウェブのレスポンスの早さに対して、
評価の目が厳しいということがわかった。
（画面が変わるまでに、１秒以上まてない、
欲しい情報を３度クリックして、出てこなければ閉じる）
”レシピをサクサク見られる”という
ユーザーストーリーを考慮した
クックパッドのストーリーの事例
600万人の女性に支持される”クックパッド”より

＜クックパッドのユーザーである主婦＞
は、
＜レシピをサクサク見たい＞
なぜなら、
＜夕食を作る時間帯は、子供の面倒をみたり
、する必要があり、非常に忙しいからだ＞
クックパッドのストーリーの事例
ユーザー
達成したい
ゴール
理由

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
１−２ストーリーカンバンボード
MVPを
構築する
MVP
ストーリー
ストーリー
１−１
ストーリー
１−２

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
プロダクトの既存フィーチャーの
みで十分な価値を提供しているか
？
機能追加
する！

コスト・時間
得た学びは
20人日/２週間
Activation: 30%
Retention:25%
カスタマーは、価値を感じてつかってもらうことができたが、
一度あたりに加算できる容量が少ないため、継続して使うモチベーションが続かない
という学びがあった
一度あたりに加算できる容量を増やすことができれば、カスタマーの煩わしさを解消することが
できる。それによって、カスタマーの定着率が改善するかを学習する
機能追加
によって学習
したいこと

課題仮説：
カスタマーは、現在の少しずつしか、
wifi使用容量を増やすことができない
ソリューションの使い勝手が悪くてイラ
イラしている

MVPの
Version 2 の
次のスプリントで
学習/検証したい課題仮説を
新しいイテレーションキャンパスに移す

コスト・時間
得た学びは

新たなストーリー候補（追加機能）を検討する
ストーリー候補①：広告動画を３回連続視聴できるように
する（現在は、いちいち、トップページ戻る必要がある）
ストーリー候補②：広告視聴あたりに付与される容量を増
やす（現在の10MBから15MB)
ストーリー候補③：カスタマーがアンケートに答えたら、
30MB(広告視聴の３倍）の使用容量を追加することができ
る

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
プロダクトの既存フィーチャー
のみで十分な価値を提供してい
るか？
プロダクトイテレーションを検討ストーリー候補を
カンバンボードに
貼り付ける

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
次のイテレーション
ストーリー候補を
貼り出す
MVP
ストーリー
ストーリー
２−１
ストーリー
１−１
ストーリー
１−２
ストーリー
２−２
ストーリー
２−３

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
Verizon2の
ストーリーとして
抽出する
Version 2
ストーリー
MVP
ストーリー
ストーリー
１−１
ストーリー
１−２
ストーリー
２−２
ストーリー
２−３

コスト・時間
得た学びは
カスタマーがアンケートに答えたら、
30MB(広告視聴の３倍）
の使用容量を追加することができる
同じサイクルを
再び回していく

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
構築を
開始する
Version 2
ストーリー
MVP
ストーリー
ストーリー
１−１
ストーリー
１−２
ストーリー
２−２
ストーリー
２−３

起動画面メニュー画面
Anywhere onlineの
Version 2のストーリー
使用確認確認画面
アンケート
画面
確認
画面
広告視聴確認
画面
追加された
ストーリー

コスト・時間
得た学びは
5人日/1週間
KPI/KGI
実装イメージ
工数見積もり
を洗い出す

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
MVP
ストーリー
Version 2
ストーリー
構築・ローンチ
して定量検証
を行う
ストーリー
１−１
ストーリー
１−２
ストーリー
２−２
ストーリー
２−３

登録
画面
メニュー
画面
広告視聴
開始
広告視聴
完了
wifi使用
開始画面
wifi使用
開始
Activation率
登録した割合:
９０％
Activation率
一連操作を最後
までやった割合:
35%
ログイン
画面
メニュー
画面
広告視聴
開始
広告視聴
完了
Retention率
ログイン率:
25%
Revenue
１日の広告視聴及び
アンケート回答の回数:
6回
Anytime online Ver 2 をローンチして結果を計測する
アンケート
画面
確認
画面
アンケート
画面
確認
画面

スプリットテストをベースにして
コホート分析レポートを作成する

スプリットテスト：
対象者をランダムなグループにわけて各グループ
（コントロールグループAと被験グループB)
の行動そ計測し比較する科学的な実験
*グループに分けるときは、
一つ以上の条件を変更して測定する

コホート分析：
自分たちが行った施策が、サービス
にどのような影響を与えたのかを可
視化する。その結果を次の施策へフ
ィードバックするための
分析手法のこと。

MVPの
MVPの
Version 2
Version
計測結果（割合）目標値
（訪問者）
３３２人 100% ３25人 100% 100%
（登録）３０５人 90% 291人 90% 95%
（作業完了）９３人 30% １02人 35% 80%
Retention
(三日以内再訪）２３人 25% ２5人 25% 80%
Revenue
4.2回 4.2回 6.1回 6.1回１０回
MVPと
バージョン２の
比較を行う
MVPと
バージョン２の
比較を行う

スプリットテスト/コホートレポートを
導入すると短期的な仕事が煩雑になる。
しかし、定量的な評価システムを実装する
ことで長期的には時間が大幅に節約できる

細かい数字には、そこまでこだわらず、
”顧客が自分のプロダクトを愛している”
”顧客が欲しいものを作っている”
という実感を、顧客のフィードバックから
強く感じることがPMFの基準になる
PMF前は、まだトランザクションボリュームも少
ないので、コホート分析しても誤差なのか、
どうかわからない場合が多い。

コスト・時間
得た学びは
5人日/1週間
MVP Version 2
Activation(sign-up) 90% 90%
Activation(作業完了) 30% 35%
Retention（３日以内ログイン）
(三日以内再訪）
25% 25%
Revenue
（１日当たりの広告視聴
及びアンケート返信回数）
4回 6回
定量的な結果
を書き出す

Version2を実際に使った
カスタマーにインタビューをする

コスト・時間
得た学びは
5人日/1週間
MVP Version 2
25% 25%
Revenue
4回 6回
定量的な
結果を書き出す

コスト・時間
得た学びは
5人日/1週間
MVP Version 2
25% 25%
Revenue
4回 6回
得た学びを
書き出す

工数が比較的少ない
簡単なフィーチャー追加の場合は、
タスクボードに追加する

No
Yes
Yes
Pivotを検討
No
Yes
No
Yes
No
Yes
No
を検討
プロダクトの既存フィーチ
ャーのみで十分な価値を提
供しているか？
工数が小さいものは
タスクとして扱う！

バックログ
ストーリー
構築
構築完了
ローンチ
定量検証
（スプリットテスト、コホー
ト分析）
タスクカンバンボードの活用
フィーチャー
フィーチャー
フィーチャー
優先順位の高い
フィーチャーから
上位に置いていく

バックログ
ストーリー
構築
構築完了
ローンチ
定量検証
ト分析）
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
（上限数３）（上限数３）（上限数３）（上限数３）
ストーリーカンバン
ボード同様
上限数を設ける

バックログ
ストーリー
構築
構築完了
ローンチ
定量検証
ト分析）
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
フィーチャー
（上限数３）（上限数３）（上限数３）（上限数３）
ボトルネックがある場合は
そこにリソースを投入して
スループットを増やす

プロダクトイテレーションは
リズミカルに廻していく

Startup Science 2017 拡大版（1750page）8/10

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Startup Science 2017 拡大版（1750page）8/10

Ähnlich wie Startup Science 2017 拡大版（1750page）8/10 (20)

Mehr von Masa Tadokoro

Mehr von Masa Tadokoro (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Startup Science 2017 拡大版（1750page）8/10

Hinweis der Redaktion