※ この記事はmktakuya Advent Calendar 2025 3日目の記事です。
Pull Request以外のレビューを依頼するときはレビューの期待値も伝えると良いなと思っている話。
ソフトウェアエンジニアとして受けるレビューで最も典型的なものは、Pull Requestに対するレビューだろう。
PRはレビュワーに求めるアクションが明確だ。GitHub上でレビュワーにアサインされた時点で、「これをマージして良いか」という明確な判断基準のもと、コードの可読性や成果物の品質といった観点でレビューできる。最終的にApproveかRequest Changesをつけてほしい、というところまで明確な期待値があるだろう。
一方でPR以外――例えば設計・運用のドキュメントや業務改善の提案など――だと話が違ってくる。単にレビューを依頼しても、その判断基準や観点が合意されているわけではない。そもそも成果物の完成度、それが生煮え段階のたたき台なのか、あるいは合意でき次第すぐに走り始めるつもりの最終稿なのかわからないこともあるだろう。これでは、どういった期待値でレビューを依頼されているのかがわからない。
そのため、PR以外のレビューを依頼するときは、その期待値をセットで伝えると良い。具体的には、レビューしてほしい観点と成果物のステータスを伝えられれば良いだろう。
例えば、次のような一言を添えることができそうだ。
- エンジニア間で方針を握るためのたたき台です。技術的な妥当性を見てほしいです。良さそうだったら清書してリファインメントに持って行きます！
- これで良さそうだったら顧客に送ってしまいます！表現に曖昧な点や誤りがあれば指摘してほしいです！
このようにレビューの期待値を伝えると、レビュワーは迷わずに済み、依頼者はほしいフィードバックを確実に得られる。コミュニケーションの質が向上する。また、レビュー前にレビュワーに伝える期待値を考える過程自体がある種のセルフレビューとなり、その成果物の質を上げることにもつながるはずだ。
この記事に書いたことは、まさに過去の自分が受けたフィードバックだ。前職で一緒に働いていた人に、「Notionで構成図書きました！レビューお願いします！」と雑にぶん投げたらそう言ってくれた。
ほかにもたくさんのフィードバックをくれて、もともと低かった自分の仕事の質や向き合い方をかなり底上げしてくれた。また一緒に働きたいなーと思う。
リファラルで声かけたら怒られ発生するかな？
