Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カウシェで Four Keys の改善を試みた理由
Search
ike
April 25, 2025
Programming
1
180
カウシェで Four Keys の改善を試みた理由
ike
April 25, 2025
Tweet
Share
More Decks by ike
See All by ike
2ヶ月で生産性2倍、お買い物アプリ「カウシェ」4チーム同時改善の取り組み
ike002jp
1
150
Other Decks in Programming
See All in Programming
すべてのコンテキストを、 ユーザー価値に変える
applism118
2
790
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
390
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
980
型付きアクターモデルがもたらす分散シミュレーションの未来
piyo7
0
810
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
240
Enterprise Web App. Development (2): Version Control Tool Training Ver. 5.1
knakagawa
1
120
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
230
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
1
680
Webの外へ飛び出せ NativePHPが切り拓くPHPの未来
takuyakatsusa
2
360
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
200
PHPでWebSocketサーバーを実装しよう2025
kubotak
0
150
C++20 射影変換
faithandbrave
0
530
Featured
See All Featured
Writing Fast Ruby
sferik
628
61k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
60k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
Gamification - CAS2011
davidbonilla
81
5.3k
RailsConf 2023
tenderlove
30
1.1k
Bash Introduction
62gerente
614
210k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Facilitating Awesome Meetings
lara
54
6.4k
Speed Design
sergeychernyshev
32
1k
Transcript
カウシェで Four Keysの改善を試みた理由
池松恭平 / ike @ike002jp 2021/05〜 カウシェ ・バックエンドエンジニア ➝ EM / PdM
➝ CTO 2014/04〜 DeNA ・バックエンドエンジニア / EM
タイトル 「ソーシャルEC」 × 「発⾒型EC」 創業5年を迎え、誰もが⽇常的に使うECとなるべく挑戦中
はじめに • Four KeysをFindy Team+で可視化する ➝ 定量改善のサイクルを回す • この活動を開始‧推進するにあたって、いくつか疑問があった 10.5件/⽇
21.5件/⽇ 4チーム(Backend8名、Mobile5名)で25年1⽉から2ヶ⽉間で⼤きく改善した様⼦
何かというと • Four Keysって本当に上げる意味があるのだろうか? ※ DORAチームが専⾨的に研究したものがベースになっているものの • 「どうやるか」もあるが「なぜやるか」に対するいくつかの疑問
内容 何が疑問だったか どう整理したか (と、整理していく中で参考になった情報)
何が疑問だったか (1) • SPACEとか他にも多数あるが、Four Keysでいいんだっけ? • ユーザー価値を速く、多く届けるのが重要、 少⼈数で事業KPIをどれだけ上げられるか?それを追い求めればよいのでは?
何が疑問だったか (2) • ハックできそう • 数値が適切に改善された、って、どうやれば⾔えるんだろう (ハックとの境界ってどこだ)
何が疑問だったか (3) • 改善に対する費⽤対効果ってどうなる? • 時間投下するからには、事業に紐づくリターンが何かあるはずだが、何になるんだ? (時間削減? 開発者体験向上による組織エンゲージ向上? 外部発信効果?etc)
何が疑問だったか (1) と整理 • 疑問:Four Keys、SPACE、事業KPI? • 整理:"⽣産性"の定義認識と、そのうえで、どのレベルに優先的にフォーカスするか ◦ レベル1は、技術系職種こそが最も中⼼的に責任を果たせる
◦ かつ積極的に果たすべきで、それがあったうえでCPO領域要素が強いレベル3がある ◦ レベル1は、レベル3に取り組むためにも技術組織として必要条件 参考記事:開発⽣産性について議論する前に知っておきたいこと(こちらから上記図は引⽤)
何が疑問だったか (2) と整理 • 疑問:ハック? それとも適切な数値改善? • 整理:指標と、その指標のバックグランドとなっているモデルに基づいた改善アクションを設定できるか ◦ ⼀般論として、ハックできない数値なんてない(売上だってNorth
Startだってハックできる) ◦ Four Keysは「DevOps能⼒ ➝ Four Keys ➝ 組織パフォーマンス」なモデル(どのDevOps能⼒改善するかが重要) ▪ 参考記事:『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいない(以下の図はこちらから引⽤) ▪ 参考図書:LeanとDevOpsの科学
何が疑問だったか (3) • 疑問:費⽤対効果をどう算出? 削減コスト? 組織エンゲージ? 対外PR? • 整理:「時間削減インパクト 」と「価値の⽣み出し構造における位置付け」の2観点
◦ 時間削減は「⼀⼈あたりDeploy数がX%改善 ➝ そのうちのY%は時間削減寄与ありと仮定」などで試算 ◦ 価値の⽣み出し構造 ▪ カウシェ構造は右図 • 参考:CTOの頭の中:技術を財務で表現する (右図はこちらから引⽤) ▪ 施策ヒット率 × 流量 • 流量 ≒ 施策数, 実験回数(図だとG/P) • 流量はFour Keysそのもの
まとめ • Four Keysの改善を試みた理由について紹介 ◦ 会社ごとの違いがあり、位置付けも様々と思うが、カウシェにおける例を紹介 ◦ やる意味はあるだろう、と考えていたが、正直、疑問もあったのが最初 ◦ ⾃分の中で位置付けが整理されたことで、推進はしやすくなった
◦ 推進⽅法は以下を参照 ▪ 2ヶ⽉で⽣産性2倍、お買い物アプリ「カウシェ」4チーム同時改善の取り組み • 採⽤中 ◦ Backend, iOS, Android, ML, PdM, Designer, …