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
機能追加時における 仮説検証/s-dev-talks-01
Search
AKAMATSU Yuki
May 16, 2018
0
930
機能追加時における 仮説検証/s-dev-talks-01
AKAMATSU Yuki
May 16, 2018
Tweet
Share
More Decks by AKAMATSU Yuki
See All by AKAMATSU Yuki
今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022
ukstudio
4
4.8k
Cookpad Tech Kitchen #24
ukstudio
0
700
Cookpad Summer Internship 2019 Day 1 Git
ukstudio
0
9.9k
Cookpad Summer Internship 2019 Day 1 Ruby TypeScript
ukstudio
0
9.8k
sdevtalks.org開発報告 / reporting that sdevtalks.org was launched
ukstudio
0
320
GraphQL on Rails
ukstudio
1
410
「なんでも」をしよう / 2018-12-19 s-dev talks LT
ukstudio
2
520
Rails Developers Meetup 2018 Extreme
ukstudio
0
3.2k
Rails Developers Meetup
ukstudio
6
3.4k
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Speed Design
sergeychernyshev
27
810
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
510
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Music & Morning Musume
bryan
46
6.4k
Into the Great Unknown - MozCon
thekraken
35
1.6k
Automating Front-end Workflow
addyosmani
1368
200k
Become a Pro
speakerdeck
PRO
26
5.2k
Side Projects
sachag
452
42k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Documentation Writing (for coders)
carmenintech
67
4.6k
Transcript
機能追加時における 仮説検証 クックパッド株式会社 新規サービス開発部 赤松 祐希 @ukstudio
自己紹介 • 赤松 祐希 / @ukstudio • クックパッドに3月入社 • エンジニア
• 前職では新規サービスの PdM兼エンジニア など
話すこと • 個人の経験をベースに機能開発・追加時に考えていることを共有します • 仮説検証一連の流れよりは、仮説の考え方みたいな話が中心です • 前提として数人のチームでサービス立ち上げ初期を想定しています • 入社タイミング的に具体例を発表しづらいのでなにかあれば懇親会で!
そもそも機能追加の仮説ってなんだ? • いざ考えてみると意外とむずかしい(そうでもない?) • 機能追加するときになにかしら推測していることがあるのでそれを仮説としたら どうか
ECの検索機能の例 “きっと検索機能を実装すれば、もっと簡単に欲しいものを見つけることができるはず だ” という仮説が思い浮かんだとする。 思い浮かぶためにどうするかという話は今日は省略。
隠れた前提が存在していない? • きっと検索機能を実装すれば、もっと簡単に欲しいものを見つけることができる はずだ • ↓ • 今は購入者は自身の欲しいものを一覧から探しているはずだ • 購入者は自身の欲しいものを探すのに苦労しているはずだ
個別にちょっと考えてみよう • 今は購入者は自身の欲しいものを一覧から探しているはずだ • 購入者は自身の欲しいものを探すのに苦労しているはずだ ◦ 実はGoogle検索やSNSからの流入が大半だったりしないか ? • きっと検索機能を実装すれば、もっと簡単に欲しいものを見つけることができる
はずだ ◦ 実際に一覧から探しているとして、 検索機能がベストなソリューションなのか ?
1つの機能が複数の仮説で成り立っている • 「検索機能で便利になる」という仮説が、別の仮説から成り立っている • これら複数の仮説をどう検証するのがいいのか考えてみる
リリースすることでまとめて検証できるか? • 個別に検証するのではなく、リリースすることでまとめて検証できないか? • リリースして検索機能が順調に使われているなら、仮説が証明されたと言えるのでは ないか?
リリースして使われなかった場合 • 使われなかったという事実から依存している全ての仮説を 証明もしくは否定できるか? • 前提の仮説検証が甘いと機能が悪かったのか機能のニーズがなかったのか曖 昧になりがち → 迷走しがち
使われなかったときのコスト • 機能が使われなかったときのコストも考えておきたい • エンジニア的には使われていない機能でコードが複雑化するのはつらい ◦ 実作業コスト的にも気持ち的にも • 一回出した機能を消すのって結構大変 ◦
使われていないと言っても全く誰も使っていないってことは意外とない ◦ 使っている人がいるのに消すのって少し心情的にハードルがある • この辺はある程度解消の余地があり、いきなり全公開しない、クローズにテスト を行うという方法もある
学習を積み重ねる • 小さい仮説検証を繰り返すことで、前に進みやすく、手戻りも減る • 「ユーザーがアイテムを探すのに苦労している」ところまでは検証済みだとする • その状態で検索機能をリリース → 使われない ◦
検索機能のUIや使い勝手が悪いんじゃないか ◦ リコメンドを強化した方がいいんじゃないか ◦ 商品の一覧性を改善した方がいいんじゃないか • 新しい仮説が思い浮かべば前に進める ◦ そしてその仮説で新しい学びを得る
検証はどうする? • トピックがでかすぎてなんともいえないが、あまり難しく考えすぎないこと • プロトタイプは定性的データで判断することが多い • 実際にリリースしたあとは両方を見る ◦ 事前にどういう数値がでたら、機能追加がうまくいったのか考えておく ◦
個人的には数値を見るのがあまり得意ではないので、使われているかどうかだけ気にする ◦ 定性的なデータ ▪ ユーザーテストしてみる、 SNSを検索、お問い合わせやフィードバック • チームがどういうデータを見れば納得するか ◦ データといっても定量的なものだけを指してないので注意
まとめ • 機能を作ったけど、学びがないのが一番つらい ◦ 今日の発表で一番言いたかったこと ◦ 失敗してもいいので、 次の仮説に結びつくようにしたい • 着実に前に進むためには、仮説を分解して1つずつ検証していくのが有効だと
考えています