Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Service development lecture in 2018 summer inte...

Service development lecture in 2018 summer internship - 10 Day Tech for service engineers -

クックパッドの 2018 夏エンジニアインターンで講義に用いた資料です。

Kohei Arai

August 28, 2018
Tweet

More Decks by Kohei Arai

Other Decks in How-to & DIY

Transcript

  1. 自己紹介 新井 康平 @SpicyCoffee66  会員事業部 エンジニア (17 卒) 2017年: さがす体験改善,

    新規事業バックエンド実装 2018年: 有料会員のさがす体験改善(PM)
  2. スケジュール 10:00-11:30 サービス開発講義 11:30-12:00 プロトタイプング講義・環境構築 12:00-13:00 ランチ 13:00-15:00 ワーク 15:00-16:00

    ユーザーインタビュー講義・インタビュー準備 16:00-16:30 ユーザーインタビュー 16:30-17:30 ワーク 17:30-18:30 成果発表 18:30-19:00 講評・日報
  3. • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保留にしおく • 一週間後、値下げ情報が

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

    一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした ブランド名で検索 商品詳細の確認 いいね Push 通知受信 購入申請
  5. 最小コストで実現する • 課題解決策のアイディアを具体化 • 可能な限り小さな実装で仮説を検証する = MVP ‣ Minimum Viable

    Product ‣ 検証を行える可能な限り小さいもの ‣ 「実装しない」のが最も小さい
  6. 定量評価 • 代表的なのは AB テスト • 正確な情報を得ることができる ‣ 前提や検証の状況を疑うことは必要 •

    一方で、行動の理由はわからないため
 ユーザー体験を裏付ける情報は得られない ‣ 施策の数字 良かった/悪かった のはなぜ?
 ↑ この問いが仮説の域から出ることはない
  7. 定性 vs 定量 定性評価 定量評価 • 得られる ”情報量” が多い •

    どうあがいても主観が入る • サンプルが偏る可能性が高い • 明確な結果は出てきづらい • 検証期間自体は短い • 得られる “情報量” が少ない • 主観が入りづらい • サンプルの偏りを減らせる • 明確な結果が出しやすい • それなりの検証期間が必要
  8. 定性評価が向いてる 定量評価が向いてる • サンプル数が少ない • 検証したい体験が複雑 • コンセプトを詰めていきたい • サンプル数が十分に取れる

    • 検証したい体験がシンプル • コンセプトが成熟している 定性と定量の使い分け サンプル数の判断は難しい 簡単にやるなら https://www.optimizely.com/sample-size-calculator/ などのサイトが使える FYI: https://techlife.cookpad.com/entry/2016/09/26/111601
  9. “学び” を得るために • しっかりと仮説を立てて言語化しておく • 指標の解釈を整理しておく ‣ この数値が 高い/低い のは何を意味する?その時どうする?

    • 結果の数値やユーザーの反応を想定しておく ‣ 測定指標がどのくらいになったらどうする? ‣ 想定と違った反応を見せたのはなぜ? ‣ 「なんとなく Go」を避ける • 成功のイメージを共有する
  10. 情報共有について • 知見は放っておくと腐って死ぬ • 知見共有されない問題 ‣ どこにプールされているか判然としない ‣ 知見が属人的になる ‣

    ならまだいい方で時がたって本人もはっきり覚えていない 感じになる ‣ 最悪だと組織改編や転職で闇に消える
  11. 情報共有について • 知見は放っておくと腐って死ぬ • 間違った知見共有される問題 ‣ 結果の数字の読み取り方がおかしい ‣ そもそも KPI

    の設定がおかしい ‣ 検証の期間が短すぎて正確性に欠ける ‣ といったようなことに気づかず正しい知見として共有される
  12. 社内独自の取り組み • Report.md ‣ 施策に関する仮説や結果等を Markdown 形式でまとめる ‣ 運用を Pull

    Request 形式で行うのがポイント ‣ チームのレポジトリにレビューの通った知見が貯まっていく
  13. サービス開発のフローまとめ • 「考えて・確かめる」を丁寧かつ高速に繰り返す ‣ Build: 仮説からつくるものを決める, 最小の実装ですませる ‣ Measure: 定性と定量の両視点を持つ,

    検証方法も吟味する ‣ Learn: 事前の想定が重要, 組織内に情報を共有する • 要所要所で社内外のフレームワークを利用 ‣ 最近ではデザインスプリントというフレームワークが流行り
  14. Q&A