コードレビューで凹んでも大丈夫、未経験エンジニアの乗り越え方

「コードレビューで指摘ばかりされて、正直心が折れそうだ」——「コードレビュー 未経験」と検索している方の中には、実際に未経験でIT業界に転職し、初めてのプルリクエストで思った以上に多くの指摘を受けて、自分にプログラマーとしての適性がないのではないかと不安になっている方も多いのではないかと思います。私自身、文系・未経験でIT業界に転職した直後、コードレビューで指摘を受け続けて、しばらく自信を失いかけた時期がありました。

この記事では、私が入社後に実際に経験したコードレビューでのやり取りを、指摘を受けて凹んだ具体的な場面から、そこから気持ちを立て直すきっかけになった工夫まで、時系列に沿って紹介します。

この記事でわかること

• 未経験入社した私が、コードレビューで実際にどれくらい・どんな指摘を受けたか
• 指摘を受け続けて自信を失いかけたときの、具体的な心理状態
• 指摘との向き合い方が変わった、2つの具体的なきっかけ

未経験のコードレビューは、想像していたよりずっと指摘が多かった

結論から言うと、未経験で入社した直後のコードレビューは、想像していたよりもはるかに指摘の数が多く、それ自体は決して珍しいことではありませんでした。

理由は、コードの書き方そのものだけでなく、チームで積み上げてきた暗黙のルールや書き方の慣習に、実務経験のない状態ではまだ慣れていないためです。動くコードを書けることと、そのチームの基準に沿ったコードを書けることは、別のスキルなのだと後になって気づきました。

以前の記事IT業界の仕事内容とは？未経験入社の初日から半年のリアルでも少し触れましたが、入社して2〜3ヶ月ほど経った頃、初めて画面の一部の実装を任されたプルリクエストを提出したことがありました。提出した直後は「一通り動くはずだ」と思っていたのですが、SEの同僚からついたレビューコメントは、変数名の付け方、似たような処理の重複、想定外の入力値への対応漏れなど、多岐にわたるものでした。1件や2件ではなく、画面数個分の実装に対して十数件のコメントがついたことに、正直かなり動揺したのを覚えています。

指摘の数の多さは、実力不足の証明ではなく、チームの基準にまだ慣れていない未経験者であれば起こりやすいことなのだと、今では捉えています。

同じプルリクエストが何度も差し戻され、自信を失いかけた時期

指摘を一つずつ直して提出し直しても、また新しい指摘がついて差し戻される、というやり取りが何度か続いた時期があり、このときが精神的には一番きつかったと感じています。

理由は、直せば終わりだと思っていた作業がなかなか終わらず、自分の理解が追いついていないことを繰り返し突きつけられる感覚があったからです。

先ほどのプルリクエストは、結局4回ほど提出し直すことになりました。3回目を提出したときには、さすがに「自分には向いていないのではないか」という考えが頭をよぎりました。ちょうど同じ頃、同じチームの別のメンバーが出したプルリクエストが、コメントもほとんどつかずにすぐ承認されているのをチャットで見かけ、余計に落ち込んだのを覚えています。誰にも相談せず、その日は「今日はもう見たくない」とだけつぶやいてパソコンを閉じてしまいました。

今振り返ると、差し戻しの回数そのものより、「終わりが見えない」という感覚が一番こたえていたのだと思います。

指摘の中身を3つに仕分けてみたら、少し冷静になれた

気持ちが落ち込んだままでは何も変わらないと思い、まず試したのが、受けた指摘を「必須の修正」「保守性に関わる相談」「好みやチームの書き方の範囲」の3つに仕分けてみることでした。

理由は、すべての指摘を同じ重さで受け止めようとしていたことが、必要以上に自分を追い詰めていたと気づいたためです。

実際に、初めての大きなプルリクエストで受けた指摘を仕分け直すと、次のようになりました。

すべての指摘が「自分の実力不足」を意味するわけではないと分かっただけで、指摘を受け取る際の気持ちの重さがかなり軽くなりました。

差し戻しの回数が減ったきっかけになった、提出前チェックの習慣

指摘の仕分けと並行して効果があったのが、プルリクエストを提出する前に、過去に受けた指摘を自分なりのチェックリストにして見直す習慣です。

理由は、同じ種類の指摘を何度も繰り返し受けていることに気づき、それなら提出前に自分で確認すればいいと考えたからです。

私が実際に使っていたチェック項目は、次のようなものです。

• 変数名が処理の中身と合っているか、日本語のローマ字表記が混ざっていないか
• 同じような処理を別の場所にも書いていないか(共通化できないか)
• 入力値がない場合や想定外の値が来た場合の処理を書き忘れていないか
• 確認用に残していたconsole.logやコメントアウトしたコードが残っていないか

このチェックリストを提出前に見返すようになってから、以前は4回ほど差し戻されていたようなプルリクエストが、1〜2回の修正でおおむね承認されるようになったという実感があります。もちろん、これは私が担当していた業務範囲での話であり、内容が複雑になればまた話は変わってくるとは思いますが、少なくとも「同じ指摘を繰り返し受ける」という状態からは抜け出せました。

今振り返って思う、コードレビューの指摘との向き合い方

今では、コードレビューの指摘は自分を否定するものではなく、チームで積み上げてきたコードの品質を保つための仕組みなのだと捉えられるようになりました。

あるとき、経験の長いSEの同僚が過去に出したプルリクエストの履歴をさかのぼって見る機会があり、そこにも他のメンバーからの指摘コメントがいくつもついているのを見つけたことがきっかけでした。指摘の数は経験の有無だけで決まるものではなく、担当した範囲の広さやレビューする人の丁寧さによっても変わってくるのだと分かり、指摘の多さと自分の適性を直結させて考える必要はないと思えるようになりました。

それでも、未経験の時期に受ける指摘の数が多くなりやすいこと自体は事実だと感じています。だからこそ、指摘の中身を仕分けて受け止め方を変えたり、繰り返し受けた指摘を自分なりのチェックリストにしたりと、自分で工夫できる部分から手をつけていくのが、遠回りに見えて一番効果があった方法でした。学習中の指摘との向き合い方については、別の記事未経験でもIT転職スキルは伸ばせる!今日から鍛えたい5つの力でも紹介しているので、あわせて参考にしてみてください。

まとめ

ここまで、未経験でIT業界に転職した私が、コードレビューで指摘を受け続けて凹んだ経験と、そこから気持ちを立て直したきっかけを紹介してきました。

• 未経験のうちはコードレビューの指摘が多くなりやすく、それ自体は珍しいことではない
• 同じプルリクエストが何度も差し戻されると、精神的にもきつくなる時期がある
• 指摘を「必須の修正」「保守性の相談」「好みの範囲」に仕分けると、受け止め方が軽くなる
• 過去の指摘をチェックリスト化して提出前に見直すと、差し戻しの回数を減らせることがある
• 指摘の数は経験の有無だけで決まるものではなく、自分の適性と直結させて考えなくてよい

コードレビューで指摘が続くと落ち込みやすいですが、指摘の中身を整理して受け止め方を工夫していくことで、少しずつ気持ちが楽になっていくのではないかと思います。