その年収差は、いつ生まれたのか
キャリアの節目で追うITエンジニアの年収

配属された瞬間に、レンジはすでに動き出す

新卒や未経験からエンジニアとしてキャリアを始めるとき、多くの人は「まずスキルを身につけること」に意識が向きます。しかし年収という観点で見ると、実はこの最初の配属先が決まった瞬間から、すでにその後のレンジの動き方が変わり始めています。同じように実装スキルを磨いていても、所属する企業タイプによって、そのスキルがどう金額に変換されるかという仕組み自体が異なるからです。

SIer・受託開発に配属された場合、未経験・若手のエンジニアは詳細設計以降の実装・テストを担うPG(プログラマ)として現場に入ることが多く、これは多重下請け構造の中では下流の階層にあたります。顧客が支払う人月単価は元請けとの契約で決まり、そこから各階層がプロジェクト管理費や営業マージンを差し引いて次の階層に発注するため、下流に位置するほど階層を経るごとの乖離を最も受けやすい立場に置かれます。本人が悪いわけではなく、配属された時点での商流上の位置が、そのまま単価への反映のされやすさを左右する構造です。

事業会社・自社開発に配属された場合は、事情が異なります。エンジニアは外部への請求対象ではなく、自社プロダクトの売上・利益を作る側に立つため、人件費は原価というより投資として扱われやすくなります。特に事業が伸びているグロース期のフェーズに配属されれば、資金調達を原資とした採用単価の上振れを享受できる可能性があります。逆に上場・黒字化を優先するフェーズでは人件費に慎重になりやすく、同じ「事業会社」でも配属時点のフェーズ次第でレンジの出方は一様ではありません。

外資系・メガベンチャーに配属された場合は、年齢や社歴ではなく、担当する職務の難易度・裁量範囲によって決まる職務等級(グレード)制度に組み込まれます。新卒・未経験期であっても、この時点でどのグレードに位置づけられるかによって、その後の年収レンジの下限と上限があらかじめ規定されます。グレードが1段違えば年収レンジの下限と上限で200万円以上の差が出ることも珍しくないため、配属時点のグレード設定自体が、以降のキャリアの土台になります。

つまり、同じ「新卒エンジニア」というスタート地点でも、どの企業タイプに配属されるかによって、年収が決まる仕組みそのものがすでに動き出しています。この違いは日々の業務の中では意識しづらいものですが、後にキャリアの節目で評価軸が変わっていく際の出発点として、押さえておく価値があります。

評価の軸が変わるのはいつか

配属された時点のレンジは、そこで固定されるわけではありません。次にレンジが動き出すのは、担う役割そのものが変わる時期です。この節目は企業タイプによって現れ方が違い、しかもタイミングを本人が意識しているかどうかで、単価への反映のされ方に差が出ます。

SIer・受託開発の場合、その節目はPGからSEへの移行にあたります。詳細設計以降の実装・テストを担うPGは多重下請けの下流に配置されやすく、階層のマージンを最も受ける立場です。これに対してSEは要件定義・基本設計を担い、顧客との折衝という接点を持ちます。顧客と直接やり取りする役割は元請け・二次請け側に残りやすいため、同じ技術力であっても、PGからSEへ役割が移った時点で単価に反映されやすくなるという構造上の違いがあります。役職が変わる前後で請求単価の土台そのものが変わるため、この移行を意識できているかどうかは無視できない差になります。

事業会社・自社開発では、節目の性質が異なります。配属直後は要件通りに機能を実装できるかという工数寄りの評価に近いことも多いですが、時間が経つにつれて、担当した機能や施策が売上・継続率といった指標にどう寄与したかが問われ出す段階が訪れます。技術負債の解消やパフォーマンス改善が事業指標に跳ね返ったかどうかも、同じ評価軸に含まれます。何を作ったかではなく、作ったものが数字をどう動かしたかを語れるようになる時期が、事業会社における評価の変わり目です。

外資系・メガベンチャーでは、グレード自体は職務の難易度や裁量範囲で決まりますが、同じグレードに留まっている間にも評価が動く場面があります。それが、グレード内でハイパフォーマーと評価されるかどうかでボーナス倍率が変わる仕組みです。ベース給与は据え置かれていても、成果評価の結果次第でボーナスや株式報酬の比率が年ごとに上下するため、グレードが変わらない期間の中にも、実質的な年収が動く節目が存在します。

この3つの節目に共通するのは、役割が変わったこと自体は本人にもわかっても、それが評価軸のどの部分に反映されるかは制度を知らないと見えにくいという点です。今の役割がどの節目に近づいているかを、と一緒に確認しておくと、次にレンジが動くタイミングを待たずに動く判断がしやすくなります。

裁量が広がるほど、単価は個人差になる

企業タイプが違っても、共通して言えるのは「裁量が広がる局面ほど、同じ職種名でも年収の個人差が開きやすい」という点です。工程を任される範囲や意思決定の重さが人によって異なってくるため、レンジの中でどこに位置するかが個人の評価次第で変わってくるのがこの段階の特徴です。

SIerでは、SEからさらに進んでPM(プロジェクトマネージャー)として工程全体の進行管理や予算責任を負う立場になると、単価は上がりやすくなります。顧客との契約金額そのものに責任を持つ立場になるため、下流のPGやSEより単価への反映度は大きくなります。ただしその分、元請け・二次請け・三次請けをまたいだ多階層の調整負荷も大きくなる点は見落とせません。進捗管理や課題管理だけでなく、複数社にまたがるステークホルダーの利害を調整する役割が加わるため、単価の伸びと業務負荷の増加が同時に起こりやすい立場と言えます。

事業会社では、この段階で裁量を持つ役割への移行度合いが評価に反映されやすくなります。具体的には、実装担当からテックリードやプロダクトマネージャーを兼務するPdM兼務のような立場に移るかどうかです。担当する機能や施策の範囲が個人の技術判断に閉じたものから、チームや事業の意思決定に関わるものへと広がるほど、評価される対象も「実装の正確さ」から「事業への影響」へと軸足が移っていきます。同じ「エンジニア」という肩書きのままでも、裁量の範囲が変わることで評価のされ方自体が変わってくる段階です。

外資系・メガベンチャーでは、職務等級(グレード)が上がるほど、評価の中心が実装力そのものから意思決定・影響範囲の広さへと移っていきます。グレードが低い段階では担当領域の実装スキルが評価の主軸になりやすい一方、グレードが上がるにつれて、どの範囲の設計判断を任されているか、その判断がどこまでの規模に影響するかが問われるようになります。同じ技術力を持つ人同士でも、任されている意思決定の範囲がグレードとレンジの差として表れやすいのがこの仕組みです。

3つの企業タイプに共通しているのは、裁量が広がる転換点を境に、年収の決まり方が「工数や実装量」から「任される範囲の大きさと、それにどう応えたか」へと切り替わっていくことです。役職や肩書きが変わるタイミングだけでなく、裁量の範囲が実質的に広がったタイミングこそが、レンジの中での自分の位置を見直す機会だと言えます。

積み上げた経験、翻訳し直せるか

SIerで培った経験は、企業タイプの異なる転職先でそのまま同じ評価を受けるとは限りません。特に多重下請け構造の中で積み上げてきた実績は、事業会社や外資系企業では評価の軸そのものが違うため、翻訳し直す作業を挟まないと、実力に見合わない年収提示を受け入れてしまうことがあります。

SIerでは、進捗管理・課題管理・要件定義の取りまとめ・多階層のステークホルダー調整といった、工数を予定通りに消化し炎上させずにプロジェクトを完了させる能力が評価の中心になりやすい仕組みです。PMやSEとして評価されてきた人ほど、この能力を職務経歴書の主軸に据えがちですが、事業会社の面接ではそのままでは伝わりにくい経験でもあります。

自社サービスを持つ事業会社では、担当した機能や施策が売上・利用者数・解約率といった指標にどう影響したかというプロダクト貢献度が評価軸になります。「予定通りに納品した」という工数管理の実績だけを語っても、それが事業の数字にどうつながったかを説明できなければ、経験として正しく伝わらないのが実情です。同じプロジェクトマネジメント経験でも、進行管理の実績なのか、事業指標を動かした実績なのかによって、評価のされ方は大きく変わります。

外資系やメガベンチャーでは、さらに評価の焦点が個人の技術力に移ります。職務等級(グレード)ごとに求められる技術的意思決定の範囲や設計の裁量が明確に定義されているため、SIerでの上流工程経験があっても、コーディング試験やシステム設計面接で個人の技術力を別途証明する必要が生じるケースがあります。上流工程を担当していたという肩書きだけでは、グレード判定の材料として不十分に扱われることがある、という点です。

マネジメント経験の定義が企業ごとに異なる点も見落とされがちです。次の3つは、いずれも「マネジメント経験」と一括りにされやすいものの、企業タイプによって重視される中身が異なります。

• 進行管理:スケジュール・予算・タスクの進捗を管理する経験(SIerのPMで評価されやすい)
• ピープルマネジメント:部下の評価・育成権限を持つ経験(事業会社・外資で個別に問われやすい)
• 技術的意思決定:設計・アーキテクチャの裁量と責任範囲(外資のグレード判定で重視されやすい)

職務経歴書に「マネジメント経験あり」とだけ書いても、応募先がどの意味で受け取るかは保証されません。自分が持っている経験がこの3つのうちどれに当たるのか、あるいは複数にまたがるのかを整理してから伝える必要があります。

つまり同じ「プロジェクトマネジメント経験5年」という経歴でも、それをどの評価軸に翻訳して伝えるかによって、書類選考や面接での評価は大きく変わります。この翻訳作業は自分の経験を客観視しにくいため、一人で正確に行うのは簡単ではありません。企業タイプを跨ぐ転職では、経験の量よりも、その経験を相手の評価軸で語り直せるかどうかが、年収の分かれ目になりやすいという点を、動く前に押さえておく価値があります。

分岐点を、動く前に確認する

ここまで見てきた配属・役割変化・裁量拡大という節目は、どれも自分ひとりでは気づきにくい形で進みます。SIerの下流に配置されたままなのか、上流の折衝ポジションに移れているのか、あるいは事業会社で収益に近い部署に配属されているのか、外資でどのグレードに位置づけられているのかは、日々の業務の中では実感しづらく、求人票の年収欄を眺めるだけでは判断できません。求人票に書かれているのは、あくまで募集ポジションの年収レンジの外形であって、そのレンジの中で自分がどの位置に評価されるか、そもそも今の自分がそのレンジに届く段階にいるのかまでは書かれていないからです。

特に、企業タイプを跨ぐ転職では、この「見えにくさ」が二重になります。ひとつは自分が今どの段階にいるかという現在地の見えにくさ、もうひとつは転職先の評価軸に照らしたときに自分の経験がどう翻訳され、どのレンジに着地しうるかという見えにくさです。SIerでの進捗管理・折衝の実績を、事業会社の「プロダクト貢献度」という言葉に置き換えられるか、外資の職務等級が求める技術的意思決定の範囲に自分の経験が届いているか。これらは求人票を何枚見比べても、自分の経歴書を読み直すだけでも、輪郭がつかみにくい論点です。

だからこそ、動く前に必要なのは「相場を知ること」以上に、「今の自分がその相場のどこに立っているか」を確認する作業です。経験年数や役職名だけでなく、担ってきた工程や裁量の範囲まで踏み込んで棚卸しできるであれば、自分の経験が企業タイプ別のレンジのどこに位置づけられるかを、面接前の段階ですり合わせることができます。次のセクションでは、経験年数・企業タイプ・職務内容を入力するだけで、この立ち位置を簡易的に確認できる診断を紹介します。

いまの自分が、どの段階にいるのかを知る

ここまで見てきたように、ITエンジニアの年収は一度きりの評価では決まりません。配属された瞬間にSIerの下流工程に置かれるか、投資フェーズの事業会社に入るか、グレード制度の外資系に組み込まれるかで、そもそもの評価軸が変わり始めます。そこからPGがSEに移って顧客折衝を持つように、事業会社で担当機能の事業貢献が問われ出すように、外資でグレード内の評価差がボーナス倍率に跳ねるように、役割の変化が単価に反映されるタイミングが訪れます。さらにPMとして予算責任を負う、テックリードやPdMを兼務する、意思決定の範囲が広がるといった裁量の拡大が起きると、そこから先は同じ職務であっても個人差として年収に現れていきます。

つまりこの記事で辿った「配属」「役割変化」「裁量拡大」という3つの節目は、多くのエンジニアが多少の時期の差はあっても通過していくものです。問題は、自分が今どの節目を通過し終えていて、どの節目の手前にいるのかを、本人が正確に把握できているとは限らない点にあります。

• 今の役職・担当工程は、所属企業タイプの相場レンジの中で上位・中位・下位のどこに位置しているか
• 次の役割変化(SE昇格、テックリード就任、グレード昇格など)は、単価にどの程度反映される段階にあるか
• 企業タイプを跨ぐ転職を考えた場合、積み上げてきた経験は転職先の評価軸でどう翻訳されるか

これらは求人票の年収欄や社内の評価シートだけを見ていても分かりません。同じ経験年数・同じ職務内容の人が、企業タイプ別・役職別にどのレンジへ分布しているかという相対的な位置づけが必要になるためです。特に、次の節目(役割変化や転職)を迎える前に自分の立ち位置を確認しておくかどうかで、提示された年収が妥当なのか、あるいはまだ動く余地があるのかの判断材料が変わってきます。

経験年数・企業タイプ・職務内容を入力するだけで、今の自分がどのレンジのどのあたりに立っているのかを確認できる診断であれば、こうした振り返りを面接や査定の場に出る前に済ませておくことができます。動いてから相場を知るのではなく、動く前に自分の分岐点を確かめておくことが、次の一歩を判断する材料になります。

よくある質問