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
11
Four keys改善の 取り組み事例紹介
gen
February 10, 2025
Tweet
Share
More Decks by gen
See All by gen
開発生産性を鈍化させる問題を 正しく捉えるアプローチ
gen87mugi
0
13
可視化から始める 開発生産性向上の取り組み
gen87mugi
0
19
Other Decks in Technology
See All in Technology
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
6
56k
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
18k
“自分”を大切に、フラットに。キャリアチェンジしてからの一年 三ヶ月で見えたもの。
maimyyym
0
320
トレードオフスライダーにおける品質について考えてみた
suzuki_tada
3
280
生成AIの利活用を加速させるための取り組み「prAIrie-dog」/ Shibuya_AI_1
visional_engineering_and_design
1
120
マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移
mtpooh
1
380
AWSでRAGを実現する上で感じた3つの大事なこと
ymae
3
870
WAF に頼りすぎない AWS WAF 運用術 meguro sec #1
izzii
0
380
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
410
Amazon Aurora バージョンアップについて、改めて理解する ~バージョンアップ手法と文字コードへの影響~
smt7174
1
420
Enhancing SRE Using AI
yoshiiryo1
1
440
Redshiftを中心としたAWSでのデータ基盤
mashiike
0
120
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Building Applications with DynamoDB
mza
93
6.2k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
390
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
The Cult of Friendly URLs
andyhume
78
6.2k
What's in a price? How to price your products and services
michaelherold
244
12k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.1k
Scaling GitHub
holman
459
140k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Done Done
chrislema
182
16k
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サイズが⼩さいと影響範囲特定しやすく、切り戻し対応時間が短くなるので、 平均修復時間も短くできる
まとめ