Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation

56,230 views

Published on

Japanese translation of Eric Ries Keynote at Startup Lessons Learned sllconf 2011 - Japanese Translation

http://www.slideshare.net/startuplessonslearned/eric-ries-sllconf-keynote-state-of-the-lean-startup-movement

Translated by Yuki Sekiguchi and Kenji Hiranabe

Published in: Business
1 Comment
141 Likes
Statistics
Notes
  • Japanese translation of Eric Ries Keynote at Startup Lessons Learned sllconf 2011, translated by Yuki Sekiguchi and Kenji Hiranabe
    エリック・リースの 5/23 Startup Lessons Learned conf (sllconf) 2011 基調講演を本人の許可を得て日本語訳しました。

    オリジナルは、以下です。
    http://www.slideshare.net/startuplessonslearned/eric-ries-sllconf-keynote-state-of-the-lean-startup-movement
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
56,230
On SlideShare
0
From Embeds
0
Number of Embeds
39,801
Actions
Shares
0
Downloads
0
Comments
1
Likes
141
Embeds 0
No embeds

No notes for slide

Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation

  1. 1. #sllconfようこそリーンスタートアップ 「ムーブメント」へ #leanstartup Eric Ries (@ericries) エリック・リース http://StartupLessonsLearned.com翻訳: 関口有紀+平鍋健児(Japanese Translation by Yuki Sekiguchi + Kenji Hiranabe)
  2. 2. リーンスタートップムーブメントは世界各地に 近くのMeetupを探すにはこちら http://lean-startup.meetup.com/
  3. 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. 4. 関連書籍も増加 http://bit.ly/FourSteps 日本語版 RunningLeanHQ.comhttp://bit.ly/Custdev http://www.amazon.co.jp/dp/4798117552/
  5. 5. 僕(エリック)の本ももうすぐ! Coming September 13, 2011 http://lean.st or http://bit.ly/LeanStartupBook
  6. 6. この本の出版に関してもリーンスタートアップの手法を用いてこの 例のような各種実験をしています。詳細はhttp://lean.stで。
  7. 7. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいるアントレプレナーシップとはマネジメントである 立証された学び 構築 (Build) - 計測 (Measure) - 学習 (Learn) イノベーションアカウンティング
  8. 8. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいる
  9. 9. スタートアップとは何か?• スタートアップとは、極度な不確実性のもとに、 新しい製品やサービスを提供するためにつくら れる、人から構成される団体である• 会社の規模や経済や産業のどこに属しているか などは全く関係ない
  10. 10. スタートアップとは何か?スタートアップ = 実験
  11. 11. 人の時間を無駄にするのはやめよう
  12. 12. 誰を責めるべきか • 科学的管理法の父 • 仕事を調査分析することで最 善の方法を見つける • 例外による管理 • 仕事をタスクとして作業分割 し標準化 • パフォーマンスに応じた報酬 “過去においては人が第一であっ た。これからはシステムが第 一になるだろう。” (1911)Frederick Winslow Taylor (1856 – 1915)
  13. 13. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいるアントレプレナーシップとはマネジメントである
  14. 14. アントレプレナーシップとはマネジメントである • 我々のゴールはただ一つの製品をつくることでは なく、機関・団体を創ること • 伝統的なマネジメント手法では上手く行かない - MBAで学ぶような“general management” とか • スタートアップの特徴である極端な不確実性に 対処するのに適した原則や実践手法が必要 • 数人でやってるガレージベンチャーのことだけ を意味するのではない
  15. 15. 「ピボット」について
  16. 16. この言葉はあらゆるところで使われるようになり まさにハイプサイクルの典型のよう
  17. 17. The New Yorker の風刺にも使われ るほど I’「別れる訳じゃないの。他の男性にピボットするだけ。」
  18. 18. TechCrunchでも「使い古されてる」と認定…
  19. 19. では「ピボット」とは実際何なのか• 成功したスタートアップに共通していることは? - PDAのデジタル通貨としてスタートしたが、eBay用のオン ライン決済へと進化した<訳者注:PayPalの例> - BASICの翻訳ツールをつくることでスタートしたが世界最 大のOSモノポリへと進化した <訳者注: Microsoftの例> - 自分達はオンラインゲーム会社のつもりだったが実は写真 の共有サイトであったことにびっくりした <訳者注: Flickrの例>• ピボット: 学んだことに軸をおきつつ方向を変える
  20. 20. スピードが重要もしピボット間の時間を短縮できるとしたら 成功の確度を上げることが可能 資金が尽きる前にね
  21. 21. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいるアントレプレナーシップとはマネジメントである 立証された学び
  22. 22. 失敗の達成• もし誰も欲しくないものをつくっているとしたら、 実現しようがしまいが何の違いがあるのか 予定通り? 予算以内? 高品質? 美しいデザイン?• 失敗の達成 = ダメなプランを着実に実行すること
  23. 23. リーン革命 W. Edwards Deming Taiichi OhnoW.エドワーズ・デミング 大野 耐一 (1900 – 1993) (1912 – 1990) “顧客は生産ラインの中で最も重要な部分だ” –デミング
  24. 24. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいるアントレプレナーシップとはマネジメントである 立証された学び 構築 (Build) - 計測 (Measure) - 学習 (Learn)
  25. 25. 一周するのにかかる合計時間を最短化せよ
  26. 26. それぞれのステップにはたくさんのことが…より速く学習 より速く構築スプリットテスト ユニットテストカスタマーディベロップメント ユーザビリティテスト5つのWhy 連続的インテグレーション顧客による「諮問委員会」 逐次デプロイメント反証可能な仮説 無料 & オープンソース製品オーナー クラウドコンピューティングアカウンタビリティ クラスター免疫システム ジャストインタイムのスケーラビリティ顧客原型 リファクタリング部門横断チーム より速く計測 より速く計測 開発者サンドボックス半自治のチーム ファネル(漏斗)分析 MVPスモークテスト スプリットテスト 継続的デプロイメント コーホート(同世代)分析 ユーザビリティテスト NPS (ネットプロモータースコア) リアルタイム監視 & 警告 SEM (サーチエンジンマーケティング) カスタマーリエゾン 予測監視
  27. 27. 人の時間を無駄にするのはやめよう
  28. 28. ザ・トヨタウェイhttp://bit.ly/thetoyotaway
  29. 29. ザ・スタートアップウェイ 人 企業文化 プロセス アカウンタビリティ
  30. 30. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいるアントレプレナーシップとはマネジメントである 立証された学び 構築 (Build) - 計測 (Measure) - 学習 (Learn) イノベーションアカウンティング
  31. 31. イノベーションアカウンティング 3つのラーニングマイルストーン1. ベースラインの設定 - Minimum Viable Product (MVP)を創る - 現時点での顧客行動を計る2. エンジンのチューニング - ベースラインから理想形に向かって各種指標値を向上で きるか実験する3. ピボットする or このまま辛抱する - 実験結果が収穫逓減に達したら、ピボットすべき
  32. 32. Questions ピボットはいつすべきか? ビジョン or 戦略 or 製品? 何を計れば良いのか? どのように製品は成長すべきか?我々は何らかの価値を創造しているのか? MVPには何が含まれてるのか? もっと速くできるか?
  33. 33. 答えはこちらでww Coming September 13, 2011http://lean.st or http://bit.ly/LeanStartupBook
  34. 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. 35. 誤解 #1 誤解リーンは「ケチ」という意味だ。 リーンスタートアップはできるだけお金を使わないようにする。 真実リーンスタートアップ手法はコストの話ではない、 スピードの話なのだ。
  36. 36. 誤解 #2 誤解 リーンスタートアップは、Web 2.0/インターネット/コンシューマ向けソフトウェア開発の会社のためのものだ。 真実リーンスタートアップは顧客が何を欲するかについての、不確実性に直面するすべての企業 に当てはまる。
  37. 37. 誤解 #3 誤解 リーンスタートアップは、小さな ブートストラップしたスタートアップだ。 真実リーンスタートアップは意欲的で、大きな資本を 投資することもできる。
  38. 38. 誤解 #4 誤解 リーンスタートアップは、ビジョンをデータや顧客からのフィードバックで 置き換える 真実 リーンスタートアップは、 説得力のあるビジョンで駆動され、そのビジョンの要素を1つ1つ厳格にテストする。
  39. 39. リーンスタートアップの原則起業家(アントレプレナー)はどこにでもいるアントレプレナーシップとはマネジメントである 立証された学び 構築 (Build) - 計測 (Measure) - 学習 (Learn) イノベーションアカウンティング
  40. 40. MVP: Minimum Viable Product (市場評価を得るための最小の製品)• もしその製品が本当の問題を解決しているのな ら、先見性のある顧客は、 まだない機能をも想 定して製品を正しい方向に導いてくれる。• 大きなビジョンを、小さな機能追加の積み重ね で到達することができる。堂々巡りをせずに。• 開発の反復(イテレーション)にコミットする ことがん必要。• MVP は大きなビジョンの製品だけに必要。小さ な製品には必要ない。
  41. 41. 継続的デプロイLearn Faster Build FasterCustomer Development Continuous DeploymentFive Whys Small Batches Minimum Viable Product Refactoring Measure Faster Split Testing Actionable Metrics Net Promoter Score SEM
  42. 42. 継続的デプロイの原則 同じ問題を2度起こさない何かが失敗したらラインを止める 予防よりも、素早い対応
  43. 43. 継続的デプロイ• 新しいソフトウェアを素早くデプロイ - IMVU ではチェックインからプロダクションまでの時間は20分。• よい変更と悪い変更を(素早く)区別• 悪い変更を素早くもとに戻す。 - そして「ラインを止める」• 小さなバッチで。 - IMVU では大きなバッチといえども3日分の仕事。• 大きなプロジェクトを小さなバッチに分割。
  44. 44. クラスタ免疫システム 一片のコードをプロダクションに配備する、というのはどういうことか:• ローカルにテストする。 (SimpleTest, Selenium) - 全員が完全なサンドボックスを持っている。• 継続的統合サーバー (BuildBot) - すべてのテストをパスする。そうでなければ、「ラインを止める」 - チームが速過ぎれば、自動でフィードバック• 逐次デプロイ - リアルタイムでクラスタ状態とビジネス指標をモニタ - 指標を大きく逸脱するような変更はリジェクト• アラートと予測的モニタリング (Nagios) - すべてのステークホルダが関心を持つ全指標をモニタ - もし何かの指標が逸脱したら、誰かを起こす - 許容境界値の予測には統計的傾向を使う• 顧客が失敗を見てしまったら - 問題を顧客のためになおす - 各レベルでの防御を改善する
  45. 45. MVP:市場評価を得るための最小の製品Learn Faster Build FasterCustomer Development Continuous DeploymentFive Whys Small Batches Minimum Viable Product Refactoring Measure Faster Split Testing Actionable Metrics Net Promoter Score SEM
  46. 46. なぜ製品を作るのか?• 顧客を喜ばせる• 多くの顧客にサインアップしてもらう• たくさんのお金を稼ぐ• 大きなビジョンを実現させる; 世界を変える• フィードバックから学習することで、未来を予 見しよう
  47. 47. 可能なアプローチ• “成功確率を最大化する” - 顧客が欲しがる「可能性」を上げるために、十分な機能を持っ た最高の製品を最初から作る。 - 問題: 最後までフィードバックがない。調整するには遅すぎる かもしれない。• “早くリリース、頻繁にリリース” - とにかく、可能な限りたくさんのフィードバックをもらう。 - 問題: 顧客が欲しいと思われるものを追いかけて、ぐるぐる 回ってしまう。
  48. 48. MVP• エバンジェリスト(先見性のあるアーリーアドプ ター)から学習するための最小セットの機能 - 欲しい人が誰もいない製品を作ることを避ける - 使った$1あたりの学習量を最大化する• きっと、あなたが思うよりもずっと小さい!
  49. 49. MVP: Minimum Viable Product (市場評価を得るための最小の製品)• もしその製品が本当の問題を解決しているのな ら、先見性のある顧客は、 まだない機能をも想 定することができる。• 大きなビジョンを、小さな機能追加の積み重ね で到達することができる。堂々巡りをせずに。• 開発の反復(イテレーション)にコミットする ことがん必要。• MVP は大きなビジョンの製品だけに必要。小さ な製品には必要ない。
  50. 50. 手法• ランディングページでのスモークテスト、 AdWords• 1日あたり$5のSEM (Search Engine Marketing)• 製品コードにスプリットテストを埋め込む• ペーパープロトタイプ• 顧客発見、検証• 機能を削除 (“カット&ペースト”)
  51. 51. 不安• 間違った判断(False negative): 「顧客は最初か ら全機能がある製品なら喜んだはずなのに、 MVPがダメだったために、ぼくらはビジョンを 捨ててしまった。」• ビジョナリ・コンプレックス: 「でも、顧客は本 当は何が欲しいかわかっていないんだ!」• 忙しすぎて学習の暇がない: 「最初から正しく 作った方が速い。計測ばかりしていたら顧客を 喜ばすことに集中できない」
  52. 52. なぜなぜ5回Learn Faster Code FasterFive Whys Root Continuous DeploymentCause Analysis Measure Faster Rapid Split Tests
  53. 53. なぜなぜ5回による真因分析• 企業プロセスの継続的改善に使われる手法。• 何か予期せぬことが起こったときに、「なぜ」 という問いを5回発する。• 5つの階層すべての予防に、バランスよく投資す る。• 想定されるすべての技術的問題の背後には、ふ つう、人間の問題が存在する。症状だけでなく 原因を直す。
  54. 54. 素早いスプリットテストLearn Faster Code FasterFive Whys Root Continuous DeploymentCause Analysis Measure Faster Rapid Split Tests
  55. 55. いつでもスプリットテスト• 仮説を検証するには、A/B テスティングが鍵• 全員が理解できるくらいにシンプルにする• スプリットテストは、コード1行で実現する。 if( setup_experiment(...) == "control" ) { // do it the old way } else { // do it the new way }
  56. 56. AAA指標• Actionable = 行動できる• Accessible = 結果が見える• Auditable = 監査できる
  57. 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

×