技術職インターンシップ投稿推進部 部長勝間 亮クックパッドにおけるサービス開発
View Slide
自己紹介• 勝間 亮 (かつま りょう)• 2009.05~ クックパッド• サービス開発エンジニア‣ 検索, 投稿, 新規事業, 会員事業, … etc• 2014.05~ 投稿推進部 部長
今日の流れ• 9:30~11:20 クックパッドのサービス開発• 11:20~11:30 !• 11:30~13:00 個人ワーク
今日の目的“クックパッドのサービス開発の 考え方を理解する”
今日のゴール「今日からウチの部でよろしく!」に(なんとか)対応できる
今日からよろしく？• 開発フェーズと目的を理解• 今、何をすべきかを判断• 最小のコストで実現
!! 注意 !!
注意• コードは書きません• 頭を使って考えてください
サービス開発の考え方
サービス？• クックパッドのWebサービス/アプリ• 目に見えている、利用できるもの‣ 検索, レシピ投稿…‣ ユーザー登録, ログイン…‣ メール, Push通知…
根底にある理解
根底にある理解誰も正解は知らない
根底にある理解• 誰も正解は知らない‣ 僕も分からない‣ 社長も分からない
根底にある理解• 限られたリソースの中で多くのトライ‣ 失敗から学ぶ
根底にある理解• 可能なかぎりの工夫‣ フレームワーク‣ 先人の知恵
大事にしている考え• アジャイルなものづくり• リーンスタートアップ• 技術に対するスタンス
アジャイルなものづくり• インクリメンタル‣ いきなり理想形をすべて形にしない‣ 一度に全部作らない
アジャイルなものづくり• イテレーティブ‣ 最初は小さくつくる‣ 継続的に改良しながら大きくする
アジャイルなものづくりコアを形に コア完成追加機能Aを形にコア完成追加機能Aを完成追加機能Bを形に
リーンスタートアップ引用: http://www.amazon.co.jp/dp/4822248976
リーンスタートアップ• サービス開発のプロセス論‣ このやり方をやればOK ⇨ ו 失敗を前提‣ いかに早く無駄なく成功に辿り着けるか‣ クックパッドの考えとマッチ
リーンスタートアップ1. ユーザの欲求をもとに 課題と解決策が持つ価値を設定2. 解決策を形にして、 実際に利用してもらい価値を検証3. 利用データを見ながら方向性を見直し
リーンスタートアップ1. ユーザの課題2. 解決策実際3. 利用し価値仮説
リーンスタートアップ1. ユーザの課題2. 解決策実際3. 利用しMVPと検証価値仮説
リーンスタートアップ1. ユーザの課題2. 解決策実際3. 利用しMVPと検証価値仮説BMLループ
技術に対するスタンス• ユーザーの課題解決‣ ↔ 面白そうだからやってみる (= 技術のための技術 )• 解くべき課題は何？を明確に
例）RxJava導入編
解くべき課題• 例) 主婦の持つ課題‣ 今日何作ろう？が決まらない‣ 同じものを作りたくない‣ 毎日買物には行けない
解くべき課題• 例) 主婦の持つ課題‣ 今日何作ろう？が決まらない‣ 同じものを作りたくない‣ 毎日買物には行けない• 解) 人気レシピを探せる検索
サービス開発の考え方まとめ
サービス開発の考え方• 正解は誰にも分からない• 多くのトライを打つことが合理的• 技術はユーザーの課題解決のため
Q & A
サービス開発のフロー
開発フロー• 課題発見• 価値仮説• MVP• 効果検証
開発フロー‣ 課題発見• 価値仮説• MVP• 効果検証
課題発見• ユーザーインタビュー‣ アンケートから感情を理解するのは困難‣ コストは高いが確実• ターゲット層と直接話す‣ 課題発見以外の場面でも
インタビュー" #
インタビューユーザーの声を聞くのではない#
インタビュー声の背後にある具体的な体験を聞く#$
インタビュー• 知りたいのは声の背後にある具体的体験‣ ユーザの「声」は自身が体験を分析した結果‣ 分析が正しい保証はない‣ 普遍的な意見なのかどうかもわからない• 体験をきちんと理解/分析し直してこそプロ
実際やるといろいろ難しい
ユーザの話夕飯の献立はどうやって決めますか？だいたい家にあるもので検索して、その日の気分でメインを決めます。そのあと合いそうな副菜を探してだいたい３品くらい作ります。#"
ユーザの話は不完全夕飯の献立はどうやって決めますか？だいたい家にあるもので検索して、その日の気分でメインを決めます。(実は家族にこの間にLINEで相談してた) そのあと合いそうな副菜を探してだいたい３品くらい作ります。(実は作りおきのおかずで1品はすませます)#"
ユーザは例外には触れない夕飯の献立はどうやって決めますか？だいたい家にあるもので検索して、その日の気分でメインを決めます。そのあと合いそうな副菜を探してだいたい３品くらい作ります。 本当は家族が食べたいものをリクエストしてくれる日は一番さくっと決まるんですけどね。#"
体験を聞き出すコツ
具体的なシーンを「夕飯の献立はどうやって決めますか？」「昨日の夕飯の献立はどうやって決めましたか？」
具体的なシーンを「いまスマートフォンをお持ちですか？ 実際に使っているところを見せてもらえますか？」
教えを請う• 教えてほしい姿勢の人には丁寧に説明‣ 話してる最中に次の質問を考えるのはNG
根堀り 葉堀り• 最初の質問から理解しようと努める‣ 自ずと次の質問が湧いてくるはず‣ 理解できるまで疑問があれば素直に質問
理解したことを確認• 理解した内容を直接確認してみる‣ 一部の回答だけ聞いて分かった気にならない
記録のコツ
役割分担• メインインタビュアー• 記録係"%
全部書く• 何が重要かはその場で分からない‣ 誰かによるフィルタ前の生データ• 手書きで残す‣ 話し相手の横でPCに向かれると距離%
課題の発見• 「絶対に必要」とする課題は何？• 現在の解決策は何？
課題発見• 「絶対に必要」とする課題は何？• 現在の解決策は何？これは解決すべき課題？
ユーザー抽出• クックパッドのデータから抽出‣ 地域‣ 年代‣ 利用データ• メールでインタビュー許諾
インタビュイーどういう層のユーザーを向いているか
インタビュイー社内スタッフもベンチマーク
引用: http://www.oreilly.co.jp/books/9784873115917/ http://www.oreilly.co.jp/books/9784873117218/
開発フロー• 課題発見‣ 価値仮説• MVP• 効果検証
方向性のまとめ• 課題と解決策の仮説をまとめる• 自社フレームワーク‣ 価値仮説シート‣ EOGS‣ ステートメントシート
まとめる意義• 自分たちの思考整理• 開発中にメンバー間で考えがぶれる‣ 「何で作ってんだっけ?」の方向性を正す‣ 限られた時間の中で目的を見失うのは無駄
価値仮説シート• シンプルなフォーマット‣ ユーザー‣ 欲求‣ 課題‣ 価値
価値仮説シート• (ユーザー) ________ は• (欲求) _______ (し)たいが• (課題) _______ (でき)ないので• (特徴) _______ (こと)に価値がある
例) 人気順検索• (ユーザー) レシピをさがすユーザーは• (欲求) 今日のメニューを早く決めたいが• (課題) 多くのレシピから決められないので• (特徴) 人気レシピを探せる検索に価値がある
EOGS• 多くのキャストを考慮するとき‣ のせる/さがす/クライアント/クックパッド• 欲求をベース‣ 方向性をまとめるのに向いてる‣ 例）レシピコンテスト
200万レシピ
ステートメントシート• やること/やらないことを明確化‣ シンプルな機能を実現できる‣ 新規アプリ開発に向いている
お料理アルバム
使い分け• 価値仮説シートはまず書く‣ シンプルなので一番書きやすい• アプリならステートメントシート• いろんなキャストが絡むとEOGS
開発フロー• 課題発見• 価値仮説‣ MVP• 効果検証
MVP• Minimum Viable Product• 価値仮説が正しいかを検証• 検証を行える可能な限り小さいもの‣ 実装しないものは最も優れたMVP‣ 例) 手書きのチラシ
プロトタイプ• 最短で動くものを作る‣ 実装せずにできるとベスト• Flinto/Prott‣ 絵だけで動くものができる‣ スマホで実現したときの疑似体験
Flinto
デザインルール
小さくためす• 限定ユーザーを対象‣ スタッフのみ‣ 特定のユーザーのみ• いきなり全体リリースはしない‣ イレーティブな開発‣ ツールで工夫
限定公開• Web: Chanko• iOSアプリ: Test Flight• Androidアプリ: Deploy Gate
Chanko• Webで限定公開する仕組み• Railsの内製プラグイン‣ Staffだけ‣ 特定条件のユーザーだけhttps://speakerdeck.com/mrkn/chanko
小さくためす• 実装しない工夫• 少人数で試す工夫• ツールを最大限活用
開発フロー• 課題発見• 価値仮説• MVP‣ 効果検証
検証• 検証すべき数字をあらかじめ決定‣ 利用ユーザー数‣ リテンション数 … etc• 定量的な情報で仮説を判断
なぜ効果検証？• MVPを答え合わせ‣ このまま進む？‣ 方向転換すべき？引用: Lean Analytics http://www.oreilly.co.jp/books/9784873117119/
BMLループideadataBuildMeasureLearnproduct
BMLループideadataBuildMeasureLearn価値仮説 何を学びたいか考える検証答えあわせをするMVP学びたいものをつくるproduct
指標• 物事を客観的に評価、判断するもの• サイト状態を示す指標‣ PV, UU …• ユーザーの行動を示す指標‣ CTR, CVR, リテンション …
PV• ページが表示された回数• 広告のimpression(imp)もほぼ同義• 100人が1回表示 = 1人が100回表示"#5 PV
UU• 期間内にサイト利用したユーザー数"#2 UU
CTR (Click Through Rate)• クリック回数 / 表示回数clickCTR 50%
CVR (Conversion Rate)• 最終評価に辿り着く=コンバージョン‣ 商品購入, 投稿完了など• コンバージョン数をPV, UUで割ったもの¥離脱CVR 50%
リテンション• 操作xを行ったユーザーがn日後に操作y• (ざっくり)ユーザーが定着をしているか5/15/25/3&&&& &&&" # ' (2日後のリテンション率25%
意思決定MVP 評価リリース範囲を拡大リリース内容見直し戦略練り直し(Pivot)
引用: http://www.oreilly.co.jp/books/9784873117119/
サービス開発のフローまとめ
開発フローのまとめ• インタビューによる課題発見• フレームワークで価値仮説をまとめ• ツールを使ったMVP• 指標の評価による仮説の検証
katsuma
mitsuaki96
kohbis
ryohatanmonolog
shin_higuchi
oracle4engineer
ymty
takahana
victorrentea
leekwangsoo1995
soracom
trycycle
daihiraoka
shpigford
mclloyd
sachag
cherdarchuk
cromwellryan
tenderlove
tammielis
zenorocha
jmmastey
eitanlees
pedronauck