Faster Pull Request Reviews 〜ハイパフォーマンスチームへの道〜 / Faster Pull Request Reviews

『ベストプラクティスから学ぶ！Four Keys向上へのトライ~夏の開発生産性LT Week~』の登壇資料です。

- イベントURL: https://findy.connpass.com/event/292030/

Transcript

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