本記事は、Applibot Advent Calendar 2025 の16日目の記事です。
前日は @yakisabananoka さんの クリスマスなのでUnityエディタのアイコンを光らせてみた！ でした。
この記事で分かること
- PRレビュー会の具体的なやり方（30分/日、昼休憩後）
- 半月実施して得られた4つのメリット
- 導入前の懸念と実際の結果
はじめに
私たちのチームでは、プルリクエスト（以下PR）のレビューがされず、マージできないことで開発フローが止まってしまう問題がしばしば発生していました。
理想はチームメンバー全員に向けてPRを投げ、知見のある人や直近工数的に厳しくない人がレビューすることだと思いますが、新規ジョインの人が増えたタイミングということもあり、レビュー負荷が一部の人によってしまったり、忙しい時期だとみんなレビューする余裕がないなどの問題が発生していました。
この問題の対応として、プロジェクト知識が深いベテランエンジニアがレビュー担当を申し出てくれ、彼にレビューを集約することで一時的にこの問題は解消されました。
しかし彼が別チームに異動することになってしまい、他の対応を迫られてしまいました。
対策を考えているときに私の前の会社でうまくワークしていたPRレビュー会のことを思い出し、今のチーム状況にハマるかもしれない、と導入してみることにしました。
レビュー会を導入したチームについて
| 項目 | 詳細 |
|---|---|
| チーム構成 | エンジニア9名（うち新規ジョイン4名） |
| 職掌 | サーバーサイド |
| PR数 | 1日平均9.5件（2リポジトリ） |
| レビュー待ち時間 | 導入前：平均45時間 → 導入後：平均22.5時間（50%削減） |
やり方
以下のような手順で行なっています。
- 昼休憩後の30分間をPRレビュータイムとし、全員の予定を抑える
- 他予定ある人や、直近忙しくて工数がない人は不参加OK
- 開始時にレビューして欲しいPRを募集
- ファシリテーターはこの会の経験がある私メイン
- 不在時はリーダー
- 設計のレビューでもOK
- なければ解散
- 説明不要なほどシンプルなものはレビュー会では見ず、slackで個別に依頼
- 例
- 自動生成のみ
- コメント変更のみ
- 例
- ファシリテーターはこの会の経験がある私メイン
- レビュイーがPR説明
- レビュイーが画面共有し、概要やコードの説明
- みんなでレビュー
- 質問があれば随時する
- 問題なければその場でapproveをつけ、問題があったらレビュー会後にレビュイーが修正して再度レビュー依頼を投げる
効果
以下のようなメリットがありました。
PRマージ待ちが減った
実施前までは「早くマージして欲しいので見て欲しいです！」というメンションをちょくちょく見ましたが、実施後はあまり見なくなりました。
導入した月とその前の月のデータを比較すると平均マージ時間が減少していました。
（時期やメンバーが違ったり、他のマージ時間を減らす施策もあるので完全に比較できてるわけではありません）
リポジトリ1
| 項目 | 導入前 | 導入後 | 変化率 |
|---|---|---|---|
| 総PR数 | 113件 | 123件 | +8.8% |
| マージされたPR数 | 99件 | 103件 | - |
| 平均マージ時間 | 37.3時間 (約1.6日) | 23.3時間 (約1.0日) | -37.5% ⬇️ |
リポジトリ2
| 項目 | 導入前 | 導入後 | 変化率 |
|---|---|---|---|
| 総PR数 | 69件 | 68件 | -1.4% |
| マージされたPR数 | 56件 | 57件 | - |
| 平均マージ時間 | 52.5時間 (約2.2日) | 22.0時間 (約0.9日) | -58.1% ⬇️⬇️ |
レビュー精度が上がった
レビュイーによる前提の説明が聞けたり、レビュワーの疑問点をその場でレビュイーに質問できることで、slackでPRレビューを投げるよりもレビュー精度が上がったように感じます。
レビュワーが多いことで、レビュー抜けも減っていると思われます。
PRの変更内容や意図がチーム全体に共有されるようになった
slackによるレビュー依頼で一部の人だけでレビューすると、レビューに参加していない人はPRの内容を把握できませんが、チーム全員で見ているので全員が把握できます。
特に、チームにジョインしたばかりのメンバーは学習効果を感じていました。
レビュー以外のことでも話す機会が増えた
これは意図していなかった効果ですが、全員で話す機会が増えたことで、レビュー以外でも話すことがあったら気軽に話せるようになりました。
例
- 「そういえば、あの件どうなりました？」
- 「〜〜が動かないのですが、知っていますか？」
- 「終わった後、Aさんと軽く話したいです！」
実践前に不安だったこと
いくつか懸念事項もありましたが、現時点では特別に問題にはなっていません。
全部のPRをレビュー会の時間だけでレビューできる？
PR数に応じてグループを分割して行う予定でしたが、今のところ1グループでできています。
今後PR数が増えたらグループ分割するかもしれません。
（共有範囲がその分狭まってしまうのでなるべく小さいグループ数でいきたいと思っています）
レビュー工数的には増えてしまっているのでは？
増えてしまっている人もいます。
ただ、1日30分という固定時間なのと、PR内容の共有が受けられるという意味ではメリットの方が大きいのかなと思っています。
レビュー会中に見切れないような大きいPRはどうする？
大事な部分や複雑な説明の必要なところだけ説明して、あとは次回か、レビュー会以外でレビューするようにする予定でした。
チームとしてPRを細かく出す文化があるので、今のところレビューしきれないケースはほとんどありません。
すぐマージしたい、緊急でレビューして欲しいPRはどうする？
レビュー会を待たずにslackでレビュー依頼を出す決めにしています。
制度が必要な場合は必要に応じてみんなを集めて対面レビューを行います。
終わりに
半月ほど実施してみてからチームメンバーにレビュー会の所感をヒアリングした結果、特に反対意見なく、概ね好評をもらえたのでメンバーのみんなにも受け入れてもらえているのかなと思います。
今後も継続して効果をみながら、問題があれば改善していきます。
みなさんのチームでもPRレビューがスムーズにいっていなかったらぜひ試してみてください！
明日は michoさんの記事になります。お楽しみに！
株式会社アプリボットでは、 エンジニアをはじめ全職種で積極採用中 です。
記事を読んで少しでも興味を持たれた方やお話を聞きたい方は、是非お気軽にご連絡ください！