SE（システムエンジニア）の年収相場｜平均が割れる理由と企業タイプで178万円の差

SE（システムエンジニア）の年収は、肩書きでは決まりません。どの工程に責任を持ち、商流のどの位置の会社で働いているかで決まります。同じ「SE」という名刺を持っていても、顧客と要件を決めて見積もりに責任を持つ人と、決まった設計書をもとに詳細設計と実装を進める人では、公的統計の上でも別の職種として数えられ、平均の水準も大きく違います。

ネットで「SEの平均年収」を調べると、出てくる数字がばらばらで戸惑うかもしれません。その理由の多くは、どの範囲の人を「SE」と呼んで集計したかの違いにあります。この記事では、厚生労働省の職種別統計を使ってSEがどの区分に入るのかを確かめ、そのうえで当サイトの推定モデルを使って、SIerの企業タイプ、商流、役割がどれだけ年収を動かすかを整理します。ITエンジニア全体の水準はエンジニアの平均年収で、ほかの職種との比較は職種別のエンジニア年収で扱っています。

結論：SEの年収は担う工程で2つの水準に分かれる

先に結論を書くと、SEの年収を自分の相場として読むには、要件定義・設計・管理を担っているのか、詳細設計・実装・保守を担っているのかを最初に切り分ける必要があります。前者は公的統計の「システムコンサルタント・設計者」に、後者の多くは「ソフトウェア作成者」に近く、両者の年収換算額には大きな開きがあるからです。

理由は、日本のIT業界でSEという言葉が非常に広く使われていることにあります。SIerでは新卒で入社した人の多くがSEという職種名で採用され、入社直後はテストや実装を担当し、経験を積むと設計、要件定義、プロジェクト管理へと担当工程が上がっていきます。つまりSEという肩書きの中に、下流の実装担当から上流の設計者・管理者までが入っています。

具体的に言えば、入社3年目で詳細設計と実装を担当しているSEと、15年目で顧客の業務部門と要件を詰めているSEは、どちらも社内ではSEです。しかし市場で評価されている仕事はまったく違い、統計で比べるべき数字も違います。前者がシステムコンサルタント・設計者の平均と自分を比べると、必要以上に低く感じてしまいます。

注意点として、この2区分の境界ははっきり線が引けるものではありません。小さな会社では一人で要件定義から実装までを担うことも多く、どちらか一方に当てはめにくい人もいます。その場合は、仕事時間の大半を占める工程、あるいは評価面談で主に問われている成果がどちらに近いかで判断すると、読み違いが減ります。

SEとは何をする仕事か、肩書きはどう使われているか

SEは、顧客や利用部門の要望をシステムの形に落とし込む役割を指すことが多い言葉です。ただし法律や公的な資格で定義された職名ではないため、会社ごとに指している仕事の範囲が違います。

一般的なシステム開発では、要件定義、基本設計、詳細設計、実装、テスト、移行、運用保守という工程を順に進めます。SIerの文脈でSEと呼ばれるのは、このうち要件定義から設計、テストの計画あたりまでを担う人で、実装はプログラマーや協力会社が受け持つという分担が典型でした。一方で、Webサービスを開発する会社ではSEという呼び方自体をあまり使わず、同じ仕事をバックエンドエンジニアやソフトウェアエンジニアと呼ぶことが多くなります。

肩書きの使われ方をよく表すのが求人票です。「SE（Java）」と書かれた求人の中身が、実際には詳細設計とJavaでの実装が中心という例は珍しくありません。反対に「プログラマー」と書かれた求人で、顧客との仕様調整まで任されることもあります。SIerや受託開発の会社では、職種名を工程ではなく社内の等級や入社年次と結びつけて使っている場合もあります。

例外として、社内SEのように、所属する事業会社の情報システム部門で、ベンダーへの発注、社内の要望整理、運用までを担う人もSEと呼ばれます。社内SEは自分でコードを書かないこともあれば、小さなツールを内製することもあり、仕事の中身は会社によってさらに幅があります。社内SEの年収の決まり方は社内SEの年収で詳しく扱っています。

公的統計ではSEが2つの職種にまたがる

厚生労働省の賃金構造基本統計調査には、「システムエンジニア」という単独の職種がありません。情報処理・通信技術者は、システムコンサルタント・設計者、ソフトウェア作成者、その他の情報処理・通信技術者の3つに分けて集計されています。

調査の職種の説明では、システムコンサルタント・設計者にはシステムコンサルタント、システムアナリスト、情報処理プロジェクトマネージャなどが含まれます。ソフトウェア作成者にはプログラマー、テクニカルスペシャリストに加えて、社内システムエンジニアが含まれます。その他の情報処理・通信技術者は、ITサービスマネージャ、システム保守技術者、サーバー管理者、情報セキュリティ技術者などです。上流の設計と管理を担うSEは1つ目に、実装寄りのSEや社内SEは2つ目に数えられることになります。

最下段から2行目の年収換算額は、調査が公表した年収ではありません。当サイトが、きまって支給する現金給与額（6月分の月額）を12倍し、年間賞与その他特別給与額を足して算出した概算です。この表で目を引くのは、システムコンサルタント・設計者とソフトウェア作成者の平均年齢がほぼ同じなのに、給与の水準が大きく違うことです。年齢の差では説明できず、担っている仕事と所属している会社の違いが表れていると読むのが自然です。

もうひとつ注目したいのは賞与の差です。月額の給与よりも賞与のほうが区分間の開きが大きく、システムコンサルタント・設計者は賞与の比重が高い構成になっています。上流の設計や管理を担う人が、賞与の水準が高い大手のSIerやコンサルティング会社、事業会社に多く在籍している可能性が考えられますが、この表だけでは会社の規模ごとの内訳までは分かりません。

統計の数字を読むときの注意点

この表を自分の年収と比べる前に、どんな人の、どの時点の数字なのかを押さえておく必要があります。条件を外して読むと、自分の位置を大きく見誤ります。

まず、対象は常用労働者10人以上の企業の民営事業所で働く一般労働者で、短時間労働者は含みません。フリーランスや個人事業主は入っていないため、業務委託で働くSEの収入とは比べられません。次に、月額は令和7年6月分、賞与は令和6年1年間の支給額で、時点がずれています。6月分の月額を12倍しているので、繁忙期の残業代の増減や、年の途中の昇給は反映されていません。

具体的な読み違いの例を挙げます。SIerで設計を担当する30代のSEが、年収換算額のシステムコンサルタント・設計者の値を見て「自分は大きく下回っている」と感じたとします。しかしこの平均には、プロジェクトマネージャやコンサルタント、大手企業の管理職に近い人も含まれています。しかも平均値なので、高い年収の人がいると全体が引き上げられます。比べるべきは平均そのものではなく、自分と同じ工程、同じ規模の会社で働く人の水準です。

例外として、ソフトウェア作成者の値を見て安心するのも早計です。この区分は人数が多く、未経験に近い若手から熟練の技術者までを幅広く含みます。所定内給与額ときまって支給する現金給与額の差は残業代などにあたる部分で、どちらの区分もこの差は比較的小さく出ていますが、残業の多い現場で働く人には当てはまりません。統計は全体の傾向をつかむ道具として使い、個別の判断は次章以降の条件別のレンジで行ってください。

ネットの「SEの平均年収」が食い違う理由

ネット上でSEの平均年収として示される数字が食い違うのは、どれかが間違っているからとは限りません。多くの場合、集計の対象と、SEという言葉に含めた範囲が違うことが原因です。

ひとつ目の違いは、職種の区切り方です。公的統計のシステムコンサルタント・設計者だけを「SE」と呼べば平均は高く出ますし、ソフトウェア作成者まで含めれば低く出ます。労働者数を見ると、ソフトウェア作成者が 81.8万人、システムコンサルタント・設計者が 17.4万人 で、人数は前者のほうがはるかに多いため、両方を合わせた平均はソフトウェア作成者の水準に引き寄せられます。

ふたつ目の違いは、集計元の母集団です。転職サービスの集計は、そのサービスに登録した人の申告をもとにしています。民間の転職サービスの集計では、ITエンジニア全体の平均年収は 469万円（2025年） でしたが、これは転職を考えて登録した人の数字で、若手の比率や職種の構成が公的統計とは違います。どちらが正しいという話ではなく、測っている対象が違うのです。

具体的には、同じ「SE 年収」で検索しても、公的統計の設計者区分を引用した記事と、転職サービスの職種別平均を引用した記事では、見える数字に大きな幅が出ます。読む側としては、数字の大きさより先に、その数字が「誰を」「いつ」「どうやって」集めたものかを確かめる習慣をつけると、極端な数字に振り回されなくなります。

注意点として、出典が書かれていない平均年収は比較の材料にしないほうが安全です。年収のように個人の判断に直結する情報では、集計方法を説明できない数字ほど扱いに困ります。当サイトでは、記事内の統計にはすべて出典と調査時点を付けています。

経験年数で見るSEの推定レンジ

統計の平均で全体像をつかんだら、次は自分の条件に近いレンジを確認します。ここからは当サイトの推定モデルを使い、SEが多く働く中小の受託・SIer、東京勤務、スキル中位という条件を固定して、経験年数だけを変えた場合を見ます。

この表は、SEとしての年数そのものに値段が付くことを示しているわけではありません。年数とともに任される工程が上がった場合の水準と読んでください。SIerのSEは、1〜2年目にテストや実装、3〜5年目に詳細設計と小規模な機能のとりまとめ、6〜9年目に基本設計やチームリーダー、10年以上で要件定義やプロジェクト管理を担う、という順に進むことが多く、表の行の上がり方はこの流れとおおむね重なります。

例外は、年数が増えても担当工程が上がらない場合です。同じ保守案件で同じ範囲の改修を長く続けていると、社内の等級は少しずつ上がっても、市場で評価される経験は増えません。逆に、3〜5年目でも顧客との仕様調整や設計判断を任されているなら、上の行の水準を目指せる材料があります。表は年数ではなく、担っている工程で自分の行を探してください。

なお、このモデルは「中小の受託・SIer」をひとつの企業タイプとして扱っており、元請けか下請けかといった商流の位置は直接は入っていません。商流の影響は、次の企業タイプの比較とあわせて読む必要があります。

SIer・SESなど企業タイプで178万円の差

同じ実務10年以上、東京勤務、スキル中位のSEでも、所属する企業のタイプを変えると推定レンジはこれだけ動きます。

上場・大手とSESの推定の中央値の差は 178万円 です。大手のSIerの多くは顧客と直接契約する元請けの立場にあり、SESの多くは他社の開発現場にエンジニアを送り出す立場にあります。モデルは商流を直接の変数にしていませんが、この2つの企業タイプは、商流の上と下に多い働き方をおおまかに表していると読めます。

この差が生まれる理由は、単価の決まり方にあります。元請けのSIerは、顧客と要件や金額を交渉する立場にあり、要件定義やプロジェクト管理といった付加価値の高い工程を自社で持ちます。SESでは、エンジニアの稼働に対して月額の単価が決まり、そこから所属会社の取り分を差し引いた額が給与の原資になります。上流の工程を持つかどうか、価格を決める側にいるかどうかが、そのまま給与の原資の差になります。

SIerにはユーザー系、メーカー系、独立系といった成り立ちの違いもあり、親会社との取引の比重や案件の取り方によって水準が変わります。この違いについてはユーザー系・メーカー系・独立系SIerの年収の違いで、企業タイプ全体の比べ方は企業タイプ別のエンジニア年収相場で扱っています。

注意点として、この表を「大手に入れば上がる」と読むのは早計です。大手のSIerでも、子会社や関連会社として親会社から仕事を受ける立場では、元請けの水準には届きにくくなります。一方で、SESでも高い専門性があり、顧客から直接指名されるような立場なら、表の下端に留まる理由はありません。企業のタイプは入口の目安で、最終的には次に扱う商流と役割で決まります。

商流：一次請けと二次請けで何が変わるか

SIer業界の年収を考えるうえで避けて通れないのが商流です。顧客から直接仕事を受ける一次請けか、一次請けからさらに仕事を受ける二次請け以降かで、SEの年収と経験の質は変わりやすくなります。

理由は大きく3つあります。ひとつは、商流を一段下がるごとに、上位の会社が受け取る取り分が差し引かれ、自社に残る金額が小さくなることです。ふたつ目は、価格を決める主体が変わることです。一次請けは顧客と金額を交渉できますが、二次請け以降は上位の会社が決めた単価を受け入れる立場になりやすくなります。3つ目は、任される工程です。要件定義や基本設計は一次請けが持ち、詳細設計以降が下位の会社に渡される分担が多いため、上流の経験を積む機会そのものが商流で変わります。

具体例として、官公庁のシステム更改のような大規模案件では、元請けの大手SIerがプロジェクト全体を管理し、その下に複数の会社が機能ごとに入る構造になることがよくあります。同じ案件に参加していても、元請けのSEは顧客と仕様を決める会議に出ており、三次請けのSEは決まった設計書をもとに製造とテストを進める、という違いが生まれます。公共案件の構造は官公庁・公共システムに関わるエンジニアの年収相場で詳しく扱っています。

例外もあります。二次請けでも、特定の業務パッケージや技術領域で代わりのきかない専門性を持つ会社は、高い単価で参加できることがあります。反対に、一次請けの会社に勤めていても、社内で担当が細分化されていて自分は一部の作業しか持っていない、ということもあります。商流の見分け方と確認の質問は一次請けと二次請けでエンジニアの年収はなぜ変わる？にまとめています。

役割：要件定義・設計・PMで評価が変わる

SEの年収が大きく動くのは、担う工程が要件定義、プロジェクト管理といった上流に移るときです。上流の工程ほど、判断の誤りがプロジェクト全体の費用と期間に響くため、その責任を持てる人に高い評価が付きます。

要件定義では、顧客の業務を理解し、何をシステム化し何をしないかを合意する力が問われます。ここで範囲を曖昧にしたまま進むと、後の工程で手戻りが膨らみ、赤字案件の原因になります。基本設計では、業務の流れを画面、帳票、データ、外部システムとの連携に分解し、後工程の担当者が迷わない形に整理する力が求められます。どちらも、技術の知識と顧客との対話の両方が必要で、経験を積んだ人しか任されにくい仕事です。

プロジェクト管理まで進むと、評価の対象は自分の成果物から、チーム全体の品質、費用、納期に移ります。SIerのプロジェクトマネージャは、案件の利益に責任を持つ立場になることが多く、等級も大きく上がりやすい役割です。PMの年収の決まり方はITプロジェクトマネージャーの年収相場で、PMを支える立場の役割はPMOの年収相場で扱っています。

注意点として、管理職に上がると残業代が支給されなくなる会社もあります。SIerのSEは繁忙期に残業が増えやすく、残業代が年収の一部を占めていることがあるため、昇格によって手当の構成が変わり、かえって年収が下がる時期が出ることもあります。上流に移るときは、役職だけでなく、残業代の扱いと賞与の評価方法がどう変わるかを先に確認してください。

業界と技術領域で変わるSEの仕事

SEの年収は、どの業界のシステムを、どの技術で扱うかによっても変わります。業務知識が深く、代わりの人を見つけにくい領域ほど、評価が安定しやすい傾向があります。

金融機関の勘定系や決済のシステムは、止まったときの影響が大きく、業務の規則も複雑です。こうした領域のSEは、技術に加えて金融の業務と規制の知識を持つことで評価されます。詳しくは金融系システムのエンジニアの年収で扱っています。企業の基幹業務を支えるERPの導入では、会計や販売、生産管理といった業務の知識が年収に直結します（SAP・ERP導入エンジニアの年収相場）。

技術の面では、業務システムの開発でいまも多く使われるJavaの経験は、SIerで働くSEの土台になることが多い一方、それだけでは差がつきにくくなっています（Javaエンジニアの年収相場）。長く使われてきたメインフレームとCOBOLの資産は、移行の時期を迎えて経験者の需要が残っており、現行の仕様を読み解ける人が評価される場面があります（COBOL・メインフレームのエンジニアの年収）。海外の開発拠点と国内の顧客をつなぐ役割では、語学より責任範囲の広さが問われます（ブリッジSEの年収相場）。

例外として、業務知識が深いことが、かえって転職の選択肢を狭めることもあります。特定の会社独自のシステムにしか通用しない知識は、社内では重宝されても、社外では評価の材料になりにくいからです。業務知識を年収につなげるには、その業界で共通して使われる業務の流れや規制、パッケージの知識として説明できる形に整理しておくことが大切です。

SEとプログラマーの違い

SEとプログラマーの違いは、どこまでの工程に責任を持つかで整理すると分かりやすくなります。プログラマーは設計に沿って正しく動くコードを書くことに、SEは要件を設計に落とし込み、関係者と合意することに主な責任を持つ、というのが従来の分担です。

公的統計で設計を担う区分の平均が高く出るのは、この責任の違いを反映しています。ただし、Webサービスの会社のように工程を分けずにひとりが設計から実装まで担う職場では、SEとプログラマーという区別自体が意味を持ちません。高い専門性を持つプログラマーが、設計中心のSEより高く評価されることも普通にあります。

プログラマーの年収そのものはプログラマーの年収相場で、仕事内容、必要なスキル、キャリアの進み方を並べた比較はプログラマーとSEの年収はなぜ違う？で扱っています。この記事では、比較そのものより、SEという肩書きで働く人が自分の水準をどう読むかに絞っています。

SEが年収を上げる4つの道

SEが年収を上げる道は、大きく4つに分けられます。どれを選ぶにしても共通するのは、いまの職場で次の段階の仕事を先に取りに行き、説明できる実績にしてから動くことです。

1. 上流の工程を担う

最も一般的なのは、詳細設計から基本設計、要件定義へと担当工程を上げることです。上流の工程は顧客との合意形成を含むため、経験者の数が限られ、評価も高くなりやすくなります。いきなり要件定義の担当にはなれなくても、顧客との打ち合わせに同席して議事録と論点の整理を引き受ける、仕様の曖昧な点を一覧にして確認する、といった動きから始められます。

2. プロジェクト管理に進む

チームリーダーからプロジェクトマネージャへ進む道です。SIerでは等級と年収が大きく上がりやすい一方、技術から離れる時間が増え、責任も重くなります。小さな機能のとりまとめ、進捗と課題の管理、協力会社との調整など、管理の一部を担った経験を積み上げると、登用の判断材料になります。

3. 業務知識で専門性を作る

金融、製造、物流、公共など、特定の業界の業務に詳しいSEは、技術だけのSEより代わりがききにくくなります。業務パッケージの導入経験や、業界の規制に関わる知識は、転職市場でもそのまま説明できる強みです。前章で触れたように、会社独自の知識ではなく、業界で通用する知識として整理しておくことが条件になります。

4. 事業会社や自社開発の会社へ移る

商流の下位にいる場合、会社の中でどれだけ評価されても、受け取れる単価の上限に縛られることがあります。その場合は、自社のシステムを持つ事業会社の社内SEや、自社サービスを開発する会社へ移ることで、構造そのものを変える選択肢があります。ただし事業会社では、ベンダーを管理する力や、事業への貢献を説明する力が問われ、SIerでの評価軸とは違います。

注意点として、どの道も年数だけで自動的に開けるものではありません。スキルの評価が変わるだけでも推定は動きます。実務3〜5年、上場・大手、東京の条件で、スキル下位なら 491〜576万円、スキル上位なら 602〜707万円 です。同じ年数、同じ会社でも、担える仕事の深さで位置は変わります。

求人票でSEの仕事を見分ける質問

SEの求人は職種名から仕事内容が読み取りにくいため、応募前に次の点を確認すると入社後のずれが減ります。

• 顧客と直接契約している案件の割合はどのくらいか、二次請け以降の案件はあるか
• 入社後に担当する工程は、要件定義、基本設計、詳細設計、実装、テストのどこか
• 自社のSEが実装まで担うのか、実装は協力会社に任せるのか
• 客先に常駐する働き方か、自社で開発する働き方か
• プロジェクト管理を任される等級と、そこまでの標準的な道筋はどうなっているか
• 残業代は等級によって支給されなくなるか、賞与は何で評価されるか

これらは面接で聞けば答えが返ってくる範囲の質問です。答えが曖昧なまま「上流から下流まで幅広く経験できます」と説明される場合は、実際の案件の構成を具体的に聞き直してください。幅広く経験できるという意味の場合もあれば、商流の位置が案件ごとにばらばらで、上流の経験が積みにくいという意味の場合もあります。

確認した内容は、提示された年収と等級に突き合わせます。上流の工程を担う前提の求人なのに等級が低い場合、その理由を説明できるかどうかが、入社後に評価が上がる会社かどうかの手がかりになります。

SEの年収を比べるときの注意点

最後に、SEの年収を比べるときに外れやすい読み方を整理しておきます。結論としては、ひとつの平均を自分の物差しにせず、工程・商流・企業タイプの3つを揃えて比べることです。

まず、統計の平均には中央値より高く出る性質があります。参考として、情報通信業全体の平均給与は 682万円（令和7年（2025年））、同じ調査から当サイトが推計した中央値は 600万円 です。業種全体の数字なのでSEに限りませんが、平均を下回っていることは珍しくありません。次に、本記事の推定レンジは公開統計と編集判断にもとづくモデルの値で、個別の会社の提示額を保証するものではありません。

具体的な失敗例は、転職の場面で起きやすくなります。たとえば、二次請けで実装を中心に担ってきたSEが、設計者区分の平均を根拠に高い希望年収を出すと、応募先から見ると経験と希望が合っていないように映ります。反対に、要件定義を任されてきたSEが、ソフトウェア作成者の平均を見て希望額を低く抑えると、本来得られる水準を取り逃します。どちらも、統計の区分と自分の担当工程を揃えていないことが原因です。

例外として、地方で働くSEや、フルリモートで働くSEは、勤務地による係数の違いを考慮する必要があります。また、業務委託として働くフリーランスのSEは、月額の単価を単純に12倍して正社員の年収と比べることはできません。働き方が違う場合は、この記事の数字をそのまま当てはめず、それぞれの条件に合った比べ方を選んでください。

まとめ

• SEは公的統計でシステムコンサルタント・設計者とソフトウェア作成者にまたがり、どちらを見るかで平均が大きく変わる
• 年収換算額は当サイトが算出した概算で、平均値であることと調査対象の範囲に注意して読む
• 実務10年以上・東京・スキル中位でも、企業タイプだけで推定の中央値に178万円の差がある
• 年収を動かすのは、商流の位置と、要件定義・設計・PMといった担当工程
• 上流、PM、業務知識、事業会社への移動のどれも、いまの職場で次の工程を取りに行くことから始まる

自分の条件でのレンジは、経験年数・企業タイプ・勤務地・スキルを入れて診断で確認できます。