自信を持ってピボットするために

Transcript

1. 自信をもってピボットするために 森川 慎太郎 @morishin127 s-dev talks #4 2018/10/13

2. 自己紹介 • クックパッド, お料理アルバム, みんなのお弁当 (iOS・Rails) • Cookin’ (iOS・Firebase) •

   クックパッド MYキッチン (React Native) ৿઒
   ৻ଠ࿠
   ΫοΫύουגࣜձࣾ
   !NPSJTIJO
   !NPSJTIJO

3. 宣伝 買ってよかったもののまとめ ページを作れるサイト https://katteyokatta.morishin.me

4. 今日の話 • ピボットとは • 自信を持ってピボットするための工夫 • サービス開発の流れ • 仮説の設計 •

   検証の設計

5. ピボットとは

6. ピボットとは • 方向転換のこと • サービスの価値仮説検証の過程で、大きなコストを払う 前に、できるだけ早く仮説を棄却して別の仮説を立てる

7. ピボットとは - 例1 「レシピを投稿することを通して料理は楽しくなるはず」 という信念のもと 「もっと投稿に対するフィードバックがもらえる人が増えたら レシピ投稿者数が増えるのでは」 という方針から 「レシピのフォーマットをもっと手軽に書けるものに変えれば レシピ投稿者数が増えるのでは」

   という方針に変える

8. ピボットとは - 例2 「レシピのエディタをもっと手軽に書けるものに変えれば レシピ投稿者数が増えるのでは」 という信念のもと 「作り方や材料の分量入力時に補完が出れば投稿は手軽に感じられるのでは」 という方針から 「必須入力項目を減らせば投稿は手軽に感じられるのでは」 という方針に変える

9. ピボットするには 仮説を検証して、その仮説が合っていそうか間違っていそ うか判断する

10. 仮説の検証 • 成功 = 仮説が合ってた • 失敗 = 仮説が間違ってた

11. 仮説の検証 • 成功 = 仮説が合ってたか間違ってたかはっきりした • 失敗 = 仮説が合ってたか間違ってたかよくわからなかった わ


    か
 ら
 ん

12. 仮説の検証 - わからん例 • 最高の機能を作ったからユーザーインタビュー • ユーザーさん「へぇ〜なるほど〜これいいですね〜」 • 反応は悪くはなかったし、仮説は正しい？？？ わ


    か
 ら
 ん C ヒマだったら
 使いたいかも

13. 自信を持ってピボットするために • 仮説が合ってたか間違ってたかをはっきりさせるのは
 難しいのでがんばりが必要 • 今日は仮説の設計と検証をどうがんばるかの話

14. サービス開発の流れ

15. サービス開発の流れ ① 取り組む施策の内容を決めて作る • 価値仮説を立てる • 施策の内容を考える • プロトタイプを作る ②

    施策の筋が良いかを判断する • プロトタイプの定性的評価 • プロダクションリリース後の定量的評価

16. サービス開発の流れ ① 取り組む施策の内容を決めて作る ② 施策の筋が良いかを判断する ①→②→(ピボット or not)→①→②→(ピボット or not)→①→…

    ピボット or not ピボット or not

17. ピボットの判断を速く正しくするために

18. ピボットの判断を速く正しくするために • デザインスプリント • 検証しやすい仮説の設計 • 検証しやすいインタビュー質問設計

19. デザインスプリント • 5日間でアイデア出し→プロトタイプ制作→ユーザーテ ストをチームで行う手法

20. スプリントクエスチョン • デザインスプリントの中に出てくる概念 • 目標を達成するためにプロダクトが満たすべき条件、ま た失敗しうる要因を問いの形にしたもの • 仮説の検証、つまり作ったプロトタイプの評価はスプリ ントクエスチョンの YES/NO

    を判断することで行う

21. 評価しやすい仮説の設計 仮説→スプリントクエスチョンの形で持つ (例) 「自分の料理をレシピだけでなくもっと魅力的に表現で きる場があればレシピ投稿はもっと増えるはず」 という仮説があったとする

22. 評価しやすい仮説の設計 - 例 「自分の料理をレシピだけでなくもっと魅力的に表現できる場があればレシピ投稿はもっと増えるはず」 →スプリントクエスチョン ① レシピを投稿した後にさらに表現に手を加えようと思うか? ② 自分の料理の表現にこだわりを込めるか? ③

    自分の料理を魅力的に表現できているか? ④ 次に投稿したい料理の発想につながるか? ⑤ レシピを投稿するハードルが今より上がらないか?

23. 評価しやすい仮説の設計 - 例 仮説の検証 = プロダクトをユーザーに当てて評価し、①〜⑤のクエ スチョンに YES/NO を言う

24. プロダクト案の例 • 「レシピまとめ」 • レシピのコレクションを
 作って名前を付けられる

25. 仮説に YES/NO が言えるような質問の設計 • ユーザーインタビューによる定性的評価でクエスチョン を検証 • スプリントクエスチョン ➡ インタビュー質問

    • ユーザーに訊ける or ユーザーの行動から判断できる 形に変換する

26. ユーザーに訊ける or ユーザーの行動から判断できる形 • 口頭でそのまま訊ける質問文 or 観測できる行動 • オープンクエスチョン •

    ユーザーに考えさせてしまう質問は避ける • 未来でなく過去のことを訊く これ日常的に
 使いそうですか？ ❌

27. 質問 - 例 ① レシピを投稿した後にさらに表現に手を加えようと思うか? ➡レシピを投稿した後にレシピまとめ[を作成|に追加]した か ② 自分の料理の表現にこだわりを込めるか? ➡レシピまとめの名前はユニークだったか、レシピまとめ内

    のレシピ順序を変更したか、カバー画像を設定したか

28. 質問 - 例 ③ 自分の料理を魅力的に表現できているか? ➡レシピまとめの載ったMYキッチンページを見たときに驚きがあったか、 他人に見せたくなったか ④ 次に投稿したい料理の発想につながるか? ➡作ったレシピまとめに次に入れたい料理のアイデアを聞けたか、他に

    作りたいレシピまとめのアイデアが聞けたか ⑤ レシピを投稿するハードルが今より上がらないか? ➡レシピを投稿するまでの操作で詰まる場所が無かったか

29. 検証 • プロトタイプを5人程度のユーザーに触ってもらう • インタビューで質問を行い多くのスプリントクエスチョ ンに YES が言える結果になれば仮説は正しそう • ➡実際に作ってリリース

    • 重要なクエスチョンに NO がつけばピボットする • リリース後やっと定量的評価ができる

30. まとめ • ピボットすべきか判断するのは難しい • 仮説を検証可能な問いの形にする (スプリントクエスチョン) • 問いをユーザーインタビューで確認できる形にする

31. ありがとうございました