最近とあるPJで一人エンジニアとしてコードを書いていたところ、レビューをもらうときに特定の人にしか依頼ができずにレビュワーの負担を強めたりリリースが遅くなるといったことがあった。そのPJは社内でも新しい技術セットを使ったもので、設計から開発、テストまでほぼ一人で進めて来たこともあってレビューのタイミングでいきなりチーム外の人にお願いするのはハードルが高いものでもあった。
PJが終わってからどうすればもっと上手くレビューをお願いできたのか？と思い、社内のエンジニアに質問したところ次のようなコメントをいただいたので、次のPJの糧にしようと思い残しておく。
1. 設計レビュー会を開き、チーム外の人を巻き込む
新しい技術セットを導入するとコードレビューのハードルがグッと上がるが、なぜその技術を導入したのか？全体のアーキテクチャがどう変わるのかなどを事前に設計レビューしてもらい、事前知識を持っておいてもらうことでコードレビューがしやすくなる。
また、レビュー会に参加してもらう人には後々PRが投げられた時にレビューしてもらうようにネゴしておくことも大事。
2. PRには変更の全体像をまとめたドキュメントのリンクを貼ってPRの位置付けを説明する
Design DocなりADRなりなんでもいいけど、チーム外の人がどのような変更を加えるのかをパッと理解できたり、深く知りたいときに非同期で理解できる状況を作ることが大事。特に複数のPRを出す時には、この変更が全体のうちのどこを指すのかがわかりやすくなっているとレビューしやすい。これがないとレビュワーが過去のPRを見て、必要な情報をピックアップして理解しないといけないので負担が大きい。
どうやったらチーム外の人を上手く巻き込んで、1人PJを上手く回せるのか、これからも勉強していきたい。
