More Related Content Similar to リーンスタートアップにおける良い仮説、悪い仮説 (20) More from Takaaki Umada (17) リーンスタートアップにおける良い仮説、悪い仮説4. リーン生産方式をはじめとした、リーン全般の目指すものはムダの排除。特に Lean Startup では
「顧客が欲しがらないものを作る」という最大のムダを極力排除していく必要がある。
Original uploader was Laurensvanlieshout at nl.wikipedia
4
リーンの系譜: 目指すものは ムダ の排除
トヨタ生産方式
不確実性が低く、求めら
れる成果物はある程度一
定している状況に用いら
れる。
主に工場の生産など。
起きうるムダの種類
1. 作り過ぎのムダ
2. 手待ちのムダ
3. 運搬のムダ
4. 加工そのもののムダ
5. 在庫のムダ
6. 動作のムダ
7. 不良をつくるムダ
(トヨタ生産方式より)
リーンスタートアップ
リーン生産方式とアジャ
イルと顧客開発をベース
にした方法論。
不確実性が高く、求めら
れる成果物がまだ未確定
な状況に用いられる。
主に新規のプロダクト。
起きうるムダの種類
1. 顧客が欲しがっ
ていないものを
作るムダ
リーンソフトウェア開発
不確実性が高く、求めら
れる成果物(顧客の要
件)が変動しやすい状況
に用いられる。
起きうるムダの種類
1. 未完成の作業のムダ
2. 余分な機能のムダ
3. 再学習のムダ
4. 引き継ぎのムダ
5. タスク切り替えのム
ダ
6. 遅れのムダ
7. 欠陥のムダ
(リーン開発の本質より)
リーン生産方式
(トヨタ生産方式をベー
スにMIT が体系化。製
造工程全体の最適化を
狙う)
18. Customer/Problem Fit (顧客と課題) から Product/Market Fit に至るまで順々に仮説検証をして
いく。検証は顧客と課題から始まる。
18
仮説検証の順番 (例 1): Product/Market Fit
BL
M
Customer /
Problem Fit
BL
M
Product /
Market Fit
BL
M
Solution /
Product Fit
BL
M
Problem /
Solution Fit
• 顧客に課題はあ
るか?
• その課題はどの
程度重要な課題
か?
• そのソリュー
ションで顧客の
課題を解決でき
るか?
• 顧客はソリュー
ションにお金を
支払うか?
• プロダクトはソ
リューションを
十分に実現でき
ているか?
• プロダクトとし
てスケーラブル
か?
• スケーラブルな
ビジネスモデル
を構築できてい
るか?
• 効率的なチャネ
ルは分かってい
るか?
20. Lean Canvas などは計画した時点で終わり、というものではなく、検証を通して必ず行ったり来た
りが発生する。
20
仮説検証の順番 (例 2): Lean Canvas
⑦ コスト構造
① 課
題
④ ソ
リュー
ション
1.
2.
3.
③ 独
自の価
値提案
⑨ 圧
倒的な
優位性
② 顧
客セグ
メント
⑥ 収益の流れ
⑧ 主
要指標
⑤
チャネ
ル
⑦ コスト構造
① 課
題
④ ソ
リュー
ション
1.
2.
3.
③ 独
自の価
値提案
⑨ 圧
倒的な
優位性
② 顧
客セグ
メント
⑥ 収益の流れ
⑧ 主
要指標
⑤
チャネ
ル
⑦ コスト構造
① 課
題
④ ソ
リュー
ション
1.
2.
3.
③ 独
自の価
値提案
⑨ 圧
倒的な
優位性
② 顧
客セグ
メント
⑥ 収益の流れ
⑧ 主
要指標
⑤
チャネ
ル
⑦ コスト構造
① 課
題
④ ソ
リュー
ション
1.
2.
3.
③ 独
自の価
値提案
⑨ 圧
倒的な
優位性
② 顧
客セグ
メント
⑥ 収益の流れ
⑧ 主
要指標
⑤
チャネ
ル
⑦ コスト構造
① 課
題
④ ソ
リュー
ション
1.
2.
3.
③ 独
自の価
値提案
⑨ 圧
倒的な
優位性
② 顧
客セグ
メント
⑥ 収益の流れ
⑧ 主
要指標
⑤
チャネ
ル
⑦ コスト構造
① 課
題
④ ソ
リュー
ション
1.
2.
3.
③ 独
自の価
値提案
⑨ 圧
倒的な
優位性
② 顧
客セグ
メント
⑥ 収益の流れ
⑧ 主
要指標
⑤
チャネ
ル
顧客で
検証失敗
課題で
検証失敗
UVP まで
検証成功
1st Trial
2nd Trial
3rd Trial
29. 仮説検証は Build ‒ Measure ‒ Learn のループによって行われる。オペレーションでは、このサイ
クルをいかに早く回すかが重要になる。
29
仮説検証のサイクル: Build ‒ Measure - Learn
Idea
s
1. Build3. Learn
Data
2.
Measure
Prod
uct
より速く構築
MVP
ユニットテスト
ユーザビリティテスト
継続的インテグレーション
クラウド
などなど
より速く計測
スプリットテスト
ユーザビリティテスト
ファネル分析
コホート分析
より速く学習
顧客開発
5 つの Why
反証可能な仮説
などなど
30. アクションは BML の順に行われるが、計画は LMB の順、つまり「何を学びたいか」を中心に考え
る必要がある。基本的に、リスクの大きいものから順に学びを得ていくと良い。
30
仮説検証の計画は Learn -> Measure -> Build の順
Idea
s
1. Build3. Learn
Data
2.
Measure
Prod
uct
Idea
s
3. Build1. Learn
Data
2.
Measure
Prod
uct
アクションは Build ‒> Measure -> Learn
仮説検証の行動としては、何かを作ってから計測して、
その計測を元に学ぶ。
計画は Learn -> Measure -> Build
仮説検証の計画は、何を学びたいかを考えてから、計
測方法を考え、それに基づいて MVP を作る。
35. MVP は一部の仮説検証のために作られる、評価や学びを得るための最小の製品のこと。MVP が不
要な場合もあれば、様々なパターンで作られる場合もある。
35
検証のための Minimal Viable Product の設計も細分化
理想の
プロダ
クト
このソリューションは
顧客の課題を
解決するか?
コンシェルジュ
MVP
MVP1
MVP2
理想の
プロダ
クト
Closed Beta
(Function/Operation)
機能は十分か?
自動化できるか?
MVP1
MVP のパターン 1
一個一個検証していながら徐々に大きくするパターン。
普通はこちらを考えがち(特にサイエンス&ハード
ウェア系)。
MVP のパターン 2
できるところは分割しつつ検証していくパターン。別
にできるところは別に検証したほうが早いことが多い。
Landing Page
十分な顧客がいるか
プロトタイプ 1
(AHA Moment &
Contextual)
このプロダクトの
UX は適切か?
プロトタイプ 2
(Usability)
プロトタイプ 3
(Aesthetic)
インタビュー
顧客に課題があるか?
37. Just do it (とりあえずプロダクトを作ってみよう) をはじめとして、ムダを大量に生む仮説検証は
悪い仮説検証と言える。以下は悪い仮説検証の代表的な例である。
37
悪い仮説検証の特徴
仮説 A
仮説 B
仮説 C
仮説 D
仮説 E
仮説の上の仮説の上の仮説の検証 仮説が曖昧だったり小さすぎる チームの合意なき検証
仮説
1個のMVP
で検証
41. 初期の仮説検証のフェーズでよく受ける質問とその回答を以下に挙げる。
41
仮説検証 FAQ
顧客インタビュー
Q. インタビューできる人が見つかりません
A. 自身に既に顧客ベースのないセグメントに参入する
のはそもそも無謀な気がします(顧客への洞察がない
と良い仮説も立てられないのでは)。
Q. インタビューを広く呼びかけても来てくれません
A. 基本インタビューに積極的に参加してくれる人はい
ないので、個別に声をかけましょう。特に既存顧客を
うまく使ってください。
MVP
Q. MVP が小さくなりません
A. 本当に小さくならない時もあるとは思いますが、小
さくできるように考えてみてください。大概方法はあ
ります。たとえばコンシェルジュ MVP は試しました
か?既存の競合製品のカスタマイズは? 自分が思っ
ているよりも、MVP は小さくなることが多いです。
Q. 競合製品がありません
A. それは「マーケットがない」と言っているようなも
のです。たとえ製品がなくても、顧客は別の手段で課
題を解決しているのかもしれません。そうでないのな
ら切実な課題ではないということでは?
62. BML の後工程のことを考えずにフローを流してしまうと後工程で失敗が見つかり、ムダが発生しや
すい。
62
その他の Build ‒ Measure ‒ Learn の設計ミスの例
Learn における設計ミス
• そもそも学びたいことが明確で
はない
• 顧客インタビューが下手で、良
い洞察を得られない
• 顧客の発言をそのまま学びとし
てしまい、顧客の発言の本当
の 原因 にまで深堀りできてい
ない
• 検証のメトリクスが「行動への
繋がりやすさ (Actionable)」
「分かりやすさ (Accessible)」
「チェックしやすさ
(Audible)」の基準を満たせてい
ない
Measure における設計ミス
• 仮説立案フェーズで検証のコス
トや存在を無視していて、
Measure の段階で長く止まる
(仮説立案と検証方法はセット
で考える)
• 定量調査をしようとしても、十
分な顧客がいない
• 顧客インタビューに固執しすぎ
ていて、他の方法を検討してい
ない
• 検証の段取りが下手で、時間が
かかりすぎている
Build における設計ミス
• MVP のサイズが大きすぎて
Build に時間がかかりすぎる
• MVP のサイズが大きすぎて、
結果的にムダが多くなる
• 一気に複数の MVP を作ってい
てフォーカスがぶれていて、う
まく検証できないものを作る
• Viable (実用的) であることを低
くみすぎる。Viable かどうかは
顧客の環境やプロダクトのカテ
ゴリによって大きく異なるし、
MVP によっても異なる