「やめとけ」と言われる4つの理由と職場で変わる範囲
インフラエンジニアが敬遠される理由をまとめると、休日や夜間の障害対応、監視と運用だけが続く現場、オンプレミスの縮小への不安、止められない責任の重さの4つです。どれもインフラの仕事に付いてくる面がある一方、当番の体制や任される工程、扱う技術によって重さが変わるので、転職先を選ぶ段階で見極められます。
夜間や休日の障害対応とオンコール
サービスは夜も週末も動いているため、障害が起きれば時間を問わず対応が要ります。データセンターでの夜間作業や、24時間稼働のシステムを交代で見守る監視の仕事もあり、ここが「きつい」と言われやすいところです。
負担の大きさを決めるのは、呼び出しの頻度と、当番を何人で回すかです。
Offers に掲載されたインフラエンジニアと SRE(Site Reliability Engineering・サービスの信頼性をソフトウェアの手法で高める職種)の正社員求人を数えました。夜間・休日の対応やオンコール(障害時の呼び出しに備えて待機する当番)を本文か勤務条件の欄に書く求人は、そのうち4.3%です(Offers(株式会社overflow)調べ・インフラ・SRE 系の正社員求人 n=282・2022年11月〜2026年10月公開)。
書いている求人には、「休日オンコール対応あり(月1日程度シフト申告制、代休必須)」と頻度と代休まで示すものや、SRE の業務に「オンコール対応の設計と改善」を挙げるものがあります。
求人票から当番の有無や頻度を読み取れない求人のほうが多いので、月に何回当番が回るか、呼び出されたあとの代休や手当はどうなるかは、面接で聞いておきたいところです。
監視と運用の手順を回すだけの現場
決められた手順で監視とアラート対応を続ける仕事は、技術を伸ばしにくく、年数を重ねても任される範囲が広がらないと感じやすい働き方です。ただ、求人を見るかぎり、運用だけを任せる募集は少数でした。
同じ求人で業務の欄を見ると、「設計」「構築」を書く求人は89.7%、「運用」「保守」「監視」を書く求人は86.9%で、運用・保守・監視だけを書いて設計・構築を書かない求人は6.7%でした。自動化や IaC、Ansible(サーバーの設定を自動化するツール)を業務に挙げる求人も42.9%あります。
運用の経験そのものは、障害の起こりやすい箇所や監視の勘所を知っている強みです。転職先を選ぶときは、運用で見つけた課題を設計や自動化で直す役割まで任されるかを確かめると、伸びしろのある職場かどうかを見分けられます。
オンプレミスの縮小と、経験が古くなる不安
自社でサーバーやデータセンターを持つオンプレミスの環境はクラウドへの移行が進んでおり、オンプレミスの経験だけでは応募できる求人が狭まるのではないか、という不安も、この職種が敬遠される理由の1つです。
企業のクラウド利用が広がっていることは、統計でも確かめられます。総務省の「令和7年通信利用動向調査」(2026年5月公表)では、クラウドサービスを一部でも利用している企業の割合は83.5%で、全社的に利用している企業は60.0%と前年から6.9ポイント増えました。
それでも、オンプレミスの経験が求人から消えたわけではありません。Offers の求人では、本文にオンプレミスか仮想化の語を書く求人が38.3%ありました。
その求人に限ると、89.8%がクラウドの語も書き、32.4%がオンプレミスからクラウドへの移行を書いています(Offers(株式会社overflow)調べ・本文にオンプレミスか仮想化の語を書くインフラ・SRE 系の正社員求人 n=108・2022年11月〜2026年10月公開)。
オンプレミスと仮想化の経験は、クラウドとの併用や移行を進める職場で、移す側の環境を知る人として求められています。不安を減らす近道は、これまでの経験を手放すことより、その上にクラウドの設計と IaC を重ね、移行を任せられる側に回ることです。
止められないシステムを預かる責任の重さ
インフラが止まればサービス全体が止まるため、障害が起きたときの責任は重く、何も起きないことが成果なので評価されにくいと感じる人もいます。重さを左右するのは、障害を個人で抱えるか、チームの仕組みで減らすかです。
求人の本文では、障害対応やインシデント対応を書く求人が28.0%でした。SLO(サービスが満たすべき信頼性の目標)やポストモーテム(障害のあとの振り返り)、再発防止、オブザーバビリティ(システムの状態を外から観測できるようにすること)といった、障害を仕組みで減らす語を書く求人は16.0%です。
振り返りと再発防止の進め方が決まっている職場では、障害は個人の失敗で終わらず、監視や設計を直す材料になります。信頼性の目標をどう置き、障害のあとに誰が何を直すかは、面接で聞ける点です。
求人が求めるスキルはクラウド・IaC・コンテナ
インフラエンジニアの求人の大半は AWS をはじめとするクラウドに触れ、半数は必須要件にもクラウドの経験を挙げています。IaC やコンテナを挙げる求人も少なくありません。インフラ・SRE 系の正社員求人のうち、本文にクラウド(AWS・Google Cloud・Azure)の語を書く求人は85.8%で、AWS に限っても82.6%でした。
技術 | 本文に出る割合 | 必須要件に挙げる割合 | 歓迎の側にだけ書く割合 |
|---|
クラウド(AWS・Google Cloud・Azure) | 85.8% | 50.0%(「クラウド」の語を含む) | ― |
コンテナ(Docker・ECS・Kubernetes など) | 42.9% | 13.1% | 14.2% |
IaC(Terraform・CloudFormation など) | 36.2% | 10.3% | 14.9% |
Kubernetes(EKS・GKE・AKS を含む) | 19.1% | 6.0% | 9.6% |
オンプレミスまたは仮想化 | 38.3% | 9.2% | ― |
(Offers(株式会社overflow)調べ・インフラ・SRE 系の正社員求人 n=282・2022年11月〜2026年10月公開)
必須要件に挙がるのはクラウドの経験が中心です。IaC は必須要件に挙げる求人より歓迎の側にだけ書く求人のほうが多く、コンテナは必須要件に挙げる求人と歓迎の側にだけ書く求人がほぼ同じ割合でした。IaC とコンテナを必須要件に挙げる求人はどちらも1割台なので、クラウドで構築と運用を担った経験があれば、IaC やコンテナの実務経験が浅くても応募の対象になる求人は少なくありません。
IaC の中では Terraform を本文に書く求人が28.7%でした。コードの変更を自動でテストして本番へ反映する CI(Continuous Integration・継続的インテグレーション)と CD(Continuous Delivery・継続的デリバリー)を書く求人も32.3%あります。
手作業の手順をコードに置き換えてきた経験は、職務経歴書でも具体的に書ける強みになります。クラウドへ軸足を移す進路は「クラウドエンジニアの転職」で扱っているので、あわせて参考にしてください。
掲載中の求人が必須要件に何を書いているかは、Offers Jobs のインフラエンジニアの求人一覧から求人の詳細を開くと、業務内容・必須スキル・歓迎スキルで読み比べられます。
インフラエンジニアの年収は扱う技術と工程で差が出る
インフラエンジニアの年収は、設計・構築の側か運用・管理の側かで差が大きく、求人の提示年収でも、IaC やコンテナを扱う求人ほど上限が高い傾向があります。厚生労働省の賃金構造基本統計調査から年収を換算すると、設計の側の区分は889.0万円、運用・管理の側の区分は609.8万円でした。
公的統計では設計の区分の年収が高い
設計・構築を担うインフラエンジニアが入る区分は「システムコンサルタント・設計者」、運用・管理を担う人が入る区分は「その他の情報処理・通信技術者」で、年収換算は設計の区分のほうが高くなります。区分の当てはめは、厚生労働省の職業情報提供サイト(job tag)の職業分類対応表によるものです。
賃金構造基本統計調査の区分 | job tag で対応する職業 | 平均年齢 | 年収換算 | 超過実労働時間数(月) |
|---|
システムコンサルタント・設計者 | システムエンジニア(基盤システム) | 38.3歳 | 889.0万円 | 11時間 |
その他の情報処理・通信技術者 | 運用・管理(IT) | 42.2歳 | 609.8万円 | 12時間 |
出所:厚生労働省「令和7年賃金構造基本統計調査 職種第1表」(2026年3月公表)と job tag 職業分類対応表をもとに編集部が年収換算。
超過実労働時間数は、残業や休日出勤など所定の時間を超えて働いた時間です。平均にすると月11時間と12時間ですが、夜間の当番がどれだけ回ってくるかまでは平均に表れないので、当番の重さは職場ごとに確かめる必要があります。
求人の提示年収は IaC とコンテナの語がある求人で高い
Offers の求人で提示年収を見ると、インフラと SRE の正社員求人の上限の中央値は900万円で、上限を800万円以上とする求人が75.0%でした。技術の語の有無で分けると、上限の中央値は IaC の語がある求人で1,000万円、無い求人で900万円です。
求人の区分 | 母数 | 下限の中央値 | 上限の中央値 | 上限1,000万円以上の割合 |
|---|
全体 | n=280 | 500万円 | 900万円 | 39.6% |
IaC の語がある | n=100 | 550万円 | 1,000万円 | 57.0% |
IaC の語が無い | n=180 | 500万円 | 900万円 | 30.0% |
コンテナの語がある | n=120 | 540万円 | 1,000万円 | 50.8% |
コンテナの語が無い | n=160 | 500万円 | 869.5万円 | 31.3% |
オンプレミス・仮想化の語がある | n=108 | 460万円 | 800万円 | 28.7% |
オンプレミス・仮想化の語が無い | n=172 | 540万円 | 975万円 | 46.5% |
(Offers(株式会社overflow)調べ・年収の下限と上限を記載したインフラ・SRE 系の正社員求人 n=280・2022年11月〜2026年10月公開)
語の有無は求人の書き方で分けた比較で、その語を職務経歴書に書けば年収が上がるという関係までは示していません。それでも、IaC やコンテナを任せる求人ほど上限の高い募集が多いことから、オンプレミスの経験に IaC やコンテナの実務を重ねると、応募できる年収帯が広がると考えられます。
年代や企業規模による違いを含めた年収の水準は「インフラエンジニアの年収」で詳しく取り上げました。
経験を活かせる進路はクラウド・SRE・プラットフォーム
インフラの経験を活かした進路には、クラウドの設計と構築を専門にするクラウドエンジニア、サービスの信頼性を目標と数値で管理する SRE、開発者が使う基盤を整えるプラットフォームエンジニアがあります。どれも構築と運用の経験を土台に、手作業をコードと仕組みに置き換えていく役割です。
クラウドエンジニアは、オンプレミスからの移行や、クラウドの権限・ネットワークの設計を担います。移す側の環境を知っていることが、そのまま強みになる進路です。
SRE は、障害対応と監視の経験を、SLO の設計や自動化、オンコールの仕組みづくりに広げる進路で、障害のたびに呼ばれる側から、呼ばれる回数を減らす仕組みを作る側へ移ることになります。
プラットフォームエンジニアは、コンテナの基盤や CI/CD を整え、開発チームが自分でサービスを動かせる環境を用意する役割です。進路ごとの年収帯と移り方の全体像は「インフラエンジニアのキャリアパス」にまとめました。
長く働けるインフラの職場を見分ける5つの点
インフラエンジニアとして長く働ける職場かどうかは、当番の頻度と体制、任される工程、自動化の進み具合、障害の振り返りの仕組み、オンプレミスとクラウドの比率の5つで見分けられます。「やめとけ」と言われる理由の多くは職種そのものより職場の側にあり、この5つの答え次第で重さが変わる、というのが求人から見える実情です。
確かめる点 | 求人票で見る箇所 | 面接で聞くこと |
|---|
当番の頻度と体制 | 業務内容・勤務時間の注記 | 月に何回当番が回るか、何人で回すか、呼び出されたあとの代休や手当 |
任される工程 | 業務内容 | 設計・構築から任されるか、運用で見つけた課題を直す役割まで持つか |
自動化の進み具合 | 業務内容・開発環境 | 構成をコードで管理しているか、手順書どおりの手作業がどれだけ残っているか |
障害の振り返りの仕組み | 業務内容・歓迎スキル | 障害のあとに振り返りをどう進め、誰が監視や設計を直すか |
オンプレミスとクラウドの比率 | 業務内容・募集の背景 | 移行の計画があるか、どちらの環境を主に任されるか |
(編集部の整理)
求人の要件から見えるのは、手順を回すだけの人より、仕組みを設計して直せる人を求める職場が多い、という傾向でした。Offers では、職務経歴とスキルを登録しておくと、その経験に関心を持った企業からスカウトが届く仕組みです。Offers に登録し、届いた求人の業務内容や面談の場で上の5つを確かめながら、「やめとけ」の理由に当てはまらない職場を選んでください。