はじめに

チームで開発する際にはGitHubのプルリクエスト(以下PR)機能を使って「ソースコードレビュー」をする機会が多いと思います。
しかし、PRを作成をする人により「記載内容」がバラバラであるため、レビューがしづらいなと感じることはありませんか？
そこで今回は「PRテンプレート」を使ってこの問題を簡単に解決しよう！という内容です。

※後から名称だけ登場しますが、私は開発に以下ツールを使用しています。

チャットツール：Slack
チケット管理ツール：Backlog
Webデザインツール：Figma

こんな人に読んでほしい

チーム開発している
GitHubを使っている
レビューをすることがある
レビュー依頼をすることがある

レビューがしづらいと感じる原因

そもそもPRの「記載内容」がバラバラであると、なぜ「レビューがしづらい」と感じるのか。
私はざっくり以下が原因であると感じます。
※PR運用方法のベストプラクティスについてはここでは言及しません。

この実装の目的(何がしたいのか)が読み取りづらい
いつまでにマージしたいのかわからない
時にはチャットツールやチケット管理ツールなどから背景を読み取る必要がある

レビューがつらいPR事例

私がつらいなと感じるPR事例を紹介します。
少し極端ですが。

パターンA(情報が少ない)

# 概要

- 機能Aの追加

レビューお願いします！

機能Aの仕様は？デザインは？
ソースコードからすべてを読み取るのはつらい。

パターンB(内容が冗長)

前回のMTGにてクライアントの〇〇さんから
フォーム中項目Bの下へ項目Aを追加したいという要望があり、
フロントエンドでは項目のタイトルとプルダウン表示、
選択がない場合にはバリデーションメッセージの表示、
また単体テストも実装しました。
レイアウトについてはFigmaをご覧ください。
XX月XX日には結合テストのため
△△ブランチへマージする必要があり、
お忙しいところ恐縮ですが早めにレビューお願いします！

たくさん書いてくれるのでなんとか読み取れますが、欲しい情報をピンポイントで取得しづらい。

上記のようなPRを見るのは(特に忙しい時には)つらいと感じますよね。
この「つらい」を解決するために、簡潔にPRに情報を集約させることでレビューの負担を減らそうと考えました。

レビュアーのメリット

実装の目的が読み取れる
情報取得のためのレビューイとのコミュニケーションを減らすことができる

レビューイのメリット

「何を記載すれば良いか」を考える時間を短縮できる
「マージ期限」など付加情報をレビュアーに伝えられる

テンプレート事例

実際にテンプレートを作成する前に、私がプロジェクトで運用しているテンプレートを紹介します。
内容はプロジェクトやチームに合わせてカスタマイズしてください。

## 概要
- フォームへ項目Aを追加

## 背景/経緯
- クライアントより項目Aを追加したいと要望があったため

## 対応内容
- フォームへの項目追加
- バリデーションメッセージ表示
- フロントエンドテスト実装

## マージ期日
XX月XX日までにマージしたく、レビューお願いします

## バックログチケット
[チケットタイトル](URL)

## エビデンス
- フォーム内の項目Aレイアウト
（ここに画像をFigmaのURLや画像を添付する）

## 備考
- 何かあればここに記載する

テンプレートの作り方

それでは実際にテンプレートを作っていきましょう。
やることは次の2つだけです。

.githubフォルダ作成
pull_request_template.md作成

.githubフォルダ作成

プロジェクトのルートで次のコマンド使ってフォルダを作成してください。

mkdir .github

pull_request_template.md作成

作成したフォルダ以下にファイルを作成します。

touch .github/pull_request_template.md

そして記載したい内容をマークダウンで記載してください。

GitHubへの反映方法

テンプレートを作成したブランチをmainブランチへマージすれば、次回PR作成時にdescriptionへ反映されます。

まとめ

今回はPRテンプレートの作成方法を紹介しました。
テンプレートを使うことで、少しでもレビューが楽になれば幸いです。
ここまで読んでくださりありがとうございました！