汎用スキルと専門スキル、
年収を分けているのはどちらか

なぜこの2つがいつも比較の対象になるのか

ITエンジニアの年収を語るとき、多くの人は「どの職種を選ぶか」に意識を向けがちです。しかし実際の年収レンジを分けているのは、職種名そのものではありません。同じ「エンジニア」という肩書きでも、AI/ML、クラウドインフラ、Web開発、組み込み、レガシー保守のどれを扱っているかによって、市場が用意している年収の上限も下限も大きく異なります。この差を生んでいるのは、技術の新しさや難易度ではなく、その技術領域における市場の需給バランスです。

需要の伸びに対して対応できる人材が少ない領域は、企業が高い年収を提示してでも確保しようとします。逆に学習コストが低く供給が豊富な領域は、同じ役割を担える人材が市場に多く存在するため、年収レンジの中央値が下がりやすくなります。つまり年収差は「職種の格」ではなく、その時点でその技術を扱える人がどれだけ希少かという一点に集約されます。

この需給バランスを生み出している根本の軸が、汎用スキルか専門スキルかという区分です。汎用スキルは、業界を問わず幅広い現場で使われる基礎的な技術を指します。求人の母数が多く転職先を選びやすい一方で、同じスキルを持つ人材も多いため、単価は上がりにくい構造にあります。専門スキルは、習得に時間がかかる、あるいは対応できる人材が市場に少ない技術です。代替が効きにくいぶん企業が単価を上げてでも確保しようとしますが、対応できる案件の母数自体が少なく、需要が急に細るリスクも抱えています。

この2つはよく比較の対象になりますが、それは単なる「安定志向か挑戦志向か」という好みの話ではありません。求人の多さと単価の高さは、構造上両立しにくいという事実がまずあり、その上でどちらの構造を選ぶか、あるいは組み合わせるかという判断になります。次のセクションでは、この汎用スキルと専門スキルそれぞれが持つ強みとリスクを、対比の形で具体的に見ていきます。

求人の多さと、単価の高さは両立しない

ITエンジニアの技術領域を汎用スキルと専門スキルに分けたとき、まず目につくのは「求人の多さ」と「単価の高さ」がセットでは動かないという点です。基本的なWeb開発言語や一般的なフレームワーク、汎用的な業務システムの保守経験といった汎用スキルは、業界を問わず幅広い現場で使われているぶん、求人の母数が多く転職先を選びやすいという利点があります。特定の業界の景気に左右されにくく、職を失うリスクが低いという安定性も、この母数の多さから生まれています。

ただし、この求人の多さは同時に単価の上がりにくさと表裏一体です。同じスキルを持つエンジニアの数も市場に多く存在するため、企業側から見れば代わりの人材を見つけやすい状態が続きます。結果として、経験年数を重ねても年収レンジの上限が頭打ちになりやすく、「求人はあるのに条件が伸びない」という感覚につながりやすいのが汎用スキルの構造です。

一方、特定のクラウド基盤の設計運用やAI/MLモデルの実装、大規模データ基盤の構築、特殊な組み込み領域といった専門スキルは、この関係が逆転します。習得に時間がかかり対応できる人材が市場に少ないため、企業は代わりを見つけにくく、単価を上げてでも確保しようとします。案件単価や年収レンジの上限が汎用スキルより高く設定されやすいのは、この代替のされにくさが理由です。

その代わり、専門スキルは案件の母数自体が少ないという制約を抱えます。特化する領域が狭くなるほど対応できる案件は限られ、景気後退やその技術のトレンド終息によって需要が急に細る可能性も残ります。習得にかけた学習時間が回収できるかどうかは、その領域が今後どれだけ伸びるか次第という不確実性も、求人の多い汎用スキルとは質の異なるリスクです。

つまり汎用スキルは「求人は多いが単価の天井が低い」、専門スキルは「単価の天井は高いが案件そのものが少ない」という、量と単価がトレードオフの関係にあります。どちらの構造が今の自分の技術領域に近いのか、また今後どちらに寄せていくのかを判断する材料として、では実際にどちらの求人がどの程度の量で動いているかを事前に確認できます。感覚だけで「専門に寄せれば単価が上がる」と判断すると、案件母数の少なさによって想定より選択肢が狭まる場合もあるため、量と単価の両方を見た上で方向性を決めることが大切です。

単価を決めているのは、代替のされにくさだ

技術領域による年収差は、結局のところ「代替されにくさ」という一点に集約されます。この代替されにくさは、需給バランスと、企業がその技術をどの予算区分で扱っているかという2つの軸が重なって生まれています。

まず需給の軸です。Web開発の一般的なフロントエンド・バックエンドCRUDのように、学習コストが低く参入しやすい領域は、扱える技術者の数が案件数に対して多くなりがちです。企業から見れば、担当者が抜けても代わりを見つけやすいため、単価を上げる動機が生まれません。一方でクラウドインフラの大規模設計や機械学習基盤の構築は、実務経験者の絶対数が需要の伸びに追いついていないため、企業は複数の候補から選ぶのではなく、限られた候補を確保するために単価を積む側に回ります。供給が過多なら単価は下がり、経験者が少なければ単価は上がる。この関係自体は単純です。

もう一つの軸が、企業がその技術をコストとして計上するか、投資として計上するかという予算区分の違いです。基幹システムの安定稼働に直結するインフラや、事業の中核となるプロダクト開発は、担当者の稼働が止まれば売上や信用に直接影響します。そのため企業側は、多少単価が高くても確保する方が投資対効果に見合うと判断しやすくなります。逆に定型的な保守作業や、他の技術・他の人材でも代替しやすい業務は、事業インパクトが限定的なため、企業はこれを人件費というコストとして扱い、単価を上げる理由を持ちません。

この2つの軸を汎用スキルと専門スキルに当てはめると、それぞれの構造がはっきりします。

• 汎用スキル:供給が多く代替が効きやすいため、企業からはコスト区分で見られやすく、経験年数を重ねても単価の上限が頭打ちになりやすい
• 専門スキル:経験者が少なく代替が効きにくいため、企業からは投資区分で見られやすく、単価の上限も汎用スキルより高く設定されやすい

重要なのは、この予算区分は職種名では決まらず、担当する工程が事業のどの部分に近いかで決まるという点です。同じ「エンジニア」という肩書きでも、事業の中核に近い工程を担っていればコストではなく投資として扱われやすく、逆に代替手段が多い定型工程であれば、専門性の高い技術を使っていてもコスト扱いに近づくことがあります。技術領域を選ぶ際は、その技術の希少性だけでなく、自分が担う工程が企業の予算区分の中でどちらに位置づけられやすいかも合わせて見ておくと、単価の伸びやすさをより正確に見積もれます。

専門領域に移るには、何を証明すればいいのか

ITエンジニアのキャリアで最も見落とされがちなのが、この「証明コスト」の非対称性です。汎用スキルから専門スキルへ移るとき、企業が求めるのは学習の事実ではなく、その技術で実務が回せるという証拠であり、この証拠を用意できるかどうかで移動コストがまったく違ってきます。

まず問われるのは、実務経験の有無です。独学やスクールでの学習は本人にとって大きな一歩でも、採用側から見ると「経験者」と「未経験者」の間には明確な線があり、特にAI/MLやクラウドインフラのような専門領域では、育成しながら採用する余力を持つ企業自体が限られているため、実務経験のない候補者は書類選考の段階で弾かれやすくなります。この壁を越える経路は、現職の中で新領域の業務を意図的に取りにいき経験者として動ける状態を作ってから動くか、経験の浅さを給与や役職で妥協して先に領域内へ入り実績を積み直すかのどちらかで、選び方によって移動までの期間と年収の推移カーブが変わります。

もう一つの軸が、隣接領域か遠い領域かという距離です。Web開発からクラウドインフラのような隣接領域への移動は、既存スキルの一部がそのまま評価対象になるため証明コストは比較的低く済みます。一方、組み込みからAI/MLのように前提知識の重なりが少ない移動では、既存スキルが評価に直結しないため、実務経験の代わりとなる材料を別途用意する必要が出てきます。

その代替材料として使われるのが、副業やOSSでの実績作りです。ポートフォリオや個人開発の成果物、あるいは副業案件での実践は、実務経験がない状態でも「実務相当の形で示せるもの」として機能します。つまり専門領域への移動は「学べば移れる」ものではなく、「学んだことを実務相当の形で見せられるか」で評価が決まる、という構造です。この証明コストの高さは技術領域の組み合わせごとに異なるため、感覚だけで判断すると、移った先で想定より低い条件を提示されることも珍しくありません。

陳腐化のリスクは、実は逆向きにも働く

汎用スキルと専門スキルは、リスクの「量」ではなく「質」が違います。専門スキルが特化を通じて高い年収レンジを得られるのは、多くの場合「今この瞬間、その技術を扱える人が少ない」という一時的な需給バランスへの対価だからです。技術の寿命という時間軸を無視して特化を選ぶと、需要そのものが緩やかに減っていくリスクを抱えることになります。

専門スキルの陳腐化は、言語やフレームワークが突然使われなくなるという形では起きにくいものです。実際に起きやすいのは、その技術を必要とする新規案件の絶対量が少しずつ減っていく変化です。フレームワークのメジャーバージョンが更新されて後継技術が新規プロジェクトの標準になる、オンプレミス中心の構成がクラウド移行で置き換えられていく、といった動きがこれにあたります。既存システムの保守自体はすぐには消えないため、当事者が需要縮小を実感するまでに時間差が生じるのも特徴です。専門領域に特化するほど、対応できる案件の母数自体が少ないぶん、この縮小の影響を直接受けやすくなります。

一方の汎用スキルは、業界を問わず幅広い現場で使われる基礎的な技術であるぶん、景気や特定業界の浮き沈みに左右されにくく、需要が急に細るリスクは低めです。ただしリスクの質が違うだけで、リスクがないわけではありません。同じスキルを持つエンジニアの数も多いため、経験年数を重ねても年収レンジの上限が頭打ちになりやすいという、緩やかで長期的なリスクを抱えています。専門スキルが「急な落ち込み」なら、汎用スキルは「上がりにくさが続く」というリスクです。

この構図が逆転して見えるのが、レガシー保守の領域です。新規採用が止まった技術ほど若手の供給が細り、既存の有資格者に発注が集中するため、扱える人材が減るほど単価が上がる局面があります。ただしこれは案件総量そのものが縮小トレンドにあることとセットの現象で、単価が上がっているように見えても、母数となる案件数が減っていれば、長期的にキャリアとして成立する規模かどうかは別問題です。「今の単価」だけでなく「その技術が今後どちらの方向に向かっているか」を合わせて見る必要があるのは、専門・汎用を問わず共通しています。

自分が扱っている技術領域が、案件市場全体の中で伸びているフェーズにあるのか、縮小しながら局所的に単価が上がっているだけなのかは、社内から見える範囲だけでは判断しづらいところです。複数社の案件動向を横断的に見ているに確認すると、外部からの需要の見え方を把握しやすくなります。

どちらが自分に合うかを決める前に

ここまで、汎用スキルと専門スキルという二つの構造を見てきました。汎用スキルは求人母数が多く安定していますが年収レンジの上限が頭打ちになりやすく、専門スキルは代替されにくい分だけ単価は上がりやすいものの、案件母数が少なく需要が急に細るリスクを抱えています。どちらの構造にも異なる種類のリスクとリターンがあり、「絶対にこちらが正解」という答えは技術領域の性質そのものからは出てきません。

この二択で判断を誤りやすいのは、多くの場合自分がどちらの土俵に今立っているのかを正確に把握しないまま、将来性やイメージだけで選んでしまうケースです。専門領域を目指すにしても、証明コストをどこまで払えるか、隣接領域からの移動か遠い領域への移動かによって必要な準備は変わります。汎用領域にとどまる選択をするにしても、今の経験年数と実績が市場のどのレンジに位置しているかが分からなければ、上限が頭打ちになっているのか、まだ伸びしろがあるのかの判断もできません。

つまりこの記事で説明してきた需給構造・代替されにくさ・証明コスト・技術の寿命リスクは、どれも「自分の技術がどう評価されるか」を理解するための材料であって、そのまま自分に当てはめられる一般論ではありません。実際の評価は、保有スキルの組み合わせ・経験年数・担当してきた工程の範囲によって一人ひとり異なります。同じ「バックエンドエンジニア5年」という肩書きでも、扱ってきた技術スタックや事業への関わり方が違えば、市場での位置づけはまったく別物になります。

汎用スキルを軸に安定を取るか、専門スキルに寄せてリターンを狙うか、あるいは両方を組み合わせるか。どの方向に進むにせよ、最初に必要なのは決断ではなく、今の自分がどのレンジに立っているかという現在地の把握です。現在地が分かっていなければ、専門領域への移動が本当にリターンに見合うのか、今の汎用スキルのままであとどれくらい伸ばせるのかも見積もれません。

まずは自分の技術領域・経験年数・実績を整理したうえで、今の適正年収のおおよそのレンジを確認するところから始めてみてください。

よくある質問