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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Shintaro Morikawa
October 17, 2018
Business
1
570
自信を持ってピボットするために
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
530
Firebase.yebisu #2 - 料理ショートライブアプリ Cookin' の開発
morishin
0
5k
Cookpad iOS Release Flow
morishin
6
11k
みんなのReactiveX
morishin
0
460
Other Decks in Business
See All in Business
2026年3月7日(土)放射性金属がやってくるか 廃炉原発等のクリアランスについて
atsukomasano2026
0
290
ARI会社説明
arisaiyou
1
22k
VISASQ: ABOUT DEV TEAM
eikohashiba
6
41k
LW_brochure_engineer
lincwellhr
0
40k
2025 サステナビリティレポート
mpower_partners
PRO
1
120
202601〜【合同会社プレップ湘南】COMPANY DECK
prepp
0
210
BLUEPRINTエンジニア採用_候補者向け会社説明資料
hik
0
190
税理士法人チェスター_事務所紹介資料
mabhr
0
1.1k
採用ピッチ資料
s_kamada
0
430
急成長プロダクトを支える「組織の検査と適応」—— SmartHR 労務ドメイン Scrum@Scale 導入半年間のリアルと展望
wadak8sk
1
370
(15枚)NotebookLMのスライド生成機能で「絶対達成」「予材管理」「大量行動」の重要性を解説してもらう
nyattx
PRO
0
190
-生きる-AI時代におけるライターの生存戦略
mimuhayashi
0
240
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
55
9.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
9.9k
Building AI with AI
inesmontani
PRO
1
720
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3.3k
Context Engineering - Making Every Token Count
addyosmani
9
670
エンジニアに許された特別な時間の終わり
watany
106
230k
The Invisible Side of Design
smashingmag
302
51k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Visualization
eitanlees
150
17k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
140
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.3k
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 がつけばピボットする • リリース後やっと定量的評価ができる
まとめ • ピボットすべきか判断するのは難しい • 仮説を検証可能な問いの形にする (スプリントクエスチョン) • 問いをユーザーインタビューで確認できる形にする
ありがとうございました