月末の役員報告で、マージされたプルリクエストの件数が号令前の2倍を超えたグラフが映る。役員はうなずき、次の議題へ移る。その同じ週、あなたのレビュー待ちの一覧には、AIコードレビューが指摘なしで通したプルリクエストが、人の目を待って積み上がっている。
flowchart TD
A[開発2倍の号令] --> B[マージ数が倍増]
B --> C[確認の負荷も倍増]
B --> D[報告は成果だけ]
C --> E[確認者が吸収]
D --> E
「2倍」は達成され、レビュー担当の負荷もおおむね2倍になった#
号令が数字のうえで達成された職場を、長い期間追った研究がある。arXivに投稿された論文「AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate」だ。対象は、2025年なかばから、エンジニア1人あたりのマージ済みプルリクエストを2倍にするという号令を掲げた、AI活用に前のめりな中規模の企業1社である。
開発者802人、プルリクエスト196,212件を、2024年1月から2026年4月まで追っている。1人あたりのスループットは、2026年4月に号令前の基準値の2.09倍に届いた。（出典: AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate）
同じ期間に、レビューの形も変わった。要旨に書かれているのは次の3点だ。
- レビュー担当1人あたりの負荷 おおむね倍増
- 自動レビュー 人によるレビューを追い越した
- マージ率とリバート率 横ばい
但し書きも付いている。著者は、AIの導入や使用量が無作為に割り当てられたものではないとして、伸びを正確な因果として読まないよう断っている。原文の語は automated review で、AIに限った言い方でもない。AIコードレビューを入れた職場は、この自動レビューの側を厚くした職場だ、と私は読んでいる。
マージ率もリバート率も横ばいだから、確認の倍増はどの数字にも出ない#
役員報告に載る数字は、どれも成功を示している。1人あたりのマージ数は2倍、マージ率もリバート率も横ばい。品質を落とさずに量だけが倍になった、と読める並びだ。
ところが倍になったレビューの負荷は、この3つのどこにも出てこない。出るとすれば、レビューを担った人の残業か、夜の未読か、週末の画面だ。私はこれを簿外の確認コストと呼んでいる。帳簿には載らないが、誰かの燃料からは確実に引き落とされている。
私にも覚えがある。発言していない会議の時間は、別案件のレビュー・承認・15秒の判断で埋まっていた。会議に出ている時間は空き時間ではない。レビュー待ちの一覧が帳簿に出ないのも、同じ構造だ。
ここから先は論文の主張ではなく、私の読みだ。横ばいのリバート率は、見る側が倍の量を引き受けた結果として保たれている面がある。その読みが当たっていれば、品質の数字が良い月ほど、確認の負荷は見えにくくなる。
だから、レビューが追いつかないことを、あなたの処理の遅さとして扱う必要はない。報告の様式が、作った量だけを載せて、確かめた人手を載せていない。設計の側の問題だ。PR数が増えるほど成果に見えてしまう評価の仕組みも、量だけを数える同じ穴から生まれている。
達成した倍率は、おそらく次の期の出発点として扱われる。確認の負荷を載せないまま報告を続ければ、その出発点の上にさらに積まれる。AIを入れても手元に残る仕事が、組織の結節点にいる人へ寄っていく構造は、AIに渡しても減らない仕事を10項目で数えた回で棚卸しした。レビューは、その結節点のど真ん中にある。
月次報告のマージ数の隣に、レビュー担当1人あたり件数を1行足す#
最初の一手は、報告を1行増やすだけで済む。論文が測ったのはレビュー担当1人あたりの「負荷」だが、報告に載せるのは数えやすい件数でいい。
- 号令前の3か月分を基準値にする。人がレビューしたプルリクエストの件数を、人のレビュー担当の人数で割る
- 集計は自分でやらない。リポジトリから件数を出す作業は、ツールの担当者かAIに渡す。自分が決めるのは数え方の定義だけだ
- 毎月の報告で、マージ数と同じ枠に並べる。別ページや付録に置くと読まれない
報告に足す行は、これで足りる。
【開発の量と、確認の量】（今月）
・マージ済みPR：〇〇件（号令前の〇.〇倍）
・人のレビュー担当1人あたり件数：〇〇件（号令前の〇.〇倍）
・合意済みの上限：〇〇件／超過：あり・なし作った量の隣に、確かめた量が並ぶ。役員が2倍のグラフを見るとき、同じ視線で確認の倍率も目に入る。説明の言葉は要らない。数字が並んでいれば、問いは向こうから出てくる。
上限は、超える前に役員と合意しておく#
1行を足したら、その行に上限を引く。超えたら受け入れを止める線だ。
上限で受け入れを止めれば、マージ数の倍率は下がる。下がった月に初めて事情を話すと、号令への言い訳として受け取られる。下がる前に「この線を超えたら止める。その月は倍率が下がる」と合意しておけば、下がった数字は約束どおりの結果になる。順番を入れ替えるだけで、同じ数字の意味が変わる。
上限の値は、外から目安を持ち込まない。判定基準は自分のチームの実測に置く。
- 基準の月 レビュー担当が定時内で見切れた月の件数
- 見つからないとき 号令前の基準値をそのまま上限にして交渉を始める
1人あたりの平均が上限の内側でも、特定のシニアに寄っていたら意味がない。担当者ごとの件数を表で見せて、判断だけを上に求めるやり方は、レビューの偏りにもそのまま使える。
合意を取りにいく文面は、これで足りる。
件名：開発2倍の運用で、レビューの上限を先に決めたい
来月から、月次報告のマージ件数の隣に
「人のレビュー担当1人あたり件数」を載せます。
あわせて、1人あたり月〇〇件を上限とし、
超えた分は翌月に回すか、対象を絞るかの判断をいただきたいです。
上限で止めた月は、マージ件数の倍率が下がります。
この前提で進めてよいか、〇日までにご判断ください。止めるか、絞るかを決めるのは役員の側だ。あなたが引き受けるのは、線を引いて数字を出すところまででいい。
逃げの一手：合意が取れない月は、人の目を通さずにマージした件数を別に書く#
「2倍は維持、上限は認めない」と返されることもある。そのときは、それ以上押し返さなくていい。
代わりに、人のレビューを通さず自動レビューだけでマージした件数を、報告の別の行に書く。省く対象は、障害時の影響が小さい種別（ドキュメント・設定・テストのみの変更など）に先に限り、その種別を書面にしてから省く。省くかどうかも、役員に確認を取ってから決める。確認を省くリスクを取るかどうかの判断が、書面の上で役員の側に置かれる。後で見落としが表に出ても、あなた個人の処理能力の問題として片づけられる道は細くなる。
倍の件数を黙って見続けて燃料を空にするより、省いた分を記録に残して手を離すほうが、退路として安い。その行が3か月たまれば、次の要員計画で出せる材料にもなる。
まとめ：2倍の横に、見る側の倍率を並べる#
マージ数の2倍と、レビュー担当の負荷の倍増は、同じ月に起きている。片方だけが報告に載る限り、もう片方はあなたの燃料から払われ続ける。
本記事は AI が下書きし、管理人が監修しています。
査定に載らない組織仕事を振られたその日に、そのまま出せる定型文が3通ある。
→ 期待値コントロール定型文集（抜粋版）続きはタイムラインに置いていく。
