プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews

2025/03/06『コードレビューどうしてる？ 品質向上と効率化の現場Tips共有会』
https://findy.connpass.com/event/345102/

での登壇資料です。
資料内で紹介しているブログ記事などは以下……

『実際に会社で使っているプルリクエストのテンプレートを紹介します！』
https://zenn.dev/lovegraph/articles/a974f188c6cbb2

『プルリクエスト一覧を Slack にリマインドするCLIアプリ』
https://github.com/nekonenene/gh-pull-requests-slack-reminder

『レビュー待ちプルリクを減らす GitHub Actions』
https://zenn.dev/lovegraph/articles/928955bdf03c2f

Transcript

1. Α͑͜ プルリクレビューを 終わらせるための チーム体制 @yokoe24
2. ࣗݾ঺հ よこえ • X : @yokoe24 （フォローを返すタイプの人類） • ラブグラフの執行役員CTO （MIXIの子会社） • グロービス経営大学院で ちょうど１年経った大学院生
3. ϥϒάϥϑ ( https://lovegraph.me )
4. ΈͯͶΞϓϦͰ͸…
5. ϥϒάϥϑ • 出張撮影サービスを提供 • ウェブやみてねアプリを通して 撮りたい場所を指定しつつ 好みのカメラマンに依頼できる • もともとはカップル撮影で人気が 出たサービスだが、 現在は家族撮影で幅広く使用される
6. ̌ はじめに
7. ϗϯϚ͝ΊΜ • そんなに目新しい話は 開発体制が整っている会社だと ないかも……ごめん……🥺 • 「これはやってなかったな」 というものが１つでもありましたら 幸いです☺
8. ͜Ε͔Β࿩͢͜ͱ 1. 方針を決めることの大事さ 2. 情報が届くことの大事さ 3. 時間を作ることの大事さ 4. おわりに
9. ̍ 方針を決めることの大事さ
10. ίʔσΟϯάϧʔϧ • 「方針」は例えば Linter の 設定だったり、どの会社でも共通する 統一解があるわけではないもの • 「方針」を決める責任者がいて、 意見を聞きつつ決断する必要がある （⇒CTOやテックリードなどが負う）
11. ܾΊΔඞཁͷ͋Δํ਑ • ESLint や Stylelint などの Linter のどの設定をオンにするか • Linter にない決めごと： 例）routing の記述をABC順に並べる 例）Rails の includes の使用を避ける Custom Rule を作ってもいいが、まず はドキュメントに書くなど最小の工数
12. ํ਑͕ͳ͍ͱ…… • レビューする人によって方針が 異なって、レビューされる側が困惑 • レビュアーは同じようなコメントを 違う相手に何度もすることになって 疲れてしまう • コーディングスタイルを巡って 長い議論になってしまうことも
13. ϓϧϦΫςϯϓϨ • プルリクエストに何を書いてもらいた いか、ということを決めるのも大事 • プルリクテンプレートは その方針を落とし込んだものとなる • レビューする人にとって知りたい情報 が書かれていると、 レビューの往復回数が減る
14. ϥϒάϥϑͰ͸ ͜Μͳײ͡ˠ
15. ॻ͖΍͢͞΋େࣄ • プルリクエストは何度も書くものなの で、書きやすさも大事 • HTMLコメントも活用して、書いてほし いことを示しつつも編集の必要な文字 数はテンプレ内にできるだけ少なく • https://zenn.dev/lovegraph/ articles/a974f188c6cbb2
16. ϨϏϡʔपΓͷϧʔϧ • 新入社員やインターンは、自分が レビューしていい立場なのか 迷ってしまうこともあるので、 研修ドキュメントで明言する • 複雑な議論が起こりそうなときに Slackでのやり取りを推奨するルールも レビューを早めるために大事かも？
17. ̎ 情報が届くことの大事さ
18. ৘ใ͸ pull ΑΓ push • 「情報を取りに行く人は少ない」 ↑ この前提は考えとして大事 • 「レビューをすることはイイこと！」 と伝えつつも、一方で 「リマインドをしないのにレビューが 必ずされると思ってはいけない」とい うこともチーム内に啓蒙していく
19. ϥϒάϥϑͰ͸ ͜Μͳײ͡ˠ
20. Slack΁ࣗಈϦϚΠϯυ • インターンメンバーは勤務時間も 限られているので、リマインドに限界 • https://github.com/nekonenene/gh-pull- requests-slack-reminder を使って、 「レビュー依頼中」ラベルが付いた プルリクが Slack チャンネルに 投稿されるように！
21. 詳しくはこちら → https://zenn.dev/lovegraph/articles/928955bdf03c2f
22. ̏ 時間を作ることの大事さ
23. ࣌ؒΛͭ͘Δ • それでもやっぱり、みんな レビューよりも開発をやりがちで プルリクエストは溜まってしまう • もはやこれは自然の摂理 • というわけで、 みんなでレビューをする時間！
24. ʮϨϏϡʔձʯͷࢼΈ • 週に３回、30分「レビュー会」という ミーティングを始めてみた • プルリク作成者がどういうプルリクか 説明したあとで、他全員がレビューを する時間。多くのマージを目指す • レビュー会のあとも流れでレビューを 続けられるよう、開催時間も大事
25. ϝϦοτɾσϝϦοτ • その場でコードの意図の質問が できたり、直してほしいところを 説明するときもやりやすかったりと、 レビューの負荷が下がった • 「レビュー会があるから」と、 それ以外の時間にレビューしなくなる 人が生まれる可能性も？
26. ̐ まとめ
27. ·ͱΊ • レビュアーのレビューをおこなうこと へのモチベーションが上がらない • やり取りの往復に時間がかかる • 時間 ＝ 往復回数 × １往復の時間 • プルリクがなかなかApproveされないと き、上の２つがほとんどの原因 • これを解決できるチーム施策が大事
28. 必要なこと 取り組み プルリクの存在を知らせる ・レビューされる側のリマインド意識と、 それを促すドキュメントを用意 ・Slackへの自動リマインド通知 レビューをおこなうまでの 心理的障壁を低くする ・誰でもしていいことを明記、研修 ・レビュー会 ・１プルリクのDiffの目安を明文化 やり取りの往復に かかる時間を減らす ・Linterの導入・遵守 ・Linter以外の開発ルールのドキュメント 化。議論ではSlackも推奨 ・プルリクテンプレ ・レビュー会