Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Itsuki Kuroda, profile picture
Uploaded byItsuki Kuroda
16,313 views

LEANSTARTUPの現場 #leanstartup

LEAN STARTUP UPDATE 2015の資料です。 https://atnd.org/events/60368

Small Business & Entrepreneurship◦
Downloaded 141 times
LEAN STARTUPの 現場 Recruit Holdings Recruit Institute of Technology Media Technology Lab Itsuki KURODA @i2key <- Follow Me Plz :-)
自己紹介 Recruit Holdings Recruit Institute of Technology Media Technology Lab 黒田 樹 (@i2key) ! 全世界でシリーズ累計1000万DLのアプリcameranシリーズ の開発責任者（開発、採用、組織構築、プロセスetc） 社内でリーンスタートアップやアジャイルの導入を推進して います http://mtl.recruit.co.jp
100
速度注意 本日は100スライドです。 発表時間は20分です。 ! Velocity 5枚/分 速すぎて見えなかったら 後ほどSlideShareで・・・
前回までのあらすじ サービス大ヒット ↓ 増員 ↓ カオス ↓ 炎上 ↓ ギスギス ↓ 鎮火 http://www.slideshare.net/i2key/rebuild-devlove-scrum-leanstartup
現場の悩み プロダクトバックログに起票されるタスクが本当にやるべ きことなのか。やるべき理由はあるのか。 ! もっと効率よく出来ないのか ! そのタスク（機能）をリリースしたあとの効果はタスク（機 能）毎にわかるのか。結果から学びを得ているのか。 ! やっていることはサービスの成長に直結しているのか。
LEAN STARTUPで解決する！
守 り つ く し て 離 る る と て も 本 を 忘 る な 破 る と も 千 利 休
守破離 Shu - Ha - Ri
守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る
守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る
スタートアップマニュアル アントレプレナーの教科書 リーンスタートアップ 顧客開発モデルのトリセツ RUNNING LEAN LEAN UX LEAN Analytics リーン開発の現場    ：    ：    ： 先人の知恵に触れる
500Startupsメンター James氏 （LeanStartup）
Pivotal Labs Janice氏 （Lean UX)
Hooked著者 Nir氏 (UX)
Lean Analytics著者 Alistair氏 (Lean Analytics)
IDEO @SFオフィス デザインシンキング ワークショップ （デザインシンキング)
全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する   成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い） 真意
全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する   成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い） 真意 当時は真意を2ミリも 理解できていないけど・・・ 浅い理解
例）写真加工アプリにフィルタ購入機能を作ろう！！やりた いことの実装工数は3人月くらいかかりそうです。 ! あなたがこのプロダクトのオーナーならどうしますか？ ! ①フィルタ購入機能を3人月かけて実装する  （一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユー ザーの10%に表示して確認し、本当に購入ボタンが押された 回数を測定してから開発着手の判断をする。工数は2人日。 （本当に購入されるのかのみを検証） ②のほうが無駄の無い判断してるぽい つまりはこういうこと。
100円で 購入 100円で 購入 現在開発中です！ 近日リリース予定です！ インタビューで「あったら買いますか？」 「買います！」みたいなやりとりよりも確度が高い そういう聴き方したときの「買います」は大抵買わないwww ＜ポップアップ＞
顧客開発モデルに則って現状の理解をする。 ビジネス仮説を全てLeanCanvasに書き出す。 既に実証済みのことと、そうでないこを明らかにする 顧客セグメントを明らかにする 市場タイプを選ぶ 顧客との関係 キーパートナー 売上/プライシング 顧客理解 トラフィック/競合分析 顧客の行動測定 アドバイザリーボードメンバーの選定開始    ：    ： 顧客開発でやるべきこと Lean Canvas
顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 今自分達がスタートアップの どのフェーズに いるかを認識する
顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み
  Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている （Engine of Growthが装着できている） 例）CAC < LTV Scaling 例）Retentionしている MAU右上がり
  Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている （Engine of Growthが装着できている） 例）CAC < LTV Scaling 例）Retentionしている MAU右上がり ←いまココ（※当時）
まだ実証出来ていない仮説に対して リスクの高い順に優先順位をつけて実証していく 実証済 実証済 実証済 実証済
じゃあ、どうやって 仮説を検証するの？？？ ! MVPってのがあってな
MVPとはMinumum Viable Product（検証可能な最小限の製品）。 Productと言ってるけど製品じゃなくてよい。 目的である仮説を検証できればよいので、 それができるものならなんでもMVPと言ってよい（と思う） Build->Measure->Learn MVP ビジネスアイデアを仮説として捉えて 検証するためのプロセス。 仮説検証のためのMVPをBuildして それを元にMeasureし、 その結果得られたデータからLearnする。
開発をしなくても、仮説を検証できるものであれば それはMVPになる。例えばインタビュースクリプトもそう。 それを作るフェーズがBUILDだと理解している。 顧客開発におけるユーザーインタビューについては 馬田さんのスライドに全てお任せしますので、 インタビューによる仮説検証については言及しません！！
【良くある質問】 MVPの粒度ってどれくらいですか？
んなこた、知らん！ 5min
MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する こういう場合もあるし
1つのMVPで 全ての仮説を検証する こういう場合もある
既存市場に参入する場合には、ユーザーは競合サービスによっ て学習がすんでおり、その最低限ここまで出来るでしょう？と いう最低限品質を担保するように追ってしまうとMVPは肥大 化していきます。 最初にサービスを当てにいくのはなぜアーリーアダプターなの か、彼らはそのあって当たり前はなくても補完してくれる存在。 それでも、競合と同等の機能がないとMVPと言えないと言う のであれば、その市場の再セグメント化をして競争しないよう にするとか、戦わない選択をするとかしたほうがよいかも。 既存市場での性能競争がはじまると資金を持っている企業との 体力勝負になるのでつらいだけ。（個人的にそう思います）
顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Scrum 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み
型を学ぶ
アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
http://www.slideshare.net/i2key/rebuild-devlove-scrum-leanstartup
アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
実装した機能（MVP）毎に効果を検証する コホートAにリリース 結果数値をウォッチ コホートBにリリース 結果数値をウォッチ コホートCにリリース 結果数値をウォッチ やったことの単位に結果を見ること
https://www.leanplum.com A/BテストプラットフォームとしてLeanplumを採用
計測例 •仮説 • SNS型サービスだが、ユーザのサインアップ率が悪 い。現在他人の投稿はクローズドでサインアップした ユーザーにしか見えない。サインアップしてないユーザ にも見えるようにすることでSNSのUXを事前体験・学 習させるとアカウント登録率があがるのはないか。 •MVP • サインアップ不要で他人の投稿を閲覧出来る機能を実 装しユーザ数%対象に公開して計測。 •学びたいこと • サインアップ率の上昇。及び、既存機能への悪影響 度。
実装した機能毎にコホートxA/Bテストを行い、 様々なトレードオフを意識して判断する。
http://www.localytics.jp 全体の指標モニタリングのために Localytics採用（GAの代わり）
リリース後はコホートで対象バージョンの リテンション等を計測。この画面は7日間継続率。 ※サンプルデータです！
ver1から参加したユーザー ver2から参加したユーザー ver3から参加したユーザー フォロワー数▲人のユーザー フォロワー数■人のユーザー フォロワー数●人のユーザー このように縦に見ないほうがよい場合がある
コホート分析の例 ・Version○○から使い始めた人の継続率 ・○○機能をβ公開しているユーザーの継続率 ・○○に「いいね」した人の継続率 ・○○した人の継続率 ・フォロワー○○人の人の継続率 ・○○をフォローしている人の継続率 ! 何で測るか Localytics最高。 MixPanelやLeanPlumもよい。コホートを作って、そこに向 けてプッシュが打てるものもある。
アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
リーンスタートアップとは科学的アプローチというけれど、 その場合、実験の計画の思考プロセスは逆。 こうじゃなく 実際の思考プロセスは こう考えて計画する
①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ 思考プロセス
①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー 思考プロセス
⑥どう構築するか？ (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー もっとも効果的に学びが得られるMVPはどれか選択する ・費用対効果 ・期間 ・工数 ・この検証方法により回避できる将来のリスク ・この検証方法により逆に発生する将来のリスク 思考プロセス
⑫仮説を調整する ⑪学ぶ ⑩データを元に検証 ⑨計測する ⑧完成したMVP ⑦構築する (MVP)A/Bテスト 実証プロセス
http://www.slideshare.net/aerodynamic/mvp-canvas この一連の思考プロセス・実証プロセスを 髙橋さんとフォーマット化！
http://www.slideshare.net/aerodynamic/mvp-canvas 仮説 何を学ぶのか 仮説実証に 必要なデータ 条件 MVP構築に 必要なコスト 仮説実証に 必要な時間 回避/発生する 将来のリスク 結果と、得た学び MVPのタイプ ・紙プロト ・インタビュー ・A/Bテスト ・動くデモ etc 何を作るのか どうやってそのMVPで実証するのか
LeanCanvas - MVPCanvas - Scrum 型の整理
Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ Out of Building!!! MVPがインタビューの場合 MVPがエンジニア稼働必要な場合 改善タスク ・改善目的A/Bテスト ・計測装置導入 メンテナンスタスク ・技術的負債解消 ・OSバージョンアップ対応 ・バグ対応 アライアンスタスク 直接仮説検証には 関係ないけど サービス維持に 必要なタスク
Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 顧客 発見 顧客 実証 顧客 開拓 組織 構築 Problem Solution Fit Product Market Fit Pivot
守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る 10min
この型をひたすら回すと・・・・
プロダクトバックログが最小化されていく ＝やらないことが最大化されていく エンジニアの働き方（活躍出来る場所）に 一部変化が出てくる ＝グロースハッカーというロールの出現
プロダクトバックログが最小化されていく ＝やらないことが最大化されていく エンジニアの働き方（活躍出来る場所）に 一部変化が出てくる ＝グロースハッカーというロールの出現
LeanStartup以前の Product Backlog LeanStartup以後の Product Backlog ・○○検証用モック作成 ・○○検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・リファラル向上改善 ・登録ファネル改善 ・計測基盤実装 ・コホートに対するプッシュ実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装
Product Backlog ＜開発タスク＞ 10個ひらめいた！ Product Owner 10個のエンジニアタスク LeanStartup以前
Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築 （エンジニアタスク） 10個のMVP設計 7個のOutOfBuilding （プロダクトオーナータスク） LeanStartup以後
新規機能追加コスト ＞ 仮説検証コスト 新規機能追加コスト ＜ 仮説検証コスト
プロダクトバックログが最小化されていく ＝やらないことが最大化されていく ＝エンジニアの開発タスクが減る ＝エンジニア体制の縮小（最適化）  or 技術的負債解消に当てる時間  or エンジニアドリブンで改善する時間   
プロダクトバックログが最小化されていく ＝やらないことが最大化されていく エンジニアの働き方（活躍出来る場所）に 一部変化が出てくる ＝グロースハッカーというロールの出現
Lean Engineer 価値：仮説検証サイクルの速度を上げること コミット：サービスの成長 生産性：仮説検証できた回数/時間 Not Lean Engineer 価値：開発をやりきること コミット：開発の完遂 生産性：Step/時間 エンジニアの働き方 ＝グロースハッカー
ここでのグロースハックの定義 ボタンの色を赤から緑に変えて コンバージョン率あがりました！！ ではなく
ここでのグロースハックの定義 本質的なサービスの成長に寄与するエンジニア  →ビジネスKPIにコミットする !   エンジニアはテーマを持って改善を行う   例えば【継続率】及びそれを構成する意味のある数値      【チャーンレート改善】 !   その数値を改善するために、自身で仮説検証サイクルを   自らエンジニアリングすることにより   高速で実施しビジネスKPIを向上させる。 数値にコミット出来るため、 権限と成果責任がエンジニアに発生する。 エンジニアの適正によってはこっちのが、 やりがいがある（場合もある）し、成長速度はあがる。
プロダクトチーム 仮説に対して機能を実装する ! プロダクトオーナー エンジニア デザイナ マーケタ セールス アライアンス グロースチーム 実証された仮説の機能を 磨き上げて成長率を改善する ! エンジニア デザイナ データアナリスト（いれば） ! 数値にコミットする データから仮説を導き出し 改善サイクルを高速に回す 各施策がバッティングしないための基盤が必要 A/Bテストやコホート
プロダクトチーム グロースチーム プロダクトチームP/S Fit前 P/M Fit Scaling プロダクト グロースチーム 体制コスト比率 フェーズに応じた体制コスト比率（例、業態やドメインによる） 基盤
※ただし、エンジニアリングのみにコミットしたいスーパーハっ カーを否定しているわけではなく、その場合は、チーム全体と してリーンに回るようにチームデザインをするべき。望まない 働き方の強要をして、スーパーハっカーの生産性をさげても意 味がない。
闇雲に改善しても意味ないので、 AARRRを元に スタートアップのフェーズに応じて やるべき改善をするようにする
Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 AARRRモデル復習 ※ChurnはAARRRには 無いけど勝手に付け足しました
LEAN STARTUPを 理解した上で AARRRを再度見てみると いろいろスッキリする
Acquisition Retention Churn Referral Activation Revenue 一番大事
継続して利用してくれているということは 顧客の課題を解決していること （それが想定していた課題と 想定していた解決策かはまた別だけど） ! ユーザーがプロダクトに 価値を感じている状態 エンゲージしている状態 ! Problem Solution Fit 15min
顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling
実証済み 実証済み 実証済み 実証済み
MAU ＝ 新規流入ユーザ数＋継続ユーザ数＋復活ユーザ数 MAUの構成要素を分解して理解する 買える 増やせる SEO ASO テクニック バイラル P/S FIT ！！！
Acquisition Retention Churn Referral Activation Revenue
あと数日でチャーンしそうなユーザーをチャーンさせない 例えば、あと数日で退会してしまいそうなユーザーの母集団に 対して、コホートをきり、そこに対してアクションをするよう な仕組みを実装し再びサービスの価値を感じるようにしてもら い退会率を下げる。 ! チャーンしたユーザーを復活させる 使うのを辞めてしまったユーザーの母集団に対しては、友達の 誕生日にプッシュ通知を出したり、友達が結婚したらプッシュ 通知したり再びサービスの価値を感じてもらえるようにする。
Acquisition Retention Churn Referral Activation Revenue ユーザーが全くRetention （P/S Fit）していないのに AcquisitionやActivationの 改善をする人が多い。 ! 例）ボタンの色変えて○％UP 例）有料集客、キャンペーン ユーザーが全くRetention （P/S Fit）してないのに Referralの改善をする人が多 い。 例）ソーシャル投稿 例）友達招待機能 !
顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling 売り上げを最大化するという チューニングの意味で ここら辺でそういうことはして欲しい まずは価値を高めることが先
引用 - Lean Entrepreneur P163 P/S Fitしてない何か
Acquisition Retention Churn Referral Activation Revenue 本当に良いものは、テクニックを 使わなくても自然と広まるもの。 テクニックはそれを加速させるため。
Growth Hack(er) AARRR LEAN STARTUP Customer Development 全て、ひとつの真理を 様々な側面から見た投影 どれも言ってる本質は同じ
河合さんの「大組織の中でのリーン」で既に出てた… http://www.slideshare.net/inuro/ss-15681262
守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る
車を売る オフィスを引き払う コワーキングスペースに住みつく ! エンジニア雇うお金が勿体無いから 自分で勉強して書く 西海岸スタートアップでは ファウンダーは・・・
黒田「リーンキャンバスの書き方を相談したいのですが」 ! ファウンダーA「何それ？リーンキャンバスって何？」 500 startupsに入ってるとあるスタートアップとの会話
黒田「スティーブブランクのスタートアップマニュアルに    こうかいてあったんですが、どうやりました？」 ! ファウンダーB「何それ？へー、そんな本あるのか」 500 startupsに入ってるとあるスタートアップとの会話
資金のバーンダウンしていく速度をいかに遅くして なおかつ学びを得るか、そして成功するか
全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する   成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い） 真意
まとめはデブサミ2015で！！