最近、コードレビューばかりしていますがレビューってなかなか難しいですよねー。

レビューワーにちゃんと確認してほしいポイントを伝えらた内容ならいいのですがそれがないとこの人一体何をしたいのかわからない？ってなります。

コードレビューをする前にまずは依頼のお作法を書きたいと思います。

①依頼する背景を書くこと。

修正したPRを見た場合この人は何でこの変更をしようとしたんだろうってなります。そこで背景を書くことで仕様面で納得が行くからです。

また、背景から影響範囲を想像できるので背景は書くべきです。

②どんなユーザがどのように使うか機能を書くこと。

一般的な人は検索できることとか、ソートができることしか書いていないことがほとんどです。

それでも通じますが、それだと想定したユーザが業務に沿った機能かどうかを判断できないです。ツールは、業務の効率化だったり反復作業を楽にしたいという要望から直すべきなのに想定したユーザ（ペルソナ）が使うことをイメージした機能を実装できていないとせっかく作っても無意味になってしまうのでどのように検索するか書いた方が良いです。

例えば下記のような依頼だとGoodです。

エンドユーザが、求人を探したいので条件（単価、スキル、勤務時間）を絞り込むような検索機能を追加

③修正した内容のスクリーンショットとURLを貼り付けること。

単純にどんな箇所を修正しているかイメージがつくのと実際のURLがあると検証がしやすいです。

④確認してほしいポイントを書くこと。

レビューワーに見てもらいたいポイントですね。レビューワーは機能が問題なく動作するか、無駄な機能ができていないかなど見ますが、その機能について仕様の知識がない場合は、確認してほしいポイントがあると助かります。

⑤影響範囲を書くこと。

外部システムとの連携だったりしていると、影響範囲を伝えていないと思わぬトラブルに巻き込まれるのでこれは書くべきです。

以上レビューワーにレビューを依頼するポイントでした。

コードレビューの依頼も一般的に５W1Hが基本ですよねー