エンタープライズへのアジャイル開発の導入事例
Your SlideShare is downloading.
×
Check these out next
LEANSTARTUPの現場 #leanstartup
- 1. LEAN STARTUPの 現場 Recruit Holdings Recruit Institute of Technology Media Technology Lab Itsuki KURODA @i2key <- Follow Me Plz :-)
- 2. 自己紹介 Recruit Holdings Recruit Institute of Technology Media Technology Lab 黒田 樹 (@i2key) ! 全世界でシリーズ累計1000万DLのアプリcameranシリーズ の開発責任者（開発、採用、組織構築、プロセスetc） 社内でリーンスタートアップやアジャイルの導入を推進して います http://mtl.recruit.co.jp
- 3. 100
- 4. 速度注意 本日は100スライドです。 発表時間は20分です。 ! Velocity 5枚/分 速すぎて見えなかったら 後ほどSlideShareで・・・
- 5. 前回までのあらすじ サービス大ヒット ↓ 増員 ↓ カオス ↓ 炎上 ↓ ギスギス ↓ 鎮火 http://www.slideshare.net/i2key/rebuild-devlove-scrum-leanstartup
- 6. 現場の悩み プロダクトバックログに起票されるタスクが本当にやるべ きことなのか。やるべき理由はあるのか。 ! もっと効率よく出来ないのか ! そのタスク（機能）をリリースしたあとの効果はタスク（機 能）毎にわかるのか。結果から学びを得ているのか。 ! やっていることはサービスの成長に直結しているのか。
- 7. LEAN STARTUPで解決する！
- 8. 守 り つ く し て 離 る る と て も 本 を 忘 る な 破 る と も 千 利 休
- 9. 守破離 Shu - Ha - Ri
- 10. 守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る
- 11. 守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る
- 12. スタートアップマニュアル アントレプレナーの教科書 リーンスタートアップ 顧客開発モデルのトリセツ RUNNING LEAN LEAN UX LEAN Analytics リーン開発の現場 ： ： ： 先人の知恵に触れる
- 13. 500Startupsメンター James氏 （LeanStartup）
- 14. Pivotal Labs Janice氏 （Lean UX)
- 15. Hooked著者 Nir氏 (UX)
- 16. Lean Analytics著者 Alistair氏 (Lean Analytics)
- 17. IDEO @SFオフィス デザインシンキング ワークショップ （デザインシンキング)
- 18. 全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する 成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い） 真意
- 19. 全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する 成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い） 真意 当時は真意を2ミリも 理解できていないけど・・・ 浅い理解
- 20. 例）写真加工アプリにフィルタ購入機能を作ろう！！やりた いことの実装工数は3人月くらいかかりそうです。 ! あなたがこのプロダクトのオーナーならどうしますか？ ! ①フィルタ購入機能を3人月かけて実装する （一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユー ザーの10%に表示して確認し、本当に購入ボタンが押された 回数を測定してから開発着手の判断をする。工数は2人日。 （本当に購入されるのかのみを検証） ②のほうが無駄の無い判断してるぽい つまりはこういうこと。
- 21. 100円で 購入 100円で 購入 現在開発中です！ 近日リリース予定です！ インタビューで「あったら買いますか？」 「買います！」みたいなやりとりよりも確度が高い そういう聴き方したときの「買います」は大抵買わないwww ＜ポップアップ＞
- 22. 顧客開発モデルに則って現状の理解をする。 ビジネス仮説を全てLeanCanvasに書き出す。 既に実証済みのことと、そうでないこを明らかにする 顧客セグメントを明らかにする 市場タイプを選ぶ 顧客との関係 キーパートナー 売上/プライシング 顧客理解 トラフィック/競合分析 顧客の行動測定 アドバイザリーボードメンバーの選定開始 ： ： 顧客開発でやるべきこと Lean Canvas
- 23. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 今自分達がスタートアップの どのフェーズに いるかを認識する
- 24. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み
- 25. Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている （Engine of Growthが装着できている） 例）CAC < LTV Scaling 例）Retentionしている MAU右上がり
- 26. Agile 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot ユーザーの深い課題/ニーズを把握し 解決策を提示しそれが刺さっている ビジネスモデルの成立することが 実証できている （Engine of Growthが装着できている） 例）CAC < LTV Scaling 例）Retentionしている MAU右上がり ←いまココ（※当時）
- 27. まだ実証出来ていない仮説に対して リスクの高い順に優先順位をつけて実証していく 実証済 実証済 実証済 実証済
- 28. じゃあ、どうやって 仮説を検証するの？？？ ! MVPってのがあってな
- 29. MVPとはMinumum Viable Product（検証可能な最小限の製品）。 Productと言ってるけど製品じゃなくてよい。 目的である仮説を検証できればよいので、 それができるものならなんでもMVPと言ってよい（と思う） Build->Measure->Learn MVP ビジネスアイデアを仮説として捉えて 検証するためのプロセス。 仮説検証のためのMVPをBuildして それを元にMeasureし、 その結果得られたデータからLearnする。
- 30. 開発をしなくても、仮説を検証できるものであれば それはMVPになる。例えばインタビュースクリプトもそう。 それを作るフェーズがBUILDだと理解している。 顧客開発におけるユーザーインタビューについては 馬田さんのスライドに全てお任せしますので、 インタビューによる仮説検証については言及しません！！
- 31. 【良くある質問】 MVPの粒度ってどれくらいですか？
- 32. んなこた、知らん！ 5min
- 33. MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する MVPで検証する こういう場合もあるし
- 34. 1つのMVPで 全ての仮説を検証する こういう場合もある
- 35. 既存市場に参入する場合には、ユーザーは競合サービスによっ て学習がすんでおり、その最低限ここまで出来るでしょう？と いう最低限品質を担保するように追ってしまうとMVPは肥大 化していきます。 最初にサービスを当てにいくのはなぜアーリーアダプターなの か、彼らはそのあって当たり前はなくても補完してくれる存在。 それでも、競合と同等の機能がないとMVPと言えないと言う のであれば、その市場の再セグメント化をして競争しないよう にするとか、戦わない選択をするとかしたほうがよいかも。 既存市場での性能競争がはじまると資金を持っている企業との 体力勝負になるのでつらいだけ。（個人的にそう思います）
- 36. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Scrum 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み
- 37. 型を学ぶ
- 38. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
- 39. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
- 40. http://www.slideshare.net/i2key/rebuild-devlove-scrum-leanstartup
- 41. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
- 42. 実装した機能（MVP）毎に効果を検証する コホートAにリリース 結果数値をウォッチ コホートBにリリース 結果数値をウォッチ コホートCにリリース 結果数値をウォッチ やったことの単位に結果を見ること
- 43. https://www.leanplum.com A/BテストプラットフォームとしてLeanplumを採用
- 44. 計測例 •仮説 • SNS型サービスだが、ユーザのサインアップ率が悪 い。現在他人の投稿はクローズドでサインアップした ユーザーにしか見えない。サインアップしてないユーザ にも見えるようにすることでSNSのUXを事前体験・学 習させるとアカウント登録率があがるのはないか。 •MVP • サインアップ不要で他人の投稿を閲覧出来る機能を実 装しユーザ数%対象に公開して計測。 •学びたいこと • サインアップ率の上昇。及び、既存機能への悪影響 度。
- 45. 実装した機能毎にコホートxA/Bテストを行い、 様々なトレードオフを意識して判断する。
- 46. http://www.localytics.jp 全体の指標モニタリングのために Localytics採用（GAの代わり）
- 47. リリース後はコホートで対象バージョンの リテンション等を計測。この画面は7日間継続率。 ※サンプルデータです！
- 48. ver1から参加したユーザー ver2から参加したユーザー ver3から参加したユーザー フォロワー数▲人のユーザー フォロワー数■人のユーザー フォロワー数●人のユーザー このように縦に見ないほうがよい場合がある
- 49. コホート分析の例 ・Version○○から使い始めた人の継続率 ・○○機能をβ公開しているユーザーの継続率 ・○○に「いいね」した人の継続率 ・○○した人の継続率 ・フォロワー○○人の人の継続率 ・○○をフォローしている人の継続率 ! 何で測るか Localytics最高。 MixPanelやLeanPlumもよい。コホートを作って、そこに向 けてプッシュが打てるものもある。
- 50. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計 我々のLeanStartupの型
- 51. リーンスタートアップとは科学的アプローチというけれど、 その場合、実験の計画の思考プロセスは逆。 こうじゃなく 実際の思考プロセスは こう考えて計画する
- 52. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ 思考プロセス
- 53. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー 思考プロセス
- 54. ⑥どう構築するか？ (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー もっとも効果的に学びが得られるMVPはどれか選択する ・費用対効果 ・期間 ・工数 ・この検証方法により回避できる将来のリスク ・この検証方法により逆に発生する将来のリスク 思考プロセス
- 55. ⑫仮説を調整する ⑪学ぶ ⑩データを元に検証 ⑨計測する ⑧完成したMVP ⑦構築する (MVP)A/Bテスト 実証プロセス
- 56. http://www.slideshare.net/aerodynamic/mvp-canvas この一連の思考プロセス・実証プロセスを 髙橋さんとフォーマット化！
- 57. http://www.slideshare.net/aerodynamic/mvp-canvas 仮説 何を学ぶのか 仮説実証に 必要なデータ 条件 MVP構築に 必要なコスト 仮説実証に 必要な時間 回避/発生する 将来のリスク 結果と、得た学び MVPのタイプ ・紙プロト ・インタビュー ・A/Bテスト ・動くデモ etc 何を作るのか どうやってそのMVPで実証するのか
- 58. LeanCanvas - MVPCanvas - Scrum 型の整理
- 59. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ Out of Building!!! MVPがインタビューの場合 MVPがエンジニア稼働必要な場合 改善タスク ・改善目的A/Bテスト ・計測装置導入 メンテナンスタスク ・技術的負債解消 ・OSバージョンアップ対応 ・バグ対応 アライアンスタスク 直接仮説検証には 関係ないけど サービス維持に 必要なタスク
- 60. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 顧客 発見 顧客 実証 顧客 開拓 組織 構築 Problem Solution Fit Product Market Fit Pivot
- 61. 守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る 10min
- 62. この型をひたすら回すと・・・・
- 63. プロダクトバックログが最小化されていく ＝やらないことが最大化されていく エンジニアの働き方（活躍出来る場所）に 一部変化が出てくる ＝グロースハッカーというロールの出現
- 64. プロダクトバックログが最小化されていく ＝やらないことが最大化されていく エンジニアの働き方（活躍出来る場所）に 一部変化が出てくる ＝グロースハッカーというロールの出現
- 65. LeanStartup以前の Product Backlog LeanStartup以後の Product Backlog ・○○検証用モック作成 ・○○検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・リファラル向上改善 ・登録ファネル改善 ・計測基盤実装 ・コホートに対するプッシュ実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装
- 66. Product Backlog ＜開発タスク＞ 10個ひらめいた！ Product Owner 10個のエンジニアタスク LeanStartup以前
- 67. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築 （エンジニアタスク） 10個のMVP設計 7個のOutOfBuilding （プロダクトオーナータスク） LeanStartup以後
- 68. 新規機能追加コスト ＞ 仮説検証コスト 新規機能追加コスト ＜ 仮説検証コスト
- 69. プロダクトバックログが最小化されていく ＝やらないことが最大化されていく ＝エンジニアの開発タスクが減る ＝エンジニア体制の縮小（最適化） or 技術的負債解消に当てる時間 or エンジニアドリブンで改善する時間
- 70. プロダクトバックログが最小化されていく ＝やらないことが最大化されていく エンジニアの働き方（活躍出来る場所）に 一部変化が出てくる ＝グロースハッカーというロールの出現
- 71. Lean Engineer 価値：仮説検証サイクルの速度を上げること コミット：サービスの成長 生産性：仮説検証できた回数/時間 Not Lean Engineer 価値：開発をやりきること コミット：開発の完遂 生産性：Step/時間 エンジニアの働き方 ＝グロースハッカー
- 72. ここでのグロースハックの定義 ボタンの色を赤から緑に変えて コンバージョン率あがりました！！ ではなく
- 73. ここでのグロースハックの定義 本質的なサービスの成長に寄与するエンジニア →ビジネスKPIにコミットする ! エンジニアはテーマを持って改善を行う 例えば【継続率】及びそれを構成する意味のある数値 【チャーンレート改善】 ! その数値を改善するために、自身で仮説検証サイクルを 自らエンジニアリングすることにより 高速で実施しビジネスKPIを向上させる。 数値にコミット出来るため、 権限と成果責任がエンジニアに発生する。 エンジニアの適正によってはこっちのが、 やりがいがある（場合もある）し、成長速度はあがる。
- 74. プロダクトチーム 仮説に対して機能を実装する ! プロダクトオーナー エンジニア デザイナ マーケタ セールス アライアンス グロースチーム 実証された仮説の機能を 磨き上げて成長率を改善する ! エンジニア デザイナ データアナリスト（いれば） ! 数値にコミットする データから仮説を導き出し 改善サイクルを高速に回す 各施策がバッティングしないための基盤が必要 A/Bテストやコホート
- 75. プロダクトチーム グロースチーム プロダクトチームP/S Fit前 P/M Fit Scaling プロダクト グロースチーム 体制コスト比率 フェーズに応じた体制コスト比率（例、業態やドメインによる） 基盤
- 76. ※ただし、エンジニアリングのみにコミットしたいスーパーハっ カーを否定しているわけではなく、その場合は、チーム全体と してリーンに回るようにチームデザインをするべき。望まない 働き方の強要をして、スーパーハっカーの生産性をさげても意 味がない。
- 77. 闇雲に改善しても意味ないので、 AARRRを元に スタートアップのフェーズに応じて やるべき改善をするようにする
- 78. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 AARRRモデル復習 ※ChurnはAARRRには 無いけど勝手に付け足しました
- 79. LEAN STARTUPを 理解した上で AARRRを再度見てみると いろいろスッキリする
- 80. Acquisition Retention Churn Referral Activation Revenue 一番大事
- 81. 継続して利用してくれているということは 顧客の課題を解決していること （それが想定していた課題と 想定していた解決策かはまた別だけど） ! ユーザーがプロダクトに 価値を感じている状態 エンゲージしている状態 ! Problem Solution Fit 15min
- 82. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling
- 83. 実証済み 実証済み 実証済み 実証済み
- 84. MAU ＝ 新規流入ユーザ数＋継続ユーザ数＋復活ユーザ数 MAUの構成要素を分解して理解する 買える 増やせる SEO ASO テクニック バイラル P/S FIT ！！！
- 85. Acquisition Retention Churn Referral Activation Revenue
- 86. あと数日でチャーンしそうなユーザーをチャーンさせない 例えば、あと数日で退会してしまいそうなユーザーの母集団に 対して、コホートをきり、そこに対してアクションをするよう な仕組みを実装し再びサービスの価値を感じるようにしてもら い退会率を下げる。 ! チャーンしたユーザーを復活させる 使うのを辞めてしまったユーザーの母集団に対しては、友達の 誕生日にプッシュ通知を出したり、友達が結婚したらプッシュ 通知したり再びサービスの価値を感じてもらえるようにする。
- 87. Acquisition Retention Churn Referral Activation Revenue ユーザーが全くRetention （P/S Fit）していないのに AcquisitionやActivationの 改善をする人が多い。 ! 例）ボタンの色変えて○％UP 例）有料集客、キャンペーン ユーザーが全くRetention （P/S Fit）してないのに Referralの改善をする人が多 い。 例）ソーシャル投稿 例）友達招待機能 !
- 88. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Pivot Scaling 売り上げを最大化するという チューニングの意味で ここら辺でそういうことはして欲しい まずは価値を高めることが先
- 89. 引用 - Lean Entrepreneur P163 P/S Fitしてない何か
- 90. Acquisition Retention Churn Referral Activation Revenue 本当に良いものは、テクニックを 使わなくても自然と広まるもの。 テクニックはそれを加速させるため。
- 91. Growth Hack(er) AARRR LEAN STARTUP Customer Development 全て、ひとつの真理を 様々な側面から見た投影 どれも言ってる本質は同じ
- 92. 河合さんの「大組織の中でのリーン」で既に出てた… http://www.slideshare.net/inuro/ss-15681262
- 93. 守 破 離 ひたすら師の教えを守り、 学ぶ 教えの言葉から抜け出し、 他流まで理解を広げ、 真意を会得する 型に一切とらわれず、 自分の境地に入�る
- 94. 車を売る オフィスを引き払う コワーキングスペースに住みつく ! エンジニア雇うお金が勿体無いから 自分で勉強して書く 西海岸スタートアップでは ファウンダーは・・・
- 95. 黒田「リーンキャンバスの書き方を相談したいのですが」 ! ファウンダーA「何それ？リーンキャンバスって何？」 500 startupsに入ってるとあるスタートアップとの会話
- 96. 黒田「スティーブブランクのスタートアップマニュアルに こうかいてあったんですが、どうやりました？」 ! ファウンダーB「何それ？へー、そんな本あるのか」 500 startupsに入ってるとあるスタートアップとの会話
- 97. 資金のバーンダウンしていく速度をいかに遅くして なおかつ学びを得るか、そして成功するか
- 98. 全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する 成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い） 真意
- 99. まとめはデブサミ2015で！！
- 100. ご清聴ありがとうございました！
- 101. Appendix という名の書きなぐりボツメモ置き場
- 102. チーム構成（アジャイルチーム） Scrum Master Server Scrum team Android Scrum team iOS Scrum team Scrum Master PO team Product Owner Sub PO iOS team Product Backlog Server team Product Backlog Android team Product Backlog Scrum Master BOSS Client Customer Designer
- 103. • 全てのプロセスへのインプットは仮説であり、仮説を立てる力がすべて • 仮説の質があがれば、どんどんゴールに近づく。 • 仮説の質をあげるには、その業界・ドメインに誰よりも詳しくなること。 顧客開発をすること。24時間サービスのことを考えること。常に課題意 識を持つこと。そういう生き方をすること。当たり前だけど再確認。 • リーンスタートアップはあくまで仮説がある前提で、それを科学的＋アー トに実証する方法。だから、リーンスタートアップをやったからといって 成功するわけではないよ！あくまで、失敗による損失を小さくする方法。 バーンアウトしていく資金の中、無駄を省き切り詰めてリスクを取り除い ていく方法。 • 今も昔も変わらず、これやるだけで成功するなんて方法はない。
- 104. このループへのインプット自体はかってに沸いてこない このプロセスに放り込むアイデアを作るのは自分。 市場の見立て、自分達のケーパビリティ、時代の流れ、 様々な変数がある。リーンやったから成功するわけじゃない。 これはあくまでリスクを最小化するプロセス。
- 105. BMLループを皆が理解するとき、 エンジニアはロールの壁を越境する。 BMLサイクルの速度があげるための振る舞いになる エンジニアがビジネスKPIを持つことが可能になる ! Churnを減らすことを目標とするエンジニア Retentionを増やすこととを目標とするエンジニア ・各自が仮説をたて、実装し、計測する それを支える技術が、A/Bテストやコホート分析 ! 機能実装のエンジニアチームとグロースハックチーム
- 106. ビジネスKPIにエンジニアがコミットすることは大事。 →各自の評価制度上の業務目標になる 社内新規事業やストックオプションを持っていないようなケー スでは特に重要。 ! 社内新規事業においては、ファウンダーとメンバーとの熱量の 差は埋められない。業務目標設定が重要。 ! エンジニアに仕様決定の裁量を与え、なおかつ最適なエンジニ アリングを行うためには数値の結果目標・責任をあたえる。 ! 技術的負債が発生すると自らの改善速度低下を招くため、高度 なエンジニアリングとビジネスマインドを要する。
- 107. ■良くある質問 MVPとは言え、完成品と比べると不完全になってしまうが、 それでもユーザーは理解してもらえるのか ! →だからアーリーアダプターで実験する。 彼らは製品にかけている部分は脳内で補完してくれる存在。
- 108. ■よくある質問 リーンキャンバスの記述レベル。粒度について。 →特にない。自由で良い。 ! ただし、そのドメイン知識がある人と無い人では出来上がった ものは全く違う。自分の戦うドメインの知識が充分にあること が前提。それが無い場合は、顧客に会う、聴く、勉強する。顧 客理解を深めると自ずとキャンバスの記述レベルが深くなるし、 具体性が増す。これこそが顧客開発でもある。 ! あっさりしたものしか書けない場合は、そのドメインの知識が 浅いのかもしれないと一度立ち戻ることも必要。
- 109. CUSTOMER SEGMENT ・顧客の想定は明確か - セグメント・ペルソナに納得感があるか。 ・理想的な顧客（アーリーアダプター）の見立てが正しいか - リアルにその顧客が顧客の中でのアーリーアダプターに 属するか。 ! ★想定している顧客が実際にいるか、いる場合のエビデンス もしくは実証実験結果はあるか ★その精度はどれくらいか。
- 110. PROBLEM ・想定顧客が抱える課題を構造的に把握し、優先順位 が立てられているか。 ・その課題は深い痛みがあるか。解決すべき課題か。 ・その想定顧客の現状の代替手段が明確に想定できて いるか。 ! ★その課題の存在を実証できているか ★その精度はどれくらいか。
- 111. UNIQUE VALUE PROPOSITION & SOLUTION ・課題に対する解決策が明確かどうか。 ・アーリーアダプターが既に代替手段で解決している状況 において、スイッチングコストを支払ってまでやるべき解 決策になっているか。 （Facebookでいいじゃん、LINEでいいじゃん、○○でい いじゃんに答えられるか。プラットフォーマーがやったら どうするの？に答えられるか。） ・解決策に実現性があるか。（チームのケーパも含む） ・性能競争になっていないか。（消耗戦になるだけ） ! ★その解決策によって、課題を本当に解決出来ることを実 証出来ているか。 ★その精度はどれくらいか。
- 112. ★検証精度の高さとは？ 例えば、 「送った写真が１０秒で消えるコミュニケーションア プリが欲しいかまわりの人１０人に聞いて、６人が欲 しいと言いました！このソリューションは的を得てい ます！」 という仮説検証結果と、 ! 「実際に１０秒で写真が消えてしまうアプリのプロト タイプをつくり、大学の１００人限定で使ってもらっ たところ、継続率が50％、フリークエンシーが25回/ 週でした！このソリューションは的を得ています！」 という仮説検証結果では、後者の方が検証精度が高 い。
