1. New
Service
Development
By Validation Board

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

3. Issue
「誰が」「どんな問題を」持っているか
ユーザインタビューなどでIssueが
存在するかを実験・検証
Solution
Issueに対してのSolutionを考える
PitchなどでSolutionが魅力的か、
成立するかを実験・検証
Service
人力などでSolutionのMVPを作る
プロトタイプでServiceの価値を
実験・検証
「Issue」「Solution」「Service」の3ステップそれぞれで、仮説-実験-検証のサイクルを回していく。

4. 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週間程度で十分ここまでできるはず。

5. 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仮説の設定
Solution Assumptiom
7/11
LP仕様・アプリ名の検討
7/18
LP制作
Service Prototyping
7/25
LPブラッシュアップ
8/1 Service Experiment
Solution価値仮説検証方法のPivot
8/5 Service Validate
Solution価値仮説の検証結果
「Issue」「Solution」「Service」の3ステップを当てはめるとこんな感じ。

6. 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仮説の設定
7/11
LP仕様・アプリ名の検討
7/18
LP制作
7/25
LPブラッシュアップ
8/1
Solution価値仮説検証方法のPivot
8/5
Solution価値仮説の検証結果
まずは「Issue」の仮説-実験-検証。

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

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

9. 【
Who?
】
『休日に展覧会を見に行く、都会に住む社会人』
【 Problem 】
『作品の背景・意図をもっと深く知りたい』
その結果、最初に決めた「Issue」はこれ。

10. 【 Assumption 】
『気になった作品に解説が付いていない』
そして「Assumption」、最もIssueのコアになると思った実験仮説がこれ。
こういう体験があると分かれば、「Issue」が正しいと検証できるのではないか？ということ。

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

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

13. ===================================
インタビューガイドライン
===================================
■1.イントロ(3分)
---------------------------------------------------◎1.挨拶
・自己紹介&インタビュー目的
◎2.撮影許可
・発言を収録することの説明
・利用目的の説明
---------------------------------------------------■2.事前インタビュー（5～10分）
---------------------------------------------------◎1.個人属性
・仕事
・家族構成
・趣味
・ライフスタイル（一人暮らしなど）
---------------------------------------------------------■3.インタビュー（30分）
---------------------------------------------------------◎1.美術館での体験について
・直近で美術館に行った時の話
・今までで一番良かった美術館の体験
◎2.実証したい内容について
・美術館で気になったについて調べる時はありますか？
・どうやって調べますか？直近の話を聞かせて下さい。
・美術館で解説を読む機会はあるか？
※直近のストーリーも聞く
・気になった作品に解説が付いていない時は？
・音声ガイドは利用しますか？
※直近のストーリーも聞く
-------------------------------------------------------■4.事後インタビュー（5～10分）
-------------------------------------------------------・美術館の解説（キャプション/音声解説）について
率直な感想を聞かせて下さい。
・美術館の解説（キャプション/音声解説）に1～7
で評価するとしたらどれぐらい？
また、その理由は？
・満足していない場合、この評価を上げる場合、
何か1つ改善するとしたら、
何を改善すべきだと思いますか？
軸となる質問項目はもらさないようにインタビューガイドラインにまとめるが、気になったところは都度対話しながら掘
り下げていく。撮影・録音などログを取っておき、すぐに振り返るのも大切なポイント。

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

15. インタビュー結果

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

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

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

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

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

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

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

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

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

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

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

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

28. 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
Solution仮説の設定
7/11
LP仕様・アプリ名の検討
Service Prototyping
7/18
LP制作
7/25
LPブラッシュアップ
8/1 Service Experiment
Solution価値仮説検証方法のPivot
8/5
Solution価値仮説の検証結果
存在する「Issue」が分かったので、次は「Solution」の仮説を立てて、サービスの形に落とし込む。

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

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

31. 【 検証方法 】
新サービスとしてLPをソーシャルで拡散し、
サンキューページに設置したGAタグで効果計測
【 検証ポイント 】
コンバージョンレート、ダウンロード数
検証方法としては、LPに仕込んだ計測タグから、どのくらい反応があるかデータを取得することに。
しかし…

32. 【 検証方法 】
新サービスとしてLPをソーシャルで拡散し、
サンキューページに設置したGAタグで効果計測
【 検証ポイント 】
コンバージョンレート、ダウンロード数
断念。

33. ・統計上有意な母数が集められなさそう
・偽LPなので、拡散すればするほどリスクも増える
・数値を取っても、明確なKPI設定が難しい
偽LPを使った手法は海外だと割とあるらしいが、日本だと炎上しそうという懸念や、数値を計測しても、どれくらいの
CVRやDL数があれば「サービスに価値がある」と判断できるのか分からなかったため。

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

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

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

37. 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
Solution仮説の設定
7/11
LP仕様・アプリ名の検討
7/18
LP制作
7/25
LPブラッシュアップ
8/1
Solution価値仮説検証方法のPivot
8/5 Service Validate
Solution価値仮説の検証結果
そのアンケート結果をもとに、Zulogが世の中に求められるサービスなのかどうかを判断。

38. 【 検証方法 】
LPをMVPとしてアンケートを取る
【 検証ポイント 】
KPI：アンケート回答数のうち、70％以上が
「ダウンロードする」を選ぶかどうか
見直した検証方法とKPIはこちら。

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

40. 果たして結果は

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

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

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

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