実務経験がないまま人のコードをレビューして分かったこと

2026年9月2日 22:30

待機期間に入ってから、社内業務として若手のコードレビューを担当することになりました。Javaで書かれたコードを読んで、気になったところを指摘する役割です。

困ったのは、私自身にJavaの実務経験がないことでした。研修で触れたのと、Java Silverに向けて自分で勉強している、それだけです。書いたことのない言語のコードを読んで、人に指摘するということで、引き受けたときは、務まるのかとかなり不安でした。

やってみて分かったことを書きます。

難しいことは見ていない

レビューというと、設計の妥当性とかアルゴリズムの効率とか、そういう深いところを指摘するものだと思っていました。実際に私が見ているのは、もっと手前です。

変数やメソッドの名前。コメントの書き方。同じ処理が何度も書かれていないか。要件との整合性が取れているか。

特に整合性については、言語の知識がなくても指摘できます。仕様に書いてある文言と、実際に出てくるメッセージが違う。出力結果が想定とずれている。仕様書とコードを突き合わせれば見つかります。

命名も同じで、読んで意味が取れない名前がついていれば、それは指摘できます。むしろその言語に慣れていない自分が読んで分からないのなら、慣れている人が読んでも分かりにくい可能性はあります。

引き受ける前に想像していたレビューと、実際にやっているレビューは、かなり違いました。

読むだけで済ませないようにしています。

自分のPCに研修生と同じ環境を用意して、GitHubで共有されたコードを持ってきて動かす。手順としてはそれだけですが、これをやるかどうかで指摘の中身が変わりました。

読んでいると、分かった気になってしまいます。書き方は正しそうに見えるのに、動かすと想定と違うものが出てくる。逆に、読んだときに引っかかった書き方が、動かしてみると意図が通っていることもあります。

環境構築そのものは面倒です。ただ一度作れば毎回使えますし、実務経験がないぶん頭の中でコードの動きを追いきれないので、実際に動かすことでそこを補っている形になります。

それでも分からないものは出てきます。見たことのない書き方や、なぜそう書くのか理解できない箇所です。

まず過去の質問をまとめた資料を見に行きます。同じ研修を通った人が詰まった箇所は、だいたいそこに残っています。それでも解決しなければ、詳しい他のレビュアーに聞きます。

順番を先に決めておくのが大事でした。決めていないと、分からない箇所を前にしたときに「たぶん大丈夫だろう」で流してしまいます。指摘が漏れるだけならまだしも、自分も何も分からないまま次に進むことになります。

レビューされる側の若手には、自分に実務経験がないことは伝えていません。

ただ、私も同じ内容を研修でやっているので、その話はできます。どのあたりで詰まりやすいか、なぜその課題が出されているのか。実務経験の長い人にはない立ち位置かもしれません。

技術で上回っているわけではないけれど、通ってきた道が同じなので、相手がどこで止まっているか見当がつく。これは思っていたより役に立ちました。

ここまで書いておいて何ですが、この経験が評価につながっているかというと、正直そうでもありません。

スキルシートにはレビュー担当として書いています。面談で「実務経験がないのに、どうやってレビューしているんですか」と聞かれることもあって、そのときは環境を作って動かしていることや、分からないときの調べ方を答えています。

ただ、手応えはあまりありません。相手が知りたいのはコードを書けるかどうかで、読んで指摘できることはその代わりにはならないのだと思います。

面談での受け答えについては、別の記事にもう少し詳しく書いています。

そこは受け止めています。レビュー経験があればアサインが決まる、というほど単純な話ではありません。

人の書いたコードを読んで、なぜそう書いたのかを考える。動かして確かめる。分からなければ調べる。

これを繰り返していると、自分がコードを書くときに気をつけたい場所が少しずつ見えてきます。実務経験がないぶん、人のコードから拾えるものは多いです。待機中にできることを探しているなら、レビューは選択肢のひとつになると思います。

待機期間にやっている他のことについて、こちらにもまとめています。