Service Development at Cookpad 2016 summer internship

Transcript

1. 技術職インターンシップ 投稿開発部 副部長 勝間 亮 クックパッドにおけるサービス開発
2. 自己紹介 • 勝間 亮 (かつま りょう) • 2009.05~ クックパッド • サービス開発エンジニア ‣ 検索, 投稿, 新規事業, 会員事業, … etc • 2014.05~ 投稿領域 マネージャー
3. 今日の流れ • 09:30~10:30 講義+課題説明 • 10:30~12:00 プロトタイプ作成 • 12:00~13:00 ! • 13:00~14:00 ユーザーテスト準備 • 14:00~14:30 ユーザーテスト • 14:30~15:00 テストの振り返りと改善点まとめ • 15:00~16:00 成果発表会 • 16:00~　　　 まとめ
4. 今日の目的 “クックパッドのサービス開発の
 考え方を理解する”
5. 今日のゴール 「今日からウチの部でよろしく!」 に(なんとか)対応できる
6. 今日からよろしく？ • 開発フェーズと目的を理解 • 今、何をすべきかを判断 • 最小のコストで実現
7. !! 注意 !!
8. 注意 • コードは書きません • 頭を使って考えてください
9. コードを書かない? • 使われることがない「最高の実装」? • 欲しがられる「プロトタイプ」?
10. コードを書かない? • 使われることがない「最高の実装」? • 欲しがられる「プロトタイプ」?
11. サービス開発の考え方
12. 根底にある理解
13. 根底にある理解 誰も正解は知らない
14. 根底にある理解 • 誰も正解は知らない ‣ 僕も分からない ‣ 社長も分からない
15. 根底にある理解 • 限られたリソースの中で多くのトライ ‣ 失敗から学ぶ
16. 根底にある理解 • 可能なかぎりの工夫 ‣ フレームワーク ‣ 先人の知恵
17. 技術に対するスタンス • ユーザーの課題解決 ‣ ↔ 面白そうだからやってみる
 (= 技術のための技術 ) • 解くべき課題は何？を明確に
18. 解くべき課題 • 例) 主婦の持つ課題 ‣ 今日何作ろう？が決まらない ‣ 同じものを作りたくない ‣ 毎日買物には行けない
19. 解くべき課題 • 例) 主婦の持つ課題 ‣ 今日何作ろう？が決まらない ‣ 同じものを作りたくない ‣ 毎日買物には行けない • 解) 人気レシピを探せる検索
20. サービス開発の考え方 まとめ
21. サービス開発の考え方 • 正解は誰にも分からない • 多くのトライを打つことが合理的 • 技術はユーザーの課題解決のため
22. サービス開発のフロー
23. 開発フロー • 課題発見 • 価値仮説 • MVP • 効果検証
24. 開発フロー ‣ 課題発見 • 価値仮説 • MVP • 効果検証
25. 課題発見 • ユーザーインタビュー ‣ アンケートから感情を理解するのは困難 ‣ コストは高いが確実 • ターゲット層と直接話す ‣ 課題発見以外の場面でも
26. インタビュー " #
27. インタビュー ユーザーの声を聞くのではない #
28. インタビュー 声の背後にある具体的な体験を聞く #$
29. インタビュー • 知りたいのは声の背後にある具体的体験 ‣ ユーザの「声」は自身が体験を分析した結果 ‣ 分析が正しい保証はない ‣ 普遍的な意見なのかどうかもわからない • 体験をきちんと理解/分析し直してこそプロ
30. 実際やるといろいろ難しい
31. ユーザの話 夕飯の献立はどうやって決めますか？ だいたい家にあるもので検索して、その日の気 分でメインを決めます。そのあと合いそうな副 菜を探してだいたい３品くらい作ります。 # "
32. ユーザの話は不完全 夕飯の献立はどうやって決めますか？ だいたい家にあるもので検索して、その日の気 分でメインを決めます。(実は家族にこの間に LINEで相談してた) そのあと合いそうな副菜を 探してだいたい３品くらい作ります。(実は作り おきのおかずで1品はすませます) # "
33. 体験を聞き出すコツ
34. 具体的なシーンを 「夕飯の献立はどうやって決めますか？」 「昨日の夕飯の献立はどうやって決めましたか？」
35. 具体的なシーンを 「いまスマートフォンをお持ちですか？
 　実際に使っているところを見せてもらえますか？」
36. 課題の発見 • 「絶対に必要」とする課題は何？ • 現在の解決策は何？
37. 課題の発見 • 「絶対に必要」とする課題は何？ • 現在の解決策は何？ これは解決すべき課題？
38. 引用: http://www.oreilly.co.jp/books/9784873115917/
 http://www.oreilly.co.jp/books/9784873117218/
39. 開発フロー • 課題発見 ‣ 価値仮説 • MVP • 効果検証
40. 方向性のまとめ • 課題と解決策の仮説をまとめる • 自社フレームワーク ‣ 価値仮説シート ‣ EOGS ‣ ステートメントシート
41. まとめる意義 • 自分たちの思考整理 • 開発中にメンバー間で考えがぶれる ‣ 「何で作ってんだっけ?」の方向性を正す ‣ 限られた時間の中で目的を見失うのは無駄
42. 価値仮説シート • シンプルなフォーマット ‣ ユーザー ‣ 欲求 ‣ 課題 ‣ 価値
43. 価値仮説シート • (ユーザー) ________ は • (欲求) _______ (し)たいが • (課題) _______ (でき)ないので • (特徴) _______ (こと)に価値がある
45. 例) 人気順検索 • (ユーザー) レシピをさがすユーザーは • (欲求) 今日のメニューを早く決めたいが • (課題) 多くのレシピから決められないので • (特徴) 人気レシピを探せる検索に価値がある
46. 開発フロー • 課題発見 • 価値仮説 ‣ MVP • 効果検証
47. MVP • Minimum Viable Product • 価値仮説が正しいかを検証 • 検証を行える可能な限り小さいもの ‣ 実装しないものは最も優れたMVP ‣ 例) 手書きのチラシ
49. プロトタイプ • 最短で動くものを作る ‣ 実装せずにできるとベスト • Flinto/Prott/InVision ‣ 絵だけで動くものができる ‣ スマホで実現したときの疑似体験
50. Flinto
51. Flinto
52. 開発フロー • 課題発見 • 価値仮説 • MVP ‣ 効果検証
53. 検証 • 検証すべき数字をあらかじめ決定 ‣ 利用ユーザー数 ‣ リテンション数 … etc • 定量的な情報で仮説を判断
54. なぜ効果検証？ • MVPを答え合わせ ‣ このまま進む？ ‣ 方向転換すべき？ 引用: Lean Analytics 
 http://www.oreilly.co.jp/books/9784873117119/
55. 指標 • 物事を客観的に評価、判断するもの • サイト状態を示す指標 ‣ PV, UU … • ユーザーの行動を示す指標 ‣ CTR, CVR, リテンション …
56. PV • ページが表示された回数 • 広告のimpression(imp)もほぼ同義 • 100人が1回表示 = 1人が100回表示 " # 5 PV
57. UU • 期間内にサイト利用したユーザー数 " # 2 UU
58. 意思決定 MVP 評価 リリース範囲を拡大 リリース内容見直し 戦略練り直し(Pivot)
59. 引用: http://www.oreilly.co.jp/books/9784873117119/
60. サービス開発のフロー まとめ
61. 開発フローのまとめ • インタビューによる課題発見 • フレームワークで価値仮説をまとめ • ツールを使ったMVP • 指標の評価による仮説の検証