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
560
自信を持ってピボットするために
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
520
Firebase.yebisu #2 - 料理ショートライブアプリ Cookin' の開発
morishin
0
4.9k
Cookpad iOS Release Flow
morishin
6
11k
みんなのReactiveX
morishin
0
450
Other Decks in Business
See All in Business
20251012_社内でのMCT活動
ponponmikankan
0
360
社内請負スクラムから脱却する〜複雑性に適応するスクラムチームの作り方〜
yasuhirokimesawa
1
140
ele&company_companydeck
eleand
0
480
株式会社10X - Company Deck
10xinc
89
1.6M
freeeを軸に変えていく記帳代行の概念
yuki_yano
PRO
0
120
スクラム再始動 〜場づくりで透明性を促進し、『形骸化』から脱出しよう!〜
nato
0
130
【早わかり】アライドアーキテクツ
alliedarchitectsir
0
110
15 分で学ぶ Cloud Run のユースケースと代表的なアーキテクチャパターン
googlecloudjapan
3
500
プラスディーアンドシー合同会社 FACTBOOK _ver1.51_20250801
plusdc
PRO
1
230
フルカイテン株式会社 採用資料
fullkaiten
0
75k
ワンキャリア 会社説明資料 / Company Deck
onecareer
7
240k
No Company - Company Deck 2025
nocompany
1
690
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
53
9k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
Practical Orchestrator
shlominoach
190
11k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
Why Our Code Smells
bkeepers
PRO
339
57k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Documentation Writing (for coders)
carmenintech
75
5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Building Applications with DynamoDB
mza
96
6.7k
How to train your dragon (web standard)
notwaldorf
96
6.3k
Unsuck your backbone
ammeep
671
58k
GitHub's CSS Performance
jonrohan
1032
470k
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 がつけばピボットする • リリース後やっと定量的評価ができる
まとめ • ピボットすべきか判断するのは難しい • 仮説を検証可能な問いの形にする (スプリントクエスチョン) • 問いをユーザーインタビューで確認できる形にする
ありがとうございました