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
Deployment Painをなくそう
Search
jimpei
October 06, 2023
Programming
3
650
Deployment Painをなくそう
開発生産性LT Night in 福岡
https://findy.connpass.com/event/296381/
jimpei
October 06, 2023
Tweet
Share
More Decks by jimpei
See All by jimpei
リモートだからこそ 懸念だし1on1
jimpei
3
660
文化が生産性を作る
jimpei
3
850
「コードがむずかしい」からの脱却
jimpei
43
19k
Other Decks in Programming
See All in Programming
[FEConf 2025] 모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년
mmmaxkim
0
1.4k
Testing Trophyは叫ばない
toms74209200
0
180
Claude Codeで挑むOSSコントリビュート
eycjur
0
190
Oracle Database Technology Night 92 Database Connection control FAN-AC
oracle4engineer
PRO
1
360
個人軟體時代
ethanhuang13
0
290
CSC305 Summer Lecture 12
javiergs
PRO
0
130
Improving my own Ruby thereafter
sisshiki1969
1
150
UbieのAIパートナーを支えるコンテキストエンジニアリング実践
syucream
2
800
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
130
Jakarta EE Core Profile and Helidon - Speed, Simplicity, and AI Integration
ivargrimstad
0
300
時間軸から考えるTerraformを使う理由と留意点
fufuhu
8
3.7k
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
3
1k
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
KATA
mclloyd
32
14k
Optimizing for Happiness
mojombo
379
70k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Rails Girls Zürich Keynote
gr2m
95
14k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Navigating Team Friction
lara
189
15k
Faster Mobile Websites
deanohume
309
31k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
800
Transcript
1 Deployment Painをなくそう 2023.10.06 開発生産性LT Night in 福岡 @jimpei
2 SIer -> Yahoo! JAPAN -> mercari (2021/08)
Help Center Team Software Engineer / Tech Lead 濱村 甚平(@jinpeih)
3 Deployment Painとは 今日話すこと 自チームの状態 Deploy頻度を計測する意味とは 02 03 01
4 Deployment Painをなくそう
5 Deployにどれぐらい抵抗がありますか?
6 Deployにどれぐらい抵抗があるか 3ヶ月ぶりに20本分の機能改修差分を リリース手順書とチェックリストを作って 手動で2人体制で2時間かけて Deploy Deployが怖い、負担、面倒に感じる 例えば...
7 そもそもDeployment Painとは • コードを本番環境にプッシュする際に感じる恐怖や不安の尺度 • デプロイが簡単で苦痛を伴わず、むしろ破壊的である度合い これが大きい場合、ソフトウェアの提供パフォーマンス、組織のパフォーマンス、組織 文化が低い可能性 ソフトウェアを迅速かつ安定して提供する能力を向上させる技術的なプラクティスは、
これ(本番Deployのストレスと不安)も軽減する https://dora.dev/devops-capabilities/cultural/wellbeing/ DORAによると
8 チームの状態や取り組み
9 チームとプロダクト紹介 チーム構成 • Engineering Manager(EM): 1人 • Product Manager(PdM):
1人 • Software Engineer ◦ FE: 1人(+1人) ◦ BE: 2人 • Tech Lead、Scrum Masterはメンバーで兼任 • FE/BEと分けているがクロスファンクショナルにタスクを取ることもある Help Center: お客さまの疑問やお困りごとの解消のための体験を提供する
10 Deploy数推移(2022/01 ~ 2023/10) 年間約500回Deploy (42/month, 2/day) ・mainブランチにマージ後リリースタ グを つけることによりDeploy ・立ち上げによるフェーズに左右され てい
る ・Four Key的にはEliteレベル 2022 2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期 年間約500回Deploy (42/month, 2/day)
11 Deploy数推移(2022/01 ~ 2023/10) ・フェーズごとにHelpに入って もらっていたので結構変動している ・立ち上げによるフェーズに左右され てい る エンジニア推移 2022
2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期
12 Deploy数推移(2022/01 ~ 2023/10) ・D/D/Dが0.1以上あれば健全らしい ・向上してきているというよりは フェー ズによって変動している ・改善期に入って安定してきている ・改善期より前は、大きな要件設計や技術 的な落とし込みにリソースを使っていた
Deploy / Day / Developer 2022 2023 | 初期開発 機能拡充のための 設計期 機能拡充開発期 改善期
13 チームの状態 • 技術 ◦ 自動テストへの信頼(+ ベースとなるよい設計 ◦ 監視への信頼 ◦
Deploy容易性(はやい・かんたん) ◦ リカバリ容易性(はやい・かんたん) • プロセス・組織 ◦ タスクが単一でリリース可能な粒度になっている ◦ チームで意思決定して(都度承認なしで)リリースできる • メンタル ◦ Deployする方が安心、逆にDeployの間が空くと怖い
14 Deploy頻度を計測する意味とは
15 Deploy頻度は正義か チーム構成 • Engineering Manager: 1人 • “Deploy頻度をあげるため” の取り組みはなにもしていない
• ただ”安全で早くDeployし続けることできる環境”を意識している • チームの健康診断的に使う ◦ 数値が変化したときになにか問題が起きていないのかチェックする 計測はしているが、目標にはしていない
16 なぜDeployしやすい環境を求めるのか チーム構成 • Engineering Manager: 1人 • DARAでは、Deployment PainはWellbeingのページにかかれている
◦ これが組織のパフォーマンスを向上させると信じてる Deployしやすい環境が、エンジニアの開発生産性をあげる
17 なぜエンジニアの開発生産性をあげるのか チーム構成 • Engineering Manager: 1人 素早く価値提供し、ビジネス貢献するため
18 Deploy頻度の高さは、価値提供の大きさなのか チーム構成 • Engineering Manager: 1人 • なにが一番の価値提供になるのかはわからない •
100回のDeployより、1回のDeployの方がインパクトが大きいこともある • 継続して価値提供するために、とにかく打席(仮説検証)を創出する 直接結びつくことはない
19 まとめ
20 まとめ チーム構成 • Engineering Manager: 1人 • Deploy頻度の数値が最終目標ではない •
なりたい姿をイメージして、その状態の定量的な指標の一つとして定義 • Deploy回数を計測する→数値を見て状態に気づく→Painはなにか?を探る なぜ改善する必要があるのか • 仮説検証をたくさん早く回すために開発生産性をあげたい ◦ 開発生産性をあげるために、Deployment Painをなくしたい Deployment Painがない環境を目指そう なりたい姿・状態をイメージして、改善していく
21 おわり 採用してます!
22 開発フロー Development → PR → Review → Merge to
main branch → Deploy to DEV → Release Tag → Deploy to Production • 基本的にmain branchにマージ = 本番Deployする ◦ いくつかのPRがまとめてDeployされることもある ◦ チケットのサイズやPRのサイズを調整して細かく開発&レビュー&リリース する ◦ まだ公開できない機能などはFeatureFlagを使って非公開状態でリリース する(DEV環境でのみ公開される) • 本番Deployしたものは翌日の朝会でデモ(ほぼ毎日 • 朝会にPdMもチームメンバーとして参加しているので常に合意が取れている状 態 詳細はチームメンバーのスライドで
23 チケットサイズ • 改修内容をできるだけ細かな価値提供サイズに分解しチケットを細かくする ◦ PRはさらに適切で小さな単位で作ってReview&Deployする 例えば... 何かの管理画面を作る場合 • 管理画面を開くことができる
• 管理画面で情報を取得できる(&閲覧できる) • 管理画面で情報を更新できる • など… できるようになること単位で作っていく(ケースバイケースではある
24 参考 https://engineering.mercari.com/blog/entry/20221215-devstats/ https://speakerdeck.com/myaake/fu-gang-falsecxptimufalseshao-jie-t okai-fa-falsegong-fu