こんにちは。技術開発室の井上です。

先日、このブログに レビュー指摘で凹まないための、ゆるっとメンタルライフハック という記事が投稿されました。
「レビューを受けて凹みそうになったら、こういう考え方をもってメンタルを維持しましょう」という趣旨の、非常に良い記事です。

しかし、レビューというものはレビューする側とされる側の両者が互いに協力して成立するものです。レビューで発生した苦い体験やトラブルを「レビューを受けた側の気の持ちよう」だけで解消するのは限界があります。
そこで今回、レビューする側が気を付けるべきことについてお話します。

どんな観点でレビューするかを考えておく

レビューをする際、まずはレビューする観点をうっすらでも良いので考えておきましょう。
設計書なら、

• 要件に則った設計になっているか
• 適切な文章表現になっているか（解釈が一意に定まらない表現はないかなど）
• このドキュメントをもとに実装は可能か

ソースコードなら、

• 設計書通りの実装になっているか
• コーディング規約に則った実装になっているか
• 変数、メソッドなどの命名は適切か
• 変数、メソッドのスコープは適切か
• 単一責任の原則は守られているか

などですね。
このようにレビュー観点を最初に考えておくことで、見落としを減らせます。これで「どこを見たら良いかわからなくて指摘事項出せないな…」みたいな問題は減らせるでしょう。

指摘するなら「どう改善すべきか」も言おう

レビューで改善すべき箇所を指摘する時に、「ここ良くないです」だけ言うのはやめましょう。「こう直した方が良いです」まで言うべきです。
これをしっかり言わないと、レビューを受けた側が、

• どう対応したら良いのかわからず悩む
• レビューした側が想定していない対応をしてしまう

といったトラブルを招くリスクがあります。
レビューする側が適切な対応方針を提示できれば、そのリスクをかなり軽減できます。

また、対応方針を提示する際、その方針が推奨される理由や背景情報を付け足せるとさらに良いですね。
レビューを受けた側も理解が深まるし納得しやすいでしょう。

「指摘」と「確認」は明示的に分けよう

例えば、レビューした側から「ここ何でこういう実装になってるんですか？」とだけ言われたら、レビューを受けた側は「これ指摘なんだろうか、ただ確認してるだけなんだろうか」と、悩んでしまう可能性があります。
その結果、ただの確認だから対応不要のはずのものにまで余計な対応をしてしまう、なんてことが起きるかもしれません。
逆に、レビューする側は指摘のつもりで書いていても、受けた側が「単なる確認だ」と判断して、回答だけして対応しない、ということもあり得ます。
対策としては単純で、レビュー記録に、「指摘」なのか「確認」なのかを明記すれば良いです。

指摘内容に重み付けをしよう

指摘内容には、「対応必須」なのか、「やってもやらなくても良い」なのか、重み付けをすべきです。
重み付けが無いと、指摘事項が大量に出た時に、対応内容の優先度がつけにくくなります。
また、特にコードの書き方などの指摘は、個人の好みによるところが大きかったりします。
そういう時は、対応の優先度を下げる意味でも、「私はこれよりこっちの書き方のほうが好み」ぐらいの指摘にとどめておきましょう。
（明らかに可読性を下げるようなコードだったら確実に直してもらった方が良いですが…）

うまくできているところは褒めたほうが良い

ややもすると、レビュー結果は「指摘」と「確認事項」ばかりになりがちです。ですが、良くできている部分については、褒めましょう。
そうすることで、作業者のモチベーションの増加が見込める他、「ここまではちゃんとできている」という共通認識を、レビューする側とされる側で確実に持てるという効果もあります。

とは言え批判的な視点で見ることも重要

ここまで、レビューを受ける側が快適に作業できるように、上述のような配慮をした方が良い、という話をしてきました。
が、それはそれとして、成果物の品質を高めるためには、粗探しをするぐらいの気持ちで、批判的な視点をもってレビューすることが重要です。
相手への伝え方にさえ配慮できるなら、指摘事項や自分の考えはどんどん出していくべきです。

余談ですが、会議やレビューの場で、あえて批判的な視点で物事を見て反対意見を出す役割のことを「デビルズアドボケイト」と言います。
最近は生成AIへの指示の出し方のコツ、みたいな文脈でよく耳にしますね。

まとめ

レビューを受ける側の認知負荷を下げ、悩ませずに済むためのテクニックについて紹介しました。
レビューをする側と受ける側、お互いに協力してうまいことやっていきましょう。