LEANSTARTUPの現場 #leanstartup

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 Fit15min

顧客発見 顧客実証 顧客開拓 組織構築

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 STARTUPCustomer Development

全て、ひとつの真理を 様々な側面から見た投影

どれも言ってる本質は同じ

河合さんの「大組織の中でのリーン」で既に出てた…

http://www.slideshare.net/inuro/ss-15681262

守破離

ひたすら師の教えを守り、学ぶ

教えの言葉から抜け出し、他流まで理解を広げ、真意を会得する

型に一切とらわれず、自分の境地に入�る

車を売る オフィスを引き払う

コワーキングスペースに住みつく !

エンジニア雇うお金が勿体無いから 自分で勉強して書く

西海岸スタートアップでは

ファウンダーは・・・

黒田「リーンキャンバスの書き方を相談したいのですが」 !

ファウンダーA「何それ？リーンキャンバスって何？」

500 startupsに入ってるとあるスタートアップとの会話

黒田「スティーブブランクのスタートアップマニュアルに 　　　こうかいてあったんですが、どうやりました？」 !

ファウンダーB「何それ？へー、そんな本あるのか」

500 startupsに入ってるとあるスタートアップとの会話

資金のバーンダウンしていく速度をいかに遅くして なおかつ学びを得るか、そして成功するか

全ての意思決定において 無駄の無い判断をしていること ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する 　≠ 成功を保証するプロセス !

そのために、効率的(例:小さく/短く/安く)に仮説を検証して学びを得る（ことが多い）

真意

まとめはデブサミ2015で！！

ご清聴ありがとうございました！

Appendixという名の書きなぐりボツメモ置き場

チーム構成（アジャイルチーム）

Scrum MasterServer Scrum team

Android Scrum team

iOS Scrum teamScrum Master

PO teamProduct Owner

Sub PO

iOS team Product Backlog

Server team Product Backlog

Android team Product Backlog

Scrum Master

BOSS

Client

Customer

Designer

• 全てのプロセスへのインプットは仮説であり、仮説を立てる力がすべて

• 仮説の質があがれば、どんどんゴールに近づく。

• 仮説の質をあげるには、その業界・ドメインに誰よりも詳しくなること。顧客開発をすること。24時間サービスのことを考えること。常に課題意識を持つこと。そういう生き方をすること。当たり前だけど再確認。

• リーンスタートアップはあくまで仮説がある前提で、それを科学的＋アートに実証する方法。だから、リーンスタートアップをやったからといって成功するわけではないよ！あくまで、失敗による損失を小さくする方法。バーンアウトしていく資金の中、無駄を省き切り詰めてリスクを取り除いていく方法。

• 今も昔も変わらず、これやるだけで成功するなんて方法はない。

このループへのインプット自体はかってに沸いてこない このプロセスに放り込むアイデアを作るのは自分。 市場の見立て、自分達のケーパビリティ、時代の流れ、

様々な変数がある。リーンやったから成功するわけじゃない。 これはあくまでリスクを最小化するプロセス。

BMLループを皆が理解するとき、 エンジニアはロールの壁を越境する。 BMLサイクルの速度があげるための振る舞いになる エンジニアがビジネスKPIを持つことが可能になる !

Churnを減らすことを目標とするエンジニア Retentionを増やすこととを目標とするエンジニア ・各自が仮説をたて、実装し、計測する それを支える技術が、A/Bテストやコホート分析 !

機能実装のエンジニアチームとグロースハックチーム

ビジネスKPIにエンジニアがコミットすることは大事。 →各自の評価制度上の業務目標になる 社内新規事業やストックオプションを持っていないようなケースでは特に重要。 !

社内新規事業においては、ファウンダーとメンバーとの熱量の差は埋められない。業務目標設定が重要。 !

エンジニアに仕様決定の裁量を与え、なおかつ最適なエンジニアリングを行うためには数値の結果目標・責任をあたえる。 !

技術的負債が発生すると自らの改善速度低下を招くため、高度なエンジニアリングとビジネスマインドを要する。

■良くある質問 MVPとは言え、完成品と比べると不完全になってしまうが、それでもユーザーは理解してもらえるのか !

→だからアーリーアダプターで実験する。 彼らは製品にかけている部分は脳内で補完してくれる存在。

■よくある質問 リーンキャンバスの記述レベル。粒度について。 →特にない。自由で良い。 !

ただし、そのドメイン知識がある人と無い人では出来上がったものは全く違う。自分の戦うドメインの知識が充分にあることが前提。それが無い場合は、顧客に会う、聴く、勉強する。顧客理解を深めると自ずとキャンバスの記述レベルが深くなるし、具体性が増す。これこそが顧客開発でもある。 !

あっさりしたものしか書けない場合は、そのドメインの知識が浅いのかもしれないと一度立ち戻ることも必要。

CUSTOMER SEGMENT ・顧客の想定は明確か 　-　セグメント・ペルソナに納得感があるか。 ・理想的な顧客（アーリーアダプター）の見立てが正しいか 　-　リアルにその顧客が顧客の中でのアーリーアダプターに属するか。 !

★想定している顧客が実際にいるか、いる場合のエビデンスもしくは実証実験結果はあるか ★その精度はどれくらいか。

PROBLEM ・想定顧客が抱える課題を構造的に把握し、優先順位が立てられているか。 ・その課題は深い痛みがあるか。解決すべき課題か。 ・その想定顧客の現状の代替手段が明確に想定できているか。 !

★その課題の存在を実証できているか ★その精度はどれくらいか。

UNIQUE VALUE PROPOSITION & SOLUTION ・課題に対する解決策が明確かどうか。 ・アーリーアダプターが既に代替手段で解決している状況において、スイッチングコストを支払ってまでやるべき解決策になっているか。 （Facebookでいいじゃん、LINEでいいじゃん、○○でいいじゃんに答えられるか。プラットフォーマーがやったらどうするの？に答えられるか。） ・解決策に実現性があるか。（チームのケーパも含む） ・性能競争になっていないか。（消耗戦になるだけ） !

★その解決策によって、課題を本当に解決出来ることを実証出来ているか。 ★その精度はどれくらいか。

★検証精度の高さとは？ 例えば、 「送った写真が１０秒で消えるコミュニケーションアプリが欲しいかまわりの人１０人に聞いて、６人が欲しいと言いました！このソリューションは的を得ています！」 という仮説検証結果と、 !

「実際に１０秒で写真が消えてしまうアプリのプロトタイプをつくり、大学の１００人限定で使ってもらったところ、継続率が50％、フリークエンシーが25回/週でした！このソリューションは的を得ています！」という仮説検証結果では、後者の方が検証精度が高い。