ITエンジニアの年収は、
「誰の仕事をしているか」で決まる

同じ職種名の中に、なぜ数百万円の差が生まれるのか

「ITエンジニア」という職種名は、ひとつの働き方を指しているわけではありません。同じ肩書きの中に、技術領域(インフラ・アプリ開発・データ・セキュリティなど)、雇用形態(正社員・業務委託・派遣)、そして契約構造(自社開発・SES・受託)という、性質の異なる複数の軸が混在しています。年収を左右しているのは、実はこの技術力そのものよりも先に、どの軸の組み合わせに属しているかという点です。

たとえば同じ「Webアプリケーションエンジニア」という名刺でも、自社サービスを持つ企業で開発している人と、SES契約でクライアント先に常駐している人とでは、年収を決める仕組みそのものが違います。前者は社内の評価制度と給与テーブルに沿って年収が決まりますが、後者は商流上の契約単価が先に存在し、そこから给与が逆算されます。技術力を伸ばせば誰でも同じように年収が上がる、という単純な構造にはなっていません。

この違いが見えにくいのは、求人票や名刺の職種名がどれも「ITエンジニア」「システムエンジニア」といった大きなくくりで統一されているためです。同じ職種名の中に、実際には報酬の決まり方が異なる複数の働き方が同居していることが、数百万円単位の年収差が生まれる出発点になっています。

この先のセクションでは、その差を生む具体的な仕組みとして、商流構造(何次請けか)、自社開発企業の評価等級、業務委託の仲介マージン、そして業界による年収の天井の違いを、それぞれ個別に見ていきます。いずれも「技術力の差」では説明できない、契約と組織構造に起因する差です。

大事なのは、自分が今どの軸の組み合わせに属しているかを正確に把握することです。同じスキルセットを持っていても、置かれている契約構造や評価制度が変われば、年収のレンジそのものが変わります。逆に言えば、技術力を高める努力と同じくらい、自分がどの構造の中で働いているかを見極める努力にも意味があるということです。

多重下請けの何次請けにいるかで、単価は先に決まっている

ITエンジニアの契約形態のうち、SES(システムエンジニアリングサービス)や受託開発は、発注者から見て「誰が実際に手を動かしているか」が何層にも重なる商流の上に成り立っています。発注者(ユーザー企業)が元請けのSIerと契約し、元請けが自社で人員を賄いきれない工程を一次請けの協力会社に外注し、一次請けがさらに二次請け・三次請け以降の企業に再委託する、という構造です。契約の形式は準委任契約(SES契約)が多く、成果物ではなく稼働時間に対して対価が支払われます。

この構造で問題になるのは、発注者が支払う金額と、実際に現場で作業するエンジニアに支払われる金額の差です。元請けは受注額から一定のマージンを引いた金額で一次請けに発注し、一次請けもまた自社の利益を確保したうえで二次請けに発注します。この差し引きは各階層で発生するため、階層が深くなるほど、最終的に個人の給与や請負単価に反映される金額は圧縮されます。同じ業務内容・同じ技術スタックでプロジェクトに参画していても、元請けに所属しているエンジニアと、三次請けの企業から常駐しているエンジニアとでは、額面に差が出るのはこのためです。

厄介なのは、この商流上の位置が求人票や案件情報だけでは分かりにくいことです。「大手金融機関のシステム開発」といった案件名は同じでも、自社が元請けなのか、二次請け以降として参画するのかで、精算幅や単価の伸びしろは変わってきます。契約前にこの位置関係を確認できるかどうかは、扱っている案件の商流を把握しているかどうかに左右されるため、であれば、応募前に元請け直請けか何次請けかを含めて確認できることがあります。技術力そのものよりも先に、自分が今どの階層で契約しているかを把握しておくことが、単価の交渉材料になります。

自社開発企業では、年収は評価等級と給与テーブルで決まる

自社開発企業では、給与テーブルと評価等級(グレード・バンド)が年収の決定軸になります。多くの企業は「グレード1〜グレード7」のように技術力・裁量範囲・マネジメント責任を段階分けし、各グレードに年収レンジを紐づけています。同じ「エンジニア」という肩書きでも、どのグレードに位置づけられるかで年収は数百万円単位で変わります。

商流型(SES・受託)との違いは、年収の原資がどこから来るかにあります。商流型では単価は契約時点の商流構造でほぼ決まっており、個人の評価は昇給額を左右しても構造自体は変えません。一方、自社開発企業では会社の売上・利益が原資となるため、事業の成長フェーズが給与テーブルの水準そのものを左右します。急成長中のSaaS企業は採用競争力を保つためにテーブルを頻繁に見直しますが、成長が鈍化した企業ではテーブル改定が数年止まることもあります。

評価等級制度には、実務上押さえておくべき仕組みがいくつかあります。

• 昇格には「グレード相当の職務を一定期間継続して遂行した実績」が求められることが多く、実力があってもポジションが空かなければ昇格が保留されるケースがあります
• グレードごとに年収レンジには上限があり、レンジ上限に達すると同じグレード内では昇給が止まる(昇格しない限り頭打ちになる)構造の企業が一般的です
• 中途採用者は前職年収を基準にグレードを仮決定し、入社後の評価で正式なグレードに調整されることがあり、入社時点のグレード判定が数年間の年収水準に影響することがあります

つまり自社開発企業では、技術力そのものよりも「その技術力が今のグレード定義の中でどう評価されるか」が年収を決めます。同じスキルセットでも、評価制度の運用が緩い企業と厳格な企業とでは反映されるスピードが大きく異なります。

業務委託・フリーランスは、仲介マージンの分だけ額面が変わる

ITエンジニアが「業務委託」「フリーランス」として契約する場合、多くはクライアントと直接つながっているわけではなく、エージェント(人材紹介会社・SES仲介会社)を経由しています。この経路では、クライアントが支払う金額(発注単価)とエンジニアが受け取る金額(契約単価)の間に、エージェントの取り分である仲介手数料(マージン)が発生します。

このマージンは公開されないのが一般的で、業界内では発注単価の20〜30%程度が仲介側の取り分になっているケースが多いと言われています(ただし正式な統計として公表されているものではなく、契約条件やエージェントごとに幅があります)。同じスキル・同じ稼働時間で同じ現場に入っていても、間に入るエージェントの数や交渉力によって、手元に届く額面は変わってきます。

特に見落とされやすいのが、複数のエージェントが連鎖している場合です。クライアント→元請けエージェント→再委託エージェント→エンジニア、という形で仲介が重なると、マージンも重複して差し引かれ、発注単価との乖離がさらに広がります。これは前段で触れた多重下請け構造と同じ力学が、業務委託契約の中でも起きているということです。

一方で、クライアントと直接契約を結ぶ直接契約(直請け)の場合は、この仲介マージンが発生しないため、同じ発注単価であってもエンジニア側の受取額はエージェント経由より高くなりやすい構造です。ただし直接契約は自分で営業・契約交渉・請求管理までこなす必要があり、案件を安定して見つける手間や、契約が途切れるリスクを自分で引き受けることになります。エージェント経由の契約は、その手間とリスクをエージェントに肩代わりしてもらう対価としてマージンを支払っている、という見方もできます。

つまり、業務委託契約における額面の差は、技術力の差ではなく、「誰を何人介して契約しているか」という商流上の位置から生まれています。同じ仕事内容・同じ稼働先であっても、契約形態(直接契約かエージェント経由か)、そして経由するエージェントの数によって、手取りは変わってきます。

同じ技術を使っていても、業界によって年収の天井は違う

ITエンジニアという職種は、業界を横断してどこでも同じ技術が通用するように見えます。しかし実際には、扱う事業がどの業界に属するかによって、年収レンジの上限そのものが変わります。技術力の伸びとは別軸で効いてくる要因です。

金融業界のシステム(証券・銀行の勘定系や決済基盤など)は、障害が即座に金銭的損失や社会的影響につながるため、要求される品質・セキュリティ水準が高く、それに見合う単価が予算として確保されやすい領域です。同じ言語・同じフレームワークを使っていても、業務要件の重さが単価に反映されます。

一方、SaaS・自社開発企業は、事業の成長速度と評価制度の柔軟さがそのまま年収レンジに直結します。プロダクトが伸びている段階の企業では給与テーブルの上限が引き上げられやすく、逆に成長が鈍化した企業では等級が上がっても年収レンジは動きにくくなります。技術力ではなく、事業のフェーズが天井を決めているケースです。

受託開発は、案件ごとの契約単価が積み上がる構造のため、個人の年収は「どの業界のクライアント案件を担当してきたか」の履歴に左右されます。金融系の大型案件を渡り歩いてきたエンジニアと、小規模な業務システムばかりを担当してきたエンジニアとでは、同じ経験年数でも提示される単価に差が出ます。

つまり、年収を上げる動き方には少なくとも2種類あります。今の会社の中で評価等級を上げていく動き方と、より年収レンジの高い業界・事業モデルへ転職する動き方です。後者を選ぶ場合、募集要項だけでは配属先の業界や具体的な単価水準までは読み取れません。であれば、案件が属する業界や商流上の立ち位置まで踏み込んで確認できます。

自分のスキルセットが、今よりレンジの高い業界でどう評価されるかは、外から見ているだけでは判断がつきません。まずは自分の現在地を把握することが、次の一手を選ぶ前提になります。

動く前に、自分の適正年収を確かめる

ITエンジニアの年収を上げる方法として「転職する」「スキルを増やす」がよく語られますが、その前に確認すべきことがあります。それは、今の自分がどの契約構造・評価制度・業界に置かれているかです。

ここまで見てきた通り、年収を決める軸は技術力だけではありません。SES・受託であれば商流の何次請けにいるかで単価の天井が先に決まっています。自社開発企業であれば、技術力よりも等級制度(グレード・バンド)のどの位置に評価されているかが年収を決めます。業務委託であれば、エージェント経由の仲介マージンが額面から差し引かれています。そして同じ技術を扱っていても、金融・SaaS・受託・自社開発のどの業界にいるかで、そもそも狙える年収レンジの上限が違います。

問題は、この4つの軸のどこに自分がいるかは、求人票を眺めているだけでは分からないという点です。「エンジニア 年収」で検索して出てくる平均値や中央値は、商流も評価制度も業界も違う人たちをひとまとめにした数字にすぎません。自分が二次請けのSESにいるのか、自社開発の中堅グレードにいるのか、業務委託で仲介を二重に挟んでいるのかによって、同じ「年収500万円」でも改善の余地がまったく違います。

たとえば商流の下層にいる人が転職活動をせずにできる改善はほぼありませんが、自社開発企業で評価等級が実力より低く据え置かれている人であれば、社内で等級交渉や異動という選択肢が先にあり得ます。契約形態が違えば、打ち手も動くタイミングも変わってきます。

つまり、次に取るべき行動は「転職する・しない」を決めることではなく、自分が今どの軸のどの位置にいて、そこからどれだけの伸びしろがあるかを把握することです。それを自己判断するのは難しいため、契約構造・評価制度・業界の3つの軸から自分の立ち位置を確認できる診断を用意しました。まずは現在地を確かめるところから始めてみてください。

よくある質問