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
gen
February 10, 2025
Technology
0
10
Four keys改善の 取り組み事例紹介
gen
February 10, 2025
Tweet
Share
More Decks by gen
See All by gen
開発生産性を鈍化させる問題を 正しく捉えるアプローチ
gen87mugi
0
10
可視化から始める 開発生産性向上の取り組み
gen87mugi
0
17
Other Decks in Technology
See All in Technology
[JAWS-UG栃木]地方だからできたクラウドネイティブ事例大公開! / jawsug_tochigi_tachibana
biatunky
0
210
A Hidden Pitfall of K8s DNS with Spring Webflux
musaprg
0
220
プロダクト観点で考えるデータ基盤の育成戦略 / Growth Strategy of Data Analytics Platforms from a Product Perspective
yamamotoyuta
0
420
AWSでRAGを実現する上で感じた3つの大事なこと
ymae
3
860
さいきょうのアーキテクチャを生み出すセンスメイキング
jgeem
0
390
Kubernetes x k6 で負荷試験基盤を開発して 負荷試験を民主化した話 / Kubernetes x k6
sansan_randd
1
520
AIをプロダクトに実装するならAPIで分離しよう 〜タクシーアプリ『GO』のアーキテクチャ実例紹介〜
74th
2
130
依存関係があるコンポーネントは Barrel ファイルでまとめよう
azukiazusa1
2
450
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
2
420
事業継続を支える自動テストの考え方
tsuemura
0
190
[2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例] re:Invent 2024 から見る AWS マルチアカウントガバナンスのこれまでとこれから
0nihajim
0
110
Zenn のウラガワ ~エンジニアのアウトプットを支える環境で Google Cloud が採用されているワケ~ #burikaigi #burikaigi_h
kongmingstrap
19
7.2k
Featured
See All Featured
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
390
Six Lessons from altMBA
skipperchong
27
3.6k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
Speed Design
sergeychernyshev
25
760
YesSQL, Process and Tooling at Scale
rocio
171
14k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
Agile that works and the tools we love
rasmusluckow
328
21k
Building Applications with DynamoDB
mza
93
6.2k
A Philosophy of Restraint
colly
203
16k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
Sansan株式会社 部署 名前 Four keys改善の 取り組み事例紹介 Sansan技術本部 Bill One Engineering
Unit 川元 謙治
写真が入ります 川元 謙治 Sansan株式会社 技術本部 Bill One Engineering Unit SIerやパッケージ開発会社での経験を経て、2022
年にSansanへ中途⼊社。 Sansan株式会社ではWebアプリケーション開発エ ンジニアとしてキャリアをスタートし、現在は Bill OneのCore Businessグループのエンジニアリ ングマネジャーとして、 Bill One 全体の開発⽣産 性向上に向き合っている。
アジェンダ - Four keys改善に取り組む背景 > 拡⼤組織の中でユーザーへの価値提供を最⼤化するために - スループット - 安定性
- リードタイムの改善 > 組織全体での取り組み > チームでの取り組み - 改善結果とまとめ
Four keys改善に取り組む背景
エンジニア組織の成⻑ プロダクト成⻑とともに急拡⼤中 国内SaaSにおいて類を⾒ない速度で成⻑ T2D3とBill Oneの⽐較 組織の規模 スクラム 開発 単独のチーム 初のチーム分割
LeSS Framework をベースに導⼊ ⼈、チームが 急激に増える PdM が 複数⼈に LeSS Hugeをベー スに導⼊
拡⼤組織の中でユーザーへの価値提供を最⼤化するために Four Keysの定義 スループット - 変更のリードタイム: 変更コミットから本番環境で稼働するまでの所要時間 - デプロイ頻度: 本番環境へのリリース頻度
安定性 - 変更失敗率: 意図通り動かないコードをリリースした割合 - 平均修復時間: 障害から復旧するまでにかかる平均の時間
Four Keysの定義 スループット - 変更のリードタイム: 変更コミットから本番環境で稼働するまでの所要時間 - デプロイ頻度: 本番環境へのリリース頻度 安定性
- 変更失敗率: 意図通り動かないコードをリリースした割合 - 平均修復時間: 障害から復旧するまでにかかる平均の時間 拡⼤組織の中でユーザーへ素早く多くの価値を提供するためには 統計的に組織パフォーマンスと 関係があることが立証されており、 「スループット」と「安定性」の 両方を定量的に計測可能な指標を持って、 自ら言語化可能なパフォーマンス改善を 進めることが重要!!
Four Keysの定義 スループット - リードタイム: 変更コミットから本番環境で稼働するまでの所要時間 > 現場のリードタイムの定義としては「オープンからマージまで」をリードタイムとし ている -
デプロイ頻度: 本番環境へのリリース頻度 安定性 - 変更失敗率: 意図通り動かないコードをリリースした割合 - 平均修復時間: 障害から復旧するまでにかかる平均の時間 拡⼤組織の中でユーザーへ素早く多くの価値を提供するためには ユーザーへの価値提供観点において 「スループット」と「安定性」はトレードオフではなく、4指標全て重要!! ただ最も改善による成功体験を得やすく、 他3指標にレバレッジを効かせやすいのが リードタイムの改善だと思っている
リードタイムの改善
リードタイムの改善 組織全体での取り組み リードタイムの中でレバレッジの効くスタッツを選択し、透明性を担保する - 内訳として主にどこで時間が掛かっていて、どこからなら改善着⼿できそうか - これから改善したいチーム(左表)と既に成功体験を得てきているチーム(右表)を⽐較分析する プルリクの分析をチームのふりかえりに根付かせ、検査及び適応を繰り返す - 改善するスタッツを決めたら短い期間(1週間程度)で改善サイクルを回して、定量的な数値改善の成功
体験を得る
リードタイムの改善 チームでの取り組み PRサイズを⼩さくする - レビュー修正内容が理解しやすくなるので、レビュー速度が向上する - PRが⼩さいとWIP(仕掛かり)が溜まりにくく、チーム内で柔軟にタスク優先度変更や引き継ぎができる - レビュアー体験が良ければ、レビュイー側になった場合も⼩さくしようとする好循環が⽣まれる ペアプロ・モブプロを⾏う
- レビューコメントの認識齟齬による⼿戻りやレビュー待ち時間が削減できる - 要点は同期的に合意できているので、⼤きなレビュー変更が発⽣しない - お互いにレビュー観点やコーディング⽅法が学べるといった副次的効果がある チームでPRポリシーを作り、みんなで守る - チーム内で合意形成できていることで、認知負荷の軽減やPR内容の平準化に繋がる - 例1: PRレビューは依存タスクであるため、⾃分の開発タスクより優先度を⾼く実施する - 例2: レビュー着⼿が遅くなりそうであれば、まずはコメントで伝える(場合によってレビュアーを振替える)
改善結果とまとめ
改善結果はどうなったか 各チーム成功体験が少しずつ組織全体に伝播 リードタイム(≒変更のリードタイム)が短くなるにつれて、 プルリク作成数(≒デプロイ頻度)も増加し、⼿触り感のあるパフォーマンス改善を実感できた
Four keys改善の取り組みはリードタイムから着⼿するのがオススメ - PRサイズを⼩さくすると⼀定期間内におけるデプロイ頻度は⾃ずと増える - PR変更内容の理解度が⾼まると、レビューの質が⾼まり、結果的に変更失敗率を 下げることにも繋がる - PRサイズが⼩さいと影響範囲特定しやすく、切り戻し対応時間が短くなるので、 平均修復時間も短くできる
まとめ