本記事の概要

新卒から今まで4年間BEエンジニアとして業務に当たってきた日々を振り返り、これやっときゃ今よりも早くジュニア卒業できたなと思った事柄で、特に業務内でできることから3つをピックアップしました。

今回はレビュー編です。別編は気分が乗れば書きます。

筆者の情報

・情報系大学卒業後、IT企業新卒入社(2022) → 転職(2025) → 現在
・ずっとBEエンジニア
・ミドルエンジニアとして、技術面でプロジェクトを引っ張っていくような立ち回りをしている(ちゃんとやれてるかは置いておいて)

本編

1. レビューにポジティブなイメージを持つ

レビューされること自体をポジティブに受け止めることが非常に大切です。

最初は自分のコードに指摘されて、否定されたような気分になるかもしれません。
私もジュニアのころは、頑張って実装したのにめちゃくちゃコメントされて、悲しいような腹立たしいような、でも正しいことを言われているので、どこにもぶつけられない感情を抱えてヤキモキした経験がいくつもあります。

コメントされることのプレッシャー

自身のコードにコメントがたくさんつくと「自分の実装が良くなかったんだ」「迷惑かけたな」「なんて思われてるだろう」と、マイナスな感情を抱えられるかもしれません。

ですが気にしないでください。
レビュワーは意外と「この実装わかるなぁ...同じことして昔指摘されたっけ...懐かしいなぁ。頑張れ〜、成長応援してるよ」みたいなこと思ってます。
先輩エンジニアって感情表現が苦手なだけで意外と優しい人が多いんですよ(当社比)。

...となると、レビューのマイナスなイメージはあなただけが持っているもの。あなたがレビューをどう捉えるか次第になると思います。

レビューは最高の学び場

意地悪でコメントをしているわけじゃないということを理解いただけたかと思います。
でも、ということは「レビューを受ける」 = 「シンプルに技術力が足りていない」ってことになるじゃん...と思われるかもしれません。

ここでいう「技術力」とはなんでしょうか。

技術力

そもそも、ジュニアとミドル以上で求められる「技術力」は異なります。

ジュニアに求められる技術力を「動くコードが書けること」だとします。

対して、ミドル以上に求められる技術力は、「プロジェクト、ビジネスを成功に持っていける実装を行える能力」です。すごくざっくり書きましたが、セキュリティやパフォーマンス、その他たくさんの求められる能力をまとめるとそんな感じです。

では、エンジニアという大きな括りで求められるのはどちらかというと、後者です。

つまり、ジュニアに区分されるエンジニアは、エンジニアに求められる「技術力」が不足している、と判断されているということです。

ジュニアに対するコメントが多くなる理由は、ジュニアに求められる「技術力」とエンジニアに求められる「技術力」、両方で指摘があるからです。

レビューから得られるもの

なぜジュニアに対するレビューが多いかと、実際に自身の受けたレビューを振り返れば、自身のコメント量に納得性が出てくると思います。
また同時に、自身がエンジニアとして成長する上で、レビューがどれほど重要かもわかったのではないでしょうか。

レビュアーは実装者が備えていない知識や視座、経験を以てレビューを行います。

エンジニアにとってレビューは、レベルに関わらず、
自分では知り得なかった、成長できるポイントを気付かせてくれる最高の学び場
なのです。

ここで得られる知識・経験は「とりあえず技術書を読む」「Qiitaの気になった記事を読む」なんてことの何十倍も価値のある知識です。

あなたがジュニアレベルであるなら、「技術力が足りていない」ということは受け止めてください。
もし気持ちを整理することができれば、レビューされることが自分にとってプラスにしかならない、と思えてくるのではないでしょうか。

2. レビューのコメントは意図まで理解する

先述のように、レビューは自分では気が付かないことを理解する機会です。
ただ指摘された内容をそのまま対応するだけだと、その機会を自ら手放していることになります。

コメントには必ず意図があります。
そのコメントがどういった理由でつけられたのか必ず理解し、自身の知識へと昇華してください。

やり方

私がコメントする際は、コーディング規約に則っていないなどの些細な指摘でない限り、極力指摘 + 説明 + 実装例(+ 他案)を記載しています。こういったコメントは読んでわからないところを調べるだけで十分かと思います。
しかし、丁寧にコメントを書く時間のある人ばかりではありません。先輩エンジニア、結構忙しいんです。
基本は指摘のみ、や指摘 + 理由が多いと思います。

そういったコメントがついた際には以下の工程で理解を深めるのがおすすめです。

まず自分で解釈する
自身の解釈が正しいか調べる
わからない/解釈に自信がない場合は、コメントの返信で自身の理解を述べた上でレビュワーに質問する

1,2はAIを使ってもいいと思います。
ただし、AIはモデルによって質問者の意見に迎合するものがあるのと、ハルシネーションがあることに注意してください。

わからないことを質問する際、「怖いな」「申し訳ないな」と思われるかもしれませんが、先輩エンジニアからするとウェルカム、むしろ嬉しいくらいです。
ジュニアの成長を促すのもミドル以上の務めですし、プロジェクトとしてもメンバーのレベルが上がればタスクの遂行が効率的に行えるようになって、悪いことなんかひとつもないです。(あと、個人的に頼ってくれるとシンプルに嬉しい☺️)
ガンガン質問してください。

ただし、必ず1,2の工程は踏んでください。

3. 人のPR(レビュー依頼)を見る

別のメンバーが出しているPRでも、当然コメントがつきます。
大抵の場合、そういったコメントは非常に勉強になります。
なぜなら、そのPRの実装者は自分とは異なる考え方なので、自分では思いつきもしなかった実装がされています。それに対するコメントは、さらに未知の世界です。

きっと、ハッと目が覚めるような、今までの固定観念が打ち砕かれるような発見があると思います。

やり方

とはいえ、ジュニアで人の実装を見るには非常に時間がかかります。それに、ジュニアが人のPRを見るなんてタスクを振る側は想定していません。
なので、最初はコードを読まずに、他の人のPRについているコメントと、コメントされている部分のコードだけ読みましょう。それだけでも新たな知識を身につけるには十分です。

人のPRで誰かに質問したくなった場合、コメントの返信で行うのはNGです。
コメント欄はあくまで当人同士のやり取りを行う場で、あなたは勉強のためにそのPRをたまたま見ていたということを忘れないでください。

質問するときはレビューのコメントは意図まで理解するのやり方で記載した1,2を行った後で、チャットツールで行うようにしてください。
DMかグループチャットでするかは、プロジェクトや組織の方針に従うようにしてください。
当然、ウェルカムですよ。

あとがき

レビューは業務において非常に重要ですが、エンジニアが成長する上でも大きな役割を担ってくれるということを理解いただければ幸いです。