Service development lecture in 2019 cookpad summer internship

クックパッドの 2019 夏インターンでサービス開発の講義に用いた資料です。

Transcript

1. クックパッドのサービス開発 Cookpad Summer Internship 2019
2. 新井 康平 @SpicyCoffee66 　会員事業部 エンジニア (17 卒) SEO グループグループ長 2017年: レシピサービスのさがす体験改善, 新規事業バックエンド実装 2018年: 有料会員のさがす体験改善(PM), 検索バッチの大規模リファクタ 2019年: 検索バッチの大規模リファクタ, レシピサービス SEO 改善 自己紹介
3. 今日のゴール • クックパッドのサービス開発に対する考え方を知る • クックパッドのサービス開発プロセスを体験する • サービス開発の難しさや何が求められるのかを知る
4. はじめに いつでも・なんでも質問してください cf.) https://twitter.com/motcho_tw/status/870589211832795136 ࿩
 ͕
 ଎
 ͍
5. サービス開発とは？
6. インフラ サーバーサイド フロントエンド デザイン 「サービス開発」はどの領域についての話でしょうか？ いきなりですが質問です ユーザー
7. インフラ サーバーサイド フロントエンド デザイン 「サービス開発」はどの領域についての話でしょうか？ いきなりですが質問です ユーザー そもそもこういう話ではない
8. サービス開発 = ユーザーに価値を届けること 「そのための方法」について話します ユーザー サービス 課題を見つける 課題を解決する
9. サービス開発とは • ユーザーに価値を届けること • たとえば…… ‣ 困っていることを解決する ‣ 不便だけど仕方なく使っている仕組みの代わりを提供する ‣ 嬉しい・楽しいといった感情を強くする体験を提供する
10. またしても質問です 隣の人に誕生日プレゼントを あげるとしたら何をあげますか？
11. 身近なサービス開発の例 • 誕生日プレゼント選び ‣ プレゼントを渡して人に喜んでもらうのは難しい ‣ 友だちでも悩むし、家族ですら悩む ‣ これを知らない人相手にやるのがサービス開発
12. わからないなら本人に聞けばいい？ • 自分の欲しいものを言語化するのは難しい • ヘンリー・フォード
 「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっ と速い馬がほしい』と答えていただろう」
13. サービス開発は難しい
14. サービス開発の難しさ • ゴールがわからない ‣ ユーザーの持つ欲求は、本人も含めて誰にもわからない ‣ ユーザーの持つ欲求は、時間とともに変わっていく • 今いる場所がわからない ‣ 開発者は自分のサービスを正しく理解できていない • 失敗は前提
15. 不確実で失敗は前提
16. 不確実で失敗は前提 → 失敗を無駄にしない開発
17. 科学的にサービス開発
18. 科学的とは？ ʦܗಈʧ ̍ ߟ͑ํ΍ߦಈͷ͔͕ͨ͠ɺ࿦ཧతɺ࣮ূతͰɺܥ౷ཱ͍ͬͯΔ͞·ɻ ̎ ಛʹࣗવՊֶͷํ๏ʹ߹͍ͬͯΔ͞·ɻʮՊֶతͳ஌ࣝʹ๡͍͠ʯ σδλϧେࣙઘ
19. 科学的とは？ ʦܗಈʧ ̍ ߟ͑ํ΍ߦಈͷ͔͕ͨ͠ɺ࿦ཧతɺ࣮ূతͰɺܥ౷ཱ͍ͬͯΔ͞·ɻ ̎ ಛʹࣗવՊֶͷํ๏ʹ߹͍ͬͯΔ͞·ɻʮՊֶతͳ஌ࣝʹ๡͍͠ʯ σδλϧେࣙઘ
20. 科学的なサービス開発 • 成功する確率が比較的高い • 失敗の原因が特定できる • 成否関係なく結果から情報を得られる • 特定個人の発想・センスに強く依存しない
21. よくある失敗 すごそうな企画 開発 降りてきた これは当たる つくります！ 祝！リリース！
22. よくある失敗 ごめんて 今まで一体何を…… 利用者が無 すごそうだった企画 （別プロジェクトへ） 開発
23. まとめると
24. サービス開発の考え方まとめ • サービス開発はものすごく難しい • 失敗からいかに学びを得るかが重要 • そのために科学的なプロセスを意識する必要がある
25. 実際どうやるの？
26. サービス開発の手法はいろいろある 業界が異なれば、手法も異なる cf.) http://www.happystream.net/products_consulting/difference/
27. サービス開発の手法はいろいろある 社内でも様々な方法がある
28. 今日の講義では…… • リーン・スタートアップをベースに話します • 初期投資コストが低いネット業界と相性がよく
 共通言語になっている • 社内メンバーの支持が高い（と思う） ‣ 17 卒の課題図書だった
29. ざっっっくり言うと 考えて (仮説) 確かめる (検証) これをていねいに、高速に繰り返す
30. 「考えて・確かめる」を高速に スパンの長い開発 スパンの短い開発 一旦正解を決めて突き進む 正解を模索しながら進む
31. BML ループ
32. BML ループ • 最大のムダは誰も欲しがらないモノを作ること ‣ このサービスは作れるか？ではなく、作るべきか？を問う Ͳ͏΍ͬͯ
 ࣮ݱ͢Δ͔ ϦʔϯελʔτΞοϓ कඋൣғ Ͳ͏΍ͬͯ
 ։ൃαΠΫϧΛ ճ͔͢ Ϧιʔεͷ
 ࢖͍ํ(഑෼) ࢿۚɾϦιʔε ௐୡͷ࢓ํ ΞΠσΟΞͷख ʹೖΕํ
33. （Build の手前の）idea = 仮説
34. （Build の手前の）idea = 仮説 • 仮説を立てるにはユーザーを深く理解することが必要 • 理解のポイントは２つ やりたい 欲求 できない 課題
35. ユーザー理解の手法 • 手法はいろいろ ‣ ユーザーインタビュー → 後で fjkn が講義してくれます ‣ アンケート ‣ ドッグフーディング ‣ ログ分析 ʜ
36. ペルソナ作成 • 共通点をペルソナにする • ユーザーは百人十色 ‣ ただし、似た属性・志向を持つ
 ユーザーの行動パターンは
 数個に収束する • その行動パターンを言語化し
 ペルソナにする ‣ チーム内でユーザー像の認識を揃える
37. 仮説の定義 • 対象となるペルソナの抱えている課題を発見 ‣ 解決すべき課題はなにか？ ‣ どうやって解決するか？ ‣ 解決によって得られるものは？ ‣ 解決にかかるコストは？ ‣ 代替手段を使ってでも解決しようとしている？
38. Build
39. Build • 課題の解決策を具体化する ‣ まずはユーザーのストーリーを考える ‣ ストーリーを実現する解決策の案を出す ‣ 仮説と解決策をまとめて言語化する ‣ それを最小コストで実現する
40. Build • 課題の解決策を具体化する ‣ まずはユーザーのストーリーを考える ‣ ストーリーを実現する解決策の案を出す ‣ 仮説と解決策をまとめて言語化する ‣ それを最小コストで実現する
41. ユーザーのストーリーを考える • 解決策を点で考えないことが重要 ‣ いきなり機能を考えようとしない ‣ まずは課題を抱えてから解決するまでの流れを線で考える
 （ストーリーを描く→ユーザーストーリー）
42. ユーザーストーリー • 開発者目線で書くべからず • ユーザーの物語視点で書くべし • 機能名や UI 名を書くべからず
43. フリマアプリのストーリー例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした
44. • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保留にしおく • 一週間後、値下げ情報が Push 通知で届いた • 他の人に狙われないうちに、急いで購入手続きをした たとえば 機能名を書くとそこで思考停止する → Push 通知以外の選択肢が頭から消える
45. アプリでの行動例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした ブランド名で検索 商品詳細の確認 いいね Push 通知受信 購入申請
46. フリーマーケットでの行動例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした 会場で探す 手に取って確認 記憶・メモ フリマに再訪 声掛け
47. ポイント • ユーザー視点で記述することで、
 既存の代替手段と比較が可能になる • あえて画面外の行動も書く • そのままユーザーテストでやってもらうことの
 リストとすることもできる
48. Build • 課題の解決策を具体化する ‣ まずはユーザーのストーリーを考える ‣ ストーリーを実現する解決策の案を出す ‣ 仮説と解決策をまとめて言語化する ‣ それを最小コストで実現する
49. 解決策の案を出す インプット アウトプット 案の決定
50. 解決策の案を出す 既存のアイディアを組み合わせる インプット アウトプット 案の決定 無理矢理にでも広げる イメージしやすいように具体化する
51. 光速デモ 解決策の案を出す 既存のアイディアを組み合わせる インプット アウトプット 案の決定 無理矢理にでも広げる イメージしやすいように具体化する Crazy8s ソリューションスケッチ
52. 光速デモ 既存サービスの使えそうな点（ビッグアイディア）を共有する
53. 光速デモ
54. サービスじゃなくても使えそうなアイディアなら OK 光速デモ
55. 時間を区切ってアイディアやバリエーションを出しまくる Crazy8s
56. 解決策を 3 コマ程度のスケッチで表現する ソリューションスケッチ
57. ソリューションスケッチ
58. 注意点 • 各フェーズできちんと制限時間を設ける ‣ ダラダラ考えてもいいアイディアはでない ‣ 原則この時点では「何もわかっていない」 ‣ 議論が空中戦になりやすい
59. Build • 課題の解決策を具体化する ‣ まずはユーザーのストーリーを考える ‣ ストーリーを実現する解決策の案を出す ‣ 仮説と解決策をまとめて言語化する ‣ それを最小コストで実現する
60. 仮説と解決策の言語化 1. 利用者: そのサービスは誰が使う？ 2. 価値: そのサービスを使うと何がうれしいの？ 3. 体験: その価値はどんな体験から得られる？ 4. 機能: その体験がどんな機能があれば実現できる？ 抑えるべきポイント
61. フレームワーク 世間にある手法 クックパッド独自 シナリオ ジャーニーマップ ストーリーボード 価値仮説シート EOGS ステートメントシート ʜ
62. 価値仮説シート
63. EOGS
64. リーンキャンバス
65. Build • 課題の解決策を具体化する ‣ まずはユーザーのストーリーを考える ‣ ストーリーを実現する解決策の案を出す ‣ 仮説と解決策をまとめて言語化する ‣ それを最小コストで実現する
66. 最小コストで実現する • 課題解決策のアイディアを具体化 • 可能な限り小さな実装で仮説を検証する = MVP ‣ Minimum Viable Product ‣ 検証を行える可能な限り小さいもの ‣ 「実装しない」のが最も小さい
68. MVP • 目的は「最短で仮説が検証できるものをつくる」こと • 方法はいろいろ ‣ ペーパープロトタイピング ‣ プロトタイプツールの利用（Figma/Flinto/Prott/InVision/…） ‣ デモ環境での実装 ‣ 本番環境での実装 • 目的に合わせて最小コストのものを選択する
69. Measure
70. Measure • つくって終わりじゃ意味がない • 出てきた結果から仮説の
 答え合わせをして次に活かすのが何よりも大事 ‣ 仮説は正しかったのか？間違っていたのか？ ‣ どこが正しかったのか？どこが間違っていたのか？ ‣ このまま進んでいいのか？方向転換が必要か？
71. 検証方法 • 大雑把に分けると定性と定量 • 定性データ ‣ ユーザーインタビューのログ ‣ アンケートの自由記述欄 • 定量データ ‣ PV, UU, CV, リテンションなど ‣ ログを元にした数値情報
72. 定性 vs 定量 • 前提としてどちらの視点も必須 • それぞれに得意不得意があるので、
 施策内容やサービスのフェーズ等で重み付けを変える
73. 定性評価 • 代表的なのはユーザーテスト
74. 定性評価 • ユーザーの体験やその理由を直接確認できるので、
 行動の裏付けとなる情報が得られる • 一方で、情報の正確性には注意が必要 ‣ テスト対象が特殊な属性だったら？ ‣ ユーザーが無自覚に普段の行動と違う話をしていたら？
75. 定量評価 • 代表的なのは AB テスト
76. 定量評価 • 正確な情報を得ることができる ‣ 前提や検証の状況を疑うことは必要 • 一方で、行動の理由はわからないため
 ユーザー体験を裏付ける情報は得られない ‣ 施策の数字 良かった/悪かった のはなぜ？
 ↑ この問いが仮説の域から出ることはない
77. 定性 vs 定量 定性評価 定量評価 • 行動の裏付けが得られる • どうあがいても主観が入る • サンプルが偏る可能性が高い • 明確な結果は出てきづらい • 検証期間自体は短い • 行動の裏付けは得られない • 主観が入りづらい • サンプルの偏りを減らせる • 明確な結果が出しやすい • それなりの検証期間が必要
78. 定性評価が向いてる 定量評価が向いてる • サンプル数が少ない • 検証したい体験が複雑 • コンセプトを詰めていきたい • サンプル数が十分に取れる • 検証したい体験がシンプル • コンセプトが成熟している 定性と定量の使い分け サンプル数の判断は難しい 簡単にやるなら https://www.optimizely.com/sample-size-calculator/ などのサイトが使える FYI: https://techlife.cookpad.com/entry/2016/09/26/111601
79. Build との関係性 • 実際にはつくるものと検証方法はセットで決める ‣ ユーザーテストをするならプロトでいい ‣ AB テストをするなら実装が必要
80. Learn
81. Learn • しらべて終わりじゃ意味がない • 出てきた結果から仮説の答え合わせをして
 次に活かすのが何よりも大事（再掲） ‣ はかっただけじゃ答え合わせができていない • 学んだ結果を次の仮説のタネにする • 組織内に共有できるのがベスト
82. “学び” とは？
83. “学び” とは？
84. “学び” とは？ こっちは施策打てばわかる （やるだけ）
85. “学び” とは？ 気をつけるのはこっち 事前にサービスに対する現状の理解を固めておかないと 得られる学びの量が減る
86. “学び” を得るために • しっかりと仮説を立てて言語化しておく • 指標の解釈を整理しておく ‣ この数値が 高い/低い のは何を意味する？その時どうする？ • 結果の数値やユーザーの反応を想定しておく ‣ 測定指標がどのくらいになったらどうする？ ‣ 想定と違った反応を見せたのはなぜ？ ‣ 「なんとなく Go」を避ける • 成功のイメージを共有する
87. 要するに
88. 仮説を立てた段階でサイクル全体を設計しておく ԿΛͭͬͯ͘ Ͳ͏ݕূͯ͠ Ͳ͏ղऍ͢Δͷ͔
89. 施策実施前の整理一例
90. 情報共有について • 知見は放っておくと腐って死ぬ • 知見共有されない問題 ‣ どこにプールされているか判然としない ‣ 知見が属人的になる ‣ ならまだいい方で時がたって本人もはっきり覚えていない感じになる ‣ 最悪だと組織改編や転職で闇に消える
91. 情報共有について • 知見は放っておくと腐って死ぬ • 間違った知見共有される問題 ‣ 結果の数字の読み取り方がおかしい ‣ そもそも KPI の設定がおかしい ‣ 検証の期間が短すぎて正確性に欠ける ‣ といったようなことに気づかず正しい知見として共有される
92. 社内独自の取り組み • Report.md ‣ 施策に関する仮説や結果等を Markdown 形式でまとめる ‣ 運用を Pull Request 形式で行うのがポイント ‣ チームのレポジトリにレビューの通った知見が貯まっていく
93. Report.md 1. 施策の分析レポートを Markdown で作成し、PR を出す
94. Report.md 2. チームメンバーを中心にレポートをレビュー
95. Report.md 3. レビューが通ったら merge してレポートをプール
96. 何を書くのか？ プロジェクトのフェーズや施策の性質によって変わるが 「仮説」「仮説背景」「検証方法」「結果の想定」「検証結果」　　　 「考察・ギャップ分析」「Next Action」 くらいを抑えておくとよい cf.) https://techlife.cookpad.com/entry/2018/12/07/121515
97. Report.md 一例
98. 実際の使われ方 • https://reports.g.cookpad.com があったり • 自分がやった昔の施策を他の人に共有しやすい
99. まとめると
100. サービス開発のフローまとめ • 「考えて・確かめる」を丁寧かつ高速に繰り返す ‣ Build: 仮説からつくるものを決める, 最小の実装ですませる ‣ Measure: 定性と定量の両視点を持つ, 検証方法も吟味する ‣ Learn: 事前の想定が重要, 組織内に情報を共有する • 要所要所で社内外のフレームワークを利用
101. 今日の内容は現場でも常に全て実践されている？ • No ‣ 「ペルソナを作らないと先に進めない」みたいなことはない • プロジェクトの状況とメンバー次第 ‣ 「時間を何に使うか」の見極めは重要 • 今日の内容はベースとなるフロー ‣ 守破離の「守」 ‣ 迷ったらここに立ち返る
102. Q&A