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

1. エンジニアが成長のエンジンになる日 Recruit Holdings R&D Division Business Development Oﬃce Kuroda Itsuki @i2key SPEED for Enterprise

2. 黒田樹 (@i2key) <= Follow me :-) 前職ではSIerで官公庁系大規模システムのアーキテクト。 Java屋。数多くのデスマを経験。昨年度までは、全世界でシリーズ累計1300万DLのアプリ cameranシリーズの開発全体責任者（開発、採用、組織構築、プロセスetc）でした。また、社内外でリーンスタートアップやアジャイルの登壇とかをたまにしています。現在は、今までの経験やノウハウを使い海外のマイナー出資先スタートアップの日本展開支援をしています。 http://99designs.jp 支援先スタートアップ

3. サービス大ヒット ↓ 増員 ↓ カオス ↓ ギスギス ↓ 鎮火 ↓ やっぱダメ ↓ いいか？リーンにヤレ http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib 総合1位／ベストバリュー賞（満足度1位）／公募賞ありがとうございました！

4. サービス大ヒット ↓ 増員 ↓ カオス ↓ ギスギス ↓ 鎮火 ↓ やっぱダメ ↓ いいか？リーンにヤレ http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib 総合1位／ベストバリュー賞（満足度1位）／公募賞ありがとうございました！この取り組みの裏側ビジネススケール期エンジニアの役割成長に直接的に寄与

5. ビジネスにおけるスピードを生み出す開発

6. 「ビジネスにおけるスピードを生み出す開発」とは不確実性の高い事業ドメインやフェーズにおいて、大きく失敗するリスクを最小化するために、ビジネスアイデアを複数の小さな仮説に分解し、それら一つ一つ検証し実証していくという価値観のもと、この仮説検証の速度をエンジニアリングで最大化すること。そのために、必要なインフラ基盤があり、エンジニア自ら推進することが出来る仕組みがあり、その活動の成果が適正に評価されること。

8. エンジニアが感じるサービス開発現場のモヤモヤプロダクトバックログに起票されるタスクが本当に開発すべきことなのか。やるべき理由はあるのか。その機能をリリースしたあとの成果は機能毎にわかるのか。結果から学びを得ているのか。やっていることはサービスの成長に直結しているのか。

9. そのモヤモヤは実は正しいことが多い

10. 大抵思い込みで盛大にスベる

11. 出会い系サイトを作る ↓ うまく行かない ↓ 動画共有機能は良く使われている ↓ 動画共有サイトにピボット

12. 位置情報チェックインアプリを作る ↓ うまく行かない ↓ 写真共有機能は良く使われている ↓ 写真共有サイトにピボット

13. オンラインゲームを作る ↓ うまく行かない ↓ 写真共有機能は良く使われている ↓ 写真管理共有サービスにピボット

14. 世の中の成功してるサービスの60%以上が、最初のビジネスアイデアを捨てている。市場にだして、初めて分かること多すぎwwwwwwwww 5

15. なぜ？彼らは死なないですんだのか 5

16. 失敗から学びを得ている

17. ビジネスアイデア全てを仮説と捉えて、それらを小さく分割して検証すること効率よく失敗して、効率よく学ぶ考え方

18. 無駄を徹底的に省くこと・思い込みを排除し全てを仮説と捉える・コストに対する学びを最大化する・失敗による損失を最小化する = 不確実性(リスク)を最小化するプロセス成功を保証するプロセスそのために、効率的(例:小さく/短く/安く)に仮説を検証して学びを得る（ことが多い）

19. 例）写真加工アプリにフィルタ購入機能を作ろう！！やりたいことの実装工数は3人月くらいかかりそうです。あなたがこのプロダクトのオーナーならどうしますか？ ①フィルタ購入機能を3人月かけて実装する（一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユーザーの10%に表示して確認し、本当に購入ボタンが押された回数を測定してから開発着手の判断をする。工数は2人日。（本当に購入されるのかのみを検証） ②のほうが無駄の無い判断してるぽい例えばこんな感じ

20. 100円で購入 100円で購入現在開発中です！近日リリース予定です！＜ポップアップ＞ユーザー全体の10%にだけ表示されるボタン

21. 今みたいなのをMVPと言ったりします Minimum Viable Product（検証可能な最小限の製品）。仮説を検証するために必要な最小限の何か。・プロダクト・インタビュースクリプト・説明スライド・ペーパープロトタイピング and so on… 仮説が検証できれば別に完璧な製品である必要はない

22. 仮説立てる->MVPをつくる->測る->学ぶ MVP ビジネスアイデアを仮説として捉えて検証するためのプロセス。仮説検証のためのMVPを Buildしてそれを元にMeasureし、その結果得られたデータから Learnする。つくる測る学ぶ仮説たてる

23. 保有リスク量時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop ウォーターフォール型プロセスあれ？流行らない。よし、機能追加だ！もっと豪華なフィルターを売るぞ！まだまだ機能が足らんぞおおお！マーケットプレイスにすべきだ！！！！フィルター購入機能をつくるぞ！ 3人月

24. 時間仮説検証モデルによるプロセス保有リスク量 2人日

25. Learn Build Build Measure Measure 時間仮説検証モデルによるプロセス保有リスク量 2人日全体の10%のみに出すダミー購入ボタン作る計測した結果、全然クリックされていない需要ないんだね、あぶなかった・・・（リスクがゼロになる）

26. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？良質な仮説検証を回すには、BMLループをゴールから遡り設計をするのがキモ

27. Product Backlog ＜開発タスク＞ 10個ひらめいた！ Product Owner 10個のエンジニアタスク従来のタスクあるあるシャワー浴びながら・・トイレに入りながら・・ ktkr!!!! いやいやいや・・・フィルタを売って売上をあげる！フィルタ購入機能実装

28. Lean Canvas ＜ビジネス仮説＞仮説検証 MVPの設計 Product Backlog ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築（エンジニアタスク） 10個のMVP設計 7個のGetOutOfBuilding （プロダクトオーナータスク） ※別に開発しなくても仮説検証できる仮説検証型タスクエンジニアリング必要エンジニアリング不要フィルタが本当に購入されるのかダミー x 10%のユーザで検証検証用フィルタ購入ダミーボタン実装

29. 従来の Product Backlog 仮説検証型の Product Backlog ・仮説A検証用モック作成・仮説B検証用ダミーボタン実装・検証済み○○機能本実装・検証済み○○機能本実装・リファラル向上改善・登録ファネル改善・計測基盤実装・コホートに対するプッシュ実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装検証用フィルタ購入ダミーボタン実装フィルタ購入機能実装

30. 「ビジネスにおけるスピードを生み出す開発」とは不確実性の高い事業ドメインやフェーズにおいて、大きく失敗するリスクを最小化するために、ビジネスアイデアを複数の小さな仮説に分解し、それら一つ一つ検証し実証していくという価値観のもと、この仮説検証の速度をエンジニアリングで最大化すること。そのために、必要なインフラ基盤があり、エンジニア自ら推進することが出来る仕組みがあり、その活動の成果が適正に評価されること。 10

31. 分析計測リリース A/Bテスト 10 データ収集

32. 仮説検証単位（MVP）毎に効果を検証する検証Aの実装をセグメントAにリリース結果数値をウォッチ検証Bの実装をセグメントBにリリース結果数値をウォッチ検証Cの実装をセグメントCにリリース結果数値をウォッチやったことの単位に結果を見ること全部同時にリリースした場合、合計値でユーザー数などを見ていても何が寄与したのかが見えない。 Sprint Backlog 検証Aの実装検証Bの実装検証Cの実装 10

33. 検証Bを行っているユーザー検証Cを行っているユーザー検証Aを行っているユーザーこのように縦に合計値で見ないほうがよい場合があるこの場合検証Aの効果の影響なのに合計値のみで見ていると判断を謝る混ぜるな危険

34. ・セグメント毎に対して別々の機能をリリース出来るセグメントを自由に作成できる (例：5%のユーザ集合、○○をした人、1ヶ月使ってない人） Feature Toggle, Feature Flipping ・セグメント毎にデータの計測が出来ることコホート分析・同じセグメントに対して複数のパターンの検証が出来る A/Bテスト仮説検証を効果的に行うためのインフラ要件 ※今回説明省略します ※今回説明省略します

35. プランニング ↓ コーディング ↓ テスト・コードレビュー ↓ ステージングリリース ↓ 本番リリース ↓ 何故かわからないけどサービス全体の利用率が上昇している（学びがないから再現性がない）開発環境ステージング環境本番環境仮説検証を意識しない開発フロー

36. 仮説検証を意識した開発フロー開発環境本番環境プランニング ↓ コーディング ↓ テスト・コードレビュー ↓ 検証単位で非公開で本番リリース ↓ 検証単位で開示範囲を制限（チームメンバーだけ） ↓ 検証単位で開示範囲を制限（社員だけ） ↓ 検証単位で全ユーザーのN%に開示検証単位で特定ユーザセグメントに開示 ↓ 検証単位にコホートで効果分析 ↓ 検証単位の改善（A/Bテスト実施） ↓

37. 仮説検証を意識した開発フロー開発環境本番環境プランニング ↓ コーディング ↓ テスト・コードレビュー ↓ 検証単位で非公開で本番リリース ↓ 検証単位で開示範囲を制限（チームメンバーだけ） ↓ 検証単位で開示範囲を制限（社員だけ） ↓ 検証単位で全ユーザーのN%に開示検証単位で特定ユーザセグメントに開示 ↓ 検証単位にコホートで効果分析 ↓ 検証単位の改善（A/Bテスト実施） ↓ LEAN STARTUPが語られるときにエンジニアリングサイドについて何故か触れられることが少ない・・小さく失敗して効率よく学ぶインフラ (一部の方には当たり前かもですが・・）

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. 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-ﬂip/ その他Django関連 https://cookpad.github.io/chanko/ https://github.com/jnunemaker/ﬂipper https://github.com/FetLife/rollout Rollout

40. Permission : ROLE_ADMINPermission : ROLE_USER Feature Flipping for Java

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. 開発チーム 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. 開発チーム 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. 開発チーム 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. 開発チーム 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. 機能追加開発もやるしグロースのための改善もやるけどどうしても改善の優先度が下がりがち成長率を上げるために目標別に専門チームに分離・新規機能追加をやるプロダクトチーム・数値目標を元に既存機能の改善するグロースチームコードベースが大きくなりすぎ改善サイクルとリリースサイクルの不協和音上記に追加して、サービス単位でチーム分割（アーキテクチャも分割）サービス開発全般開発チーム 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. 機能追加開発もやるしグロースのための改善もやるけどどうしても改善の優先度が下がりがち成長率を上げるために目標別に専門チームに分離・新規機能追加をやるプロダクトチーム・数値目標を元に既存機能の改善するグロースチームコードベースが大きくなりすぎ改善サイクルとリリースサイクルの不協和音上記に追加して、サービス単位でチーム分割（アーキテクチャも分割）サービス開発全般開発チーム 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. プロダクトチーム PO Engineer Engineer Designer 機能開発グロース改善グロースチーム Engineer Engineer Designer 仕様の検討 ↓ 設計 ↓ 実装 ↓ テスト ↓ リリース仮説構築 ↓ 検証の設計 ↓ MVPの構築 ↓ 検証 ↓ データ取得 ↓ 結果から学ぶ各チームのエンジニアのフォーカス MVP実装品質 MVPリリース頻度デプロイ回数/日数値目標継続率離脱率コンバージョン率：要件/仕様は決まっている結果を出せば自由目標制約

50. 「ビジネスにおけるスピードを生み出す開発」とは不確実性の高い事業ドメインやフェーズにおいて、大きく失敗するリスクを最小化するために、ビジネスアイデアを複数の小さな仮説に分解し、それら一つ一つ検証し実証していくという価値観のもと、この仮説検証の速度をエンジニアリングで最大化すること。そのために、必要なインフラ基盤があり、エンジニア自ら推進することが出来る仕組みがあり、その活動の成果が適正に評価されること。 15

51. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装する指標：MAU/継続率/○○率/売上/etc 15

52. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装するスペシャリスト（深い専門性）深めるビジネスへ染み出すエンジニア広げるどの円にフォーカスしてコミットするかはエンジニアの生き方・価値観そのもの強制をするものではない

53. cameranでの事例

54. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装するビジネスへ染み出すエンジニア広げる @kasajei @kusudart 継続率コミット MAUコミットその代わり、勝手にやらしてもらうよ

55. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装するコミット：継続率○○%UP ファンはアーティストの投稿を必ずチェックするのではないか？今はそれに気付いていないだけではラルクアンシェルのHydeの投稿を彼の投稿を「like」したことあるセグメントに通知してあげることで、リテンションするか計測する Hydeの投稿タイミングで過去にlikeしたセグメントに対して、プッシュ通知する機能を実装ユーザーの継続率があがる仮説は正しかった、他のセグメントにもスケールできるか検証する SQLで作ったセグメントに対して、指定したトリガで自動でプッシュするようにする継続率：○○%達成 cameranでの事例指標：MAU/継続率/○○率/売上/etc

56. VAMPSにいいね！したけど1ヶ月来訪していないユーザへ VAMPS投稿タイミングで通知

57. TERUにいいね！したけど1ヶ月来訪していないユーザへ TERU投稿タイミングで通知

58. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装する継続率：○○% ファンはアーティストの投稿を必ずチェックするのではないか？今はそれに気付いていないだけではラルクアンシェルのHydeの投稿を彼の投稿を「like」したことあるセグメントに通知してあげることで、リテンションするか計測する Hydeの投稿タイミングで過去にlikeしたセグメントに対して、プッシュ通知する機能を実装ユーザーの継続率があがる仮説は正しかった、他のセグメントにもスケールできるか検証する SQLで作ったセグメントに対して、指定したトリガで自動でプッシュするようにする継続率：○○%達成エンジニアがKPIにコミットし、自分の責任の範囲内で勝手にサービスをHackし成果を出す目標達成

59. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装するビジネスへ染み出すエンジニア広げる @kasajei @kusudart 継続率コミット MAUコミットその代わり、勝手にやらしてもらうよ

60. 検証を設計する（実証条件/実証方法/etc）効果を計測する KPI（数値目標）を設定するリリースするユーザがコンバージョンする仮説をたてる仕様にする設計するユーザーに届くユーザーが使うユーザーが気づく KPI（数値目標）達成指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標データから学ぶ（仮説を修正する打ち手を変える）エンジニアが直接結果をコントロール出来る範囲（コードのみに対峙してる）エンジニアが直接結果をコントロール出来ない範囲（ユーザーの判断という不確実性が介在）テストする実装するビジネスへ染み出すエンジニア広げる @kasajei @kusudart 継続率コミット MAUコミットその代わり、勝手にやらしてもらうよ成長のエンジン

62. Hackers will be Engines of Growth!!

63. ご静聴ありがとうございました

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

Itsuki Kuroda

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