PRを出すときに個人的に気をつけていること

はじめに

PRの内容は原則ステークホルダー(e.g. :PO、ユーザー)に向けて見せることを意識した構成にしましょう。
レビュワー(もしくは未来のコミッター)はPRを見たときに知りたいことは、コードの流れや処理ではなく背景や実現したいことのはずです。
達成したことを簡潔に、まとまっていて、コードに理解がない人でも分かるように説明する時、その場にはステークホルダーがいるはずですから意識しやすくなるでしょう。

次の項目からは個人的にPRに含めたほうがいい内容と、何故そう思うのかを残しておきます。

WHY(何故)

PRには必ず出すことになった背景や原因があるはずです。
もしこれがPRに書かれていなければ、レビュワーは把握するために関連するJiraやesaなどを探し回ることになるでしょう。
また、レビュワーはプランニングの時の他者の内容まで全て記憶している訳ではないので、認識齟齬を起こす可能性もあると思います。
レビュワーの行動はPR内で完結するように心がけましょう。

WHAT(目的)

PRで達成したい目的を記述します。 レビュワーは目的を認識することで、達成するためのプロセスを考え、もしかしたらコミッターでは思いつかない解決方法を提案してくれるかもしれません。
また、レビュワーは目的から逆算し正しく要件に対して担保されているかを考えると思うので、認知できていない達成するべきことに対してはレビューができません。明文化しておきましょう。

QA(担保)

PRでは要件に対し最善となる解決手段であるか、要件に対して担保されているか、事業ロードマップと見比べて拡張性があるか等について討論すべきです。
UTが通っているか、バグが発生していないか(論外！)についてレビュワーは意識すべきではありません。もし常に低次元的な問題と常に向き合わなければならない状況が続けばコードレビューに対して消極的になっていくでしょう。 レビュワーが気にしなくてもいいように、UTやITは事前に実施し担保されていることを教えて安心させてあげましょう。もしかしたら、ユーズケースが足りないなどの指摘が発生するかもしれませんが受け入れ条件に対しての討論になるので有意義だと思っています。

（ITを貼るときは他者が再現できるようにしておいてください。これは切実な願いです。）

Appendix

レビュワーはあなたとは違う人間ですから、異なる観点でレビューを行いたいと思うかもしれません。
上記のケースの場合、貴方が認知していない領域の情報が必要になりますから、PRに関する情報だけど他の項目に書くほどでもない理由はここに書いておきましょう。
それはきっとレビュワーがレビューするための大切な助けになるはずです。