Service development lecture in 2019 cookpad summer internship

by Kohei Arai

Slide 1

Slide 1 text

クックパッドのサービス開発 Cookpad Summer Internship 2019

Slide 2

Slide 2 text

新井康平 @SpicyCoﬀee66 　会員事業部エンジニア (17 卒) SEO グループグループ長 2017年: レシピサービスのさがす体験改善, 新規事業バックエンド実装 2018年: 有料会員のさがす体験改善(PM), 検索バッチの大規模リファクタ 2019年: 検索バッチの大規模リファクタ, レシピサービス SEO 改善自己紹介

Slide 3

Slide 3 text

今日のゴール • クックパッドのサービス開発に対する考え方を知る • クックパッドのサービス開発プロセスを体験する • サービス開発の難しさや何が求められるのかを知る

Slide 4

Slide 4 text

はじめにいつでも・なんでも質問してください cf.) https://twitter.com/motcho_tw/status/870589211832795136 ࿩  ͕  ଎  ͍

Slide 5

Slide 5 text

サービス開発とは？

Slide 6

Slide 6 text

インフラサーバーサイドフロントエンドデザイン「サービス開発」はどの領域についての話でしょうか？いきなりですが質問ですユーザー

Slide 7

Slide 7 text

インフラサーバーサイドフロントエンドデザイン「サービス開発」はどの領域についての話でしょうか？いきなりですが質問ですユーザーそもそもこういう話ではない

Slide 8

Slide 8 text

サービス開発 = ユーザーに価値を届けること「そのための方法」について話しますユーザーサービス課題を見つける課題を解決する

Slide 9

Slide 9 text

サービス開発とは • ユーザーに価値を届けること • たとえば…… ‣ 困っていることを解決する ‣ 不便だけど仕方なく使っている仕組みの代わりを提供する ‣ 嬉しい・楽しいといった感情を強くする体験を提供する

Slide 10

Slide 10 text

またしても質問です隣の人に誕生日プレゼントをあげるとしたら何をあげますか？

Slide 11

Slide 11 text

身近なサービス開発の例 • 誕生日プレゼント選び ‣ プレゼントを渡して人に喜んでもらうのは難しい ‣ 友だちでも悩むし、家族ですら悩む ‣ これを知らない人相手にやるのがサービス開発

Slide 12

Slide 12 text

わからないなら本人に聞けばいい？ • 自分の欲しいものを言語化するのは難しい • ヘンリー・フォード  「もし顧客に、彼らの望むものを聞いていたら、彼らは『もっと速い馬がほしい』と答えていただろう」

Slide 13

Slide 13 text

サービス開発は難しい

Slide 14

Slide 14 text

サービス開発の難しさ • ゴールがわからない ‣ ユーザーの持つ欲求は、本人も含めて誰にもわからない ‣ ユーザーの持つ欲求は、時間とともに変わっていく • 今いる場所がわからない ‣ 開発者は自分のサービスを正しく理解できていない • 失敗は前提

Slide 15

Slide 15 text

不確実で失敗は前提

Slide 16

Slide 16 text

不確実で失敗は前提 → 失敗を無駄にしない開発

Slide 17

Slide 17 text

科学的にサービス開発

Slide 18

Slide 18 text

科学的とは？ ʦܗಈʧ ̍ ߟ͑ํ΍ߦಈͷ͔͕ͨ͠ɺ࿦ཧతɺ࣮ূతͰɺܥ౷ཱ͍ͬͯΔ͞·ɻ ̎ ಛʹࣗવՊֶͷํ๏ʹ߹͍ͬͯΔ͞·ɻʮՊֶతͳ஌ࣝʹ๡͍͠ʯ σδλϧେࣙઘ

Slide 19

Slide 19 text

科学的とは？ ʦܗಈʧ ̍ ߟ͑ํ΍ߦಈͷ͔͕ͨ͠ɺ࿦ཧతɺ࣮ূతͰɺܥ౷ཱ͍ͬͯΔ͞·ɻ ̎ ಛʹࣗવՊֶͷํ๏ʹ߹͍ͬͯΔ͞·ɻʮՊֶతͳ஌ࣝʹ๡͍͠ʯ σδλϧେࣙઘ

Slide 20

Slide 20 text

科学的なサービス開発 • 成功する確率が比較的高い • 失敗の原因が特定できる • 成否関係なく結果から情報を得られる • 特定個人の発想・センスに強く依存しない

Slide 21

Slide 21 text

よくある失敗すごそうな企画開発降りてきたこれは当たるつくります！祝！リリース！

Slide 22

Slide 22 text

よくある失敗ごめんて今まで一体何を…… 利用者が無すごそうだった企画（別プロジェクトへ）開発

Slide 23

Slide 23 text

まとめると

Slide 24

Slide 24 text

サービス開発の考え方まとめ • サービス開発はものすごく難しい • 失敗からいかに学びを得るかが重要 • そのために科学的なプロセスを意識する必要がある

Slide 25

Slide 25 text

実際どうやるの？

Slide 26

Slide 26 text

サービス開発の手法はいろいろある業界が異なれば、手法も異なる cf.) http://www.happystream.net/products_consulting/difference/

Slide 27

Slide 27 text

サービス開発の手法はいろいろある社内でも様々な方法がある

Slide 28

Slide 28 text

今日の講義では…… • リーン・スタートアップをベースに話します • 初期投資コストが低いネット業界と相性がよく  共通言語になっている • 社内メンバーの支持が高い（と思う） ‣ 17 卒の課題図書だった

Slide 29

Slide 29 text

ざっっっくり言うと考えて (仮説) 確かめる (検証) これをていねいに、高速に繰り返す

Slide 30

Slide 30 text

「考えて・確かめる」を高速にスパンの長い開発スパンの短い開発一旦正解を決めて突き進む正解を模索しながら進む

Slide 31

Slide 31 text

BML ループ

Slide 32

Slide 32 text

BML ループ • 最大のムダは誰も欲しがらないモノを作ること ‣ このサービスは作れるか？ではなく、作るべきか？を問う Ͳ͏΍ͬͯ  ࣮ݱ͢Δ͔ ϦʔϯελʔτΞοϓ कඋൣғ Ͳ͏΍ͬͯ  ։ൃαΠΫϧΛ ճ͔͢ Ϧιʔεͷ  ࢖͍ํ(഑෼) ࢿۚɾϦιʔε ௐୡͷ࢓ํ ΞΠσΟΞͷख ʹೖΕํ

Slide 33

Slide 33 text

（Build の手前の）idea = 仮説

Slide 34

Slide 34 text

（Build の手前の）idea = 仮説 • 仮説を立てるにはユーザーを深く理解することが必要 • 理解のポイントは２つやりたい欲求できない課題

Slide 35

Slide 35 text

ユーザー理解の手法 • 手法はいろいろ ‣ ユーザーインタビュー → 後で fjkn が講義してくれます ‣ アンケート ‣ ドッグフーディング ‣ ログ分析 ʜ

Slide 36

Slide 36 text

ペルソナ作成 • 共通点をペルソナにする • ユーザーは百人十色 ‣ ただし、似た属性・志向を持つ  ユーザーの行動パターンは  数個に収束する • その行動パターンを言語化し  ペルソナにする ‣ チーム内でユーザー像の認識を揃える

Slide 37

Slide 37 text

仮説の定義 • 対象となるペルソナの抱えている課題を発見 ‣ 解決すべき課題はなにか？ ‣ どうやって解決するか？ ‣ 解決によって得られるものは？ ‣ 解決にかかるコストは？ ‣ 代替手段を使ってでも解決しようとしている？

Slide 38

Slide 38 text

Build

Slide 39

Slide 39 text

Build • 課題の解決策を具体化する ‣ まずはユーザーのストーリーを考える ‣ ストーリーを実現する解決策の案を出す ‣ 仮説と解決策をまとめて言語化する ‣ それを最小コストで実現する

Slide 40

Slide 40 text

Slide 41

Slide 41 text

ユーザーのストーリーを考える • 解決策を点で考えないことが重要 ‣ いきなり機能を考えようとしない ‣ まずは課題を抱えてから解決するまでの流れを線で考える  （ストーリーを描く→ユーザーストーリー）

Slide 42

Slide 42 text

ユーザーストーリー • 開発者目線で書くべからず • ユーザーの物語視点で書くべし • 機能名や UI 名を書くべからず

Slide 43

Slide 43 text

フリマアプリのストーリー例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした

Slide 44

Slide 44 text

• セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保留にしおく • 一週間後、値下げ情報が Push 通知で届いた • 他の人に狙われないうちに、急いで購入手続きをしたたとえば機能名を書くとそこで思考停止する → Push 通知以外の選択肢が頭から消える

Slide 45

Slide 45 text

アプリでの行動例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをしたブランド名で検索商品詳細の確認いいね Push 通知受信購入申請

Slide 46

Slide 46 text

フリーマーケットでの行動例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした会場で探す手に取って確認記憶・メモフリマに再訪声掛け

Slide 47

Slide 47 text

ポイント • ユーザー視点で記述することで、  既存の代替手段と比較が可能になる • あえて画面外の行動も書く • そのままユーザーテストでやってもらうことの  リストとすることもできる

Slide 48

Slide 48 text

Slide 49

Slide 49 text

解決策の案を出すインプットアウトプット案の決定

Slide 50

Slide 50 text

解決策の案を出す既存のアイディアを組み合わせるインプットアウトプット案の決定無理矢理にでも広げるイメージしやすいように具体化する

Slide 51

Slide 51 text

光速デモ解決策の案を出す既存のアイディアを組み合わせるインプットアウトプット案の決定無理矢理にでも広げるイメージしやすいように具体化する Crazy8s ソリューションスケッチ

Slide 52

Slide 52 text

光速デモ既存サービスの使えそうな点（ビッグアイディア）を共有する

Slide 53

Slide 53 text

光速デモ

Slide 54

Slide 54 text

サービスじゃなくても使えそうなアイディアなら OK 光速デモ

Slide 55

Slide 55 text

時間を区切ってアイディアやバリエーションを出しまくる Crazy8s

Slide 56

Slide 56 text

解決策を 3 コマ程度のスケッチで表現するソリューションスケッチ

Slide 57

Slide 57 text

ソリューションスケッチ

Slide 58

Slide 58 text

注意点 • 各フェーズできちんと制限時間を設ける ‣ ダラダラ考えてもいいアイディアはでない ‣ 原則この時点では「何もわかっていない」 ‣ 議論が空中戦になりやすい

Slide 59

Slide 59 text

Slide 60

Slide 60 text

仮説と解決策の言語化 1. 利用者: そのサービスは誰が使う？ 2. 価値: そのサービスを使うと何がうれしいの？ 3. 体験: その価値はどんな体験から得られる？ 4. 機能: その体験がどんな機能があれば実現できる？抑えるべきポイント

Slide 61

Slide 61 text

フレームワーク世間にある手法クックパッド独自シナリオジャーニーマップストーリーボード価値仮説シート EOGS ステートメントシート ʜ

Slide 62

Slide 62 text

価値仮説シート

Slide 63

Slide 63 text

EOGS

Slide 64

Slide 64 text

リーンキャンバス

Slide 65

Slide 65 text

Slide 66

Slide 66 text

最小コストで実現する • 課題解決策のアイディアを具体化 • 可能な限り小さな実装で仮説を検証する = MVP ‣ Minimum Viable Product ‣ 検証を行える可能な限り小さいもの ‣ 「実装しない」のが最も小さい

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

MVP • 目的は「最短で仮説が検証できるものをつくる」こと • 方法はいろいろ ‣ ペーパープロトタイピング ‣ プロトタイプツールの利用（Figma/Flinto/Prott/InVision/…） ‣ デモ環境での実装 ‣ 本番環境での実装 • 目的に合わせて最小コストのものを選択する

Slide 69

Slide 69 text

Measure

Slide 70

Slide 70 text

Measure • つくって終わりじゃ意味がない • 出てきた結果から仮説の  答え合わせをして次に活かすのが何よりも大事 ‣ 仮説は正しかったのか？間違っていたのか？ ‣ どこが正しかったのか？どこが間違っていたのか？ ‣ このまま進んでいいのか？方向転換が必要か？

Slide 71

Slide 71 text

検証方法 • 大雑把に分けると定性と定量 • 定性データ ‣ ユーザーインタビューのログ ‣ アンケートの自由記述欄 • 定量データ ‣ PV, UU, CV, リテンションなど ‣ ログを元にした数値情報

Slide 72

Slide 72 text

定性 vs 定量 • 前提としてどちらの視点も必須 • それぞれに得意不得意があるので、  施策内容やサービスのフェーズ等で重み付けを変える

Slide 73

Slide 73 text

定性評価 • 代表的なのはユーザーテスト

Slide 74

Slide 74 text

定性評価 • ユーザーの体験やその理由を直接確認できるので、  行動の裏付けとなる情報が得られる • 一方で、情報の正確性には注意が必要 ‣ テスト対象が特殊な属性だったら？ ‣ ユーザーが無自覚に普段の行動と違う話をしていたら？

Slide 75

Slide 75 text

定量評価 • 代表的なのは AB テスト

Slide 76

Slide 76 text

定量評価 • 正確な情報を得ることができる ‣ 前提や検証の状況を疑うことは必要 • 一方で、行動の理由はわからないため  ユーザー体験を裏付ける情報は得られない ‣ 施策の数字良かった/悪かったのはなぜ？  ↑ この問いが仮説の域から出ることはない

Slide 77

Slide 77 text

定性 vs 定量定性評価定量評価 • 行動の裏付けが得られる • どうあがいても主観が入る • サンプルが偏る可能性が高い • 明確な結果は出てきづらい • 検証期間自体は短い • 行動の裏付けは得られない • 主観が入りづらい • サンプルの偏りを減らせる • 明確な結果が出しやすい • それなりの検証期間が必要

Slide 78

Slide 78 text

定性評価が向いてる定量評価が向いてる • サンプル数が少ない • 検証したい体験が複雑 • コンセプトを詰めていきたい • サンプル数が十分に取れる • 検証したい体験がシンプル • コンセプトが成熟している定性と定量の使い分けサンプル数の判断は難しい簡単にやるなら https://www.optimizely.com/sample-size-calculator/ などのサイトが使える FYI: https://techlife.cookpad.com/entry/2016/09/26/111601

Slide 79

Slide 79 text

Build との関係性 • 実際にはつくるものと検証方法はセットで決める ‣ ユーザーテストをするならプロトでいい ‣ AB テストをするなら実装が必要

Slide 80

Slide 80 text

Learn

Slide 81

Slide 81 text

Learn • しらべて終わりじゃ意味がない • 出てきた結果から仮説の答え合わせをして  次に活かすのが何よりも大事（再掲） ‣ はかっただけじゃ答え合わせができていない • 学んだ結果を次の仮説のタネにする • 組織内に共有できるのがベスト

Slide 82

Slide 82 text

“学び” とは？

Slide 83

Slide 83 text

“学び” とは？

Slide 84

Slide 84 text

“学び” とは？こっちは施策打てばわかる（やるだけ）

Slide 85

Slide 85 text

“学び” とは？気をつけるのはこっち事前にサービスに対する現状の理解を固めておかないと得られる学びの量が減る

Slide 86

Slide 86 text

“学び” を得るために • しっかりと仮説を立てて言語化しておく • 指標の解釈を整理しておく ‣ この数値が高い/低いのは何を意味する？その時どうする？ • 結果の数値やユーザーの反応を想定しておく ‣ 測定指標がどのくらいになったらどうする？ ‣ 想定と違った反応を見せたのはなぜ？ ‣ 「なんとなく Go」を避ける • 成功のイメージを共有する

Slide 87

Slide 87 text

要するに

Slide 88

Slide 88 text

仮説を立てた段階でサイクル全体を設計しておく ԿΛͭͬͯ͘ Ͳ͏ݕূͯ͠ Ͳ͏ղऍ͢Δͷ͔

Slide 89

Slide 89 text

施策実施前の整理一例

Slide 90

Slide 90 text

情報共有について • 知見は放っておくと腐って死ぬ • 知見共有されない問題 ‣ どこにプールされているか判然としない ‣ 知見が属人的になる ‣ ならまだいい方で時がたって本人もはっきり覚えていない感じになる ‣ 最悪だと組織改編や転職で闇に消える

Slide 91

Slide 91 text

情報共有について • 知見は放っておくと腐って死ぬ • 間違った知見共有される問題 ‣ 結果の数字の読み取り方がおかしい ‣ そもそも KPI の設定がおかしい ‣ 検証の期間が短すぎて正確性に欠ける ‣ といったようなことに気づかず正しい知見として共有される

Slide 92

Slide 92 text

社内独自の取り組み • Report.md ‣ 施策に関する仮説や結果等を Markdown 形式でまとめる ‣ 運用を Pull Request 形式で行うのがポイント ‣ チームのレポジトリにレビューの通った知見が貯まっていく

Slide 93

Slide 93 text

Report.md 1. 施策の分析レポートを Markdown で作成し、PR を出す

Slide 94

Slide 94 text

Report.md 2. チームメンバーを中心にレポートをレビュー

Slide 95

Slide 95 text

Report.md 3. レビューが通ったら merge してレポートをプール

Slide 96

Slide 96 text

何を書くのか？プロジェクトのフェーズや施策の性質によって変わるが「仮説」「仮説背景」「検証方法」「結果の想定」「検証結果」　　　「考察・ギャップ分析」「Next Action」くらいを抑えておくとよい cf.) https://techlife.cookpad.com/entry/2018/12/07/121515

Slide 97

Slide 97 text

Report.md 一例

Slide 98

Slide 98 text

実際の使われ方 • https://reports.g.cookpad.com があったり • 自分がやった昔の施策を他の人に共有しやすい

Slide 99

Slide 99 text

まとめると

Slide 100

Slide 100 text

サービス開発のフローまとめ • 「考えて・確かめる」を丁寧かつ高速に繰り返す ‣ Build: 仮説からつくるものを決める, 最小の実装ですませる ‣ Measure: 定性と定量の両視点を持つ, 検証方法も吟味する ‣ Learn: 事前の想定が重要, 組織内に情報を共有する • 要所要所で社内外のフレームワークを利用

Slide 101

Slide 101 text

今日の内容は現場でも常に全て実践されている？ • No ‣ 「ペルソナを作らないと先に進めない」みたいなことはない • プロジェクトの状況とメンバー次第 ‣ 「時間を何に使うか」の見極めは重要 • 今日の内容はベースとなるフロー ‣ 守破離の「守」 ‣ 迷ったらここに立ち返る

Slide 102

Slide 102 text

Q&A