エンジニアが成長のエンジンになる日 #devsumi #natsumiC7

Transcript of "エンジニアが成長のエンジンになる日 #devsumi #natsumiC7"

1. 1. エンジニアが 成長のエンジン になる日 Recruit Holdings R&D Division Business Development Office Kuroda Itsuki @i2key SPEED for Enterprise
2. 2. 黒田 樹 (@i2key) <= Follow me :-) 前職ではSIerで官公庁系大規模システムのアーキテクト。 Java屋。数多くのデスマを経験。 昨年度までは、全世界でシリーズ累計1300万DLのアプリ cameranシリーズの開発全体責任者（開発、採用、組織構 築、プロセスetc）でした。また、社内外でリーンスタート アップやアジャイルの登壇とかをたまにしています。 現在は、今までの経験やノウハウを使い海外のマイナー出資 先スタートアップの日本展開支援をしています。 http://99designs.jp 支援先スタートアップ
3. 3. サービス大ヒット ↓ 増員 ↓ カオス ↓ ギスギス ↓ 鎮火 ↓ やっぱダメ ↓ いいか？リーンにヤレ http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib 総合1位／ベストバリュー賞（満足度1位）／公募賞 ありがとうございました！
4. 4. サービス大ヒット ↓ 増員 ↓ カオス ↓ ギスギス ↓ 鎮火 ↓ やっぱダメ ↓ いいか？リーンにヤレ http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib 総合1位／ベストバリュー賞（満足度1位）／公募賞 ありがとうございました！この取り組みの裏側 ビジネススケール期 エンジニアの役割 成長に直接的に寄与
5. 5. ビジネスにおける スピードを生み出す開発
6. 6. 「ビジネスにおけるスピードを生み出す開発」とは 不確実性の高い事業ドメインやフェーズにおいて、 大きく失敗するリスクを最小化するために、ビジネス アイデアを複数の小さな仮説に分解し、それら一つ一 つ検証し実証していくという価値観のもと、この 仮説検証の速度をエンジニアリングで最大化 すること。そのために、必要なインフラ基盤があ り、エンジニア自ら推進することが出来る仕組み があり、その活動の成果が適正に評価されること。
7. 7. 「ビジネスにおけるスピードを生み出す開発」とは 不確実性の高い事業ドメインやフェーズにおいて、 大きく失敗するリスクを最小化するために、ビジネス アイデアを複数の小さな仮説に分解し、それら一つ一 つ検証し実証していくという価値観のもと、この 仮説検証の速度をエンジニアリングで最大化 すること。そのために、必要なインフラ基盤があ り、エンジニア自ら推進することが出来る仕組み があり、その活動の成果が適正に評価されること。
8. 8. エンジニアが感じる サービス開発現場のモヤモヤ プロダクトバックログに起票されるタスクが本当に開発す べきことなのか。やるべき理由はあるのか。 その機能をリリースしたあとの成果は機能毎にわかるのか。 結果から学びを得ているのか。 やっていることはサービスの成長に直結しているのか。
9. 9. そのモヤモヤは実は正しいことが多い
10. 10. 大抵思い込みで盛大に スベる
11. 11. 出会い系サイトを作る ↓ うまく行かない ↓ 動画共有機能は良く使われている ↓ 動画共有サイトにピボット
12. 12. 位置情報チェックインアプリを作る ↓ うまく行かない ↓ 写真共有機能は良く使われている ↓ 写真共有サイトにピボット
13. 13. オンラインゲームを作る ↓ うまく行かない ↓ 写真共有機能は良く使われている ↓ 写真管理共有サービスにピボット
14. 14. 世の中の成功してるサービス の60%以上が、最初のビジ ネスアイデアを捨てている。 市場にだして、初めて分かる こと多すぎwwwwwwwww 5
15. 15. なぜ？彼らは死なないですんだのか 5
16. 16. 失敗から学びを得ている
17. 17. ビジネスアイデア全てを 仮説と捉えて、 それらを小さく分割して 検証すること 効率よく失敗して、 効率よく学ぶ考え方
18. 18. 無駄を徹底的に省くこと ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する  = 不確実性(リスク)を最小化するプロセス   成功を保証するプロセス そのために、効率的(例:小さく/短く/安く)に 仮説を検証して学びを得る（ことが多い）
19. 19. 例）写真加工アプリにフィルタ購入機能を作ろう！！やりた いことの実装工数は3人月くらいかかりそうです。 あなたがこのプロダクトのオーナーならどうしますか？ ①フィルタ購入機能を3人月かけて実装する  （一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユー ザーの10%に表示して確認し、本当に購入ボタンが押された 回数を測定してから開発着手の判断をする。工数は2人日。 （本当に購入されるのかのみを検証） ②のほうが無駄の無い判断してるぽい 例えばこんな感じ
20. 20. 100円で 購入 100円で 購入 現在開発中です！ 近日リリース予定です！ ＜ポップアップ＞ ユーザー全体の10%にだけ 表示されるボタン
21. 21. 今みたいなのをMVPと言ったりします Minimum Viable Product（検証可能な最小限の製品）。 仮説を検証するために必要な最小限の何か。 ・プロダクト ・インタビュースクリプト ・説明スライド ・ペーパープロトタイピング  and so on… 仮説が検証できれば別に完璧な製品である必要はない
22. 22. 仮説立てる->MVPをつくる->測る->学ぶ MVP ビジネスアイデアを 仮説として捉えて 検証するためのプロセス。 仮説検証のためのMVPを Buildして それを元にMeasureし、 その結果得られたデータから Learnする。 つくる 測る 学ぶ 仮説たてる
23. 23. 保有リスク量 時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop ウォーターフォール型プロセス あれ？流行らない。 よし、機能追加だ！ もっと豪華な フィルターを売るぞ！ まだまだ機能が 足らんぞおおお！ マーケットプレイスに すべきだ！！！！ フィルター購入機能を つくるぞ！ 3人月
24. 24. 時間 仮説検証モデルによるプロセス 保有リスク量 2人日
25. 25. Learn Build Build Measure Measure 時間 仮説検証モデルによるプロセス 保有リスク量 2人日 全体の10%のみに出す ダミー購入ボタン作る 計測した結果、全然 クリックされていない 需要ないんだね、 あぶなかった・・・ （リスクがゼロになる）
26. 26. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ 良質な仮説検証を回すには、BMLループ をゴールから遡り設計をするのがキモ
27. 27. Product Backlog ＜開発タスク＞ 10個ひらめいた！ Product Owner 10個のエンジニアタスク 従来のタスクあるある シャワー浴びながら・・ トイレに入りながら・・ ktkr!!!! いやいやいや・・・ フィルタを売って 売上をあげる！ フィルタ購入機能実装
28. 28. Lean Canvas ＜ビジネス仮説＞ 仮説検証 MVPの設計 Product Backlog ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築 （エンジニアタスク） 10個のMVP設計 7個のGetOutOfBuilding （プロダクトオーナータスク） ※別に開発しなくても仮説検証できる 仮説検証型タスク エンジニアリング必要 エンジニアリング不要 フィルタが本当に 購入されるのか ダミー x 10%のユーザで 検証 検証用フィルタ購入 ダミーボタン実装
29. 29. 従来の Product Backlog 仮説検証型の Product Backlog ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・リファラル向上改善 ・登録ファネル改善 ・計測基盤実装 ・コホートに対するプッシュ実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 検証用フィルタ購入 ダミーボタン実装 フィルタ購入機能実装
30. 30. 「ビジネスにおけるスピードを生み出す開発」とは 不確実性の高い事業ドメインやフェーズにおいて、 大きく失敗するリスクを最小化するために、ビジネス アイデアを複数の小さな仮説に分解し、それら一つ一 つ検証し実証していくという価値観のもと、この 仮説検証の速度をエンジニアリングで最大化 すること。そのために、必要なインフラ基盤があ り、エンジニア自ら推進することが出来る仕組み があり、その活動の成果が適正に評価されること。 10
31. 31. 分析 計測 リリース A/Bテスト 10 データ収集
32. 32. 仮説検証単位（MVP）毎に効果を検証する 検証Aの実装を セグメントAにリリース 結果数値をウォッチ 検証Bの実装を セグメントBにリリース 結果数値をウォッチ 検証Cの実装を セグメントCにリリース 結果数値をウォッチ やったことの単位に結果を見ること 全部同時にリリースした場合、合計値でユーザー数などを 見ていても何が寄与したのかが見えない。 Sprint Backlog 検証Aの実装 検証Bの実装 検証Cの実装 10
33. 33. 検証Bを行っているユーザー 検証Cを行っているユーザー 検証Aを行っているユーザー このように縦に合計値で見ないほうがよい場合がある この場合検証Aの効果の影響なのに 合計値のみで見ていると判断を謝る 混ぜるな危険
34. 34. ・セグメント毎に対して別々の機能をリリース出来る  セグメントを自由に作成できる   (例：5%のユーザ集合、○○をした人、1ヶ月使ってない人） Feature Toggle, Feature Flipping ・セグメント毎にデータの計測が出来ること   コホート分析 ・同じセグメントに対して複数のパターンの検証が出来る   A/Bテスト 仮説検証を効果的に行うためのインフラ要件 ※今回説明省略します ※今回説明省略します
35. 35. プランニング     ↓   コーディング     ↓   テスト・コードレビュー     ↓   ステージングリリース     ↓   本番リリース     ↓   何故かわからないけど   サービス全体の利用率が上昇している   （学びがないから再現性がない） 開発環境 ステージング環境 本番環境 仮説検証を意識しない開発フロー
36. 36. 仮説検証を意識した開発フロー 開発環境 本番環境 プランニング     ↓   コーディング     ↓   テスト・コードレビュー     ↓   検証単位で非公開で本番リリース     ↓   検証単位で開示範囲を制限（チームメンバーだけ）     ↓   検証単位で開示範囲を制限（社員だけ）   ↓   検証単位で全ユーザーのN%に開示 検証単位で特定ユーザセグメントに開示     ↓   検証単位にコホートで効果分析     ↓   検証単位の改善（A/Bテスト実施）     ↓
37. 37. 仮説検証を意識した開発フロー 開発環境 本番環境 プランニング     ↓   コーディング     ↓   テスト・コードレビュー     ↓   検証単位で非公開で本番リリース     ↓   検証単位で開示範囲を制限（チームメンバーだけ）     ↓   検証単位で開示範囲を制限（社員だけ）   ↓   検証単位で全ユーザーのN%に開示 検証単位で特定ユーザセグメントに開示     ↓   検証単位にコホートで効果分析     ↓   検証単位の改善（A/Bテスト実施）     ↓ LEAN STARTUPが語られるときに エンジニアリングサイドについて 何故か触れられることが少ない・・ 小さく失敗して効率よく学ぶインフラ (一部の方には当たり前かもですが・・）
38. 38. Java http://www.ff4j.org Feature Flipping for Java https://github.com/togglz/togglz Togglz https://github.com/tacitknowledge/flip https://github.com/akomtur/fitchy Fitchy Flip
39. 39. Python Ruby Gutter Django-lean Chanko Flipper https://github.com/disqus/gutter https://bitbucket.org/akoha/django-lean/wiki/Home https://www.djangopackages.com/grids/g/feature-flip/ その他Django関連 https://cookpad.github.io/chanko/ https://github.com/jnunemaker/flipper https://github.com/FetLife/rollout Rollout
40. 40. Permission : ROLE_ADMINPermission : ROLE_USER Feature Flipping for Java
41. 41. 「ビジネスにおけるスピードを生み出す開発」とは 不確実性の高い事業ドメインやフェーズにおいて、 大きく失敗するリスクを最小化するために、ビジネス アイデアを複数の小さな仮説に分解し、それら一つ一 つ検証し実証していくという価値観のもと、この 仮説検証の速度をエンジニアリングで最大化 すること。そのために、必要なインフラ基盤があ り、エンジニア自ら推進することが出来る仕組み があり、その活動の成果が適正に評価されること。
42. 42. 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち ・・・ 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） 開発チーム PO Engineer Designer サービス開発全般 エンジニア体制の推移例（あくまで例） 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す)
43. 43. 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち ・・・ 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） 開発チーム PO Engineer Designer サービス開発全般 エンジニア体制の推移例（あくまで例） 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す) ガンガンいこうぜ！！！！
44. 44. 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち ・・・ 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） 開発チーム PO Engineer Designer サービス開発全般 エンジニア体制の推移例（あくまで例） 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す) 機能追加をやりつつ、 既存機能のグロース・改善もやる 同じプロダクトバックログで管理 Sprintのタスクウェイトを 新規機能30%、既存改善30%のように 定義しているものの・・・
45. 45. 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち ・・・ 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） 開発チーム PO Engineer Designer サービス開発全般 エンジニア体制の推移例（あくまで例） 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す) 既存の成長を維持しつつ、 新規にもスケールさせるという 目標を持ち始め、明確に目標と チームをリンクさせ分離しはじめる (コードベースが重厚長大化の兆し付き）
46. 46. 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち ・・・ 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） 開発チーム PO Engineer Designer サービス開発全般 エンジニア体制の推移例（あくまで例） 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す) エンジニア体制が大きくなり、 一度のリリースで大量のソースコードがリリース。 CIの時間は増大し、ソース間の依存性は高まり、ひとたび テストで落ちると・・・。 リリース頻度＝仮説検証トライ回数と考えると、 BMLループのスループット低下。 そのため、リリースをシンプルに、依存性を最小化。 リソースと権限とコミットを同じ場所におくために、 リリース単位(サービス単位)=ビジネスKPI=仮説検証単位(大 仮設)=チーム単位をリンクさせる。 ※この最終的に出来上がった何かが、 結果的にマイクロサービスアーキテクチャ？？(自信ないw)
47. 47. 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） サービス開発全般 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer ・・・ 開発チーム PO Engineer Designer 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す) グロース改善 機能開発 機能開発 機能開発 機能開発 グロース改善 グロース改善 エンジニア体制の推移例（あくまで例）
48. 48. 機能追加開発もやるし グロースのための改善もやるけど どうしても改善の優先度が下がりがち 成長率を上げるために目標別に専門チームに分離 ・新規機能追加をやるプロダクトチーム ・数値目標を元に既存機能の改善するグロースチーム コードベースが大きくなりすぎ 改善サイクルとリリースサイクルの不協和音 上記に追加して、 サービス単位でチーム分割 （アーキテクチャも分割） サービス開発全般 開発チーム PO Engineer Engineer Engineer Designer プロダクトチーム PO Engineer Engineer Designer グロースチーム Engineer Engineer Designer カメラ機能チーム プロダクト担当 PO Engineer Designer SNS機能チーム プロダクト担当 PO Engineer Designer ユーザ管理チーム プロダクト担当 PO Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer グロース担当 Engineer Designer ・・・ 開発チーム PO Engineer Designer 立ち上げ (P/S Fit目指す) ユーザー定着してきた (P/M Fit目指す) グロース頑張る (Scale目指す) グロース改善 機能開発 機能開発 機能開発 機能開発 グロース改善 グロース改善 エンジニア体制の推移例（あくまで例）
49. 49. プロダクトチーム PO Engineer Engineer Designer 機能開発 グロース改善 グロースチーム Engineer Engineer Designer 仕様の検討 ↓ 設計 ↓ 実装 ↓ テスト ↓ リリース 仮説構築 ↓ 検証の設計 ↓ MVPの構築 ↓ 検証 ↓ データ取得 ↓ 結果から学ぶ 各チームのエンジニアのフォーカス MVP実装品質 MVPリリース頻度 デプロイ回数/日 数値目標 継続率 離脱率 コンバージョン率 ： 要件/仕様は決まっている 結果を出せば自由 目標 制約
50. 50. 「ビジネスにおけるスピードを生み出す開発」とは 不確実性の高い事業ドメインやフェーズにおいて、 大きく失敗するリスクを最小化するために、ビジネス アイデアを複数の小さな仮説に分解し、それら一つ一 つ検証し実証していくという価値観のもと、この 仮説検証の速度をエンジニアリングで最大化 すること。そのために、必要なインフラ基盤があ り、エンジニア自ら推進することが出来る仕組み があり、その活動の成果が適正に評価されること。 15
51. 51. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する 指標：MAU/継続率/○○率/売上/etc 15
52. 52. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する スペシャリスト （深い専門性） 深める ビジネスへ染み出す エンジニア 広げる どの円にフォーカスしてコミットするかは エンジニアの生き方・価値観そのもの 強制をするものではない
53. 53. cameranでの事例
54. 54. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する ビジネスへ染み出す エンジニア 広げる @kasajei @kusudart 継続率コミット MAUコミット その代わり、 勝手にやらしてもらうよ
55. 55. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する コミット：継続率○○%UP ファンはアーティストの投稿を必ず チェックするのではないか？ 今はそれに気付いていないだけでは ラルクアンシェルのHydeの投稿を 彼の投稿を「like」したことあるセ グメントに通知してあげることで、 リテンションするか計測する Hydeの投稿タイミングで 過去にlikeしたセグメントに対し て、プッシュ通知する機能を実装 ユーザーの継続率があがる 仮説は正しかった、他のセ グメントにもスケールでき るか検証する SQLで作ったセグメントに対して、 指定したトリガで自動でプッシュす るようにする 継続率：○○%達成 cameranでの事例 指標：MAU/継続率/○○率/売上/etc
56. 56. VAMPSにいいね！したけど1ヶ月来訪していないユーザへ VAMPS投稿タイミングで通知
57. 57. TERUにいいね！したけど1ヶ月来訪していないユーザへ TERU投稿タイミングで通知
58. 58. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する 継続率：○○% ファンはアーティストの投稿を必ず チェックするのではないか？ 今はそれに気付いていないだけでは ラルクアンシェルのHydeの投稿を 彼の投稿を「like」したことあるセ グメントに通知してあげることで、 リテンションするか計測する Hydeの投稿タイミングで 過去にlikeしたセグメントに対し て、プッシュ通知する機能を実装 ユーザーの継続率があがる 仮説は正しかった、他のセ グメントにもスケールでき るか検証する SQLで作ったセグメントに対して、 指定したトリガで自動でプッシュす るようにする 継続率：○○%達成 エンジニアがKPIにコミットし、 自分の責任の範囲内で 勝手にサービスをHackし成果を出す 目標達成
59. 59. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する ビジネスへ染み出す エンジニア 広げる @kasajei @kusudart 継続率コミット MAUコミット その代わり、 勝手にやらしてもらうよ
60. 60. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する   打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する ビジネスへ染み出す エンジニア 広げる @kasajei @kusudart 継続率コミット MAUコミット その代わり、 勝手にやらしてもらうよ 成長のエンジン
61. 61. 「ビジネスにおけるスピードを生み出す開発」とは 不確実性の高い事業ドメインやフェーズにおいて、 大きく失敗するリスクを最小化するために、ビジネス アイデアを複数の小さな仮説に分解し、それら一つ一 つ検証し実証していくという価値観のもと、この 仮説検証の速度をエンジニアリングで最大化 すること。そのために、必要なインフラ基盤があ り、エンジニア自ら推進することが出来る仕組み があり、その活動の成果が適正に評価されること。
62. 62. Hackers will be Engines of Growth!!
63. 63. ご静聴ありがとうございました