『ベストプラクティスから学ぶ！Four Keys向上へのトライ~夏の開発生産性LT Week~』の登壇資料です。
- イベントURL: https://findy.connpass.com/event/292030/
Faster Pull Request Reviews〜ハイパフォーマンスチームへの道〜
View Slide
# 👨💻 自己紹介- 榎本 敏丸 / X: [@toshimaru_e](https://twitter.com/toshimaru_e)- メドピア株式会社 - 集合知プラットフォーム事業部 基盤開発グループ グループリーダー- 最近のお仕事：分散モノリスアーキテクチャから真のモノリスアーキテクチャを取り戻すべく、技術的負債の解消を中心にやっています。
# 📚 コンテンツPull Requestのレビュー速度を上げるために行った施策をその結果とともに紹介します。1. 何を計測する？1. 実際に行った施策とその結果紹介1. 全体振り返り・まとめ
# 💣 開発生産性の課題感- 「（Four Keysなどの）開発生産性指標を計測したいよね〜」と思いはありつつも、きちんと計測はできていない状況- きちんと定量化できていないので、漠然と「最近デプロイ頻度が減ってるよね〜」とぼやく程度
# 🚀 Findy Team+の導入理由- 開発チームのパフォーマンス・健全性を定量的に計測したい ⏱️- 計測指標を決めて独自にメトリクス収集も可能だがダルい 😰- Findy Team+ 導入 🤗
数値化できないものは改善できない。cf. 推測するな 計測せよ
# ⏱️ 何を計測するか？（1/3）開発生産性指標としては、Four Keys[^1]から考えるのが王道（先ず Four Keys より始めよ）。- **デプロイの頻度**:組織による正常な本番環境へのリリースの頻度- **変更のリードタイム**:commit から本番環境稼働までの所要時間- **変更障害率**:デプロイが原因で本番環境で障害が発生する割合- **サービス復元時間**:組織が本番環境での障害から回復するのにかかる時間
# ⏱️ 何を計測するか？（2/3）GitHubアクティビティから機械的に集計しやすい下記２つからアプローチするのがオススメ。- ⭐️ **デプロイの頻度**- ⭐️ **変更のリードタイム**
# ⏱️ 何を計測するか？（3/3）「**変更のリードタイム**」を計測した際（Findy Team+導入前）に、リードタイムの長いPRを分析すると**レビュー速度**にボトルネックがあると判明した。👉 レビュー速度の改善に着手
# 🏃♂️ なぜレビュー速度は重要か？[^2][コードレビューのスピード \| google-eng-practices-ja](https://fujiharuka.github.io/google-eng-practices-ja/ja/review/reviewer/speed.html)
# 🗓️ 施策タイムライン- 2022年01月: 開発ルールに24時間以内に何らかの反応を返す旨のルールを追加- 2022年02月: レビュー体制の簡易化- 2022年04月: レビュワー指名をGitHub Teamアサインとした- 2022年10月: Findy Team+導入- 2022年11月: Pull Request分割のメリットをチームに展開- 2023年04月: チーム目標として「オープンからレビューまでの平均時間 12時間以内」を組み込んだ
# 💡 レビュールール追加"Google's Engineering Practices"[^2] を参考に、開発ルールに「レビュー依頼されてから24時間以内に何らかの反応を返す」ルールを追加。
## レビュールール追加 結果- 結果: **△**（まずまず）- 👍 レビュワーは遅くとも翌営業日にはレビューを返さなければいけないという意識を植え付けられた- 👎 ルールが破られているケースが散見されたが、チェック機構がなく強制力も働かなかったので、結果的に個々人の努力目標にとどまる
## 💡 レビュー体制の簡易化- Before: （コードの品質を保つために）2名以上のレビュワーからのLGTM/Approveがなければマージ不可 🙅- After: （コードの品質が担保できる）ミドル〜シニアレベルのエンジニアのApproveがあればマージ可 🙆♀️ - 同時に一定スキルのあるメンバーをApprove可能なエンジニアに昇格させ、レビュー人員の冗長化を実施 🧑🤝🧑
## レビュー体制の簡易化 結果- 結果: **◯**（成功）- 👍 「どっちがレビューするんだ...」とお見合い状態になるのがなくなった- 👍 「レビューからApproveまでの時間」が減った
## レビュー体制の簡易化 振り返り- 変更のリードタイム短縮を考えたときに、レビュワー二人体制は明らかに過剰だった（レビュワー二人体制の割にそれがコード品質向上に寄与していたかというと❓が付く）- レビュイーからすると二人のレビュワーからの承認を待たなきゃいけないというのは、かなり心理的負担がデカい
# 💡 GitHub Teamレビューアサイン- Before: GitHub Teamレビュワーアサイン → ランダムレビュワーアサイン → アサインされた人がレビュー- After: GitHub Teamレビュワーアサイン → チームに所属しているエンジニアの誰かが速い者勝ちでレビュー- Why: チームメンバーの忙しさにムラがあり、ランダムレビューアサインで忙しい人にあたるとレビュー待ち時間が突如増えるというレビュワーガチャ要素があった
## GitHub Teamレビューアサイン 結果- 結果: **△〜◯**（そこそこ成功）- 👍 チームで分担してレビューすることができるようになった- 👎 速い者勝ちシステムだと爆速レビュワーが常に勝利するので、結局チームの中でレビュー意識の高い人のレビュー負担が増えただけ説が一部あり
## GitHub Teamレビューアサイン 振り返り- GitHubの`CODEOWNER`機能[^3]と組み合わせると◯ - チームがオーナーシップを持てるコードベースの範囲を定義 - 定義範囲を`CODEOWNER`ファイルに設定し、当該範囲のファイルを触ったときに自動レビュワーアサイン発動 - アサインの手間の省力化、アサイン漏れがなくなる```bash# .gihtub/CODEOWNER 設定例/app/**/x_feature @org/x_feature-team/app/**/y_feature @org/y_feature-team/app/**/z_feature @org/z_feature-team```
# 💡 Findy Team+導入&PR分割- Findy Team+導入（2022年10月）- 担当カスタマーサクセスの方にレビュー速度の課題感を共有、CSの方から「Pull Request分割のすすめ」資料をいただけたのでチームに共有しPR分割を促した 1. PR分割して粒度を小さくすることは、マネージャー/PR作成者/レビュワー全員にメリットがある 1. PR分割はFour Keysにも良い影響がある
# Findy Team+導入&PR分割 結果(1/2)- 結果: **△〜◯**（まずまず成功）- 👍 この頃から長命な巨大Featureブランチは悪、小さいPRこそ正義という考え方がチーム全体に浸透した印象- 👍 小さいPRによりブランチのメンテナンス(rebaseでコード最新化, conflict解消)コストが減った
# Findy Team+導入&PR分割 結果(2/2)- 👍 「オープンからレビューまでの平均時間」が改善
# Findy Team+導入&PR分割 振り返り- フィーチャートグル環境が整っていたことは、PR分割に明確に良い影響を与えた - 機能トグルOFFにしてユーザーに公開しないかたちで小さく変更をリリースできる[^6]- 細かくリリースするための戦略・テクニックもチームに浸透した - 例: URL公開せずバックエンドを先行実装、バッチジョブの実装をバッチ起動しないかたちで先行リリース[^6]: フィーチャートグルは[flipper](https://github.com/flippercloud/flipper) + [filipper-ui](https://www.flippercloud.io/docs/ui) を使って実現している
## 余談: デプロイ頻度も向上⤴️botが作成するRelase Pull Requestのレビュー回数が増加👉 **デプロイ頻度向上**
# 💡 チーム目標に組み込む- Findy Team+導入により数値が追いやすい環境ができたので、「レビュー速度」をチーム目標として追ってみてはどうかと提案- 今期（2023年4月〜）の開発チームの目標として「オープンからレビューまでの平均時間（Weekly）: **12時間以内**」が組み込まれた 🎉
## チーム目標に組み込む 結果（1/2）- 結果: **◎**（大成功）- 👍 個々人の努力目標がチームとして達成すべき目標にレベルアップ- 👍 具体的な数値目標を掲げたことで、今までレビューに消極的だった人も積極的にレビューしてくれるようになった
## チーム目標に組み込む 結果（2/2）- 👍 「来期からレビュー速度を追いましょう」と議論し始めたタイミング（2023年2月頃）で、明らかに「オープンからレビューまでの時間」数値は改善
## チーム目標に組み込む 振り返り- 目標を形骸化させないためにも、毎週の開発定例で目標数値をオーバーしていないか定期確認するのが良い- 「数値化できないものは改善できない。」（本日二回目）
# 🔎 全体結果１レビュワー数向上⤴️ / PR作成数向上⤴️ / フロー効率上昇⤴️
# 🔎 全体結果２(オープンからマージまでの平均時間)- Before: **200** hours- After: **50** hours
# 🔎 全体結果３(DevOps Performance Metrics[^4])- Before: **Medium** Performance- After: **High** Performance → ハイパフォーマンスチーム達成 🎉[^4]: [Google Cloud で実行されている DevOps 組織の有効性を評価する \| Google Cloud 公式ブログ](https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora)
# 💪 全体振り返り・まとめ (1/2)- 努力目標は限界あり、数値目標で設定せよ- Four Keysとかカッコつける前に、開発現場の「当たり前品質」として下記は実現しておくのが◯ - CI（テスト自動化） - CD（デプロイ自動化） - サービス監視（障害の検出）
# 💪 全体振り返り・まとめ (2/2)- プラスαで下記もあると良い - フィーチャートグル環境（PR分割に効く） - SLO[^5]（サービス品質は守る）- やはり優れた開発者体験を提供するにはレビュー速度は重要 - 朝出したPRが当日中にレビューされ翌日にはシップできる安心感 🚢[^5]: [優れた SLO を策定するには : CRE が現場で学んだこと \| Google Cloud 公式ブログ](https://cloud.google.com/blog/ja/products/gcp/building-good-slos-cre-life-lessons)
# ⚡️ 今後の課題 (1/2)- 息を吸うようにレビューをする文化を根付かせたい - レビュー意識の高いレビュワーにレビュー負担が偏りがち- 究極のフロー効率実現のためにはレビューレスな開発チーム - そのためのモブプロ・ペアプロチームみたいのがあっても良さそう
# ⚡️ 今後の課題 (2/2)- Findy Team+でアウトプットの計測はできるが、アウトカム（成果）の計測はできない（Four Keysの限界） - アウトプットがアウトカムにつながったのか別途検証は必要 - アウトプット総量を増やすことは打席を増やす・打率を高めることにつながる（👉 PDCAサイクルの高速化）
# 💬 感想- Findy Team+ CSの方のサポートが強力で助かりました 😇- 今回Findy Team+を使って開発メトリクス収集を行ったが、GitHub Insightsで公式機能としてリードタイム分析が見れると嬉しいところ - [github/issue-metrics](https://github.com/github/issue-metrics)はイマイチだった（今後に期待）- Findy Team+で平均値だけではなく p50/p90/p95 とかも知れると嬉しい 👀
宣伝
toshimaru
bengo4com
rilmayer
comucal
line_developers_tw
is_ryo
wakamatsu_takumu
yoshidashingo
route06
ufried
chiroito
optimisuke
leveragestech
chriscoyier
akosma
ddemaree
zakiwarfel
lauravandoore
jacobian
keithpitt
iamctodd
tanoku
moore
michaelherold
cassininazir