Startup Science ⑥

How to start a startup
スタートアップを成功に導くサイエンス
2017年度版 ⑥
Copyright 2017 Masayuki Tadokoro All rights reserved
Startup Science

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

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

新たなアイデアやコンセプト
を素早く形にして（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やカスタマー獲得にこだわるな！

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

登録後三日以内の
ログイン率
ユーザー一人あたりの
１日平均広告視聴回数
登録者画面に
きた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

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

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

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

バックログ
ストーリー
で学習したい
構築
構築完了
ローンチ
定量検証
定性検証/
内省する
カスタマーの
話を聞く
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からの最大の学びは何か？
・どの既存フィーチャーの改善が必要か？どの既存のフィーチャーを
廃止する必要があるか？どのような追加フィーチャーを加える必要があ
るか？

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

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

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

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

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

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

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

PMF達成基準
チェックシート
✔︎ 高いリテンションを保てるか？
✔︎ カスタマー獲得から売り上げを上げるまで再現
可能なパターンがあるか？
✔︎ 資金を投入すれば、LTV>CPAがどんどん改善す
るというモデルができているか？
✔︎ リーンキャンバスの全体をみて成立しているか？

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

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

Product-market-fit
MVPを
ーに届ける
MVPで
何を学ぶか
明らかにする
MVPで
何を学ぶかを
明らかにする
カスタマーに
して学ぶ
innovation
Hooked model
カスタマーを
ハマらせる
プロダクト
定量的計測と
MVPを
構築
次のステップを
検討する
ビジネスモデルをpivotする
ビジネスモデルの
Pivotを行う
PMFを達成する
ための次の施策を
検討する

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を行う

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

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

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

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

Product-market-fit
MVPを
ーに届ける
MVPで
何を学ぶか
明らかにする
MVPで
何を学ぶかを
明らかにする
カスタマーに
して学ぶ
innovation
Hooked model
カスタマーを
ハマらせる
プロダクト
定量的計測と
MVPを
構築
ビジネスモデルをpivotする
ビジネスモデルの
Pivotを行う

プロダクト（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

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

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

次のイテレーションで
検討したい課題仮説は何か？
をきちんと考慮する

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と
バージョン２の
比較を行う

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

コスト・時間
得た学びは
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
を検討
プロダクトの既存フィーチ
ャーのみで十分な価値を提
供しているか？
工数が小さいものは
タスクとして扱う！

実装するタイミングが
近づいてきたら必要な項目の分析を行い
必要な機能を必要な時に作る
ジャストインタイムを採用

・最新かつ、もっとも充実した情報に基づいて分
析できる（今やる理由を問い続ける）
・開発者はカスタマーから学ぶ機会を増やせる
・手戻りが大量に発生することを防げる
・ひとつひとつの施策（バッチ）に対して、スプ
リットテスト/コホート分析をすることによって施
策の品質を早期に検証できる
ジャストインタイムの効果

Product
Market-Fit
リスク
（＝カスタマーが
欲しいものを
作れないリスク）
時間
カスタマーの
フィードバックが
ないと、PMFリスクが
増え続ける
カスタマーの声を聞きながら小さいバッチを回して
”人が欲しがらないものを作ってしまう”リスクを減らす
カスタマーの
フィードバックをと
PMFリスクを抑える
ことができる
高
低
x

ジャストインタイムを
リズミカルに運営する方法
・タスクカンバンボードを活用する
・デイリースタンドアップを行う
・カスタマーとの対話をベースに開発を進める
・文書化をせずに開発を進める
*ただし、カスタマーインサイトに関しては資産化/共有していく

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

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

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

開発の進捗を
デイリーStand upミーティング
で共有する
デイリーStand upで共有する３つのこと
①昨日やったこと
②今日やること
③チームの開発速度を下げてしまう障壁

開発する際に
文書化はしない
文書化すると、
文書にどうにか合わせること
優先順位が上がってしまう

カスタマー
からの定性的
フィードバック
チーム
定量的なデータ
社内の
学びとして
蓄積していく
学びの蓄積
カスタマーのインサイトは文書化して、
チーム内で共有するようにする

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

Startup Science ⑥

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Startup Science ⑥

Similaire à Startup Science ⑥ (20)

Plus de Masa Tadokoro

Plus de Masa Tadokoro (20)

Dernier

Dernier (6)

Startup Science ⑥

Notes de l'éditeur