はじめに
この記事は カオナビ Advent Calendar 2025 シリーズ3の2日目です。
はじめまして、今年の9月に入社したフロントエンドのkamabokoです。
私が所属するカオナビ労務には複数のチームがあるのですが、自分はその中の1チーム（自分を含めて開発メンバーが4名所属している）で開発しています。
最近、開発メンバーと雑談していた時に「Claude Codeとglabをかけ合わせて使ったら、レビューやMR作成作業の一部を任せられるようになって、とても良かった」という話題がありました。
AIやツールをかけ合わせて使うことで、アイディア次第で様々なことができるようになるという話は個人的にもとても興味が湧き、自分もなにかできないかなぁと考えてみることにしました。
そこで（既に事例はあるかもしれないですが）、チームの生産性を改善するためのデータ取得や分析を試してみることにしました。（なんちゃってFour Keysのようなイメージ）
目的
今回着目したのは、チームパフォーマンスの計測をするにあたり発生する「数値を取得するまでの工数」を削減することです。カジュアルに計測できることで、「試しにやってみたい」というニーズに応えられたり、導入のハードルを少しでも下げられればと考えました。
使用するツール
- Claude Code
- GitLab CLI（glab）
データ取得と分析
プロンプト
今回実際に利用したプロンプトを添付します（一部情報は記事用に伏せています）。
プロンプトの作成ですが、やりたいことをAIと対話しながら下地を作成してもらい、私の方で仕上げをするという共同作業で作成しました。
お試しということもあり、今回は難しいことを省いて簡易的に作成しました。
また対象データの取得（今回で言うと自分のチームのMR）ですが、私の現場ではMRのレビュー依頼を出すときに、MRにそのチームのラベルをつける文化があるのでこれを利用しました。
（ラベルをつけると、Slack経由で各チームメンバーにレビュー依頼が届く仕組みとなっているためです。）
今回はこの仕組みを活かして、自分のチームのラベルがついたMRを過去30日分取得し、以下の数字を取得してみることにしました。
- 対象MRのマージ総数
- 平均リードタイム（MR作成からマージまで）
この2つの項目を選んだ理由は、単純にどれくらいのMRが消化されているんだろうという興味とそこからある程度の今の生産力が見えればいいなと考えたためです。
（本記事のテーマでは、分析より取得を目的にしているので、そこまで深い根拠はないです）
【役割】
あなたは、ソフトウェア開発のパフォーマンス分析を専門とするシニアアナリストです。
提供されたデータに基づき、明確で洞察に満ちたレポートを作成してください。
なお、データ取得は gitlab cliを利用してください。（書き込みは禁止）
【データ定義】
過去30日間にマージされた、特定のラベル（[review] {チーム名}）を持つMRのデータを取得してください。
【分析目標】
以下の2つの指標を計算し、分析してください。
1. **対象MRのマージ総数**: 過去30日間でマージされた、このラベルを持つMRの合計数。
2. **平均リードタイム（MR作成からマージまで）**: 各MRの `merged_at` から `created_at` を引いて計算したリードタイムの、全体平均値。
【レポートの構成】
計算結果に基づき、以下のセクションで構成される日本語のレポートを作成してください。
## 📊 {チーム名} パフォーマンス分析レポート (過去30日間)
### 1. エグゼクティブサマリー
* 今回の分析の対象（特定のラベルと期間）と、主要な結論（パフォーマンスはどうか）を簡潔に述べる。
### 2. 主要な計測結果
* **マージ総数**: [具体的な数値] 件
* **平均リードタイム**: [具体的な時間（例: X日 Y時間）]
* 注: リードタイムは**日、時間、分**で表示し、秒単位の生データを変換して分かりやすくすること。
### 3. リードタイムに関する詳細分析
* 中央値（Median）を算出し、平均値と比較して異常値の影響を考察する。
* リードタイムの分布から、最も長かったMRと最も短かったMRの差が大きいか小さいかを評価し、プロセスの安定性について簡単に言及する。
### 4. 洞察と推奨事項
* この平均リードタイムが、**開発プロセスにおいて何を意味するか**（例: レビュー待ち、QA待ちの時間など）について考察を加える。
* このリードタイムをさらに短縮するために、**レビューサイクル、CI/CD、あるいはブランチ戦略**に関して取るべき具体的な改善策を提案する。
### 禁則事項
* gitlabへの書き込みは禁止する。
出力結果
こちらに出力結果を添付します。
まずは、それらしい数字は取得できているようです。（GitLab上で確認しても件数はほぼ合っていそう）
気になった部分は、最長でmergeまでに時間がかかったMRのリードタイムが11日6時間と言う部分です。
おそらくですが、リリース準備として事前に用意していたMRなどが引っかかったのではないかと思われますが、この辺の外れ値を含めないような工夫は今後の課題になりそうです。
また本当にそういうMRが存在したか、GitLab上では簡単に分からなかったので、次回から対象となるMRのタイトルも合わせて記載してもらうようにしたいと思いました。
とはいえ、多くのMRは1日程度で処理されているとのことだったので、MR作成-> レビュー依頼 -> レビューとFB対応 -> 再レビュー -> mergeまでのプロセスがおおよそ1日で済んでいるということなので
割と生産性高く開発ができていそう、と楽観的に捉えています。
（大雑把にみると、過去30日間（20営業日）に対して、99件のMRがほぼ1日程度であれば毎日約4.95個のMRがmergeされていることになりそう、みたいなチームの状態が数値で見えてくるのは面白いなと感じました。）
⏺ 📊 [review] {チーム名} MR パフォーマンス分析レポート (過去30日間)
1. エグゼクティブサマリー
過去30日間における[review] {チーム名}ラベルを持つマージ済みMRのパフォーマンス分析を実施しました。分析結果から、
開発チームは標準的なパフォーマンスを維持していますが、リードタイムの分布に不安定性が見られ、プロセス改善
の余地があることが判明しました。
2. 主要な計測結果
- マージ総数: 99件
- 平均リードタイム: 2日4時間
3. リードタイムに関する詳細分析
- 中央値（Median）: 1日
- 最短リードタイム: 4分
- 最長リードタイム: 11日6時間
- 分布の幅: 11日6時間
平均値（2日4時間）と中央値（1日）の差が大きく、リードタイム分布は不安定です。これは一部のMRが異常に長いリ
ードタイムを持っており、全体の平均値を押し上げていることを示しています。多くのMRは1日程度で処理されている
ものの、プロセスの一貫性に課題があります。
4. 洞察と推奨事項
パフォーマンスの意味
現在の平均リードタイム（2日4時間）は標準的なレベルです。一般的な開発プロセスの範囲内ですが、更なる効率化
の余地があります。中央値が1日であることから、大部分のMRは迅速に処理されており、基本的なレビューフローは機
能しています。
改善推奨事項
1. レビューサイクルの最適化
- レビュー待ちの可視化: 長期間レビュー待ちになっているMRを特定し、優先順位付けを行う仕組みを導入する
- レビュワーの負荷分散:
特定のレビュワーに集中しないよう、チーム全体でレビュー負荷を分散する体制を構築する
2. CI/CDパイプラインとプロセス改善
- 複雑なMRの事前識別: 大きな変更や複雑な機能追加は事前に分割し、小さなMRに分けて迅速な処理を促進する
- 自動品質チェックの強化: コード品質チェック、テスト自動化を充実させることで、レビュー時の手戻りを削減し
、一貫したリードタイムを実現する
まとめ
今回は、チームパフォーマンス計測をカジュアルにはじめてみるための方法を試しました。
本記事の作業はトータルで、実はとある一日のお昼休みの30分くらいで試しています。
なので、簡単にとりあえず数字を取ってみたいという場合にはもしかしたら有効な手段かもしれません。
私も数字をどういった改善アクションへ繋げていくか、という観点はかなり浅いので少しずつそういった部分も学んでチームの生産性を向上させていきたいと思います。