本記事は READYFOR 株式会社の READYFOR Advent Calendar 2024 の4日目です。
昨日は @makkinry222 の 「施策効果の可視化に挑むPMの試行錯誤 12選」 でした。
この記事の3行まとめ
- READYFORでは、GitHubのPullRequestからFourKeysの「デプロイ頻度」「リードタイム」を計測・活用し、開発生産性向上を目指してきました
- 実際にGitHub GraphQL APIを利用してPullRequestデータを多角的に分析する方法を簡単に説明します
- 分析の結果とそれがどう役立つのか、考えてみたことを共有します
はじめに
こんにちは！READYFORでエンジニアリングマネージャーをやっておりますtoyocです。
今年は「開発生産性」が話題にあがることの多い年だったような気がしていますが皆さんの周りはいかがでしたでしょうか？
弊社では3年前からFourKeys（特に「デプロイ頻度」と「リードタイム」）の測定を行っており、開発生産性向上の取り組みの主要指標としてきました。
これらの測定はGithubのPullRequestを分析して行っているのですが、この記事ではどうやって計測しているのかを簡単に説明して、いろんな切り口で分析を試みようと思います。
PullRequestを分析できる様にするまで
1. GitHubのAPIから情報取得
今回は「GitHub GraphQL API」からデータを取得しました。（APIの叩き方は公式ドキュメントを見ていただくのが正確だと思うので割愛します。）
呼び出しに使うクエリーはsearch です。こちらを利用することでリポジトリを跨いだ検索ができ、その検索クエリはGitHubサイト上の検索と同じ構文が利用できるため、確認しやすいという利点があります。
具体的にPullRequestのどんな情報が取得できるかはPullRequestオブジェクトの説明を見ていただくと概ね理解できるかと思います。自分がどんな分析をしたいか、どんな情報を取得したいか、こちらのドキュメントを眺めながら考えていただいてもいいかもしれません。
2. データの精査と加工
APIから取得した情報をそのまま格納すると場合によってはとても膨大で扱いづらいものになるかもしれません。
保存する前に前処理としてAPIクエリーで絞りきれなかったものの除去と、分析しやすい形への加工を行いました。
例えば自分の場合は、PullRequestのレビュアーからbotユーザーを取り除いたり、変更ファイルを変更ディレクトリにまとめなおしました。
3. データの保存と可視化
2で調整したデータを実際に保存し、表やグラフで確認します。弊社ではBigQueryに保存してRedashで可視化しています。（他の方法として、Googleの環境であればSpreadSheetに保存してLooker Studioで可視化する方法も試したのですが、データ量が多くてロードに時間がかかってしまい諦めました）
いろんな切り口で分析してみる
そんなこんなで分析の準備が整ったらいろんな観点で分析してみます。ここではREADYFORのPullRequestを分析してみた例をペタペタ貼りつつそこから何がわかりそうかを紹介します。（数字やリポジトリ名など出せない情報があるため雰囲気になってしまいますが…）
リポジトリごと
リポジトリごとのPR数
その時々の施策や方針によってどのリポジトリの変更が活発なのかの変遷を見ることができます。保守が全くされてないリポジトリの存在に気づけるかもしれませんね。
AuthorごとのPR数の標準偏差
PullRequestのAuthorごとの標準偏差を見ることで、あるリポジトリを変更する人が一部に偏っているか、あるいはさまざまな人の手が入っているのか、属人性の有無が確認できます。
ドメインごと
ドメインごとのPR数
弊社のバックエンドではビジネスロジックやドメイン知識をドメインごとに切ったディレクトリ内へ分けて管理しています。（詳しく書くとそれで1記事書けてしまうので別の機会に🙏）
そのディレクトリ内の変更差分があるPR数を集計しています。どのドメインに注力していたのか振り返るのに役立ちそうです。Authorと組み合わせると誰がどのドメインに詳しいか、というような属人性も見られるかもしれません。
ロールごと
各ロールごとの平均PR数
人をロールごとにまとめて平均PR数を集計しています。役割によってどれだけアウトプットに違いが出ているか全体像を把握できるかもしれません。
（READYFORでは複数の開発チームの中にそれぞれチームリードとメンバーがおり、それとは別に横断的に技術的なリーダーシップも担う役割としてテックリードがおります）
リードタイム
初回レビューリードタイム
PRをPublishしてから最初にレビューされるまでの時間になります。最初に触れたFourKeysでも「リードタイム」を測定していますが、こちらはPRを作成してからマージするまでの時間になります。この「リードタイム」の改善を考えるときに「初回レビューリードタイム」を測定しておくと問題の切り分けや改善策の考案に役立ちそうです。
まとめ
PullRequestを分析してみようと手を出してみたら色々な観点で分析できて沼にハマりましたが楽しかったです。比較的簡単に組織全体の開発の傾向やコンディションを測ることができたので、ぜひ皆さんも自分の組織やリポジトリのPRを分析してみてはいかがでしょうか。
明日はREADYFOR Advent Calendar 2024
の5日目、 @omnis さんによる記事です。お楽しみに！