コードレビュー文化がない自社開発、技術力停滞の見抜き方

「LGTMです」——それだけが書かれたコメント欄を見て、Kさんは自分の書いたコードがちゃんと読まれているのか分からなくなりました。承認までにかかった時間は、投稿から3分。

私はIT・Web業界を中心に800名以上の転職支援を担当してきましたが、「自社開発」「裁量あり」という求人票の言葉を信じて転職した先で、コードレビューやテストの文化がほとんどないことに入社後気づく、という相談は決して珍しくありません。今回は、そうした環境で技術力の伸び悩みに気づいたKさんの事例をもとに、入社前に見抜けなかった理由と、現職での立て直し・再転職の判断基準を実際のやり取りを交えてお伝えします。

目次

1. コードレビュー文化がない自社開発、Kさんが半年で気づいた停滞
2. なぜ「自社開発」「裁量あり」の求人票では見抜けなかったのか
3. 技術力は「十分条件」ではなく「参加チケット」に変わっている
4. カジュアル面談でレビュー体制の実態を確認する質問
5. 現職で立て直す、レビューの仕組みを自分から持ち込む選択肢
6. それでも変わらないとき、再転職に踏み切る判断基準
7. Kさんがその後どう動いたか
8. よくある質問
9. まとめ

コードレビュー文化がない自社開発、Kさんが半年で気づいた停滞

Kさん(30歳・経験6年)は、受託開発会社でECサイト構築の案件を複数クライアント分抱えるバックエンドエンジニアでした。要件通りに動くものを期限内に納めることが評価の中心で、「もっと技術的な力を伸ばしたい」という焦りを常に抱えていたそうです。

転職先に選んだのは、社員22名ほどのシリーズAのBtoB SaaS企業。求人票には「自社開発」「裁量あり」「モダンな技術スタック」という言葉が並び、面接でも技術的な深掘りより人柄重視の質問が多く、Kさんは「技術に理解のある環境なのだろう」と受け止めて内定を承諾しました。

入社後、最初の1ヶ月は歓迎ムードで過ぎていきます。ただ、出したPull Requestに付くコメントは「LGTMです」の一言だけか、コメントすらつかずに自分でマージすることも許容されている状態でした。テストコードは既存のコードベースにほぼ存在せず、CIも整っていません。

最初はKさんもこれを「裁量」だと解釈していました。しかし3ヶ月が過ぎたあたりから、自分のエラーハンドリングの書き方や設計判断が本当に適切なのか、誰にも指摘されないまま実装が積み重なっていく状態に違和感を持ち始めます。上司に「これでいいですか」と聞いても、返ってくるのは「動いていれば大丈夫です」という一言でした。

決定的だったのは半年後、業務外で参加した勉強会でのLT発表です。他社のエンジニアがN+1問題の解消事例を発表していたのを聞いて、Kさんは自分のコードに同じ問題が山ほど残っていることに気づきました。指摘してくれる人がいない環境では、自分の書き方の何が古いのかにすら気づけない――それが、Kさんが私に最初に相談してきた言葉でした。

追い打ちをかけたのは、その少し後に起きた本番障害でした。Kさんがマージした決済関連の処理に、想定していなかった例外系の抜けがあり、深夜に本番環境でエラーが多発します。原因を遡ると、レビューで指摘されていれば防げたはずの単純な条件分岐の見落としでした。障害対応の振り返りでも「次から気をつけましょう」で終わり、レビュー体制そのものを見直す議論には発展しません。Kさんは、この一件で自分の技術的な成長よりも先に、事業に実害が出る形でこの環境の限界を思い知ったと話していました。

なぜ「自社開発」「裁量あり」の求人票では見抜けなかったのか

Kさんの相談を受けて最初に整理したのは、なぜ選考の段階でこのギャップに気づけなかったのか、という点でした。「自社開発」「裁量あり」という言葉自体は嘘ではありません。ただ、この2つの言葉が指しているのは雇用形態と権限の範囲であって、開発プロセスの成熟度とは別の軸にあります。

「裁量あり」は本来、意思決定の自由度が高いという意味で使われますが、レビュー体制が整っていない現場では、それが「型を決める人がいない」ことの言い換えになっている場合があります。Kさんが受け取った裁量は、実際には設計判断の責任を一人で負わされる状態と地続きでした。

面接で技術的な深掘りがほとんどなく人柄重視だったことも、後から振り返れば重要なサインだったとKさんは話していました。技術面接の設計自体が薄い会社は、そもそも技術的な水準を測る文化——つまりレビューの文化——が社内に根付いていない可能性が高いのです。

ポイント： 「モダンな技術スタック」は使用しているフレームワークやバージョンの話であり、レビュー・テスト・CI/CDといった開発プロセスの成熟度を示すものではありません。求人票の技術欄と、実際の開発の進め方は別々に確認する必要があります。

シリーズA規模のスタートアップでは、事業のスピードを優先するあまりレビュープロセスへの投資が後回しになる傾向があります。創業初期に採用されたエンジニアの書き方がそのまま社内標準になり、後から入った人が異論を挟みにくい空気ができていることも少なくありません。Kさんの会社もまさにこの状態で、CTO自身が「レビューをする時間があるなら新機能を作りたい」という考えを持っていました。

求人票の言葉と実態のずれを、Kさんと一緒に振り返ったときに整理した対応表が次のものです。同じ表記でも意味する幅が広いことが分かります。

こうして並べると、求人票の言葉自体を疑う必要はなく、同じ言葉が指す幅の広さを知っておくことの方が重要だと分かります。Kさんも「裁量あり」を額面通りに良い意味だけで受け取ってしまったことを、後から一番の反省点として挙げていました。

もう一つ見落とされやすいのが、KさんのようにSESや受託開発の現場からの転職では、レビューが機能している状態を実体験として知らないまま選考に臨むケースがある点です。要件通りに作ることが評価軸だった環境では、そもそも「良いレビュー」がどういうものかを比較する基準を持っていません。だからこそ、面談で聞かれた答えの良し悪しを判断できず、雰囲気の良さだけで意思決定してしまいやすいのです。この構造は、Kさんに限らず自社開発への転身を考えるSES・受託出身のエンジニアに共通して見られます。

似たような相談を重ねる中で、入社後にレビュー文化の欠如に気づく人には共通する初期サインがあることも分かってきました。1つ目は、入社1ヶ月以内に自分よりレビューについて聞いてくる人が誰もいないこと。2つ目は、質問への答えが「人によります」で終わりやすいこと。3つ目は、Pull Requestのマージ権限が実質的に本人任せになっていて、誰かの承認を待つ工程が形だけになっていることです。この3つが揃っている場合、入社してすぐの段階で立て直しの検討を始めた方がいいというのが、複数の相談を見てきた上での私の判断基準です。

技術力は「十分条件」ではなく「参加チケット」に変わっている

Kさんが感じていた焦りは、決して個人的な思い込みではありません。パーソル総合研究所が2020年に実施したITエンジニア1,600名(20〜30代800名・40〜50代800名)への調査では、キャリアに関する不安の1位が「自分の技術やスキルの陳腐化」で46.5%、3位に「新しい技術やスキルの習得」が43.6%で入っています(出典：パーソル総合研究所「ITエンジニアの就業意識に関する調査結果」)。

この調査自体は2020年時点のものですが、技術力の陳腐化に対する不安の大きさは、私が現場で受ける相談の傾向とも変わっていません。かつては技術力が高ければ転職市場で選ばれる「十分条件」でしたが、今は転職の選考に参加するための「参加チケット」に近い位置づけに変わってきていると私は見ています。技術力があること自体はもう前提であり、それをどう伸ばし続けているかまで見られる時代です。

だからこそ、コードレビューという「他人の目で自分のコードを検証してもらう機会」が失われている環境に長くいることは、単に居心地の悪さの問題ではなく、市場で戦える技術力を維持できるかどうかに直結します。Kさんのように自分の書き方の何が問題なのか気づく機会そのものが失われている状態は、本人が気づいた時点でかなり進行していることが多いというのが実感です。

面接の場でも、この変化は感じられます。以前は「何ができるか」を聞かれれば十分でしたが、最近の技術面接では「その判断が正しいかどうか、どう検証しているか」まで聞かれることが増えました。レビューを受けた経験がないと、この質問に答える材料そのものを持てません。技術力を証明する材料が、成果物の完成度だけでなく、その過程で受けた検証の質にまで広がっている、という感覚を持っておくといいと思います。

カジュアル面談でレビュー体制の実態を確認する質問

Kさんのケースを踏まえて、私が今後の相談者に必ず伝えるようにしているのが、カジュアル面談や面接の場でレビュー文化の実態を具体的に確認する質問です。「レビュー文化はありますか」という聞き方では、どの会社も「あります」と答えてしまうため、もう一段具体的な聞き方に落とし込む必要があります。

ポイントは、抽象的な質問ではなく「実例」を求めることです。実際にレビュー文化が機能している会社の担当者は、この質問にほぼ即答できます。逆に言葉を濁したり、「基本的には各人の裁量で」という答えが返ってきたりする場合は、Kさんの会社と同じ状態である可能性が高いと考えていいでしょう。

面接官が現場エンジニアか人事かによっても答えの精度は変わります。人事担当者しか同席しない選考プロセスで技術的な質問への回答が曖昧なままなら、それ自体が現場エンジニアの選考への関与が薄い——つまり技術面での意思決定に組織的な仕組みがない——ことのサインになります。

現職で立て直す、レビューの仕組みを自分から持ち込む選択肢

Kさんに最初に提案したのは、いきなり転職活動を始めるのではなく、今の会社でレビュー文化を自分から持ち込めないか試してみることでした。誰かが作ってくれるのを待つのではなく、小さく始めて実績を見せるアプローチです。

Kさんが実際にやったのは、週1回30分だけの「ペアレビュー会」の提案でした。全員参加の大掛かりな仕組みではなく、その週にマージされたPull Requestのうち1件だけを画面共有で見返し、気になった点を口頭で話し合うという軽い形式です。CTOには「時間を奪うものではなく、むしろ後からの手戻りを減らす投資」という言い方で提案しました。

提案の説得力を上げるために、Kさんは直近1ヶ月に起きた本番障害を数え直しました。3件のうち2件は、レビューで一言指摘があれば防げていた可能性が高いという内容です。感覚的な「レビューがあった方がいい」という主張ではなく、実際に発生したコストを示す形にしたことで、CTOからも一定の理解を得られたとKさんは振り返っていました。

一般論として、エンジニアが数名〜十数名の創業期は、レビューの仕組みが創業者やCTO個人の意識に依存しやすい時期です。組織がそこから数十名規模に育つ過程で、属人的な判断だけでは品質を保てなくなり、レビューやテストの運用が制度として整っていくことが多いというのが、複数の自社開発企業を見てきた実感です。Kさんの会社がどちらの段階にあるかを見極めることも、立て直しの見通しを立てる材料になります。

もう一つ持ち込んだのが、Pull Requestのテンプレートに簡単なチェックリストを追加することです。「エラー時の挙動を確認したか」「既存のテストが通ることを確認したか」といった数項目だけの短いリストですが、これを書く過程で自分自身の見落としに気づく効果がありました。仕組みそのものが完璧でなくても、振り返りの機会を自分で作ることが目的だったとKさんは話していました。

こうした立て直しの動きは、組織の規模が小さいうちほど個人の提案が通りやすいという利点があります。一方で、その提案がどう受け止められるかによって、この先も自分の力でどこまで変えられるかの見通しが立ちます。

社内で仕組みを変えるのと並行して、Kさんには社外でレビューの機会を補うことも勧めました。OSSのリポジトリに小さなPull Requestを送ってメンテナーからの指摘を受けたり、コードレビューをテーマにした勉強会・LT会に参加して他社のやり方を知ったりすることは、社内の文化を変えられない間の「もう一つの指摘してもらう場」として機能します。Kさん自身も、最初にN+1問題に気づいたきっかけが社外の勉強会だったように、社内で得られない気づきを社外から補う動きは、立て直しの選択肢を試している最中でも並行して進められます。

次にお伝えするのは、社内での提案がどこまで根付いたかを、感覚ではなく事実として見極めるための判断基準です。

それでも変わらないとき、再転職に踏み切る判断基準

立て直しを試みても状況が変わらない場合、いつまで待つべきかで悩む相談者は多くいます。私がKさんと一緒に整理したのは、感覚ではなく具体的な事実に基づいたチェックリストでした。

このうち特に重視したいのは1つ目です。言葉として賛成されることと、実際に時間や予算が割かれることは別です。Kさんの会社でもCTOは提案に賛成しましたが、実際に手を動かして参加したのはチームメンバー1人だけで、組織としての優先順位が上がった形跡は見られませんでした。

反対に、提案が採用要件の見直しや評価制度の議論にまで発展するようなら、時間はかかっても文化が育つ土台はできています。数ヶ月単位で状況を見極め、事実として何も動いていないと判断できた時点で、再転職を検討する段階に入ったと考えていいと私は伝えています。

Kさんがその後どう動いたか

Kさんは提案から3ヶ月、様子を見ることにしました。ペアレビュー会には最初こそ2人が参加しましたが、次第に1人に減り、それ以上広がる動きは出てきませんでした。CTOも「いい取り組みだと思う」と言い続けてはいたものの、評価制度や採用要件にレビューの観点が加わることはありませんでした。

チェックリストの4項目を並べたとき、Kさんは「経営層が本気で時間を割く気があるかどうか」という1つ目の項目が明確に欠けていると判断し、転職活動を再開しました。今度の活動では、先ほどのカジュアル面談での質問を実際に使い、複数社を比較しました。

ある会社では「直近のPull Requestで、設計判断についてこんな指摘がありました」と、実際のコメント内容まで具体的に答えが返ってきたそうです。テストカバレッジの目安も数字で即答され、Kさんはこの会社を軸に選考を進めることにしました。

内定を得て転職した後、KさんはPull Requestごとに複数のコメントが付く環境で働くようになり、「自分の書き方の癖が言語化されるようになった」と話しています。年収面での変化は小さなものでしたが、Kさんにとって一番大きかったのは、技術力が伸びている実感を自分で確認できるようになったことでした。

入社してから数ヶ月経った頃、Kさんから改めて連絡がありました。以前の会社で提案したペアレビュー会と似た仕組みが、今の会社では入社時点からオンボーディングの一部として組み込まれていて、「これが当たり前だったのか」と驚いたそうです。前職での経験があったからこそ、今の環境のありがたさを言葉にできる、とも話していました。自分から動いた経験は、環境が変わっても無駄にならないという実例だと私は受け止めています。

よくある質問

面接で「レビュー文化はありますか」と直接聞いても失礼にならないでしょうか。 直接的な聞き方自体は失礼になりません。ただ、抽象的な質問には抽象的な答えしか返ってこないため、本文で紹介したような「直近の実例を教えてください」という具体的な聞き方に変えることをおすすめします。実例で答えられる会社ほど、実際に文化が根付いている傾向があります。

小規模なスタートアップだと、レビュー文化が整っていないのは仕方ないのでしょうか。 規模が小さいこと自体は理由になりません。社員10名前後でも、創業者自身がレビューの重要性を理解していて意識的に時間を確保している会社は存在します。規模より、経営層がレビューを「コスト」ではなく「投資」として扱っているかどうかを確認する方が実態に近づけます。

今の会社で立て直しを試す期間は、どれくらいが目安ですか。 Kさんのケースでは3ヶ月を目安にしましたが、提案の規模によって前後します。目安としては、四半期の評価サイクルが1回回る程度の期間で、参加者の増減や経営層の関わり方に変化が見られるかどうかを確認すると判断がつけやすくなります。

コードレビューがない環境にいたこと自体は、次の転職の選考でマイナスになりますか。 それ自体はマイナスになりません。むしろ、その環境で何を課題と捉え、どう自分から動いたかを語れると、主体性を示す材料になります。Kさんも面接で「レビューの仕組みを自分から提案した経験」を、環境への不満としてではなく行動の実績として伝えていました。

入社前にレビュー文化の有無を、ネット上の情報だけで調べることはできますか。 限界はありますが手がかりはあります。企業の技術ブログでレビューやテストについて具体的に触れている記事があるか、公開しているOSSリポジトリのPull Requestに実際のレビューコメントが残っているかは、外から確認できる材料です。とはいえ最終的には、本文で紹介した質問をカジュアル面談で直接ぶつける方が精度は高くなります。

まとめ

「自社開発」「裁量あり」という求人票の言葉は、レビュー文化の有無を何も保証していません。この2つを混同してしまうと、Kさんのように入社後何ヶ月も経ってから、自分の技術力が伸びているのかどうかすら分からない状態に陥ります。

大切なのは、選考の段階で実例を尋ねる質問を用意しておくことと、入社後に文化が育っていないと感じたときに、感覚ではなく事実に基づいたチェックポイントで見極めることです。立て直しを試すことと、見切りをつけて動くことは矛盾しません。Kさんのように、まず動いてみたうえで判断材料を揃えられるかどうかが、技術力の伸び悩みから抜け出せるかどうかの分かれ目になると私は考えています。

「技術力が伸びていない気がする」という漠然とした不安を抱えたまま何もせずに時間を過ごすのが、一番避けたい選択です。今の環境で動いてみるのか、確認する質問を持って次の環境を探すのか。どちらを選ぶにしても、まず現状を事実として言葉にしてみることが、次の一歩を決める一番の近道になります。