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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

# 👨‍💻 自己紹介 - 榎本敏丸 / X: [@toshimaru_e](https://twitter.com/toshimaru_e) - メドピア株式会社 - 集合知プラットフォーム事業部基盤開発グループグループリーダー - 最近のお仕事：分散モノリスアーキテクチャから真のモノリスアーキテクチャを取り戻すべく、技術的負債の解消を中心にやっています。

Slide 3

Slide 3 text

# 📚 コンテンツ Pull Requestのレビュー速度を上げるために行った施策をその結果とともに紹介します。 1. 何を計測する？ 1. 実際に行った施策とその結果紹介 1. 全体振り返り・まとめ

Slide 4

Slide 4 text

# 💣 開発生産性の課題感 - 「（Four Keysなどの）開発生産性指標を計測したいよね〜」と思いはありつつも、きちんと計測はできていない状況 - きちんと定量化できていないので、漠然と「最近デプロイ頻度が減ってるよね〜」とぼやく程度

Slide 5

Slide 5 text

# 🚀 Findy Team+の導入理由 - 開発チームのパフォーマンス・健全性を定量的に計測したい ⏱️ - 計測指標を決めて独自にメトリクス収集も可能だがダルい 😰 - Findy Team+ 導入 🤗

Slide 6

Slide 6 text

数値化できないものは改善できない。 cf. 推測するな計測せよ

Slide 7

Slide 7 text

# ⏱️ 何を計測するか？（1/3）開発生産性指標としては、Four Keys[^1]から考えるのが王道（先ず Four Keys より始めよ）。 - **デプロイの頻度**:組織による正常な本番環境へのリリースの頻度 - **変更のリードタイム**:commit から本番環境稼働までの所要時間 - **変更障害率**:デプロイが原因で本番環境で障害が発生する割合 - **サービス復元時間**:組織が本番環境での障害から回復するのにかかる時間

Slide 8

Slide 8 text

# ⏱️ 何を計測するか？（2/3） GitHubアクティビティから機械的に集計しやすい下記２つからアプローチするのがオススメ。 - ⭐️ **デプロイの頻度** - ⭐️ **変更のリードタイム**

Slide 9

Slide 9 text

# ⏱️ 何を計測するか？（3/3）「**変更のリードタイム**」を計測した際（Findy Team+導入前）に、リードタイムの長いPRを分析すると**レビュー速度**にボトルネックがあると判明した。👉 レビュー速度の改善に着手

Slide 10

Slide 10 text

# 🏃‍♂️ なぜレビュー速度は重要か？[^2] [コードレビューのスピード \| google-eng-practices-ja](https://fujiharuka.github.io/google-eng-practices-ja/ja/review/reviewer/speed.html)

Slide 11

Slide 11 text

# 🗓️ 施策タイムライン - 2022年01月: 開発ルールに24時間以内に何らかの反応を返す旨のルールを追加 - 2022年02月: レビュー体制の簡易化 - 2022年04月: レビュワー指名をGitHub Teamアサインとした - 2022年10月: Findy Team+導入 - 2022年11月: Pull Request分割のメリットをチームに展開 - 2023年04月: チーム目標として「オープンからレビューまでの平均時間 12時間以内」を組み込んだ

Slide 12

Slide 12 text

# 💡 レビュールール追加 "Google's Engineering Practices"[^2] を参考に、開発ルールに「レビュー依頼されてから24時間以内に何らかの反応を返す」ルールを追加。

Slide 13

Slide 13 text

## レビュールール追加結果 - 結果: **△**（まずまず） - 👍 レビュワーは遅くとも翌営業日にはレビューを返さなければいけないという意識を植え付けられた - 👎 ルールが破られているケースが散見されたが、チェック機構がなく強制力も働かなかったので、結果的に個々人の努力目標にとどまる

Slide 14

Slide 14 text

## 💡 レビュー体制の簡易化 - Before: （コードの品質を保つために）2名以上のレビュワーからのLGTM/Approveがなければマージ不可 🙅 - After: （コードの品質が担保できる）ミドル〜シニアレベルのエンジニアのApproveがあればマージ可 🙆‍♀️ - 同時に一定スキルのあるメンバーをApprove可能なエンジニアに昇格させ、レビュー人員の冗長化を実施 🧑‍🤝‍🧑

Slide 15

Slide 15 text

## レビュー体制の簡易化結果 - 結果: **◯**（成功） - 👍 「どっちがレビューするんだ...」とお見合い状態になるのがなくなった - 👍 「レビューからApproveまでの時間」が減った

Slide 16

Slide 16 text

## レビュー体制の簡易化振り返り - 変更のリードタイム短縮を考えたときに、レビュワー二人体制は明らかに過剰だった（レビュワー二人体制の割にそれがコード品質向上に寄与していたかというと❓が付く） - レビュイーからすると二人のレビュワーからの承認を待たなきゃいけないというのは、かなり心理的負担がデカい

Slide 17

Slide 17 text

# 💡 GitHub Teamレビューアサイン - Before: GitHub Teamレビュワーアサイン → ランダムレビュワーアサイン → アサインされた人がレビュー - After: GitHub Teamレビュワーアサイン → チームに所属しているエンジニアの誰かが速い者勝ちでレビュー - Why: チームメンバーの忙しさにムラがあり、ランダムレビューアサインで忙しい人にあたるとレビュー待ち時間が突如増えるというレビュワーガチャ要素があった

Slide 18

Slide 18 text

## GitHub Teamレビューアサイン結果 - 結果: **△〜◯**（そこそこ成功） - 👍 チームで分担してレビューすることができるようになった - 👎 速い者勝ちシステムだと爆速レビュワーが常に勝利するので、結局チームの中でレビュー意識の高い人のレビュー負担が増えただけ説が一部あり

Slide 19

Slide 19 text

## 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 ```

Slide 20

Slide 20 text

# 💡 Findy Team+導入&PR分割 - Findy Team+導入（2022年10月） - 担当カスタマーサクセスの方にレビュー速度の課題感を共有、CSの方から「Pull Request分割のすすめ」資料をいただけたのでチームに共有しPR分割を促した 1. PR分割して粒度を小さくすることは、マネージャー/PR作成者/レビュワー全員にメリットがある 1. PR分割はFour Keysにも良い影響がある

Slide 21

Slide 21 text

# Findy Team+導入&PR分割結果(1/2) - 結果: **△〜◯**（まずまず成功） - 👍 この頃から長命な巨大Featureブランチは悪、小さいPRこそ正義という考え方がチーム全体に浸透した印象 - 👍 小さいPRによりブランチのメンテナンス(rebaseでコード最新化, conflict解消)コストが減った

Slide 22

Slide 22 text

# Findy Team+導入&PR分割結果(2/2) - 👍 「オープンからレビューまでの平均時間」が改善

Slide 23

Slide 23 text

# Findy Team+導入&PR分割振り返り - フィーチャートグル環境が整っていたことは、PR分割に明確に良い影響を与えた - 機能トグルOFFにしてユーザーに公開しないかたちで小さく変更をリリースできる[^6] - 細かくリリースするための戦略・テクニックもチームに浸透した - 例: URL公開せずバックエンドを先行実装、バッチジョブの実装をバッチ起動しないかたちで先行リリース [^6]: フィーチャートグルは[flipper](https://github.com/flippercloud/flipper) + [filipper-ui](https://www.flippercloud.io/docs/ui) を使って実現している

Slide 24

Slide 24 text

## 余談: デプロイ頻度も向上⤴️ botが作成するRelase Pull Requestのレビュー回数が増加 👉 **デプロイ頻度向上**

Slide 25

Slide 25 text

# 💡 チーム目標に組み込む - Findy Team+導入により数値が追いやすい環境ができたので、「レビュー速度」をチーム目標として追ってみてはどうかと提案 - 今期（2023年4月〜）の開発チームの目標として「オープンからレビューまでの平均時間（Weekly）: **12時間以内**」が組み込まれた 🎉

Slide 26

Slide 26 text

## チーム目標に組み込む結果（1/2） - 結果: **◎**（大成功） - 👍 個々人の努力目標がチームとして達成すべき目標にレベルアップ - 👍 具体的な数値目標を掲げたことで、今までレビューに消極的だった人も積極的にレビューしてくれるようになった

Slide 27

Slide 27 text

## チーム目標に組み込む結果（2/2） - 👍 「来期からレビュー速度を追いましょう」と議論し始めたタイミング（2023年2月頃）で、明らかに「オープンからレビューまでの時間」数値は改善

Slide 28

Slide 28 text

## チーム目標に組み込む振り返り - 目標を形骸化させないためにも、毎週の開発定例で目標数値をオーバーしていないか定期確認するのが良い - 「数値化できないものは改善できない。」（本日二回目）

Slide 29

Slide 29 text

# 🔎 全体結果１レビュワー数向上⤴️ / PR作成数向上⤴️ / フロー効率上昇⤴️

Slide 30

Slide 30 text

# 🔎 全体結果２(オープンからマージまでの平均時間) - Before: **200** hours - After: **50** hours

Slide 31

Slide 31 text

# 🔎 全体結果３(DevOps Performance Metrics[^4]) - Before: **Medium** Performance - After: **High** Performance → ハイパフォーマンスチーム達成 🎉 ![inline](./devops-perf.png) [^4]: [Google Cloud で実行されている DevOps 組織の有効性を評価する \| Google Cloud 公式ブログ](https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora)

Slide 32

Slide 32 text

# 💪 全体振り返り・まとめ (1/2) - 努力目標は限界あり、数値目標で設定せよ - Four Keysとかカッコつける前に、開発現場の「当たり前品質」として下記は実現しておくのが◯ - CI（テスト自動化） - CD（デプロイ自動化） - サービス監視（障害の検出）

Slide 33

Slide 33 text

# 💪 全体振り返り・まとめ (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)

Slide 34

Slide 34 text

# ⚡️ 今後の課題 (1/2) - 息を吸うようにレビューをする文化を根付かせたい - レビュー意識の高いレビュワーにレビュー負担が偏りがち - 究極のフロー効率実現のためにはレビューレスな開発チーム - そのためのモブプロ・ペアプロチームみたいのがあっても良さそう

Slide 35

Slide 35 text

# ⚡️ 今後の課題 (2/2) - Findy Team+でアウトプットの計測はできるが、アウトカム（成果）の計測はできない（Four Keysの限界） - アウトプットがアウトカムにつながったのか別途検証は必要 - アウトプット総量を増やすことは打席を増やす・打率を高めることにつながる（👉 PDCAサイクルの高速化）

Slide 36

Slide 36 text

# 💬 感想 - Findy Team+ CSの方のサポートが強力で助かりました 😇 - 今回Findy Team+を使って開発メトリクス収集を行ったが、GitHub Insightsで公式機能としてリードタイム分析が見れると嬉しいところ - [github/issue-metrics](https://github.com/github/issue-metrics)はイマイチだった（今後に期待） - Findy Team+で平均値だけではなく p50/p90/p95 とかも知れると嬉しい 👀

Slide 37

Slide 37 text

宣伝