第7章：PR 説明の型（何を / なぜ / 影響 / テスト / ロールバック）

この章で学ぶこと

• PR の説明はレビュー効率を上げるために書く
• 影響範囲とテスト、ロールバックを明記する
• 関連 Issue と受け入れ条件に紐付ける
• レビューコメントへの対応方針を明示する

成果物（書けるようになるもの）

• PR テンプレを使える（付録: PR テンプレ）
• レビューで確認すべき観点を提示できる

本文

PR は差分だけでは意図が伝わらない。意図と影響を明記することで、レビューの漏れが減る。

最小の PR 説明

• 何を: 変更点
• なぜ: 背景/目的
• 影響: 互換性/運用
• テスト: 何を確認したか
• ロールバック: 戻し方
• 関連: Issue
• レビュー観点: 何を重点確認してほしいか
• 未確定点: merge 前に解消すべきか、follow-up でよいか

テストできない場合は、「できない理由」と「代替の確認方法（ログ/監視/段階リリースなど）」を明記する。テスト未実施を隠すと、本番影響の判断ができない。

Issue との対応表

PR body では、Issue の受け入れ条件をどの変更・確認で満たしたかを対応づける。

対応表があると、レビュー担当は「差分を全部読む前に、何を満たす PR なのか」を把握できる。受け入れ条件に未達がある場合は、merge 前に直すのか、follow-up Issue に分けるのかを明記する。

レビューコメントへの対応方針

レビューでは、指摘そのものだけでなく「どう扱ったか」も証跡になる。

• 修正した: どのコミット/差分で直したかを返信する
• 対応しない: スコープ外、仕様上不要、別 Issue 化などの理由を返信する
• suggestion を採用した: そのまま採用したか、調整して採用したかを返信する
• 確認中: 期限、確認方法、次回更新予定を書く

merge 前に、未解決 review thread が 0 であることを確認する。未解決のまま merge すると、レビューで合意していないリスクが残る。

注意点（実務運用）

• 受け入れ条件に対して、どこが満たされたか（または未達か）を説明する
• 破壊的変更/データ移行がある場合は、適用手順と切り戻し判断基準を追記する
• レビュー観点（見てほしい順序/注目点）を 1〜3 行で提示する

具体例（悪い例→良い例）

悪い例

説明: 修正しました
テスト: してません

良い例

何を: 入力フォームのバリデーション追加
なぜ: 誤操作が多い
影響: 保存失敗時のエラーメッセージ変更
テスト: 不正入力/境界値/回帰
ロールバック: フラグを OFF
関連: #123

チェックリスト

• 何を/なぜが書かれている
• 影響範囲が書かれている
• テストとロールバックが書かれている
• 関連 Issue がある
• 受け入れ条件と確認結果の対応表がある
• 未解決 review thread が 0 である

まとめ

• PR の差分だけでは意図が伝わらないため、背景/影響/テスト/ロールバックで補完する
• テスト未実施や不確実性は、理由と代替の確認方法を明記する
• 関連 Issue と受け入れ条件に紐付け、レビューコメント対応と未解決 thread 0 を確認してから merge する

次章への接続

• 次章: 第8章