たとえるなら
雑誌記事の校正・校閲です。書いた本人は内容を知りすぎているせいで、誤字や説明不足に気づけません。別の人の新鮮な目でチェックしてもらうことで、読者に届く前に品質がぐっと上がります。
もう少しくわしく
レビュー（コードレビュー）は、あるエンジニアが書いたソースコードを、別のエンジニアが読んで確認する工程です。バグの見落としがないか、わかりにくい書き方になっていないか、チームのルールに沿っているかなどをチェックし、問題がなければ承認されて正式にチームのコードに取り込まれます。多くの現場で、レビューを通らないコードは取り込めないルールになっています。
レビューで見られるのは、大きく4つです。仕様どおりに動くか、不具合の種が残っていないか、あとから読む人が理解できる書き方か、チームの決めごとに沿っているか。加えて「こう書くともっと読みやすいですよ」という知識の交換や、「この部分はこういう意図です」という背景の共有もこの場で行われます。先輩のコメントは、新人にとって最高の教材になります。
混同されやすいのがテストとの違いです。テストは動かして確かめる作業、レビューは人が読んで確かめる作業で、動くかどうかだけでなく半年後に読めるかまで見るのがレビューの役目です。どちらかがあればもう一方は不要という関係ではありません。そしてレビューはダメ出しではありません。見ているのは人格ではなくコードで、指摘の数が多いのは能力の評価ではなく、それだけ丁寧に読まれたという意味です。
流れはこうです。書いた人が変更一式をプルリクエストとして出し、何を変えたか、なぜそうしたかを説明します。読む人がコメントを付け、書いた人は直すか、意図を説明して相談する。合意できたら承認され、本体に取り込まれます。役職や年次に関係なく、メンバー同士で見合うのが一般的で、後輩が先輩のコードを読む場面も普通にあります。誰が読むかを順番で決めている現場もあり、体制によって違います。
よくあるのは、一度に大量の変更をまとめて出すことです。読む側の負担が大きく見落としも増えるため、小さく分けて出すほうが結局は早く通ります。書いた人側の失敗としては、指摘を攻撃と受け取って黙り込んでしまうこと。読む側にも落とし穴があり、好みの押しつけと本当に直すべき点を混ぜると、相手はどれを直せばいいのか分からなくなります。
働きはじめたばかりの人が最初に覚えたいのは、指摘は自分への否定ではないという感覚です。納得できないときは「こう考えて書きました」と意図を伝えてかまいません。意味がわからない指摘は、その場で聞くのが正解です。自分が読む側になったら、良い部分もひとこと書き添えると場が和みます。エンジニアではない立場でも、仕様の読み違いはこの場で気づけます。
レビューは時間のかかる工程なので、日程が押すと省かれがちです。しかしここを飛ばした変更は、公開後に問題として戻ってくることが多く、結局は高くつきます。伝え方も文化として大切にされていて、「なぜそう書いたのですか」と意図を尋ねる、修正案を添えて提案する、といった作法が根づいている現場ほど、レビューが学びの場として機能します。
現場での使われ方
「このプルリクエスト、レビューお願いします」
自分が書いた変更一式を確認してほしいという依頼です。GitHubなどの画面上でコメントを付け合いながら進めるのが一般的で、やりとりはそのまま記録として残ります。
「レビューで指摘もらったので、直してから取り込みます」
確認者からの指摘を反映したうえで、正式にチームのコードへ合流させるという流れの報告です。指摘が残っている段階ではまだ完成ではなく、テストにも進めません。
「変更が大きいので、分けて出してもらえますか」
一度に読む量が多すぎると見落としが増えるため、小さい単位に分割してほしいという依頼です。出す側の手間は増えますが、通るまでの時間は短くなることが多いです。
「これは好みの範囲なので、直さなくて大丈夫です」
指摘のうち、必ず直すべき点ではなく提案にとどまるものだという補足です。どこまで直せばよいかの線引きをあえて言葉にすることで、受け取る側が迷わなくなります。
よくある質問
レビューは偉い人がするものですか？
役職や年次に関係なく、チームのメンバー同士で行うのが一般的です。後輩が先輩のコードをレビューすることも普通にあり、お互いの目でチェックし合うのが健全なチームとされています。読む側も他人の書き方や考え方に触れられるので、どちらにとっても学びのある工程になります。
レビューで指摘が多いと評価が下がりますか？
下がりません。指摘の数は、丁寧に読まれた量と変更の難しさを表しているだけです。見ているのはコードであって人格ではないので、書いた人の力量の点数として扱われるものではありません。指摘を受けて直しながら覚えていくのが、いちばん早い上達の道になります。
指摘に納得できないときはどうすればいいですか？
そのまま直す必要はありません。「こういう理由でこう書きました」と意図を伝えて相談してください。レビューは議論の場なので、説明を聞いて指摘した側が引くこともよくあります。それでも決まらないときは、第三者に入ってもらって判断するのが一般的な進め方です。
レビューとテストは両方必要なのですか？
目的が違うので両方行います。テストは実際に動かして期待どおりかを確かめる作業、レビューは人が読んで読みにくさや危うい書き方に気づく作業です。動くけれど半年後に誰も直せないコードは、動かすだけでは見つからないため、人が読んで気づく工程が必要になります。
レビューはどれくらいで返すものですか？
変更の大きさによりますが、長く放置されると書いた人の作業が止まってしまうため、当日か翌日までに返すことを目安にする現場が多いです。すぐ読めないときは、いつ見られるかだけ先に伝えておくと、相手はその間に別の作業へ移れます。待ち時間を減らす気配りです。
