Four keys改善の 取り組み事例紹介

Transcript

1. Sansan株式会社 部署 名前 Four keys改善の 取り組み事例紹介 Sansan技術本部 Bill One Engineering Unit 川元 謙治
2. 写真が入ります 川元 謙治 Sansan株式会社 技術本部 Bill One Engineering Unit SIerやパッケージ開発会社での経験を経て、2022 年にSansanへ中途⼊社。 Sansan株式会社ではWebアプリケーション開発エ ンジニアとしてキャリアをスタートし、現在は Bill OneのCore Businessグループのエンジニアリ ングマネジャーとして、 Bill One 全体の開発⽣産 性向上に向き合っている。
3. アジェンダ - Four keys改善に取り組む背景 > 拡⼤組織の中でユーザーへの価値提供を最⼤化するために - スループット - 安定性 - リードタイムの改善 > 組織全体での取り組み > チームでの取り組み - 改善結果とまとめ
4. Four keys改善に取り組む背景
5. エンジニア組織の成⻑ プロダクト成⻑とともに急拡⼤中 国内SaaSにおいて類を⾒ない速度で成⻑ T2D3とBill Oneの⽐較 組織の規模 スクラム 開発 単独のチーム 初のチーム分割 LeSS Framework をベースに導⼊ ⼈、チームが 急激に増える PdM が 複数⼈に LeSS Hugeをベー スに導⼊
6. 拡⼤組織の中でユーザーへの価値提供を最⼤化するために Four Keysの定義 スループット - 変更のリードタイム: 変更コミットから本番環境で稼働するまでの所要時間 - デプロイ頻度: 本番環境へのリリース頻度 安定性 - 変更失敗率: 意図通り動かないコードをリリースした割合 - 平均修復時間: 障害から復旧するまでにかかる平均の時間
7. Four Keysの定義 スループット - 変更のリードタイム: 変更コミットから本番環境で稼働するまでの所要時間 - デプロイ頻度: 本番環境へのリリース頻度 安定性 - 変更失敗率: 意図通り動かないコードをリリースした割合 - 平均修復時間: 障害から復旧するまでにかかる平均の時間 拡⼤組織の中でユーザーへ素早く多くの価値を提供するためには 統計的に組織パフォーマンスと 関係があることが立証されており、 「スループット」と「安定性」の 両方を定量的に計測可能な指標を持って、 自ら言語化可能なパフォーマンス改善を 進めることが重要！！
8. Four Keysの定義 スループット - リードタイム: 変更コミットから本番環境で稼働するまでの所要時間 > 現場のリードタイムの定義としては「オープンからマージまで」をリードタイムとし ている - デプロイ頻度: 本番環境へのリリース頻度 安定性 - 変更失敗率: 意図通り動かないコードをリリースした割合 - 平均修復時間: 障害から復旧するまでにかかる平均の時間 拡⼤組織の中でユーザーへ素早く多くの価値を提供するためには ユーザーへの価値提供観点において 「スループット」と「安定性」はトレードオフではなく、４指標全て重要！！ ただ最も改善による成功体験を得やすく、 他３指標にレバレッジを効かせやすいのが リードタイムの改善だと思っている
9. リードタイムの改善
10. リードタイムの改善 組織全体での取り組み リードタイムの中でレバレッジの効くスタッツを選択し、透明性を担保する - 内訳として主にどこで時間が掛かっていて、どこからなら改善着⼿できそうか - これから改善したいチーム(左表)と既に成功体験を得てきているチーム(右表)を⽐較分析する プルリクの分析をチームのふりかえりに根付かせ、検査及び適応を繰り返す - 改善するスタッツを決めたら短い期間(1週間程度)で改善サイクルを回して、定量的な数値改善の成功 体験を得る
11. リードタイムの改善 チームでの取り組み PRサイズを⼩さくする - レビュー修正内容が理解しやすくなるので、レビュー速度が向上する - PRが⼩さいとWIP(仕掛かり)が溜まりにくく、チーム内で柔軟にタスク優先度変更や引き継ぎができる - レビュアー体験が良ければ、レビュイー側になった場合も⼩さくしようとする好循環が⽣まれる ペアプロ・モブプロを⾏う - レビューコメントの認識齟齬による⼿戻りやレビュー待ち時間が削減できる - 要点は同期的に合意できているので、⼤きなレビュー変更が発⽣しない - お互いにレビュー観点やコーディング⽅法が学べるといった副次的効果がある チームでPRポリシーを作り、みんなで守る - チーム内で合意形成できていることで、認知負荷の軽減やPR内容の平準化に繋がる - 例1: PRレビューは依存タスクであるため、⾃分の開発タスクより優先度を⾼く実施する - 例2: レビュー着⼿が遅くなりそうであれば、まずはコメントで伝える（場合によってレビュアーを振替える）
12. 改善結果とまとめ
13. 改善結果はどうなったか 各チーム成功体験が少しずつ組織全体に伝播 リードタイム(≒変更のリードタイム)が短くなるにつれて、 プルリク作成数(≒デプロイ頻度)も増加し、⼿触り感のあるパフォーマンス改善を実感できた
14. Four keys改善の取り組みはリードタイムから着⼿するのがオススメ - PRサイズを⼩さくすると⼀定期間内におけるデプロイ頻度は⾃ずと増える - PR変更内容の理解度が⾼まると、レビューの質が⾼まり、結果的に変更失敗率を 下げることにも繋がる - PRサイズが⼩さいと影響範囲特定しやすく、切り戻し対応時間が短くなるので、 平均修復時間も短くできる まとめ