バリデーションボードを使って新サービス開発をやってみた

New
Service
Development
By Validation Board

上段にはCustomer-Problem-Solutionの「仮定」を、下段には「実験仮説」とその検証結果を書き入れて使う。
それによって、仮説-実験-検証のプロセス、ピボット、検証結果をすべて１枚のボードに可視化できる。

Issue
「誰が」「どんな問題を」持っているか
ユーザインタビューなどでIssueが
存在するかを実験・検証

Solution
Issueに対してのSolutionを考える
PitchなどでSolutionが魅力的か、
成立するかを実験・検証

Service
人力などでSolutionのMVPを作る
プロトタイプでServiceの価値を
実験・検証
「Issue」「Solution」「Service」の3ステップそれぞれで、仮説-実験-検証のサイクルを回していく。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5/14
5/16
5/28
6/6
6/11
6/20
6/27
7/1
7/3
7/4
7/11
7/18
7/25
8/1
8/5

キックオフ
Issueの設定
実験仮説の設定
インタビュー設計
インタビュイーリクルーティング
インタビュー①・②
インタビュー③
IssueのPivot
Solution仮説の設定
LP仕様・アプリ名の検討
LP制作
LPブラッシュアップ
Solution価値仮説検証方法のPivot
Solution価値仮説の検証結果

今回は、3ヶ月間・15回の活動を通して、新サービスの開発をやってみた。
ぐっと詰めれば2週間程度で十分ここまでできるはず。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5/14
キックオフ
5/16
Issueの設定
Issue Assumption
5/28
6/6
6/11
6/20 Issueインタビュイーリクルーティング
Experiment
6/27
7/1
7/3
IssueのPivot
Issue Validate
7/4
Solution Assumptiom
7/11
7/18
LP制作
Service Prototyping
7/25
8/1 Service Experiment
8/5 Service Validate

「Issue」「Solution」「Service」の3ステップを当てはめるとこんな感じ。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5/14
キックオフ
5/16
Issueの設定
Issue Assumption
5/28
6/6
6/11
6/20 Issueインタビュイーリクルーティング
Experiment
6/27
7/1
7/3
IssueのPivot
Issue Validate
7/4
7/11
7/18
LP制作
7/25
8/1
8/5

まずは「Issue」の仮説-実験-検証。

個人的な趣味から、アートをテーマに新しいサービスの可能性を探る。

ブレストを行い、ワークショップ形式で「Issue」、ターゲットと課題の仮説を立てる。

【

Who?

】

『休日に展覧会を見に行く、都会に住む社会人』

【 Problem 】
『作品の背景・意図をもっと深く知りたい』

その結果、最初に決めた「Issue」はこれ。

【 Assumption 】
『気になった作品に解説が付いていない』

そして「Assumption」、最もIssueのコアになると思った実験仮説がこれ。
こういう体験があると分かれば、「Issue」が正しいと検証できるのではないか？ということ。

Riskiest Assumptionの実証
ユーザインタビュー

その実験仮説を、ユーザインタビューを通して確かめていく。

Open Question
応答内容を相手に委ねる質問形式のこと。

Closed Question
相手が「はい」「いいえ」あるいは
一言で答えられるような質問形式のこと。
インタビュー質問には「Open Question」と「Closed Question」の2種類がある。
直接Issueの有無を尋ねてしまうと回答を誘導しかねないので、会話形式の「Open Question」で探るのが好ましい。

===================================
インタビューガイドライン
===================================
■1.イントロ(3分)
---------------------------------------------------◎1.挨拶
・自己紹介&インタビュー目的
◎2.撮影許可
・発言を収録することの説明
・利用目的の説明
---------------------------------------------------■2.事前インタビュー（5～10分）
---------------------------------------------------◎1.個人属性
・仕事
・家族構成
・趣味
・ライフスタイル（一人暮らしなど）

---------------------------------------------------------■3.インタビュー（30分）
---------------------------------------------------------◎1.美術館での体験について
・直近で美術館に行った時の話
・今までで一番良かった美術館の体験
◎2.実証したい内容について
・美術館で気になったについて調べる時はありますか？
・どうやって調べますか？直近の話を聞かせて下さい。
・美術館で解説を読む機会はあるか？
※直近のストーリーも聞く
・気になった作品に解説が付いていない時は？
・音声ガイドは利用しますか？
※直近のストーリーも聞く
-------------------------------------------------------■4.事後インタビュー（5～10分）
-------------------------------------------------------・美術館の解説（キャプション/音声解説）について
率直な感想を聞かせて下さい。
・美術館の解説（キャプション/音声解説）に1～7
で評価するとしたらどれぐらい？
また、その理由は？
・満足していない場合、この評価を上げる場合、
何か1つ改善するとしたら、
何を改善すべきだと思いますか？

軸となる質問項目はもらさないようにインタビューガイドラインにまとめるが、気になったところは都度対話しながら掘
り下げていく。撮影・録音などログを取っておき、すぐに振り返るのも大切なポイント。

KPI
||

Over 3/6

KPIは「6人中3人以上からそのニーズが見られれば脈あり」と判断することに。

情報は事前に
調べてから行く。

誰かと行くと
キャプション
読んでられない。

音声ガイドは
声がキライ。

ぶっちゃけ
説明はないなら
ないでいい。

むしろ
人だかりができて
邪魔。

解決したい課題

インタビューから得られたユーザの声を見ると、解決したいと思った課題は…

解決したい課題

「思い込み」

こちらの勝手な「思い込み」…ユーザからは別に求められてない！！
だけど一方で…

図録を見返して
そのときの気持ち
を思い出す。

展覧会に行った
証に半券を
とっておく。

作品情報がもっと欲しいのではなく、思い出を残したい、というところにニーズがあることが判明。

Pivot
3人にインタビューしたこの時点で、早速「Issue」をピボット。
「6人中3人以上」というKPIを立てたが、すぐに「ダメだ」という「直感」が得られたならそれでいい。

リーンスタートアップでは、早く失敗して、
早く失敗から学習することが大事。
KPIは絶対じゃない。あくまで次に進むか
どうかを判断する判断材料のひとつ。
実験では「いける！／ダメそう」という
「直感」が得られればそれでいい。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5/14
キックオフ
5/16
Issueの設定
5/28
6/6
6/11
6/20
6/27
7/1
7/3
IssueのPivot
Solution Assumptiom
7/4
7/11
Service Prototyping
7/18
LP制作
7/25
8/1 Service Experiment
8/5

存在する「Issue」が分かったので、次は「Solution」の仮説を立てて、サービスの形に落とし込む。

ブレスト、ワークショップ形式でサービスの機能や仕様を考えていく。
素晴らしいアート体験ができた瞬間に、簡単に作品情報など様々なログを残せる「Zulog」というサービスを考案。

サービスの概要ができたら、MVP（Minimum Viable Product）を作って、そのSolutionの検証を行う。
今回は、 Striking.lyを使って、そのサービスが実在する想定でLPを制作し、MVPとした。

【検証方法】
新サービスとしてLPをソーシャルで拡散し、
サンキューページに設置したGAタグで効果計測

【検証ポイント】
コンバージョンレート、ダウンロード数

検証方法としては、LPに仕込んだ計測タグから、どのくらい反応があるかデータを取得することに。
しかし…

【検証方法】
新サービスとしてLPをソーシャルで拡散し、
サンキューページに設置したGAタグで効果計測

コンバージョンレート、ダウンロード数

断念。

・統計上有意な母数が集められなさそう
・偽LPなので、拡散すればするほどリスクも増える
・数値を取っても、明確なKPI設定が難しい

偽LPを使った手法は海外だと割とあるらしいが、日本だと炎上しそうという懸念や、数値を計測しても、どれくらいの
CVRやDL数があれば「サービスに価値がある」と判断できるのか分からなかったため。

「Solution」の価値仮説検証方法をピボットし、計測タグによる定量情報から、LPをサービスのMVPだと明示した上で、
アンケートによる定性情報で価値検証をすることに。

× ◎
結果的に、ユーザをだまさずに協力をあおげたので、アンケートも十分な母数が取れて、有意義な分析ができた。

リーンスタートアップでは、
どこをピボットすればいいか学べる
フレームが作られているかどうかが大事。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5/14
キックオフ
5/16
Issueの設定
5/28
6/6
6/11
6/20
6/27
7/1
7/3
IssueのPivot
7/4
7/11
7/18
LP制作
7/25
8/1
8/5 Service Validate

そのアンケート結果をもとに、Zulogが世の中に求められるサービスなのかどうかを判断。

【検証方法】
LPをMVPとしてアンケートを取る

KPI：アンケート回答数のうち、70％以上が
「ダウンロードする」を選ぶかどうか

見直した検証方法とKPIはこちら。

検証結果をもとに、
協力してもらえるパートナーに
提案を行うなど、サービスの
実現に向けて推進
サービスの価値を感じた
ポイントと、ダウンロード
しない理由のアンケート結果
からピボットのポイントを探る
アンケートの結果が良かった場合、良くなかった場合でそれぞれ次のアクションを定めておく。

91回答中64回答、70.3％が
「ダウンロードする」を選択
「ダウンロードする」はギリギリ70％以上となり、「サービスの価値はある」という実証結果に。

サービス内容の3つのポイントいずれも賛同者が多く、半数以上が「有料でもダウンロードする」と回答。
KPIとして設定した質問以外の項目でも好感触が得られた。

自分のアイデアを否定されるのは恐い。
それが本気で情熱を込めたものならなおさら。
でも、そうであればあるほど、
「早く形にして、テストして、失敗して、
正しい方向に向き直す」こと。
そうしなければいつまでも進まないし
無駄になるリスクが高い。

自分の感覚を疑い、ユーザの心の声に従え
否定を恐れず、修正回数を誇れ
サービスにこだわらず、ビジョンにこだわれ

バリデーションボードを使って新サービス開発をやってみた

More Related Content

Viewers also liked

Similar to バリデーションボードを使って新サービス開発をやってみた

バリデーションボードを使って新サービス開発をやってみた