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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Shintaro Morikawa
October 17, 2018
Business
600
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
自信を持ってピボットするために
Shintaro Morikawa
October 17, 2018
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
550
Firebase.yebisu #2 - 料理ショートライブアプリ Cookin' の開発
morishin
0
5.1k
Cookpad iOS Release Flow
morishin
6
11k
みんなのReactiveX
morishin
0
480
Other Decks in Business
See All in Business
AWS Summit Taipei 2026: Decomposing Ontology and Agentic AI - Using Amazon Bedrock to Bring Living Water to Manufacturing ERP
dwchiang
0
470
堅牢でスケーラブルな働き方を構築する技術
ikuodanaka
3
1.3k
ときめかないミーティングはアップデートのシグナル #scrumosaka
asumikam
5
1.6k
01_全社_FLUX採用ピッチ資料_Ver.5.5
flux
11
220k
【Aby3】新卒エンジニア職 採用ピッチ資料
aby3recruitment
0
260
「人を育てる」ことは「待ちこがれる」ことである
kawanotron
0
290
malna-recruiting-pitch
malna
0
24k
プレイド概要説明資料_2026/08
plaid
PRO
1
2.4k
ログラス会社紹介資料 / Loglass Company Deck
loglass2019
19
570k
SalesforceとTableauコミュニティを横断して感じたこと(Osaka Dreamin)
leafyoh
0
150
AI時代のリスク管理は どうあるべきか考えてみる
0air
0
410
株式会社SAFELY 会社紹介 / Company
safely_pr
1
8k
Featured
See All Featured
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.8k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
490
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
480
Building the Perfect Custom Keyboard
takai
2
840
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
230
The Pragmatic Product Professional
lauravandoore
37
7.4k
Producing Creativity
orderedlist
PRO
348
40k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
420
Site-Speed That Sticks
csswizardry
13
1.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.8k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
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 がつけばピボットする • リリース後やっと定量的評価ができる
まとめ • ピボットすべきか判断するのは難しい • 仮説を検証可能な問いの形にする (スプリントクエスチョン) • 問いをユーザーインタビューで確認できる形にする
ありがとうございました