【SE仕事術】レビュー依頼の書き方｜プルリクエストに添える5項目と文例

「対応しました。レビューお願いします」と届いて差分を開いたものの、なぜ変えたのか分からず、先にチケットを探しに行く。そんな手間は、依頼する側が本文に変更の理由と、判断してほしい論点を置いておくだけで減らせます。

プルリクエスト本文に書く5項目

項目	何を書くか	検索画面の修正例
目的	どんな条件で何が困るか	検索語の前後に空白があると結果が出ない
変更範囲	対象と対象外	検索画面の入力整形だけ。API側の処理は現行どおり
レビュー観点	何を判断してほしいか	全角空白も取り除く仕様でよいか
確認結果	通ったテストと未確認事項	通常入力、半角・全角空白付きは確認済み。実機は未確認
期限	いつまでに何が必要か、その理由	金曜の判定に向け、木曜15時までに初回コメント

「問題ないか見てください」では範囲が広く、優先順位を決めにくくなります。「全角空白を除く仕様でよいか」「呼び出し元にも影響が出るか」のように、答えが返せる問いにするとレビューが進みます。関連チケットは、判断材料になる仕様や経緯へ直接たどれるように添えます。

PRタイトルと依頼先を先に決める

タイトルは「不具合修正」「検索画面対応」より、「検索語の前後の空白を除去して0件表示を防ぐ」のように、変わる挙動が分かる形にします。詳細を読む前に対象が分かるので、担当者は既存の仕様や過去の修正を思い出しやすくなります。

依頼先は、今回判断してほしい箇所に合わせます。画面の挙動を見てほしい場合と、共通の入力処理への影響を見てほしい場合では、詳しい人が異なります。チームでレビュー担当や承認ルールが決まっていればそちらを優先し、複数の相手に頼むときは、それぞれに見てほしい点を書きます。

そのまま使える依頼文の例

目的：検索語の前後に空白があると結果が0件になる問題を修正します。関連チケット：[URL]

変更範囲：検索画面で入力語の前後の空白を除きます。語句の途中の空白と、API側の処理は現行どおりです。

見てほしい点：前後の全角空白も除去する仕様でよいか、空白だけを入力したときに既存の未入力時と同じ動きになるかを確認してください。

確認結果：通常入力、前後に半角・全角空白がある入力、空白だけの入力を確認済み。モバイル実機は未確認で、担当者が木曜午前に確認します。

期限：金曜のリリース判定に間に合うよう、木曜15時までに初回コメントをお願いします。難しい場合は、着手できる時間を教えてください。

チャットでも依頼する場合は、プルリクエストのURLと優先して見てほしい点、期限を短く共有します。仕様や確認結果はプルリクエストに置き、後から確認した人も同じ情報を参照できるようにします。

GitHubのレビュー依頼とチャットの文面を分ける

GitHubでは、プルリクエストを開き、右側の「Reviewers（レビュー担当者）」からレビューを頼みたい人を選びます。選べる相手やチームへの依頼可否は、リポジトリの権限や設定などで変わります。再レビューが必要な場合は、変更点をコメントで知らせたうえで、レビュー担当者の欄から再依頼できます。

検索画面の修正PRです［URL］。全角空白だけを入力したときの挙動を先に見ていただけますか。金曜の判定に使うため、木曜15時までに初回コメントがあると助かります。

チャットでリンクを送る場合も、差分の説明やテスト結果の本体はPR側に残します。期限までに相手が着手できないと分かったら、担当の調整やリリース判定日の見直しを先に行います。

出典　GitHub公式「プルリクエストレビューを依頼する」

差分が大きいときは、読む順番を示す

生成ファイルや機械的な置換が混ざる場合は、「最初に入力整形の処理とテストを確認。生成ファイルは元の変更から出力したもの」のように、見る順番と各差分の関係を示します。安全に分けられる変更であれば、動作を変えない整理と仕様変更を分けると、レビューの論点が絞れます。

画面修正は変更前後の画像、データ修正は影響を受ける条件など、差分だけでは読み取りにくい情報を添えます。画像やログを共有するときは、顧客情報や認証情報が写り込んでいないかも確認します。

修正後は、再確認してほしい点とテスト結果を返す

コメントを受けて修正したら、「どの指摘に、どう対応したか」「追加で何を確認したか」を返信します。たとえば「全角空白だけのケースで既存の未入力時と同じ表示になるよう修正し、テストを追加しました。入力整形の分岐を再確認してください」と書けば、相手は差分を追いやすくなります。

未確認のテストが残る場合は、担当と確認予定を明記します。承認後に変更を加えたら、前回の承認時から変わった箇所を示し、チームのルールに沿って再レビューを依頼します。

小さな修正用に残しておくテンプレート

タイトル：［対象の画面・処理］で［変える挙動］

背景・目的：［困っている状況と関連チケット］

変更範囲：［変えた箇所／今回の対象外］

見てほしい点：［判断してほしい問い］

確認結果：［試した条件／未確認事項と確認予定］

期限：［日付・時刻／初回コメントか承認か／理由］

短いPRなら各欄は一行で十分です。設定変更やデータ移行など、戻し方が判断に影響する変更では、反映順、影響を受ける環境、切り戻しの条件も添えます。下書き段階で方向性だけ相談する場合は、正式レビューの前であることと、今回確認してほしい点を冒頭に書きましょう。