この記事は、LayerX Tech Advent Calendar 2024 の 2 日目の記事です。

こんにちは。 LayerX バクラク事業部バクラクビジネスカード開発チームEMの高江（@shnjtk）です。

前回の私の記事では、私が所属するチームで策定したコードレビューガイドラインについてご紹介しました。

tech.layerx.co.jp

今回の記事では、チームとして Pull Request（以下PR）のレビューを円滑に行うために、どのような仕組みを導入しているかをご紹介します。

PR を止めてはいけない

これはバクラクの開発を始めた当初から大事にしている考えで、当時からデザイナーとして活躍されている森さんの記事でも言及されています。

デザイナーからみた爆速開発 - LayerX エンジニアブログ

当時と現在では事業のフェーズやプロダクトの成熟度など様々な面が異なりますが、開発スピードを落とさないこと、そのために PR を止めないことは今でも変わらず大事にしています。

コードレビューの課題

先述したコードレビューガイドラインの中に、レビュアーとしていつまでにレビューを行うかの目安として「レビューは1営業日以内を目処に行う」とあります。そのため、基本的にはレビュアーにアサインされたらなるべく速やかにレビューするように心がけていますが、一方で自分にも取り掛かっているタスクがあり、作業が一段落するまでは割り込みを受けずにまとまった時間を確保したい、作業に集中したいという欲求もあります。

レビュー待ちの状態が長く続くほど、その PR を作成したメンバーにとってはその作業に対して待ち時間が発生してしまうため、自分の作業効率を上げようとする（レビューを遅らせる）とチームの作業効率が下がってしまうというジレンマを抱えることになります。

チームメンバーからも同様の課題感が挙がり、仕組みで解決できないかということで話し合いながら複数の施策を導入しました。

コードレビューを円滑に行うための取り組み

チームとしての取り組み

レビュアーのアサインを自動化する

まず、PR 作成時に誰をレビュアーにするかを意識しなくて済むように、アサインを自動化しました。 GitHub の機能として、あらかじめ設定したポリシーに基づいて GitHub Team のメンバーを自動的にレビュアーとしてアサインする機能があるため、それを利用しています。

Teamのコードレビュー設定の管理 - GitHub Docs

具体的には、レビュアー2名が Round robin でアサインされるように設定しています。また、チームの約束事として、アサインされたレビュアーのうち最低1名が approve すれば merge してもよいことにしています。ただし、「この PR はこの人に見てほしい」というケースでは、自動でレビュアーがアサインされた後、個別に追加で指定することもあります。

レビュー待ちの PR を Slack に通知する

レビュアーとしてアサインされていることに気付いておらず、それによってレビューが遅れるということがないように、定期的にレビュー待ちの PR を Slack に通知しています。これも GitHub にそのための機能があるので、それを利用しています。

スケジュールされたリマインダーの管理 - GitHub Docs

具体的には、1日2回、朝の10時と夕方の4時に通知を送っています。通知先は開発チームのメインチャンネルに設定しています。これにより、自分がアサインされてレビュー待ちになっている PR があれば Slack でメンションされるため、そこで気付くことができます。既にレビューした PR についてはメンションされないところも地味ですが便利です。

PR には Why と What を必ず記載する

レビューするときは、いきなりコードを読むことはせず、まず最初に「なぜその変更が必要になったのか」を確認し、それから「どのような変更を行なったのか」を確認しています。そうしないと、そもそもその変更を取り込むことが正しいのかどうか判断できないからです。そのため、Why と What をこの順番で記載するように PR テンプレートを設定しています。もしこれらが記載されていない PR のレビューをアサインされた場合は、「Why と What の記載をお願いします」という感じでしっかり記載するように促しています。

また余談ですが、コードレビューガイドラインの中に「What に関しては、面倒であれば PR-Agent を使うとよいです」とありますが、現在ではこれは NG にしています。理由としては、「PR 作成者が変更したと思っている内容」と「PR-Agent が読み取った変更内容」が食い違った場合に、PR 作成者自身が What を書かないとこれに気付けないためです。

PR-Agent についてはこちらの記事もぜひご覧ください。

tech.layerx.co.jp

個人としての取り組み

ここまではチームとして取り組んだ内容についてご紹介しましたが、ここからは私が個人として取り組んでいる内容についてご紹介いたします。

GitHub の Notifications ページでレビュー待ちの PR をまとめて確認する

上述した1日2回の Slack 通知とは別に、自分の作業が一段落したタイミングで、自分にアサインされたレビュー待ちの PR がないかを確認しています。 GitHub 画面右上の Notifications をクリックし、左ペインの Filters から Review requested を選ぶとレビュアーにアサインされた PR の一覧を確認できます。

Re-request review で再レビューを依頼する

自分が PR 作成者としてレビューを依頼し、Request changes やコメントを受けて修正を行なった後、再度レビューを依頼したい場合に利用します。 PR の Reviewers にあるアイコンをクリックすることで、再レビューを依頼することができます。上述した Slack への通知や Notifications などの仕組みはレビューの依頼状態に基づいているので、適切にステータスを変更することが重要になります。

詳細は GitHub の公式ドキュメントを参照ください。

Pull Request レビューをリクエストする - GitHub Docs

取り組みの効果

これらの施策を導入したことにより、レビューのタイミングについて、ガイドラインに記載した「1営業日以内」という目処に概ね収まっており、レビュー待ちの PR がずっと滞留しているという状況はほとんど起きていません。

私自身としても、普段は Notifications ページをこまめに確認するようにしていますが、どうしても作業に集中しているとアサインされていることに気付かないということもあります。そのような場合でも、夕方の Slack 通知がちょうどよいと感じるタイミングで届くため、作業とレビューのバランスも上手く保てていると感じています。