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
12
可視化から始める 開発生産性向上の取り組み
gen87mugi
0
18
Other Decks in Technology
See All in Technology
Power BI は、レポート テーマにこだわろう!テーマのティア表付き
ohata_ds
0
140
Amazon Location Serviceを使ってラーメンマップを作る
ryder472
2
180
Bounded Context: Problem or Solution?
ewolff
1
200
これからSREになる人と、これからもSREをやっていく人へ
masayoshi
4
3.7k
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
120
自動と手動の両輪で開発するデータクレンジング
estie
2
170
Classmethod AI Talks(CATs) #14 司会進行スライド(2025.01.31) / classmethod-ai-talks-aka-cats_moderator-slides_vol14_2025-01-31
shinyaa31
0
100
地方企業がクラウドを活用するヒント
miu_crescent
PRO
1
120
マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移
mtpooh
1
380
What's New in OpenShift 4.18
redhatlivestreaming
0
720
クラウドネイティブ時代を乗り越えるためのオブザーバビリティ(可観測性)ことはじめ_CloudNative-Observability
tkhresk
0
110
ゆもつよがこの30年間自ら経験してきたQA、テストの歴史と未来
ymty
3
600
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Building Applications with DynamoDB
mza
93
6.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
The Language of Interfaces
destraynor
156
24k
A designer walks into a library…
pauljervisheath
205
24k
Agile that works and the tools we love
rasmusluckow
328
21k
Into the Great Unknown - MozCon
thekraken
34
1.6k
Faster Mobile Websites
deanohume
306
31k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
530
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
Adopting Sorbet at Scale
ufuk
74
9.2k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
230
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サイズが⼩さいと影響範囲特定しやすく、切り戻し対応時間が短くなるので、 平均修復時間も短くできる
まとめ