"35歳でエンジニアは終わる"という話は
本当なのか

"35歳定年説"は、どこで語られてきたのか

「35歳でITエンジニアは終わる」という説は、転職市場やSNSでたびたび語られてきた通説です。ただし、この説が指しているのはキャリアの後半で起きる変化であり、20代から30代前半のフェーズにそのまま当てはめられるものではありません。

ITエンジニアの年収カーブを見ると、20代から30代前半まではほぼ全員が右肩上がりで伸びる時期にあたります。未経験・第二新卒からスタートしても、経験年数を重ねるごとに担当できる業務範囲が広がり、それに合わせて年収も上がっていきます。この時期に評価を分けているのは、在籍している企業やSIer・自社開発・受託といった業態、あるいは扱う言語やフレームワークではありません。

理由は、この年代のエンジニアに求められる役割がどの現場でもほぼ同じだからです。要件を渡されて実装し、テストして、既存コードを保守する。この「作業範囲」自体に大きな差がないため、評価軸も「指示された実装をどれだけ正確に・早くこなせるか」に集約されます。

そのため、この時期の年収は個人のスキル差よりも経験年数と所属企業の給与テーブルにほぼ連動します。同期入社で似た実力の2人でも、大手SIerと受託の小規模企業では初任給・昇給幅の設計そのものが違うため、数十万円〜100万円単位の差が生まれることは珍しくありません。逆に言えば、この時期に年収が伸び悩んでいても「実力不足」と即断する必要はなく、給与テーブルの設計や評価制度の違いが要因になっているケースが多い段階です。

つまり、20代から30代前半の間は、まだ「35歳定年説」が当てはまる局面ではありません。年収を左右しているのは個人の判断力や専門性ではなく、年数と所属企業の仕組みです。この構造が崩れ始めるのが、次のフェーズにあたる30代半ばです。

35歳で本当に年収は下がるのか

「35歳定年説」と聞くと、35歳の誕生日を境に評価が急落するようなイメージを持ちがちですが、実際に起きているのは仕事を失うことではありません。年収カーブの傾きが、人によって変わり始めることです。20代からの右肩上がりが横ばいになる人と、そのまま伸び続ける人に分かれる——この分岐こそが定年説の中身です。

分岐の背景には、多くの企業が採用している等級テーブルの仕組みがあります。実装スキルを軸にした等級には上限が設けられており、経験年数だけを積んでもその上限を超えることはできません。上限に近づくと評価軸が「何を作れるか」から「何を任せられるか」へ切り替わり、そこで対応できるかどうかで、以降の年収の伸びしろがはっきり分かれていきます。上限に達したまま数年在籍すると、年収は据え置きに近い状態になります。

同じ変化は求人票にも表れます。30代前半までは実装力そのものを評価する求人が中心ですが、35歳前後を境に、要件欄に設計経験やチームでの役割に関する記載が増える求人が目立ち始めます。この要件を満たせているかどうかで、同じ年齢・同じ経験年数でも書類選考の通過率に差が出るのが実情です。ただしこの時期や基準はSIer・受託中心の企業と自社サービスを持つWeb系企業とで出方が異なり、一律に「35歳」で切れる話ではありません。

厄介なのは、この分岐が本人の自覚がないまま進むことです。日々の業務内容が急に変わるわけではないため、年収が伸びている同期と自分の違いは、査定のタイミングまで見えにくいという特徴があります。今どちらのカーブに乗っているのか、また自分の経験が求人要件のどちらに該当するのかは、社内の評価情報だけでは判断がつきにくく、求人ごとに要件がどう書き分けられているかを日常的に把握しているに照らし合わせれば、査定を待たずに自分の立ち位置を確認できます。

分岐を作っているのは年齢ではない

ITエンジニアの評価軸は、年齢や在籍年数そのものではなく、「どこまで意思決定に関わっているか」という一点で切り替わります。実装のみを担当している間は、評価の対象は要件定義書や設計書にすでに書かれた仕様を、どれだけ正確に・早く・バグなくコードへ変換できるかという範囲に絞られます。この能力は経験を積むほど習熟しますが、ある水準を超えると伸びが緩やかになりやすく、同じ工程を5年続けた人と8年続けた人の間で、実装速度や品質そのものに大きな差がつきにくくなっていきます。

一方、要件定義・設計・技術選定といった上流工程に関わるようになると、問われる内容が変わります。「仕様通りに正しく作れるか」ではなく、「何を作るべきか」「どの技術で作ればコストとリスクが最小になるか」を判断できるかが評価の中心になります。ここで見られているのは、過去の実装量というより、納期・予算・チーム構成・既存システムとの整合性といった異なる制約条件のもとで、実際に意思決定をしてきた経験の質です。

多くの企業では、この違いが等級制度そのものに組み込まれています。「実装担当」と「設計・技術選定担当」で評価グレードの区分が分かれており、後者に移行しない限り基本給テーブルの上限に到達しにくい設計になっているケースが少なくありません。つまり分岐は、日々の技術力の差というより、どちらの評価グレードに配置されているかという構造上の位置づけによって生まれています。

ここで見落とされやすいのが、上流工程への関与は本人の希望だけで得られるものではないという点です。設計や技術選定の役割は、そのプロジェクトの規模やチームの人員配置によって、機会そのものが左右されます。具体的には、次のような違いが起こり得ます。

• 大規模プロジェクトでは設計担当・実装担当が役割として明確に分かれ、上流を担当する枠が一定数存在する
• 小規模チームや受託開発中心の現場では、そもそも設計と実装を分業する体制自体がなく、経験年数が長くても実装担当のまま固定されやすい
• 同じ会社の中でも、配属されたプロジェクトの体制次第で、上流に触れられるかどうかが変わる

この点を踏まえると、上流工程に関われていないことが、必ずしも本人の実力不足を意味するわけではないことが分かります。希望していても、配置された環境にその機会がなければ、意思決定に関わる経験を積むこと自体が難しいからです。35歳前後で起きるとされる分岐は、年齢という数字が原因ではなく、「担当領域が実装から上流工程へ移ったかどうか」という配置・機会の差が、数年かけて年収差として表面化したものだと考えられます。

"作る側"のまま年収が伸び続ける人には、共通点がある

マネジメント職に進まなくても年収が伸び続けるエンジニアには、共通した条件があります。それは、担い手が少ない技術・領域を扱い続けているかどうかという一点です。実装力そのものの高さよりも、その実装力がどれだけ代替されにくいかが評価を左右します。

業務で広く使われる言語やフレームワークの標準的な実装力は、経験年数が増えるほど市場での供給も増えていきます。習得コストが下がり、対応できるエンジニアの母数が増えるため、単価は上がりにくくなる構造です。一方で、レガシー基幹システムの保守、特定業界に特化したドメイン知識(金融の勘定系、医療の規制対応など)、あるいは登場から間もない技術領域(新しいインフラ構成やセキュリティ要件など)は、対応できる人材が限られたままの状態が続きます。企業側から見れば「代わりがいない」状態が続くため、評価と単価が下がりにくくなります。

ここで見落とされがちなのが、希少性は一度獲得したら維持されるものではないという点です。ある時点で希少だった技術も、標準化が進めば数年で汎用スキルへと位置づけが変わります。伸び続けるエンジニアは、担当領域そのものを固定せず、市場での希少性が薄れる兆候が出た時点で次の領域へ更新し続けているという特徴があります。逆に、同じ技術・同じ担当範囲を長期間変えずにいると、当初は希少だった経験も次第に「経験年数が長いだけの汎用スキル」として扱われるようになっていきます。

もう一つの軸は、実装の中でも上流に近い判断をどこまで担っているかです。同じ「作る側」であっても、指示された仕様をコードに落とす役割と、技術選定やアーキテクチャ設計の意思決定に関わる役割とでは、評価される責任の範囲が異なります。後者は役職上マネジメントでなくても、事業上のリスクを背負う判断をしているため、実装専任のエンジニアより評価対象が広がりやすくなります。

つまり分岐を作っているのは、エンジニアとして「作る側」であり続けるかどうかではなく、扱う技術・領域を市場の希少性に合わせて更新し続けているかどうかです。マネジメントという選択肢を取らなくても、この更新を止めなければ年収カーブは伸び続ける余地が残ります。

40代・50代の下落も、年齢が原因なのか

40代・50代になって年収が下がるケースを見ていくと、その原因が年齢そのものであることはほとんどありません。実際に効いているのは、これまで担当してきた技術領域が、市場の需要から少しずつずれていく現象です。ある言語やフレームワークで長く保守・運用を担当し続けると、経験年数は着実に積み上がります。しかし技術トレンドは数年単位で入れ替わるため、その分野自体の求人需要が縮小したり、より新しい構成に置き換わったりすることがあります。経験年数が伸びているのに市場価値は伸びない、という状態はここで生まれます。

厄介なのは、この変化が社内にいる限り気づきにくい点です。多くの企業では給与テーブルが年功や役職と連動しているため、担当技術が更新されていなくても給与自体は緩やかに上がり続けます。ところが転職市場に出た瞬間、評価基準が切り替わります。企業側が見るのは在籍年数ではなく「今の構成にすぐ対応できるか」であり、長年の経験と提示条件が比例しないというギャップが、そこで初めて表面化します。

一方で、同じ40代・50代でも下落構造の外側にいる人はいます。分岐点はマネジメントに進んだかどうかではなく、担当領域を定期的に更新し続けているかどうかです。逆に言えば、実装からは離れずマネジメントにも進まず、かつ技術更新も止まっている場合が、最も市場価値の低下が起きやすい組み合わせということになります。

この構造の厄介な点は、本人の体感と市場評価がずれたまま何年も経過しやすいことです。社内評価が安定している間は違和感が生まれにくく、気づいたときには自分の技術構成が今の求人条件でどう扱われるのか分からない、という状態になりがちです。今の担当領域と技術構成が実際の求人条件に照らしてどの水準にあるかは、に問い合わせれば、案件条件と突き合わせた形で確認できます。年齢を理由に諦める前に、まず自分の技術構成が市場のどの位置にあるかを把握しておくことが、この段階では特に重要になります。

結局のところ、35歳定年説という通説の中で語られてきた「年齢による下落」は、40代・50代においても中身は同じです。年齢が数字として進んだことではなく、担当技術の更新が止まったことが、数年をかけて年収差として表面化しているにすぎません。

通説ではなく、自分の数字で判断する

「35歳でITエンジニアは終わる」という説を聞いてまず確認すべきは、自分の年齢ではなく、担当領域と技術更新の2つの数字です。ここまで見てきた通り、年収カーブが分岐するのは実装から意思決定への関与度が変わったかどうか、そして扱う技術領域の希少性を更新し続けているかどうかの2軸によるものであり、年齢そのものが原因になっているケースはほとんどありません。

厄介なのは、この2軸のどちらに自分が乗っているかは、社内評価だけでは見えにくいという点です。給与テーブルが年功と連動している間は違和感が生まれず、担当領域が実装のまま固定されていても、技術更新が止まっていても、査定が大きく崩れない限り気づく機会がありません。分岐は本人の自覚がないまま進むという前述の構造が、ここでもそのまま当てはまります。

そのため、通説を信じるかどうかを議論する前に、まず自分の現在地を数字で確認しておくことが実務的です。具体的には次の3点を洗い出してみてください。

• 直近の担当業務が、仕様通りの実装が中心か、要件定義・設計・技術選定に関わっているか
• 扱っている技術・領域が、この数年で市場での希少性が上がったか下がったか
• 今の年収が、同年代・同職種の実際の求人条件と比べて上流寄りの相場か実装専任の相場か

この3点は自己申告では精度が出にくく、実際の求人要件と突き合わせて初めて輪郭が見えてきます。年齢を理由に諦める前に、自分がどちらのカーブに乗っているかを診断で確かめることが、35歳定年説に振り回されないための最初の一歩になります。

よくある質問