インフラエンジニアが年収を上げるには、今いる段階の次の仕事を取りに行くことが第一の選択肢です。扱う製品を増やすより、運用から構築へ、構築から設計へと、自分で決める範囲を広げたときに評価が変わります。その仕事が今の会社にないなら、会社を変える判断に進みます。

水準や職種ごとの違いはインフラエンジニアの年収で整理しています。この記事は、そこから一歩進んで「自分の段階なら、次に何をすれば年収が動くのか」を決めるためのものです。

先に手当を抜いて現在地を測る

打ち手を選ぶ前に、今の年収から夜勤の手当、深夜割増、当番の手当を分けてください。インフラの額面には負担の対価が混ざっているため、そのまま比べると現在地を見誤るからです。

たとえば、夜勤のある運用の現場から日勤の構築の現場へ移ると、基本給は上がっても額面は下がることがあります。この変化を「年収が下がる転職」と読むと、次の段階へ進む機会を見送ることになります。反対に、額面が高いので市場価値も高いと考えていた人が、手当を除いた額を見て、思ったより低いと気づくこともあります。

公的統計でインフラに近い区分を見ると、サーバー管理者やシステム保守技術者を含む「その他の情報処理・通信技術者」の年収換算額(当サイト算出)は 610万円 です。平均年齢は 42.2歳、平均勤続年数は 12.1年 なので、経験の浅い人が比べるなら、年齢も勤続も自分より長い集団の値だと考えてください。この区分には情報セキュリティ技術者や通信技術者も入るので、インフラエンジニアだけの平均ではありません。また、6月分の月額を12倍して賞与を足した概算で、調査が公表した年収でもありません。

手当の分け方は深夜・シフト勤務の手当と実質時給とオンコールの当番手当で扱っています。ここでは、手当を除いた額を手元に置いて先へ進んでください。

段階は「変更を誰が決めるか」で判定する

自分の段階は、肩書きではなく直近の変更作業を誰が決めたかで判定します。インフラの求人は同じ職種名で幅広い仕事を含むので、名前からは判断できないためです。

段階 変更について自分がしていること 次の段階へ進む合図
運用 決まった手順を実行し、異常を報告する 手順を自分で書き直している
構築 決まった構成を環境に作り、設定を自動化する 別の構成を提案して通している
設計 構成、権限、費用を選び、理由を説明する 他のチームの基準まで変えている
信頼性・基盤 複数のサービスに共通する基準と基盤を決める 事業側と守る水準を合意している

判定で迷うときは、直近の障害を一つ思い出してください。自分が手順に沿って一次対応したなら運用、再発しないよう自動化したなら構築、そもそも問題が起きない構成に変えたなら設計に近い仕事です。

ただし、一人の中に複数の段階が混ざるのは普通です。小さな会社では、構成を決めながら夜間の一次対応もしています。その場合は、最も上の段階の仕事が全体のどれくらいを占め、選考で説明できる実績になっているかで判断してください。

運用の段階は、権限のある仕事を一つ取りに行く

運用の段階で最初に取りに行くのは、手順を変える権限です。作業を正確にこなす評価はすでに得ていても、それだけでは上の段階の実績になりません。手順を実行する人と手順を決める人では、責任の大きさが違うからです。

具体的には、毎週発生している手作業を一つ選び、原因を調べて、自動化か監視の見直しを提案します。実装まで任されなくても、切り分けの資料と変更案を自分で作れば、選考で話せる材料になります。夜間に繰り返すアラートの閾値を見直し、不要な呼び出しを減らした経験は、地味でも判断の実績です。

注意点は、客先常駐で変更の権限が顧客側にある現場です。提案そのものが契約の範囲外とされ、どれだけ力があっても上の段階へ進めないことがあります。半年を目安に提案を試みて、何も変えられないと分かったら、努力の量ではなく配属や会社の構造の問題として扱ってください。運用の配属から抜ける手順は運用保守エンジニアの年収相場に詳しく書いています。

構築の段階は、選ばなかった案を語れるようにする

構築の段階で年収が止まりやすいのは、決まった構成を速く正確に作ることで評価が完結してしまうときです。作業の速さは大切ですが、設計を任せる根拠にはなりません。会社が設計者に求めるのは、別の案を比べて、失敗したときの影響まで考えて選ぶことだからです。

打ち手は、今の案件の構成について「なぜこの形なのか」を自分の言葉で書いてみることです。冗長化の方法、権限の分け方、費用の見積もりのうち、理由を説明できないものが次に学ぶ範囲になります。その上で、小さな変更で構成案を出し、レビューを受けてください。選んだ理由と捨てた案が記録に残れば、職務経歴書でも面接でも設計の入口の実績として扱えます。

例外として、設計が別の会社や別の部門に固定されている案件では、構築の担当者が構成案を出す場がありません。その場合は、構築の手順のコード化や、再現できる環境づくりに集中して実績を作り、設計を含む募集へ応募する材料にします。

設計の段階は、担当の外へ影響を広げる

設計を任されているのに年収が動かない場合、原因は技術より責任の範囲と会社の上限にあることがあります。一つのシステムの構成を決めるだけの段階から、複数のサービスの基準や、費用と可用性の判断へ広げると、上の等級の要件に近づきます。

たとえば、担当システムのログの扱いを直して終わるのではなく、他のチームも使える基準にまとめ、導入を支えるところまで進めます。さらに、停止を許せる時間を事業側と話し合い、守る水準と費用を決められれば、技術の判断を事業の判断へつなげる役割になります。

注意点として、この段階では等級の上限を確かめないと努力の方向を誤ります。次の等級の要件が管理職だけに開かれている会社なら、技術の範囲を広げても昇格しません。専門職の上限は専門職コースの等級の確認で、担当工程と年収の関係は上流工程の年収で確かめてください。

クラウドへ移るだけでは段階は上がらない

「オンプレミスからクラウドへ移れば年収が上がる」と考えがちですが、結論としては段階が同じなら、移るだけで上がるとは言えません。クラウドの現場にも、監視や決まった設定の作業はあるからです。

役割による違いは、募集の書き方にも表れます。製品名の付いた運用の募集は「手順どおりに作業できるか」を問い、信頼性まで責任を持つ募集は「障害の再発をどう防ぐか、変更の安全をどう設計するか」を問います。後者は判断の範囲が広く、その分だけ提示額の根拠も大きくなりやすいと考えられます。ただし、これは募集の構造からの推論で、統計で確かめた差ではありません。求人を比べるときは、職種名より、障害対応と変更の判断がどこまで任されるかを読んでください。

クラウドの経験を年収につなげるなら、資格や製品の名前を増やすより、権限設計、費用の管理、障害時の切り替えのうち一つを自分で判断した実績を作ってください。資格の役割はクラウドエンジニアの年収相場で扱っています。

会社を変えると動く幅をモデルで比べる

段階を上げる話とは別に、所属する会社の構造で水準が動きます。当サイトの診断モデルの推定で、東京、実務3〜5年、スコア70(モデルの実務3〜5年の平均に近い水準)の条件で企業タイプだけを変えると次のとおりです。

企業タイプ推定レンジレンジの図
メガベンチャー・外資650〜763万円
上場・大手572〜671万円
中小の受託・SIer494〜580万円
スタートアップ520〜610万円
SES442〜519万円
条件:3〜5年/東京/スキルスコア70。公開統計をもとにした推定であり、実際の年収を保証するものではありません。算出方法

これは統計ではなく、公開統計を参考に編集判断で係数を置いたモデルの推定です。インフラエンジニアに限った計算でもありません。同じモデルでスキルの違いだけを見ると、上場・大手で実務3〜5年の中央値は、スコア50で 578万円、スコア85で 655万円 です。

読み方の要点は、社内で段階を上げる打ち手と、会社を変える打ち手は別の差を埋めているということです。SESや受託の水準にいて、変更の権限が顧客側にあるなら、社内の努力では上の行へ移りにくくなります。逆に、すでに水準の高い会社にいるなら、段階を上げるほうが先です。実際の提示は募集の段階でも変わるので、この表の金額に自動で届くとは考えないでください。

社内か転職かは、3つの答えで決める

判断は次の3つを順に確かめます。全部が「はい」なら社内を先に進め、途中で「いいえ」になった時点で、外の求人を比べる理由ができます。

  1. 次の段階の仕事が、今の会社か現場に存在するか
  2. その仕事を、半年以内に自分に回してもらえる見込みがあるか
  3. その仕事をすると、等級か給与に反映されると説明されているか

たとえば、構築の担当者が設計の機会を求めたとき、上司が具体的な案件を示し、次の等級の要件と結びつけて話してくれるなら、社内で進む価値があります。「いずれ任せる」で時期も要件も示されない場合は、残ること自体は間違いではありませんが、期限を決めてください。

転職を選ぶ場合も、必ず年収が上がるわけではありません。dodaエージェント経由の転職決定者の決定年収(採用決定時の提示額)を比べた集計では、年収が増えた人は 59.2%(2026年4〜6月(2026年度第1四半期)) で、これは職種を問わない数字です。求人側の状況として、情報処理・通信技術者の有効求人倍率は 1.33倍(令和8年8月) ですが、職種全体の数字で、インフラの段階ごとの違いまでは分かりません。

夜勤を抜ける転職で額面が下がるときの考え方

日勤へ移ると額面が下がる場合でも、それだけで不利とは言えません。比べるのは手当を除いた基本給、年間の労働時間、次の段階の経験の3つです。夜勤の負担に対して支払われていた分が消えるのは、損失というより働き方の変更だからです。

たとえば、仮に手当を除いた月額の基本給を現職 A 万円、転職先 B 万円として、B が A を上回っていれば、基本給の水準は上がっています。そのうえで、年間の額面を年間の労働時間で割った実質の時給を比べます。ここで用いる A と B は説明のための記号で、相場を示すものではありません。

例外は、生活費が手当の入った額面を前提に組まれている場合です。その場合は、差額を埋める期間の見通しを先に立ててください。数年先の伸びが見込めても、当面の家計が成り立たなければ、別の時期を選ぶほうが安全です。

応募前に段階を確かめる質問

求人票の職種名が同じでも、入社後の段階は違います。面談では次のように聞くと、仕事の中身が分かります。

  • 直近で構成を変更したとき、案を作って決めたのは誰ですか
  • 定常作業と改善の作業は、どのくらいの割合ですか
  • 直近3か月で自動化した作業は何ですか
  • 入社後半年で任せたい判断は何ですか
  • 夜間対応の頻度と手当、翌日の勤務はどうなりますか

答えが「幅広くお任せします」で止まる場合は、もう一歩具体的に聞きます。立ち上げ期のチームでは決まっていないこともありますが、誰が決めるのかまで不明なら、入社後に担当が運用だけに固まる可能性を見込んでください。

この記事の打ち手が当てはまらない場合

ここで示した段階は、自社のシステムや顧客の基盤を担当する正社員を想定しています。ネットワーク機器の専門性や、データセンターの設備に強みがある人は、段階より専門領域の希少性で評価されることがあります。その場合はネットワーク・インフラ運用の年収相場も参考にしてください。

アプリケーション開発へ移ることで年収を上げたい人は、前提が変わります。経験年数の扱いが変わる可能性があるので、インフラからアプリ開発へ移る年収で確認してください。また、この記事の推定レンジには手当を個別に織り込んでいないので、自分の額面と直接は比べられません。

次の一手を決める最終チェック

  • 年収から夜勤、深夜割増、当番の手当を分けて、手当を除いた額を出した
  • 直近の障害と変更を使って、自分の段階を判定した
  • 次の段階の仕事を一つ、具体的に書き出した
  • その仕事を任せる権限が誰にあるかを確かめた
  • 等級か給与への反映を、上司か規程で確認した
  • 社内で進む期限を決め、過ぎたら外の求人を比べると決めた

手当の割合と手当を除いた額を把握したうえで同じ条件のレンジと比べると(推定は手当を除いた水準ではありません)、社内と転職のどちらを先に試すかを決めやすくなります。