【重要】チーム開発において、レビュワーの負担軽減のためにできること

Webエンジニアの方々の多くは日常業務でチーム開発をしていると思います。

チーム開発では大体の場合、タスク担当者がPR（プルリクエスト）を発行し、1人以上のレビュワーがそのPRのコードをチェックし指摘やアドバイスを行います。

レビュワー（レビューする側）になるとチームの規模によっては1日に複数のPRをレビューする必要があり、下手すると「レビューしていたら1日終わった…」なんてことも。

レビュワーはレビュー専門のポジションではなく他のタスクもあるので、レビュイー（レビューされる側）はなるべくレビュワーがレビューしやすいPRを作成し、レビュワーの時間を奪いすぎないことが重要です。

重要ですし、こういう取り組み自体評価されるべきものだと思っています。

前置きが長くなりましたが、Webエンジニアとしてレビュイー、レビュワーどちらも経験した僕が

をご紹介します。

以前ツイートしたのでこれについて1つずつ説明を入れていきます。

RTが20以上、いいねが150以上とわりと反応が良かったツイートです。

PRに含めるとレビュワーの負担軽減に繋がるもの

【共通】
・対応チケット
・ざっくりした実装内容
・実装コードの補足説明
・特にチェックしてほしい箇所
・テスト結果

【フロント】
・画面のスクショ
・正しい挙動を表す動画

【API】
・リクエストとレスポンスのJSON

ご参考までに。

— ゆーたろー (@shimotaroo) January 17, 2022

この記事の読者の今後の開発業務の参考になることがあれば嬉しいです。

ここから取り上げることは全てPRに盛り込む必要はないと思います。場面場面で盛り込む内容を選択するのが良いかと思います。

共通

まずはフロントエンド開発、バックエンド開発に共通して言えることから書いていきます。

チケット（タスク）の情報

どのチケット（タスク）のPRなのかがレビュワーが助かると思います。

チケットの内容はJIRAやBacklog等のタスク管理ツール上に記載することが多いかと思うので、URLをPRに貼っておくと、レビュワーが「このタスクってどんな内容だったっけ？タスク管理ツールから探すか…」という手間が省けます。

実装内容

そのPRでどういうことを実装したのか、そこまで具体的ではなくても良いかと思いますが書いておくと良いです。

何を実装したかを書いておくことで、レビュワーは明らかに実装漏れしている箇所がないかを素早く判断することができます。

あくまで例ですが、以下のように箇条書きで書くのが良いと思います。

実装コードの補足説明

実装したコードの中でどのような考えた方でそのコードを書いたのかを補足説明した方がレビュワーがレビューしやすいと思うことは積極的に記載することが望ましいです。

次に記載する「特にチェックして欲しい箇所」とカブるところもありますが、実装方針を詳しく説明しておきたいところを書くとコードレビューの手助けになります。

特にチェックして欲しい箇所

ここは個人的には盛り込むのがオススメの内容です。

僕は自分が実装したコードで「ここちゃんとチェックしてもらった方が良さそうだな…」と思う箇所は必ず

を書いています。

レビュワーは色々なタスクを担当して忙しい場合もあるので、「他のところは問題なく実装できている（と思う）のでここだけは必ずチェックして欲しいです！」という感じの気持ちを伝えることができます。

（実際には全てチェックして欲しいですけどね笑）

テスト結果

テストコードの実行結果（自動でテストを実行する仕組みが導入されている場合は不要かと思います）も盛り込む必要があれば盛り込みましょう。

ここもなかったらレビュワーが「テストコード全部通る状態になっているのかな？」と思う可能性があります。

フロントエンド開発

次はフロントエンド開発に特化した内容です。

フロントエンド開発では2つ紹介するのですが、個人的にはマストかなと思います。（レビュワーだったらめっちゃ助かるので）

画面のスクショ

これはUIの修正がある場合は絶対に入れるべきです。

UIの修正のタスクにおいて実装後かつPRマージ前に修正後のUIを確認する手段はレビュワーがリモートのfeatureブランチをpullする作業が必要です。

その手間が0になるのはレビュワーにとってはとても助かります。

さらに親切に情報を入れるとしたら

両方のスクショをPRに添付するのが良いと思います。

Macの場合はcommand + shift + 5でスクショや動画を撮影できます。

動画

UIの修正の他に、検索・ローディング、フラッシュメッセージ、ダイアログ等、動的に画面が変わる処理を実装した場合はその動画を添えるとレビュワーはありがたいです。

これもUI修正の時と同じく、レビュワーがローカルで確認する作業を無くすことができ負担軽減につながります。

Macの場合はcommand + shift + 5でスクショや動画を撮影できます。

バックエンド開発

最後はバックエンド開発に特化した内容です。

リクエストとレスポンスのJSON

APIを実装した時に

をPRに添えると仕様通りに機能を実装できているかどうかを一目でわかり、コードレビューする時に「この書き方でちゃんと機能しているのか？」という観点が必要なくなりコードの書き方のレビューに集中することができます。

この項目に関してはこれまで自分はしたことがなかったのですが、知人に教えてもらい「これはいい！」と思い記事に載せています。

最後に

レビュワーの負担を減らすことにつながる方法についてまとめました。

ここまで記事を書いて思ったことは

レビューしてもらう人がレビューしてくれる人の負担を減らすためにはどうすれば良いのか

を考えてPRを作成することが最も重要だと思いました。

また、PRの説明で使う用のテンプレを使ってそれを使い回すのも良い手だと思います。

僕はClipyというアプリにPRのテンプレを登録して使っています。

今後の開発業務の参考になっていたら幸いです。