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
2ヶ月で生産性2倍、お買い物アプリ「カウシェ」4チーム同時改善の取り組み
Search
ike
April 17, 2025
Programming
1
190
2ヶ月で生産性2倍、お買い物アプリ「カウシェ」4チーム同時改善の取り組み
ike
April 17, 2025
Tweet
Share
More Decks by ike
See All by ike
カウシェで Four Keys の改善を試みた理由
ike002jp
1
220
Other Decks in Programming
See All in Programming
Oracle Database Technology Night 92 Database Connection control FAN-AC
oracle4engineer
PRO
1
460
Android 16 × Jetpack Composeで縦書きテキストエディタを作ろう / Vertical Text Editor with Compose on Android 16
cc4966
2
250
アセットのコンパイルについて
ojun9
0
130
AIを活用し、今後に備えるための技術知識 / Basic Knowledge to Utilize AI
kishida
22
5.8k
Improving my own Ruby thereafter
sisshiki1969
1
160
「待たせ上手」なスケルトンスクリーン、 そのUXの裏側
teamlab
PRO
0
550
奥深くて厄介な「改行」と仲良くなる20分
oguemon
1
550
print("Hello, World")
eddie
2
530
OSS開発者という働き方
andpad
5
1.7k
AIでLINEスタンプを作ってみた
eycjur
1
230
Navigating Dependency Injection with Metro
zacsweers
3
1k
「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
taitotnk
0
870
Featured
See All Featured
Bash Introduction
62gerente
615
210k
Why Our Code Smells
bkeepers
PRO
339
57k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
920
A better future with KSS
kneath
239
17k
For a Future-Friendly Web
brad_frost
180
9.9k
Designing for Performance
lara
610
69k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
How GitHub (no longer) Works
holman
315
140k
Transcript
2ヶ⽉で⽣産性2倍、 お買い物アプリ「カウシェ」 4チーム同時改善の取り組み
注意:ここでいう “⽣産性2倍” について、最初に補⾜ • ⽣産性には3段階あるといわれているが、そのうちの1段階⽬(仕事量)についての話 ◦ 開発⽣産性について議論する前に知っておきたいこと ◦ https://qiita.com/hirokidaichi/items/53f0865398829bdebef1 •
Four Keysの先⾏指標の、以下にフォーカスして、以下を2倍にしたよ、という話 ◦ ⼀⼈当たりあたりプルリクエスト数
池松恭平 / ike @ike002jp 2021/05〜 カウシェ ・バックエンドエンジニア ➝ EM / PdM
➝ CTO 2014/04〜 DeNA ・バックエンドエンジニア / EM
タイトル "ソーシャルEC" × "発⾒型EC" 創業5年を迎え、誰もが⽇常的に使うECとなるべく挑戦中
内容 ⼈数などの前提 改善結果 取り組み⽅
内容 ⼈数などの前提 改善結果 取り組み⽅
前提 • 25年/1⽉から改善活動を開始 ◦ 2⽉末までの活動を紹介 • 4チームで同時実施 ◦ バックエンド3チーム(8名) ◦
モバイル1チーム(5名) • Four Keys向上を⽬標 ◦ ⼀⼈当たりプルリクエスト数にフォーカス
内容 ⼈数などの前提 改善結果 取り組み⽅
⼀⼈当たりプルリクエスト数(全体) 1.1件/⽇ 2.4件/⽇
Four Keys:デプロイ頻度(全体) 10.5件/⽇ 21.5件/⽇
内容 ⼈数などの前提 改善結果 取り組み⽅
取り組み⽅ • ⽬標数値の設定 • 週次定例とレポート • DevOps能⼒ドリブン
⽬標数値の設定 • なぜ? ◦ ⾼さ設定とその登り⽅のPDCAを回して学習したかった ※ 数値⽬標は、個⼈⽬標には紐づけていない • 決め⽅ ◦
「今が1.1」 ◦ 「半年で同規模組織の上位10%の1.8を⽬指す」 ◦ 「そのために3⽉末には1.5を必達で⽬指す!」 • 背景‧意義‧⽅針は繰り返し説明
背景‧意義‧⽅針 • ⼈数が増える中で⽣産性を⾼めたい ◦ 3ヶ⽉で7⼈ ➝ 13⼈ • 客観的な判断による活動をしたい ◦
システムのモニタリング⽂化 ⇔ フロー効率状態のモニタリング⽂化 • ⽣産性3段階の1段階⽬に、まず、優先的にフォーカスしたい ◦ 「仕事量効率 ≒ フロー効率」はエンジニアこそが⼤半の責任を果たすべき領域 • 絶対にこうやって実現したい ◦ ✕:数値のハックで伸ばす ◯:DevOps能⼒の向上で伸ばす • etc…
週次定例とレポート 週次定例とレポート • ikeと、4チームの各代表の合計5名で、毎週1時間、定例を実施 • なぜ? ◦ 指標改善の習慣(指標確認➝要因と対応の検討➝…)がキモなはず ◦ 4チームの代表と⼀緒に⾛るのがキモなはず
◦ ナレッジの横連携と成果実感で、実⾏⼒UPもあるはず • なので、ike含む全員が以下をレポート ◦ 前回Nextの振り返り ◦ ⼀⼈当たりPR数の移動平均と⽇次平均の現状報告 ◦ 変化理由(と、課題や今後の⾒⽴て)
レポートの例 ※書くのをあまり頑張りすぎない、議論する、という⽅向性で運営していたので、記載は質素⽬
レポートの例
レポートの例
DevOps能⼒ドリブン • ✕ :「プルリク数どうやれば増えるか?」 • ◯:「どのDevOps能⼒がボトルネックになっているか?」 『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいない
https://speakerdeck.com/bonotake/leantodevopsnoke-xue-wokitintojie-du-suru-four-keys-dakeziyajue-dui-motutainakunaruhua?slide=40
「⼩さいバッチ単位の作業」能⼒ • ⼀部の⼈は以下を積極的に⾏っていた ◦ PRの分割(まずDB、次にこのレイヤ、…) ◦ feature flag • それを全員実⾏を促した
⼩さいバッチのためにPRどう分割しているか共有会
DevOps能⼒ドリブンで参考にしているのが以下ページ Cloud Architecture Center / DevOps の能⼒ • できている/できていないの基準がわかりやすく、気付きをもらえる •
https://cloud.google.com/architecture/devops?hl=ja
やってみてどうだったかの定性的な振り返りの⼀部抜粋
まとめ • 4チーム同時進⾏で、⼀⼈当たりPR数は2ヶ⽉で2倍 ◦ 定性的にもポジティブ • 取り組み⽅ ◦ ⽬標数値の設定 ◦
週次定例とレポート ◦ DevOps能⼒ドリブン • 直近課題‧興味 ◦ モバイル開発でのDevOps能⼒(テスト) ◦ 分析、要件定義、設計、QAでのLLM活⽤ • 採⽤中 ◦ Backend, iOS, Android, ML, PdM, Designer, …