Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
自信を持ってピボットするために
Search
Shintaro Morikawa
October 17, 2018
Business
1
520
自信を持ってピボットするために
Shintaro Morikawa
October 17, 2018
Tweet
Share
More Decks by Shintaro Morikawa
See All by Shintaro Morikawa
s-dev talks 2019/03/26 Why and How does a hobby developer monetize one's app
morishin
1
470
Firebase.yebisu #2 - 料理ショートライブアプリ Cookin' の開発
morishin
0
4.8k
Cookpad iOS Release Flow
morishin
6
10k
みんなのReactiveX
morishin
0
370
Other Decks in Business
See All in Business
株式会社Another works 採用資料
anotherworks
2
7.2k
株式会社グラファー会社紹介資料(プロダクト開発編)
graffer
0
110
これまでに存在しない業務フローは どう作っていくか?ドメインエキスパートやビジネスサイド、 チーム一丸となって取り組むドメインモデリング
iwamatsu0430
6
1.1k
Nstock 採用資料 / We are hiring
nstock
23
200k
GLP ALFALINK 茨木 まちびらきイベント2024
glp_jp
0
940
AI検索エンジンとは?おすすめの8個のAI検索ツールと活用ガイド(特徴・メリット・デメリット・仕組みを徹底解説!)(スライド版)
itarutomy
0
110
アジャイル何も知らん人事がアジャイル大好きお兄さんの引き出しを使い倒したら「変化に立ち向かえるチーム」に成長できた件
pokotyamu
1
800
NOT A HOTEL SOFTWARE DECK
notahotel
6
62k
XENDOU会社概要(テスト用)
regaliz
0
190
ホットリンク会社紹介スライド / We are hiring
hottolink_pr
1
2.9k
新卒エンジニア向け会社紹介資料/newgraduates-engineer
nextbeat
2
1.5k
株式会社ispec 会社紹介資料
emikamihara
0
5.3k
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
27
7.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
43
2k
No one is an island. Learnings from fostering a developers community.
thoeni
18
2.9k
[RailsConf 2023] Rails as a piece of cake
palkan
46
4.6k
Agile that works and the tools we love
rasmusluckow
327
20k
Building Applications with DynamoDB
mza
89
6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
28
1.6k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Faster Mobile Websites
deanohume
304
30k
BBQ
matthewcrist
83
9.1k
Code Reviewing Like a Champion
maltzj
518
39k
Embracing the Ebb and Flow
colly
83
4.4k
Transcript
自信をもってピボットするために 森川 慎太郎 @morishin127 s-dev talks #4 2018/10/13
自己紹介 • クックパッド, お料理アルバム, みんなのお弁当 (iOS・Rails) • Cookin’ (iOS・Firebase) •
クックパッド MYキッチン (React Native) ৻ଠ ΫοΫύουגࣜձࣾ !NPSJTIJO !NPSJTIJO
宣伝 買ってよかったもののまとめ ページを作れるサイト https://katteyokatta.morishin.me
今日の話 • ピボットとは • 自信を持ってピボットするための工夫 • サービス開発の流れ • 仮説の設計 •
検証の設計
ピボットとは
ピボットとは • 方向転換のこと • サービスの価値仮説検証の過程で、大きなコストを払う 前に、できるだけ早く仮説を棄却して別の仮説を立てる
ピボットとは - 例1 「レシピを投稿することを通して料理は楽しくなるはず」 という信念のもと 「もっと投稿に対するフィードバックがもらえる人が増えたら レシピ投稿者数が増えるのでは」 という方針から 「レシピのフォーマットをもっと手軽に書けるものに変えれば レシピ投稿者数が増えるのでは」
という方針に変える
ピボットとは - 例2 「レシピのエディタをもっと手軽に書けるものに変えれば レシピ投稿者数が増えるのでは」 という信念のもと 「作り方や材料の分量入力時に補完が出れば投稿は手軽に感じられるのでは」 という方針から 「必須入力項目を減らせば投稿は手軽に感じられるのでは」 という方針に変える
ピボットするには 仮説を検証して、その仮説が合っていそうか間違っていそ うか判断する
仮説の検証 • 成功 = 仮説が合ってた • 失敗 = 仮説が間違ってた
仮説の検証 • 成功 = 仮説が合ってたか間違ってたかはっきりした • 失敗 = 仮説が合ってたか間違ってたかよくわからなかった わ
か ら ん
仮説の検証 - わからん例 • 最高の機能を作ったからユーザーインタビュー • ユーザーさん「へぇ〜なるほど〜これいいですね〜」 • 反応は悪くはなかったし、仮説は正しい??? わ
か ら ん C ヒマだったら 使いたいかも
自信を持ってピボットするために • 仮説が合ってたか間違ってたかをはっきりさせるのは 難しいのでがんばりが必要 • 今日は仮説の設計と検証をどうがんばるかの話
サービス開発の流れ
サービス開発の流れ ① 取り組む施策の内容を決めて作る • 価値仮説を立てる • 施策の内容を考える • プロトタイプを作る ②
施策の筋が良いかを判断する • プロトタイプの定性的評価 • プロダクションリリース後の定量的評価
サービス開発の流れ ① 取り組む施策の内容を決めて作る ② 施策の筋が良いかを判断する ①→②→(ピボット or not)→①→②→(ピボット or not)→①→…
ピボット or not ピボット or not
ピボットの判断を速く正しくするために
ピボットの判断を速く正しくするために • デザインスプリント • 検証しやすい仮説の設計 • 検証しやすいインタビュー質問設計
デザインスプリント • 5日間でアイデア出し→プロトタイプ制作→ユーザーテ ストをチームで行う手法
スプリントクエスチョン • デザインスプリントの中に出てくる概念 • 目標を達成するためにプロダクトが満たすべき条件、ま た失敗しうる要因を問いの形にしたもの • 仮説の検証、つまり作ったプロトタイプの評価はスプリ ントクエスチョンの YES/NO
を判断することで行う
評価しやすい仮説の設計 仮説→スプリントクエスチョンの形で持つ (例) 「自分の料理をレシピだけでなくもっと魅力的に表現で きる場があればレシピ投稿はもっと増えるはず」 という仮説があったとする
評価しやすい仮説の設計 - 例 「自分の料理をレシピだけでなくもっと魅力的に表現できる場があればレシピ投稿はもっと増えるはず」 →スプリントクエスチョン ① レシピを投稿した後にさらに表現に手を加えようと思うか? ② 自分の料理の表現にこだわりを込めるか? ③
自分の料理を魅力的に表現できているか? ④ 次に投稿したい料理の発想につながるか? ⑤ レシピを投稿するハードルが今より上がらないか?
評価しやすい仮説の設計 - 例 仮説の検証 = プロダクトをユーザーに当てて評価し、①〜⑤のクエ スチョンに YES/NO を言う
プロダクト案の例 • 「レシピまとめ」 • レシピのコレクションを 作って名前を付けられる
仮説に YES/NO が言えるような質問の設計 • ユーザーインタビューによる定性的評価でクエスチョン を検証 • スプリントクエスチョン ➡ インタビュー質問
• ユーザーに訊ける or ユーザーの行動から判断できる 形に変換する
ユーザーに訊ける or ユーザーの行動から判断できる形 • 口頭でそのまま訊ける質問文 or 観測できる行動 • オープンクエスチョン •
ユーザーに考えさせてしまう質問は避ける • 未来でなく過去のことを訊く これ日常的に 使いそうですか? ❌
質問 - 例 ① レシピを投稿した後にさらに表現に手を加えようと思うか? ➡レシピを投稿した後にレシピまとめ[を作成|に追加]した か ② 自分の料理の表現にこだわりを込めるか? ➡レシピまとめの名前はユニークだったか、レシピまとめ内
のレシピ順序を変更したか、カバー画像を設定したか
質問 - 例 ③ 自分の料理を魅力的に表現できているか? ➡レシピまとめの載ったMYキッチンページを見たときに驚きがあったか、 他人に見せたくなったか ④ 次に投稿したい料理の発想につながるか? ➡作ったレシピまとめに次に入れたい料理のアイデアを聞けたか、他に
作りたいレシピまとめのアイデアが聞けたか ⑤ レシピを投稿するハードルが今より上がらないか? ➡レシピを投稿するまでの操作で詰まる場所が無かったか
検証 • プロトタイプを5人程度のユーザーに触ってもらう • インタビューで質問を行い多くのスプリントクエスチョ ンに YES が言える結果になれば仮説は正しそう • ➡実際に作ってリリース
• 重要なクエスチョンに NO がつけばピボットする • リリース後やっと定量的評価ができる
まとめ • ピボットすべきか判断するのは難しい • 仮説を検証可能な問いの形にする (スプリントクエスチョン) • 問いをユーザーインタビューで確認できる形にする
ありがとうございました