機能追加時における 仮説検証/s-dev-talks-01

Transcript

1. 機能追加時における 仮説検証 クックパッド株式会社 新規サービス開発部 赤松 祐希 @ukstudio
2. 自己紹介 • 赤松 祐希 / @ukstudio • クックパッドに3月入社 • エンジニア • 前職では新規サービスの PdM兼エンジニア など
3. 話すこと • 個人の経験をベースに機能開発・追加時に考えていることを共有します • 仮説検証一連の流れよりは、仮説の考え方みたいな話が中心です • 前提として数人のチームでサービス立ち上げ初期を想定しています • 入社タイミング的に具体例を発表しづらいのでなにかあれば懇親会で!
4. そもそも機能追加の仮説ってなんだ? • いざ考えてみると意外とむずかしい(そうでもない?) • 機能追加するときになにかしら推測していることがあるのでそれを仮説としたら どうか
5. ECの検索機能の例 “きっと検索機能を実装すれば、もっと簡単に欲しいものを見つけることができるはず だ” という仮説が思い浮かんだとする。 思い浮かぶためにどうするかという話は今日は省略。
6. 隠れた前提が存在していない? • きっと検索機能を実装すれば、もっと簡単に欲しいものを見つけることができる はずだ • ↓ • 今は購入者は自身の欲しいものを一覧から探しているはずだ • 購入者は自身の欲しいものを探すのに苦労しているはずだ
7. 個別にちょっと考えてみよう • 今は購入者は自身の欲しいものを一覧から探しているはずだ • 購入者は自身の欲しいものを探すのに苦労しているはずだ ◦ 実はGoogle検索やSNSからの流入が大半だったりしないか ? • きっと検索機能を実装すれば、もっと簡単に欲しいものを見つけることができる はずだ ◦ 実際に一覧から探しているとして、 検索機能がベストなソリューションなのか ?
8. 1つの機能が複数の仮説で成り立っている • 「検索機能で便利になる」という仮説が、別の仮説から成り立っている • これら複数の仮説をどう検証するのがいいのか考えてみる
9. リリースすることでまとめて検証できるか? • 個別に検証するのではなく、リリースすることでまとめて検証できないか? • リリースして検索機能が順調に使われているなら、仮説が証明されたと言えるのでは ないか?
10. リリースして使われなかった場合 • 使われなかったという事実から依存している全ての仮説を 証明もしくは否定できるか? • 前提の仮説検証が甘いと機能が悪かったのか機能のニーズがなかったのか曖 昧になりがち → 迷走しがち
11. 使われなかったときのコスト • 機能が使われなかったときのコストも考えておきたい • エンジニア的には使われていない機能でコードが複雑化するのはつらい ◦ 実作業コスト的にも気持ち的にも • 一回出した機能を消すのって結構大変 ◦ 使われていないと言っても全く誰も使っていないってことは意外とない ◦ 使っている人がいるのに消すのって少し心情的にハードルがある • この辺はある程度解消の余地があり、いきなり全公開しない、クローズにテスト を行うという方法もある
12. 学習を積み重ねる • 小さい仮説検証を繰り返すことで、前に進みやすく、手戻りも減る • 「ユーザーがアイテムを探すのに苦労している」ところまでは検証済みだとする • その状態で検索機能をリリース → 使われない ◦ 検索機能のUIや使い勝手が悪いんじゃないか ◦ リコメンドを強化した方がいいんじゃないか ◦ 商品の一覧性を改善した方がいいんじゃないか • 新しい仮説が思い浮かべば前に進める ◦ そしてその仮説で新しい学びを得る
13. 検証はどうする? • トピックがでかすぎてなんともいえないが、あまり難しく考えすぎないこと • プロトタイプは定性的データで判断することが多い • 実際にリリースしたあとは両方を見る ◦ 事前にどういう数値がでたら、機能追加がうまくいったのか考えておく ◦ 個人的には数値を見るのがあまり得意ではないので、使われているかどうかだけ気にする ◦ 定性的なデータ ▪ ユーザーテストしてみる、 SNSを検索、お問い合わせやフィードバック • チームがどういうデータを見れば納得するか ◦ データといっても定量的なものだけを指してないので注意
14. まとめ • 機能を作ったけど、学びがないのが一番つらい ◦ 今日の発表で一番言いたかったこと ◦ 失敗してもいいので、 次の仮説に結びつくようにしたい • 着実に前に進むためには、仮説を分解して1つずつ検証していくのが有効だと 考えています