Más contenido relacionado La actualidad más candente (20) Similar a Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation (20) Más de Kenji Hiranabe (20) Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation1. #sllconf
ようこそリーンスタートアップ
「ムーブメント」へ
#leanstartup
Eric Ries (@ericries) エリック・リース
http://StartupLessonsLearned.com
翻訳: 関口有紀+平鍋健児(Japanese Translation by Yuki Sekiguchi + Kenji Hiranabe)
3. 学術の世界にも浸透
• ハーバードビジネススクール
• Minimum Viable Product* ファンド
*市場のフィードバックを得るために必要な最低限の機能を持った製品というコンセプト
http://www.hbs.edu/news/releases/mvpwinners2011.html
• テクノロジーベンチャーの立ち上げについて
http://platformsandnetworks.blogspot.com/2011/01/launching-tech-ventures-part-i-
course.html
• スタンフォード大学
• リーン ローンチパッド(LaunchPad)
http://steveblank.com/category/lean-launchpad/
• ブリガムヤング大学
• リーンスタートアップ リサーチプロジェクト
http://nathanfurr.com/2010/09/15/the-lean-startup-research-project/
4. 関連書籍も増加
http://bit.ly/FourSteps
日本語版
RunningLeanHQ.com
http://bit.ly/Custdev
http://www.amazon.co.jp/dp/4798117552/
5. 僕(エリック)の本ももうすぐ!
Coming September 13, 2011
http://lean.st or http://bit.ly/LeanStartupBook
12. 誰を責めるべきか
• 科学的管理法の父
• 仕事を調査分析することで最
善の方法を見つける
• 例外による管理
• 仕事をタスクとして作業分割
し標準化
• パフォーマンスに応じた報酬
“過去においては人が第一であっ
た。これからはシステムが第
一になるだろう。” (1911)
Frederick Winslow Taylor
(1856 – 1915)
19. では「ピボット」とは実際何なのか
• 成功したスタートアップに共通していることは?
- PDAのデジタル通貨としてスタートしたが、eBay用のオン
ライン決済へと進化した<訳者注:PayPalの例>
- BASICの翻訳ツールをつくることでスタートしたが世界最
大のOSモノポリへと進化した <訳者注: Microsoftの例>
- 自分達はオンラインゲーム会社のつもりだったが実は写真
の共有サイトであったことにびっくりした <訳者注:
Flickrの例>
• ピボット: 学んだことに軸をおきつつ方向を変える
23. リーン革命
W. Edwards Deming Taiichi Ohno
W.エドワーズ・デミング 大野 耐一
(1900 – 1993) (1912 – 1990)
“顧客は生産ラインの中で最も重要な部分だ” –デミング
26. それぞれのステップにはたくさんのことが…
より速く学習 より速く構築
スプリットテスト ユニットテスト
カスタマーディベロップメント ユーザビリティテスト
5つのWhy 連続的インテグレーション
顧客による「諮問委員会」 逐次デプロイメント
反証可能な仮説 無料 & オープンソース
製品オーナー クラウドコンピューティング
アカウンタビリティ クラスター免疫システム
ジャストインタイムのスケーラビリティ
顧客原型
リファクタリング
部門横断チーム より速く計測 より速く計測
開発者サンドボックス
半自治のチーム
ファネル(漏斗)分析 MVP
スモークテスト スプリットテスト
継続的デプロイメント コーホート(同世代)分析
ユーザビリティテスト NPS (ネットプロモータースコア)
リアルタイム監視 & 警告 SEM (サーチエンジンマーケティング)
カスタマーリエゾン 予測監視
31. イノベーションアカウンティング
3つのラーニングマイルストーン
1. ベースラインの設定
- Minimum Viable Product (MVP)を創る
- 現時点での顧客行動を計る
2. エンジンのチューニング
- ベースラインから理想形に向かって各種指標値を向上で
きるか実験する
3. ピボットする or このまま辛抱する
- 実験結果が収穫逓減に達したら、ピボットすべき
32. Questions
ピボットはいつすべきか?
ビジョン or 戦略 or 製品?
何を計れば良いのか?
どのように製品は成長すべきか?
我々は何らかの価値を創造しているのか?
MVPには何が含まれてるのか?
もっと速くできるか?
33. 答えはこちらでww
Coming September 13, 2011
http://lean.st or http://bit.ly/LeanStartupBook
34. Thanks!
• 本の事前予約はこちら @ http://lean.st
• ブログ:Startup Lessons Learned
- http://StartupLessonsLearned.com
• コンタクト (#leanstartup)
- http://twitter.com/ericries
- eric@theleanstartup.com
• 他のリソース
- NEW: http://theleanstartup.com
- Lean Startup Wiki:
http://leanstartup.pbworks.com
35. 誤解 #1
誤解
リーンは「ケチ」という意味だ。 リーンスタート
アップはできるだけお金を使わないようにする。
真実
リーンスタートアップ手法はコストの話ではない、
スピードの話なのだ。
36. 誤解 #2
誤解
リーンスタートアップは、
Web 2.0/インターネット/コンシューマ向け
ソフトウェア開発の会社のためのものだ。
真実
リーンスタートアップは顧客が何を欲するかに
ついての、不確実性に直面するすべての企業
に当てはまる。
37. 誤解 #3
誤解
リーンスタートアップは、小さな
ブートストラップしたスタートアップだ。
真実
リーンスタートアップは意欲的で、大きな資本を
投資することもできる。
38. 誤解 #4
誤解
リーンスタートアップは、
ビジョンをデータや顧客からのフィードバックで
置き換える
真実
リーンスタートアップは、
説得力のあるビジョンで駆動され、
そのビジョンの要素を1つ1つ厳格にテストする。
40. MVP: Minimum Viable Product
(市場評価を得るための最小の製品)
• もしその製品が本当の問題を解決しているのな
ら、先見性のある顧客は、 まだない機能をも想
定して製品を正しい方向に導いてくれる。
• 大きなビジョンを、小さな機能追加の積み重ね
で到達することができる。堂々巡りをせずに。
• 開発の反復(イテレーション)にコミットする
ことがん必要。
• MVP は大きなビジョンの製品だけに必要。小さ
な製品には必要ない。
41. 継続的デプロイ
Learn Faster Build Faster
Customer Development Continuous Deployment
Five Whys
Small Batches
Minimum Viable Product
Refactoring
Measure Faster
Split Testing
Actionable Metrics
Net Promoter Score
SEM
43. 継続的デプロイ
• 新しいソフトウェアを素早くデプロイ
- IMVU ではチェックインからプロダクションまでの時間は20分。
• よい変更と悪い変更を(素早く)区別
• 悪い変更を素早くもとに戻す。
- そして「ラインを止める」
• 小さなバッチで。
- IMVU では大きなバッチといえども3日分の仕事。
• 大きなプロジェクトを小さなバッチに分割。
44. クラスタ免疫システム
一片のコードをプロダクションに配備する、というのはどういうことか:
• ローカルにテストする。 (SimpleTest, Selenium)
- 全員が完全なサンドボックスを持っている。
• 継続的統合サーバー (BuildBot)
- すべてのテストをパスする。そうでなければ、「ラインを止める」
- チームが速過ぎれば、自動でフィードバック
• 逐次デプロイ
- リアルタイムでクラスタ状態とビジネス指標をモニタ
- 指標を大きく逸脱するような変更はリジェクト
• アラートと予測的モニタリング (Nagios)
- すべてのステークホルダが関心を持つ全指標をモニタ
- もし何かの指標が逸脱したら、誰かを起こす
- 許容境界値の予測には統計的傾向を使う
• 顧客が失敗を見てしまったら
- 問題を顧客のためになおす
- 各レベルでの防御を改善する
45. MVP:市場評価を得るための最小の製品
Learn Faster Build Faster
Customer Development Continuous Deployment
Five Whys
Small Batches
Minimum Viable Product
Refactoring
Measure Faster
Split Testing
Actionable Metrics
Net Promoter Score
SEM
47. 可能なアプローチ
• “成功確率を最大化する”
- 顧客が欲しがる「可能性」を上げるために、十分な機能を持っ
た最高の製品を最初から作る。
- 問題: 最後までフィードバックがない。調整するには遅すぎる
かもしれない。
• “早くリリース、頻繁にリリース”
- とにかく、可能な限りたくさんのフィードバックをもらう。
- 問題: 顧客が欲しいと思われるものを追いかけて、ぐるぐる
回ってしまう。
49. MVP: Minimum Viable Product
(市場評価を得るための最小の製品)
• もしその製品が本当の問題を解決しているのな
ら、先見性のある顧客は、 まだない機能をも想
定することができる。
• 大きなビジョンを、小さな機能追加の積み重ね
で到達することができる。堂々巡りをせずに。
• 開発の反復(イテレーション)にコミットする
ことがん必要。
• MVP は大きなビジョンの製品だけに必要。小さ
な製品には必要ない。
50. 手法
• ランディングページでのスモークテスト、
AdWords
• 1日あたり$5のSEM (Search Engine Marketing)
• 製品コードにスプリットテストを埋め込む
• ペーパープロトタイプ
• 顧客発見、検証
• 機能を削除 (“カット&ペースト”)
51. 不安
• 間違った判断(False negative): 「顧客は最初か
ら全機能がある製品なら喜んだはずなのに、
MVPがダメだったために、ぼくらはビジョンを
捨ててしまった。」
• ビジョナリ・コンプレックス: 「でも、顧客は本
当は何が欲しいかわかっていないんだ!」
• 忙しすぎて学習の暇がない: 「最初から正しく
作った方が速い。計測ばかりしていたら顧客を
喜ばすことに集中できない」
52. なぜなぜ5回
Learn Faster Code Faster
Five Whys Root Continuous Deployment
Cause Analysis
Measure Faster
Rapid Split Tests
54. 素早いスプリットテスト
Learn Faster Code Faster
Five Whys Root Continuous Deployment
Cause Analysis
Measure Faster
Rapid Split Tests
57. マクロを計測
• いつでもコホート(同世代群)ベースの指標を
継続的に見る
• 小さくスプリットテストし、全体を計測
Control Group (A) Experiment (B)
# Registered 1025 1099
Downloads 755 (73%) 733 (67%)
Active days 0-1 600 (58%) 650 (59%)
Active days 1-3 500 (48%) 545 (49%)
Active days 3-10 300 (29%) 330 (30%)
Active days 10-30 250 (24%) 290 (26%)
Total Revenue $3210.50 $3450.10
RPU $3.13 $3.14