このエントリーは with Advent Calendar 2025 の 7 日目の記事になります。

■はじめに

どうも！
with Android チームの @KKusumi です🐶
気がつけば、今年もあっという間に 12 月ですね🌲🎁

私が所属しているチームでは、前期の半年間、マージ済み PR数を開発生産性を測るための重要なスタッツとして、毎月チェックしてきました。
その取り組みを通じて得られた気づきがいくつかあったため、この記事ではその内容をご紹介します。

■前提

まず、なぜマージ済みPR数を指標として採用したのかについてお話しします。

一般的にエンジニア組織が追うべきスタッツとしては、Four Keysがよく知られています。
ただ、Four Keysは外的要因による影響を受けやすく、チームだけではコントロールしきれない側面があります。
このような指標を目標に据えてしまうと、外部要因によって数値が下がった際、メンバーのモチベーション低下に繋がりかねません⤵️

さらに Four Keys を改善しようとすると、他チームとの協力が必須になります。
もちろんそれはそれで大切な取り組みではありますが、最初の一歩としては少し重たいというのが正直なところでした🙁
開発生産性向上の初心者としては、まずは小さく・早く始めたい気持ちがありました。

そこで、エンジニア側のみで完全にコントロール可能であり、かつ開発生産性の一側面として妥当だと判断し、マージ済みPR数を追うことにしました。

■気づき

ここからは、マージ済みPR数を追い続けたことで見えてきた学びをまとめていきます。

1. PR サイズの最適化が進む✨

マージ済みPR数を追うようになってから、自然と「PRを細かく分割しよう」という力学が働くようになりました。
大きな PR をまとめて出すメリットが薄れたことで、無理なく分割を促す環境が整ったように感じます✂️

また、1PRあたりの平均変更量が可視化されたことで、効果的に開発が回っているときの 適切なPRサイズ を具体的に把握できました。
「PRは細かいほうがいい」と多くの人が理解していても、「どの程度がちょうどいいのか？」という基準は曖昧になりがちです。
その基準がはっきりしたことは、チームにとって大きな収穫でした。

その結果、これまでメンバー間でばらついていた PR の粒度が、ある程度そろうようになったのも良い変化でした👍

2. PR 運用の最適化が進む🔧

毎月スタッツを確認し、それをもとに PR 運用周りの振り返りも行いました。
このプロセスのおかげで、PR を細分化する際にどんなブロッカーがあるのかを丁寧に拾い出すことができました。

特に顕著だったのは、PR作成におけるオーバーヘッドです。
PRの数が増えるほど、テンプレートの使いづらさや無駄な項目が気になるようになり、結果としてテンプレートの改善を何度も重ねることになりました🛠️

その副産物として、これまで曖昧に扱われていたルールが明文化され、逆に不要だったルールは整理されるなど、運用の健全化も進みました💪

3. 頑張っている人が可視化される🔥

スタッツは毎月全員で確認していたため、自然とメンバーの意識にも浸透していきました。
その結果、誰がどれくらい頑張っているのかが肌感覚で伝わってくるようになり、ポジティブな刺激がチーム内で循環していくのを感じました。

感覚的な話にはなりますが、意欲的に取り組んでいるメンバーの熱が周りに伝播し、「自分ももっと頑張ろう」と思える雰囲気が生まれた印象です。

当初はアウトプット量が数字で可視化されることで、意図しない比較が生まれ、悪影響が出るのではないかという懸念もありました。
しかし実際にはそうした問題はほとんど発生せず、むしろ健全な刺激として作用していました。

4. 不確実性の高いISSUEには取り組みづらくなる💧

ここまでメリットを中心に書いてきましたが、もちろんデメリットもありました。

「取り組まなければいけないのはわかっているけれど、どれくらい大変なのかがよくわからない」というISSUEは、どのチームにもあると思います。
こういった 不確実性の高いISSUE に対して、マージ済みPR数を指標にしていると、どうしても手を付けづらくなる傾向が見えてきました。

マージ済みPR数を追っていると、対応に必要な修正の全体像が見えているISSUEのほうが心理的に取り組みやすいというバイアスが生まれます。
調査そのものには大きな価値があるにもかかわらず、それ自体はマージ済み PR 数の増加には直結しないため、「個人スタッツ的には得をしない仕事」と感じられてしまう場面が出てきます。

この問題に対処するには、例えば次のような工夫が必要だと感じました。

調査や不確実性の高いISSUEに取り組むことを、別軸で評価する仕組みを用意する
ISSUE は基本的に 優先度順に取るルール を設け、個々人の判断で「やりやすいタスクだけを選び続ける」状況を避ける

指標としてのマージ済みPR数自体は有用ですが、それだけに依存すると扱いづらいタイプの仕事が後回しになりやすいため、別の評価軸や運用ルールと組み合わせて使う必要があると感じました。

■最後に

最後に、この指標を測る前提となるのは「メンバーがハックしないこと」です。
つまり、数を増やすためだけに過剰にPRを細かく切り分けることも、理論上は可能です☠️

この運用が成り立っていたのは、メンバーが数値のためではなく、チーム全体の改善のために動いてくれたからこそです。
性善説に基づいた仕組みであり、信頼の上に成立している運用です🙏
チームの皆様には感謝するばかりですね🙇‍♂️

チーム目標を立てなければいけないけど、どの数値を追えばいいかわからない
チームメンバーのことは信頼している

という状況であれば、ひとつの選択肢として マージ済みPR数 を追ってみるのもアリかもしれません。
思わぬ学びや、チームの新しい一面が見えてくるかもしれません😊

おしまい。

採用PR

withではエンジニア採用を強化しています。
「まずは話を聞いてみたい」だけでも大歓迎です。
選考に進むかは後でOK。ぜひ気軽にご連絡ください。