人が Pull Request を読み続けるために

Pull Request が担う役割を分解しレビューに費やす時間を減らす

Transcript

1. 人が Pull Request を 読み続けるために Pull Request が担う役割を分解しレビューに費やす時間を減らす 岩下 侑冬 (iwash) 2026/09/14
2. 自己紹介 岩下（いわし） 侑冬 Software Engineer iwash 2024 年に HERP にジョイン。ジョブミルの開発チームでソフトウェアエンジニアをしている。 ジョブミル 人材紹介会社向けの求人提案プラットフォーム。複数の採用管理システム（ATS） から求人を自動で集約し、一括で検索できる。 https://www.jobmiru.cloud 運営: 株式会社 HERP 2
3. 何が起きたか 正社員エンジニア 2 人で、Claude Codeを中心に開発している。 6月 新メンバーが 2 人参加 AI があるとキャッチアップが速い 2 人とも入社初週に最初の PR を出した レビューが開発を律速 量も重さも増える PR の数もサイズも増えた PR は月 400 件になった サイズの中央値は 4 月 41 行 → 8 月 143 行 PR の数が増えたがレビュアーは増えていない → レビューに費やす時間を削り効率化を図る 3
4. レビューの要素分解 レビューが担ってきた役割を分解して他の場に逃がし、 レビューに費やす時間を減らす。 設計の合意 知識の伝承 コード品質の担保 安全性のチェック この作り方でよいか、他に案 はないかを話し、後から変え にくい判断を固める。 コードベースの決まりや変更 の経緯を伝える。 チームの規約や設計原則に沿 っているか、明らかなミスが ないかを見る。 この変更で本番が壊れない か、壊れたときに戻せるかを 確かめる。 それぞれを PR の外に逃がす 4
5. 1. 設計の合意 役割 1 / 4 PR で設計の合意形成をしているとレビュアーが疲弊する AI 導入前 最初の PR が出る時点でまだ実装の途中だったので、フィ ードバックで軌道修正できた。 AI 導入後 最初の PR が出る時点で、手元では既に仕上がっているこ とが多い。レビュイーは AI にやり直させればよいが、レビ ュアーは真面目にやるほど疲弊する。 設計の合意という役割を PR から剥がす 5
6. 同期リファインメント 後から変えにくい設計判断は、実装前に同期的に話して決める。 何を決めるか 誰と、どう話すか テーブルの変更のように、後から変えにくい設計判断だけを対 象にする。実装に入る前に決める。 業務委託を含むチーム全員で、同期的に話す。毎日 30 分の枠 を全員が空けておき、議題があるときだけ使う。 どうなったか 1. 設計の合意 PR が来る時点で全員が設計を見終えている。レビューは「決めたとおりに書けているか」の確認 になり、設計からの差し戻しが起きなくなった。 6
7. 2. 知識の伝承 役割 2 / 4 生成されたコードへの指摘は、次回以降も繰り返される 人が相手のレビュー 指摘した分だけ改善してくれる 一般化して言外の意図も組んでくれる 生成されたコードが相手だと その場では対処してもらえるが、次回以降も繰り返される 可能性が高い。 Rules を徹底的に書く 7
8. Rules を徹底的に書く レビューで口頭で伝えていた知識を Rules に書き切る。人も AI も同じものを読む。 静的にチェック可能 これまで 口頭で伝えていた知識 設計原則 コーディング規約 文章でしか書けない Rules にない 2. 知識の伝承 Custom Linter 化する Effect の禁止関数など。 Rules に書く レビューで指摘するのは、ここに書いてあることだけにする。 レビューでも指摘しない 指摘したくなったら、コードではなく Rules を書き足す。 8
9. 知識の伝承を PR から外して、どうなったか 新メンバー 2 人をレビュアーとしてアサインできるようになった。 これまで コードベースに詳しい人しかレビューを担当できない 書き方の決まりや経緯が口頭にしかないので、それを知る 人しかレビューを担当できない。 多様な知識が還元される 2. 知識の伝承 これから 新メンバー 2 人がレビュアーになった 細かい書き方は Rules が担保する。 作法を知らなくてもレビューに参加できる。 新メンバーが持ち込む知識が、レビューを通じてチームに還元される。 コードをチームで所有する意識も育つ。 9
10. 3. コード品質の担保 役割 3 / 4 Rules を整備しても、それが守られているかを確かめるのは人間の目のまま Rules が守られているかは、読んで判断するしかない。 その「読んで判断する」を AI に任せる。 10
11. AI レビュー AI が全 Pull Request をレビューして最低限のラインを確保する 1 AI が全 PR を見る Rules をそのまま判断基準にする。 3. コード品質の担保 2 必ず直す。不要なら Rules を直す AI レビューは形骸化しやすいので、 指摘は必ず直す。 不要な指摘は Rules を直す。 3 条件を満たす PR は AI が approve 事前に列挙した承認パターンに該当 する場合は自動承認し、人間のレビ ューをスキップ。 11
12. ルールとコードを毎晩揃える 別枠で Rules と実際のコードの差を埋めていく。 一日一善 毎晩、既存コードを Rules と照らし、違反している箇所を 少しだけ直す PR を作る。 コード Rules ルールの蒸留 毎晩、前日にマージされた PR のレビュー会話から、繰り 返し効く指摘だけを Rules に書き足す。 3. コード品質の担保 12
13. コード品質の担保を PR から外して、どうなったか 人間が PR に指摘を入れる割合が、3 か月で 75 % 減った。 5本に 1 本→20本に 1 本 人間が指摘を入れる PR の数 3. コード品質の担保 13
14. 4. 安全性のチェック 役割 4 / 4 テストはコードの正しさしか担保しない テストで担保できるもの テストが担保するのはコードの正しさだけ。 「要件を満たしているか」の判断は人間がしてきた。 人がレビューできる量は有限 すべての PR を同じ深さでレビューすることはできない 要件に照らす安全性のチェックを、AI に任せる 14
15. 安全性のチェック: 要件レビュー コードに書いていない「どうあるべきか」を、AI が要件に照らして確かめる。 課題 対策 ソースコードから読み取れるのは「何をしているか」だけで、 「どうあるべきか」はコードに書いていない。AI にコードだ けを読ませても、要件と合っているかは判断できない。 各機能について、顧客視点の要件を AI が読める形に整理す る。実装前のリファインメントと PR レビューの両方で、判断 の拠り所として AI に渡す。 4. 安全性のチェック 15
16. それでも人間が見る PR 4 つの役割の外 AI レビューが承認しなかった変更は人間が読む 時間がかかるのは、指摘ではなく文脈 レビュー時間の大半は、指摘を考える時間ではなく「何のための変更で、この diff は何をしているか」を掴む時間である。 文脈を掴む時間を減らして、1 件あたりを軽くする 16
17. それでも人間が見る PR を軽くする PR を小さく分け、人間が読む前に AI が背景と読み方をまとめる。 PR ブリーフィング Stacked PRs 何をするか リファクタ・機能実装・技術境界などで PR を分割。 PR は小さいほど読むコストが低い。 副作用 分割すると、1 つの PR だけを見ても何のための変更か分から なくなる。 それでも人間が見る PR 何をするか 人間がレビューを始める前に、AI が PR 本文・Issue・リファ インメント資料・Stacked PRs の前後を収集する。 何のための変更かを要約、背景と読む順番をまとめておく。 diff の行間に「ここは何をしているか」「ここは人間が判断す べき」「テストは足りているか」と注釈を付ける。 17
18. まとめ 18
19. まとめ PR レビューを 4 つの役割に分解して PR の外に逃がし、それでも残る PR は軽くした。 設計の合意 実装前の同期リファインメン トに移した。 それでも人間が見る PR 知識の伝承 口頭の知識を Rules と linter に書き切った。 コード品質の担保 Rules を基準にした AI レビュ ーに任せ、ルールとコードは 毎晩揃える。 安全性のチェック テストで拾えない要件とのず れを AI が確かめる。 小さく分割し、PR ブリーフィングでレビューの負荷を下げる。 19