カウシェで Four Keys の改善を試みた理由

Transcript

1. カウシェで Four Keysの改善を試みた理由
2. 池松恭平 / ike @ike002jp 2021/05〜　カウシェ ・バックエンドエンジニア ➝ EM / PdM ➝ CTO 2014/04〜　DeNA ・バックエンドエンジニア / EM
3. タイトル 「ソーシャルEC」 × 「発⾒型EC」 創業5年を迎え、誰もが⽇常的に使うECとなるべく挑戦中
4. はじめに • Four KeysをFindy Team+で可視化する ➝ 定量改善のサイクルを回す • この活動を開始‧推進するにあたって、いくつか疑問があった 10.5件/⽇ 21.5件/⽇ 4チーム（Backend8名、Mobile5名）で25年1⽉から2ヶ⽉間で⼤きく改善した様⼦
5. 何かというと • Four Keysって本当に上げる意味があるのだろうか？ ※ DORAチームが専⾨的に研究したものがベースになっているものの • 「どうやるか」もあるが「なぜやるか」に対するいくつかの疑問
6. 内容 何が疑問だったか どう整理したか （と、整理していく中で参考になった情報）
7. 何が疑問だったか (1) • SPACEとか他にも多数あるが、Four Keysでいいんだっけ？ • ユーザー価値を速く、多く届けるのが重要、 少⼈数で事業KPIをどれだけ上げられるか？それを追い求めればよいのでは？
8. 何が疑問だったか (2) • ハックできそう • 数値が適切に改善された、って、どうやれば⾔えるんだろう （ハックとの境界ってどこだ）
9. 何が疑問だったか (3) • 改善に対する費⽤対効果ってどうなる？ • 時間投下するからには、事業に紐づくリターンが何かあるはずだが、何になるんだ？ （時間削減？ 開発者体験向上による組織エンゲージ向上？ 外部発信効果？etc）
10. 何が疑問だったか (1) と整理 • 疑問：Four Keys、SPACE、事業KPI？ • 整理："⽣産性"の定義認識と、そのうえで、どのレベルに優先的にフォーカスするか ◦ レベル1は、技術系職種こそが最も中⼼的に責任を果たせる ◦ かつ積極的に果たすべきで、それがあったうえでCPO領域要素が強いレベル3がある ◦ レベル1は、レベル3に取り組むためにも技術組織として必要条件 参考記事：開発⽣産性について議論する前に知っておきたいこと（こちらから上記図は引⽤）
11. 何が疑問だったか (2) と整理 • 疑問：ハック？ それとも適切な数値改善？ • 整理：指標と、その指標のバックグランドとなっているモデルに基づいた改善アクションを設定できるか ◦ ⼀般論として、ハックできない数値なんてない（売上だってNorth Startだってハックできる） ◦ Four Keysは「DevOps能⼒ ➝ Four Keys ➝ 組織パフォーマンス」なモデル（どのDevOps能⼒改善するかが重要） ▪ 参考記事：『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいない（以下の図はこちらから引⽤） ▪ 参考図書：LeanとDevOpsの科学
12. 何が疑問だったか (3) • 疑問：費⽤対効果をどう算出？ 削減コスト？ 組織エンゲージ？ 対外PR？ • 整理：「時間削減インパクト 」と「価値の⽣み出し構造における位置付け」の2観点 ◦ 時間削減は「⼀⼈あたりDeploy数がX%改善 ➝ そのうちのY%は時間削減寄与ありと仮定」などで試算 ◦ 価値の⽣み出し構造 ▪ カウシェ構造は右図 • 参考：CTOの頭の中：技術を財務で表現する (右図はこちらから引⽤) ▪ 施策ヒット率 × 流量 • 流量 ≒ 施策数, 実験回数（図だとG/P） • 流量はFour Keysそのもの
13. まとめ • Four Keysの改善を試みた理由について紹介 ◦ 会社ごとの違いがあり、位置付けも様々と思うが、カウシェにおける例を紹介 ◦ やる意味はあるだろう、と考えていたが、正直、疑問もあったのが最初 ◦ ⾃分の中で位置付けが整理されたことで、推進はしやすくなった ◦ 推進⽅法は以下を参照 ▪ 2ヶ⽉で⽣産性2倍、お買い物アプリ「カウシェ」4チーム同時改善の取り組み • 採⽤中 ◦ Backend, iOS, Android, ML, PdM, Designer, …