この記事で解決出来る疑問や悩み
- インフラエンジニアの仕事は楽？
- それともキツい？
- 楽な仕事はどれ？
この記事では、インフラエンジニアが楽だと言われる理由について解説をします。
記事前半では「インフラエンジニアが楽である理由」と、後半では「やめておいた方が良いと言われる理由」をメインに解説します。
この記事を読み終えることで、インフラエンジニアの実態を理解することができ、転職に対する不安が払拭されると思います。
目次
インフラエンジニアの業務内容
インフラエンジニアになると、まずは運用監視、保守業務に携わることがほとんどです。
まずは、インフラエンジニアの業務の特性について、簡単に知っておきましょう。
上記の画像のとおり、インフラエンジニアの業務工程は上流工程と下流工程に分別されます。
ひとつずつ見ていきましょう。
監視業務（システムが正常に動いているかチェックする仕事）
システムやサーバー、ネットワークが正常に動いているかをリアルタイムで監視する仕事です。もし異常が発生したら、すぐに対処することが求められます。
具体的な業務内容
・監視ツールを使って、サーバーやネットワークの状態をチェック
・「CPU使用率」や「メモリ使用量」などの数値を確認
・エラーやトラブルが発生した際に、担当者に報告
・夜間や休日もシステムが正常に動いているかを見守る（シフト勤務が多い）
私が体験したトラブル
とある現場のクライアントは、社内ネットワークからインターネットを使用する際に、FortiGate製のFW（ファイアウォール）を使用していました。そのクライアントにある全てのデバイスがインターネットへ接続する際に、FWを通過するネットワーク構成図です。
ある日、そのFWの監視アラームが鳴りました。そのFWのアラームが鳴るのは稀なので、非常に焦りました。
幸いにもFWは冗長化をしていて、サブのFWのアラームは鳴っていなかったので、とりあえず安堵したのを覚えています。
運用業務（システムがスムーズに動くよう管理する仕事）
運用業務は、システムが正しく動くように管理し、必要な設定や作業を行う仕事です。監視業務よりも一歩踏み込んで、システムが安定して稼働するように調整する役割を担います。
具体的な業務内容
・ユーザーのアカウント管理（新しく入社した人のIDを発行、退職者のID削除など）
・定期的なバックアップ（データを安全に保存する作業）
・ソフトウェアやOSの更新作業（アップデートを適用してセキュリティを強化）
・サーバーの負荷分散（アクセスが増えても快適に使えるよう調整）
私が体験したトラブル
上記のFWには、定期的にクライアントから設定の追加や削除の依頼が来ます。新入社員が入社すると設定の追加、退職すると設定の削除などの依頼が来るわけですね。
私はそのFWへの設定変更を担当していたのですが、とある日に何度設定しようとしてもエラーで動作しなくなったのです。
設定変更している間、サブFWに通信の流れが向かうように調整はしているのですが、とはいえ非常に焦りました。
もし、メインFWの設定などがすべて消えてしまったら、大問題です。サブFWの設定データをコピーして、メインFWに反映すればいい話なのですが、クライアントに謝罪と報告書を書かなければなりません。
最終的にエラーは解消し、メインFWの設定も一切影響がなかったので、安堵したのを覚えています。
運用監視と運用保守の違いは、運用監視と運用保守の9つの違いをご覧下さい。
保守業務（トラブルを防ぐ＆解決する仕事）
保守業務は、システムや機器の故障を防ぎ、万が一のトラブルにも素早く対応する仕事です。トラブルが発生してから対処する「修理」のような仕事だけでなく、問題が起きる前に防ぐことも重要です。
具体的な業務内容
・定期的な点検やメンテナンス（サーバーやネットワーク機器のチェック）
・障害発生時の対応（システムが落ちたときの復旧作業）
・サーバーやネットワーク機器の交換（古くなった機器の入れ替え）
・マニュアル作成（「トラブル時にはこう対応する」という手順を文書化）
私が体験したトラブル
１兆円企業の業務システムを運用しているとき、監視部署からアラームが鳴ったとの電話を受けました。
調べてみると、あるデータベースの利用率が逼迫していて、閾値を超えたみたいです。このまま放置すると、データベース使用率が100%となり、ユーザーに多大な影響を与えてしまいます。
夜間に発生したアラームだったので、私は自宅で寝ていました。夜間にたたき起こされるのは、たまったもんじゃありません。
即座にPCを立ち上げ、リモートで業務システムに入ります。そして、該当のデータベースを特定し、拡張作業を実施して終了しました。
構築業務（システムやネットワークを構築する仕事）
インフラエンジニアの構築業務は、コンピューターやネットワークを組み立てて、使えるようにする仕事です。システムがしっかり動くようにするには、サーバーやネットワークを正しく作ることが大事だからです。
具体的な業務内容
・機器の設置→ サーバーやネットワーク機器を設置・配線
・OS・ソフトの設定→ OSや必要なソフトをインストール
・ネットワーク設定→ 通信ができるようIPやルーターを設定
・セキュリティ対策→ 不正アクセスを防ぐ設定を行う
・テスト・確認→ 正常に動作するかチェック
先輩が経験したネットワーク構築トラブル
先輩がまだ入社して数年目の頃、とある企業の新オフィスのネットワーク構築を任されました。ルーターやスイッチの設定を済ませ、LANケーブルを敷設し、テストを行ったところ、なぜか一部の部署だけネットにつながりません。
最初は単純な配線ミスかと思い、ケーブルをチェック。しかし問題なし。次にスイッチの設定を見直すも、特に異常は見当たりません。何度も設定を確認し、試行錯誤するものの、一部の部署だけがどうしてもネットに接続できない状態が続きました。
先輩は「もしかして…」と考え、オフィス内のネットワーク図をもう一度じっくり見直しました。そして、あることに気づきました。その部署のネットワーク機器は、別のフロアのスイッチを経由して接続される構成になっていました。しかし、そのスイッチの設定が初期状態のままになっていたのです！
設定を正しく修正すると、すぐに通信が復旧。トラブルの原因は、事前に全てのネットワーク機器の設定を確認しなかったことでした。
この経験から先輩は、「どんなに自信があっても、ネットワークの全体図を必ず確認し、すべての機器の設定を見直すことが大事」という教訓を得たそうです。
設計業務（システムやネットワークの目的や必要な機能を明確にする仕事）
インフラエンジニアの設計業務は、コンピューターやネットワークをどんなふうに作るかを考える仕事です。
何も考えずに作ると、うまく動かなかったり、後から直すのが大変になったりするからです。
具体的な業務内容
・要件の整理→ 「何を作るか？」を決める
・機器・構成の選定→ 必要なサーバーやネットワーク機器を選ぶ
・ネットワーク設計→ 通信の流れやIPアドレスの割り当てを決める
・セキュリティ設計→ 不正アクセスを防ぐ仕組みを考える
・運用・保守の計画→ 使いやすく、長く運用できるように設計
先輩が経験したネットワーク設計トラブル
先輩がまだ中堅エンジニアだった頃、とある企業の新しいデータセンターのネットワーク設計を担当しました。要件定義もしっかり行い、設計書を作成し、いざ構築へ。順調に進んでいた…はずでした。
システムの動作テストを始めたところ、ネットワークの一部で異常な遅延が発生。ファイルのダウンロードが遅く、社内システムのレスポンスも極端に悪化。何かがおかしい…。
先輩はログを確認しながらネットワークのトラフィックを解析。すると、一部のスイッチで通信の遅延やパケットロスが発生していることが判明。構成を確認すると、ある問題が浮かび上がりました。
設計段階で「トラフィックはこのルートを通るだろう」と考えていた経路が、実際には想定外の通信によって混雑していました。具体的には、大量のデータバックアップが通常業務の通信と同じネットワーク経路を通っており、帯域を圧迫していたのです。
急遽、VLANの再設計とQoS（通信の優先制御）設定を行い、データバックアップと通常業務のトラフィックを分離。すると、ネットワークの遅延が解消し、問題なく運用できるようになりました。
この経験から先輩は、「設計の段階で実際のトラフィックの流れを詳細にシミュレーションすることが大事。思い込みで設計すると、意外なところでボトルネックが生まれる」という教訓を得たそうです。
要件定義
インフラエンジニアの要件定義は、お客様が「何をしたいのか」を聞き、それを形にするための計画を立てる仕事です。最初にお客様の希望をしっかり聞かないと、後から「思っていたのと違う」となってしまうことがあるからです。
具体的な業務内容
・目的の確認 🎯 → 何のためのシステムかを明確にする
・必要な機能の洗い出し 📋 → どんな性能・機能が必要かを整理
・予算・スケジュールの確認 💰📅 → 費用や納期の制約を把握
・運用ルールの検討 ⚙️ → 誰がどう使うのか、管理方法を決める
・要件の確定・文書化 📝 → まとめた内容をドキュメントにする
先輩が経験したネットワーク設計トラブル
先輩がまだPMとして駆け出しの頃、とある企業の新システム導入に伴うネットワーク要件定義を担当しました。お客様との打ち合わせもスムーズに進み、「これで問題なし！」と意気揚々。しかし、構築が始まった途端、大きな問題が発覚しました。
新システムでは全国の支店と本社をつなぐためにVPN（仮想プライベートネットワーク）を利用する計画でした。しかし、いざ構築段階に入ると、一部の支店から本社への接続ができないという事態に…。先輩は焦りながら原因を調査しました。
ログを確認し、構成を見直した結果、原因は「要件定義のミス」にあったことが判明しました。
実は、支店の一部ではすでに別のVPNサービスを使っていたのです。これが新しいVPNと競合し、通信が正しく確立できなくなっていました。しかし、要件定義の段階で「既存のVPN環境」について詳しくヒアリングしておらず、考慮されていませんでした。
急遽、既存のVPNと新VPNが共存できるように設定を変更し、何とかトラブルを解決。しかし、先輩はこの経験から 「当たり前だと思わず、既存環境をしっかりヒアリングすることが大事」 という教訓を得ました。
「聞いたつもり」ではなく、「本当にすべての情報を確認したか？」を意識することが、トラブルを防ぐカギだと実感したそうです。
インフラエンジニアが楽すぎと言われる理由
インフラエンジニアは、システムの安定運用を支える重要な職種ですが、近年「業務が楽になった」と言われることが増えています。自動化ツールやクラウドの発展、監視技術の進化などが、その理由として挙げられます。
インフラエンジニア最強説もあるくらいです。
この項目では、インフラエンジニアが楽すぎと言われる5つの理由について解説します。
自動化ツールの普及
インフラエンジニアの仕事が、以前より楽になっていると感じられる理由の一つは、作業が自動化ツールによって効率化されたためです。自動化ツールの普及は、インフラエンジニア界隈の人手不足問題を根本から解決する手段となっています。
自動化ツールの進化で、設定作業が効率化しました。AnsibleやTerraformを使えば、一度の設定で複数の機器に自動反映可能です。調査では、インフラエンジニアの8割以上が自動化で業務効率が向上したと回答しています。
新しいサーバーの設定は、以前は手作業でしたが、自動化ツールにより一括適用が可能になり、大幅に作業時間が短縮されました。大企業でも数百台の管理が効率化されています。
自動化ツールの普及は、インフラエンジニアの業務負担を軽減するだけでなく、効率性と正確性も向上させています。
クラウドサービスの進化
クラウドサービスが発展したことで、インフラエンジニアの業務が大幅に簡略化されました。
クラウドサービス（AWS、Azure、GCPなど）により、物理サーバーの管理が不要になり、リモート操作やコスト削減が可能です。ガートナー社の調査では、企業の80%以上がクラウドを利用しています。
AWSでは、ボタン一つでサーバー構築やストレージ拡張が可能です。以前必要だった物理的な設置作業が、オンラインで完結します。
クラウドの進化により、インフラエンジニアの仕事はリモートで行える作業が増え、作業負担も軽減されるようになりました。
インフラ即時展開の容易さ
コンテナ技術の普及によって、開発や本番環境の構築が速く、簡単に行えるようになりました。
コンテナ技術（Docker、Kubernetes）は、迅速な環境構築・展開を可能にし、従来の仮想化より軽量で移行も容易です。CNBCの報告によると、約50%の企業が導入し、展開速度の向上を実感しています。
コンテナ技術を使えば、設定が統一された状態でアプリをスムーズに移行でき、環境差異によるエラーリスクが減少します。
コンテナ技術により、インフラエンジニアはシステムの構築や展開を簡単かつ迅速に行えるようになりました。
監視・障害対応の高度化
監視ツールの発展で、インフラエンジニアの障害対応がより迅速で効率的になりました。
ZabbixやPrometheusなどの監視ツールは、異常発生時にアラートや自動対応を行い、監視業務を効率化します。IDCの調査によると、導入で障害対応時間が平均30%短縮されたことが報告されています。
例えば、CPU負荷が急上昇すると、監視ツールがアラートを出し、自動で負荷分散を行い、エンジニアが対応しなくてもシステムの安定性が保たれます。
監視ツールの進化により、インフラエンジニアの障害対応が効率化され、迅速な対応が可能になりました。
ノーコード・ローコード化の影響
インフラエンジニアはプログラミングをしないでお話しした通り、ノーコードやローコードツールが普及し、インフラエンジニアが複雑なコードを書かずに設定できる場面が増えています。
ノーコード・ローコードツールは、専門知識がなくても直感的にシステムを構築・管理でき、エンジニアの作業を簡略化します。Forrester社の報告では、これらのツール導入で開発速度が平均40%向上したとされています。
GUIツールを使えば、コードを書くことなくネットワーク設定が可能です。例えば、ドラッグ＆ドロップで設定できるツールを使うことで、システム管理が手軽になります。
ノーコード・ローコードツールの導入により、インフラエンジニアは複雑な設定作業が簡略化され、効率的に業務を進められるようになりました。
運用監視が楽である理由
インフラエンジニア業務の中でも、特に楽な業務は運用監視です。
何十年も運用監視をするのは、インフラエンジニアとしての末路を辿りやすいのでお勧めできませんが、数年であれば経験したほうが良いでしょう。
運用監視が楽だと思う理由についてお話しします。
ただ、あくまで私の実体験を元にした所感に過ぎないことを、あらかじめご了承頂ければと思います。
7割は暇
私が経験した現場は忙しい部類に入っていたと言いましたが、それでも7割ほどは暇でした。運用監視の業務のほとんどは受動的なものです。アラートが鳴動すると初動対応が必要になりますが、アラートが鳴動しなければ対応はありません。
暇な時の時間の使い方は人それぞれで、
・スマホでゲーム
・資格勉強
・副業
・タブレットで漫画
・スマホで映画視聴
など、やりたい放題だったりします。
夜勤は暇な時間が多いので、自己研鑽にあてやすい時間です。夜勤求人の探し方については、インフラエンジニアが夜勤のみで働くメリットをご覧ください。
定型業務が多い
運用監視は定型業務が多いです。アラート対応から障害対応まで、基本的に手順書に従って行います。
定型業務は作業者の業務レベルに依存することなく、一定の業務品質を担保することができます。非定型業務は手順書は用意されておらず、ケースバイケースで判断や対応が必要となり、従業員の経験値とスキルに依存する業務となります。
未経験で配属されると、まずは定型業務から覚えることになりますが、定型業務は簡単なので楽だと言えるでしょう。
出勤回数が少ない
運用監視は24時間365日体制がほとんどです。勤務体制としては2交代もしくは3交代制になります。
コツコツが経験した勤務体系の一例
夜勤は日勤2回分の出勤としたカウントしていたので、1ヶ月の営業日数が20日だとして、夜勤が7回となると
日勤：6回
夜勤：7回
合計出勤回数：13回
のシフトになります。
これでフルタイムと同じ給料になるので、個人的には楽だなと思いました。
✅2連続夜勤も楽
夜勤が2回続くシフトもありますが、
1日目：夜勤
2日目：夜勤明け
3日目：夜勤
4日目：夜勤明け
となり、2日目から3日目まではかなり時間があるのです。
出勤回数が少ないことにより、心身共に回復を図れることは、働く上で大きなメリットであり、楽と言える理由になるかと思います。
夜勤に頻度については、インフラエンジニアの夜勤頻度をご覧ください。
仮眠休憩がある
2交代の夜勤の場合、仮眠休憩が与えられる職場がほとんどです。
しかも、仮眠休憩中も給料は発生していたので、実質的な労働に対する時給は高かったです。
仮眠休憩の時間が変動するのは、その日の業務量によって変わるからですね。忙しい日は少なくなりますし、暇な日は多くなります。
責任が分散される
インフラエンジニアの運用監視の仕事は責任が分散されるので、あまりストレスがかかりません。
業務の特性上、1人の担当者が案件を担当して、最後まで担当することはほぼありません。たとえば、下記のような流れが一般的です
上記であれば、田中太郎が障害発生の初動対応を実施。復旧作業の時間帯は定時を超えているので、案件を夜勤メンバーに引き継いだ後、退社しています。
テレワークがある
インフラエンジニアもテレワークできます。クラウド系はもちろんのこと、ネットワークやサーバー系エンジニアもテレワーク可能です。
テレワークには
・通勤時間
・人間関係
・プライベート時間
など、あらゆる面でメリットがありますよね。
通勤時間はゼロになるし、会社内での面倒な会話も避けれます。オンとオフを完全に分けたい人にとっては良いですね。フルリモートワークもあれば、週1.2回だけ出社のルールがあるようなテレワークもあります。
運用監視の詳しい業務内容
次に運用監視の詳しい業務内容について解説します。未経験でインフラエンジニアになると、ほぼ100％に近い確率で運用監視、保守業務（もしくはヘルプデスク）からスタートするので、下流工程に限定をして解説をします。
運用監視の主な業務内容は６つあります。
あくまで私が経験した業務内容を元にした情報ですが、運用監視オペレーターの業務内容は職場問わず概ね共通しているはずなので、参考になるかと思います。
アラート対応
アラート対応は監視業務です。監視方法は主に2種類あります。
・死活監視(ping監視)
・SNMP監視
死活監視は最も使用されている監視方法です。
死活監視
監視サーバーがあり、監視サーバーから拠点にpingという通信プロトコルを使用して、通信を監視します。プロトコルとは通信の便利機能みたいなものだと思ってください。
上記のようなイメージで監視をしています。
pingとは要求をして応答が来れば成立するプロトコルです。
要求？
応答？
分かりにくいですよね(笑)
上記で言うと、
要求とは監視サーバーから宅内ルーターへの通信。
応答とは宅内ルーターから監視サーバーへの通信。
通信の原則
通信は基本的に一方通行ではなく双方向で成立します。監視用サーバーから宅内ルーターまで通信が届くけど、宅内ルーターからの応答が無いと、pingは成功したと言えないのです。
死活監視は5分ごと、15分ごとなど、定期的に監視用サーバーから拠点へpingを実施し、通信が正常かどうかを監視しています。
そして、pingが失敗するとアラートが鳴ります。
SNMP監視
SNMP監視とは機器情報を分析して、異常を示す状態になればアラートが鳴る仕組みになっています。
たとえば、宅内に設置しているルーターのLANケーブルが抜けると、アラートが鳴ることもあります。
アラート数が配属先によって様々だと思います。私がいた部署は月間1500件ほどのアラートでした。1500件のうち、障害起因のアラートは1%くらいです。99%はお客様起因ですね。
障害の切り分け
アラートが鳴って、まず最初に行うのは障害に切り分けです。どのように切り分けを行うかと言うと、基本的にSNMPプロトコルを使って、ネットワーク機器の状態を調べます。
私のいた部署であれば、宅内回線終端装置(MC、ONUなど)の状態を調べます。
たとえば、宅内回線終端装置の状態が以下の通りだったとします。
A.宅側回線終端装置の電源断
B.宅側回線終端装置の配下断
C.局側回線終端装置にて宅側回線終端装置からの光信号受信不可
D.宅側回線終端装置にて局側回線終端装置からの光信号受信不可
注)ここでは便宜上A〜Dにしています。
上記の場合、障害の可能性が高いのはCとDです(言ってる意味が分からないと思いますが、気にしないでください。
AとBのアラームは宅側要因である可能性が非常に高く、障害である可能性は極めて低いです。
しかし、CとDは障害の可能性が非常に高いので、即座に対応が必要になります。
障害の切り分けはツールを使うことがほとんどなので、未経験でも大丈夫です。
障害対応
障害であることがほぼ確定になると、復旧させなければなりません。ここからは関係部署、ベンダーと連携をして、速やかに復旧させるのが主な業務内容です。
障害対応
・お客様への状況説明
・現地切り分けの実施
・関係部署、ベンダーへ出向折衝
・お客様へ出向日時調整
・関係部署、ベンダーへ出向手配
・出向当日のお客様対応
・復旧作業後の正常性確認 など
アラートが障害だった場合、アラート鳴動から復旧するまで数時間〜数ヶ月かかります。復旧までの期間にズレがあるのは、その時々の状況によって変わるからですね。
私の実体験
2024年1月に能登半島地震が起きました。石川県にクライアントの拠点が複数あり、地震発生とほぼ同時にアラートが鳴動しました。
鳴動した複数の拠点の一つは、完全復旧まで5ヶ月を要しました。地震の影響で電柱が損壊してしまったため、電柱の建て直しが必要になったからです。
障害対応は、インフラエンジニアの一番のやりがいと言っても過言ではありません。障害が復旧して、感謝の言葉を貰わなかったことは一度もありませんから。
回線調査
私のいた部署では、クライアントからの回線調査も承っていました。回線調査とは、通信回線の異常有無や品質を調査することです。
回線調査の経緯としては、
など、マイナスな理由からの依頼となります。
回線調査を承ると、ルーターのログを調査したり、関係部署やベンダーに詳しい依頼をします。
全ての調査結果が出揃ったら、クライアントに報告をします。報告内容としては
・異常なし
・異常あり
大きく2パターンに分かれます。9割くらいは異常なしですが、1割くらいで異常ありとなり、その後に別対応が必要になります。
監視情報の変更
ルーターのリプレース(古いルーターから新しいルーターに変更すること)や支店統合などで監視情報に変更が生じた際に、監視情報を変更する業務もありました。
変更する項目は下記の通りです。
・I Pアドレス
・支店名
・ネットワーク構成図
・住所
などですね。
上記のアラート対応や障害対応において必要な情報に変更が生じると、監視情報の変更となります。
クライアントの数百に及ぶ支店や店舗のルーターをリプレースすることになり、業務量が膨大に増えたこともありました。地味な作業ですが、このような作業もあります。
各種手順書の作成や変更
業務には定型作業と非定型作業があります。定型作業とは手順が確立されている作業のことで、定型作業は手順書に則って行います。
以上の場合に手順書の作成や変更を行います。
インフラエンジニアの働き方
インフラエンジニアの働き方には、下流工程と上流工程という2つの大きな分類があります。それぞれで求められるスキルや仕事内容が異なり、ワークライフバランスや労働時間にも違いが生じます。
以下、それぞれの観点から詳しく見ていきます。
ワークライフバランス
下流工程
下流工程では、ワークライフバランスはやや不安定になることが多いです。
下流工程はシステムの監視やトラブル対応などが中心となり、障害発生時の対応が求められるため、勤務時間外の呼び出しや残業が発生しやすい傾向があります。
例えば、データセンターでの勤務では、システムの監視が24時間365日必要なため、夜勤や休日出勤が求められることが少なくありません。
下流工程のインフラエンジニアには、突発的な対応が必要になる場面が多いため、ワークライフバランスが安定しにくい側面があります。
上流工程
上流工程では、比較的ワークライフバランスを取りやすい環境が整っています。
上流工程は主に設計や計画が業務の中心であり、緊急対応の回数が下流工程よりも少ないためです。
例えば、新しいネットワークの設計を行う場合、設計段階での業務がほとんどで、システム運用のようなトラブル対応の頻度は低くなります。
上流工程のインフラエンジニアは計画的に業務を進められるため、比較的ワークライフバランスを取りやすい傾向にあります。
労働時間
下流工程
下流工程の労働時間は、比較的安定している傾向にあります。
下流工程では日々のルーチン作業や監視業務が中心であり、業務内容が定型化されているため、予測しやすいスケジュールでの勤務が可能です。
例えば、システムの監視業務を担当する場合、日勤のみや決められた交代制勤務で働くことが多く、残業が少ない職場もあります。
下流工程のインフラエンジニアは、労働時間が比較的安定しているため、予測可能な働き方ができる職種です。
上流工程
上流工程の労働時間は、長くなることが多いです。
上流工程はプロジェクトの進行に合わせた設計や調整業務が中心で、特に納期前やトラブル発生時には残業が増えることがあります。
例えば、ネットワークの構築計画やシステム設計を担当するエンジニアは、クライアントの要望や仕様変更に対応する必要があり、納期に合わせて夜間や休日に対応することも少なくありません。
上流工程のインフラエンジニアは、プロジェクトに伴う業務量の変動があるため、勤務時間が不規則で長くなることが多い職種です。
給料
下流工程
下流工程の給料は、比較的平均的な水準に収まることが多いです。
下流工程はルーチン業務が多く、経験年数に応じた昇給が少ない傾向があるためです。
例えば、サーバー監視を行うインフラエンジニアは、同じような業務を繰り返すことが多いため、技術的な成長や昇給があまり期待できません。
下流工程のインフラエンジニアは、経験に応じた昇給が少なく、給料が伸びにくい傾向にあります。
年収のあげ方については、インフラエンジニアの年収の上げ方をご覧ください。
上流工程
上流工程の給料は、下流工程よりも高くなることが多いです。
上流工程では高度な専門知識やスキルが求められ、責任のある業務が多いため、給料が高く設定されることが多いです。
ネットワーク設計を担当するインフラエンジニアは、プロジェクト管理や顧客対応が求められることが多く、その分高い給料が支払われるケースが多いです。
上流工程のインフラエンジニアは、専門性と責任の高さから、給料が比較的高い水準で支給されることが多いです。
未経験からのハードル
下流工程
下流工程は、未経験からでも比較的入りやすい職種です。
下流工程はルーチン業務が多く、業務を通じて少しずつ技術を習得できるため、未経験者にも適しています。
例えば、サーバーの監視業務では、異常があれば上司に報告するなど、基本的な業務からスタートできるため、未経験者でも対応しやすいです。
下流工程のインフラエンジニアは、比較的未経験からでも入りやすく、ステップアップが可能です。
上流工程
上流工程は、未経験者にはややハードルが高い職種です。
上流工程は設計や計画を担当するため、専門的な知識や経験が求められ、未経験からのスタートは難しい場合が多いです。
ネットワーク設計を行う業務では、既存の知識や経験をもとに複雑な設計が求められるため、未経験者には対応が難しいケースが多いです。
上流工程のインフラエンジニアは、専門知識や経験が必要で、未経験から始めるのは難しい傾向があります。
将来性
下流工程
下流工程の将来性は、少し不安定な面もあります。
下流工程の業務は自動化や外部委託が進んでおり、今後は仕事量が減少する可能性があります。
例えば、サーバー監視業務などは、AIや自動監視システムの導入が進んでおり、人の手を借りずとも監視ができるようになっています。
下流工程のインフラエンジニアは、自動化の影響で今後の仕事が減少するリスクがあるため、将来性にはやや不安があります。
上流工程
上流工程の将来性は、明るいと言えます。
上流工程は高度な設計や計画が求められるため、AIなどの自動化が難しく、今後も需要が期待されています。
例えば、クラウド環境の構築を担当するエンジニアは、クラウドの普及に伴い、設計や計画の需要が増加しています。
上流工程のインフラエンジニアは、技術の進展によりさらに需要が高まるため、将来性は非常に高いです。
インフラエンジニアに向いている人
インフラエンジニアに向いている人は、下記の通りです。
一つずつ解説します。
夜勤が問題ない
インフラエンジニアは業務特性上、夜勤があります。身体に負荷がかかるデメリットはありますが、夜勤手当が付くなどのメリットもたくさんあります。
夜勤に抵抗がない人は向いていると言えるでしょう。
顧客対応が得意
運用監視、保守はインフラエンジニア中でも顧客対応の多い業務です。現場にもよりますが、技術的な業務は1〜3割くらいしかないでしょう。
顧客対応は
・Teamsなどのチャットツールを使ったテキストベースのコミュニケーション
・電話
が主な対応手段になると思います。
ネットワーク監視業務で難しいのが、ネットワークを直接見ることはできないので、自分の頭でネットワークの構成図を想像しながら、顧客に説明しなければならないところです。
顧客から障害箇所について質問を受けた際、双方でネットワークの構成図を一致させておかなないと、障害箇所を誤って伝えかねません。
だからこそ、広義の意味での顧客対応力が必要になります。技術力は優れているのに顧客対応力が乏しいせいで、案件を長引かせてしまう人を何人も見てきました。
何かしらの顧客対応経験がある人は強みになります。
論理的思考が得意
障害対応で最も重要な能力が「障害の切り分け力」であり、切り分けの際に必要なのが論理的思考力です。
アクシデントが発生した際、障害や通信遅延の原因となるヒントは、どこかしらに落ちています。ルーターのログを見て分かることもあれば、他部署にエスカレーション(相談)をして分かる場合もあります。
それらのヒントをかき集めて、論理的思考を使って事象解決に導くのが運用監視の面白いところであり、難しいところでもあります。常日頃、あらゆることに疑問を持つ癖のある人は、運用監視に向いていると思います。
暇が苦ではない
先述した通り、運用監視は7割くらいは暇な時間になるので、暇が苦ではない人向きの仕事ですね。常に動き回っていたいという人には向かないかもしれません。
こんなことを書きつつ、実は私は暇が何よりも苦手です。だからこそ、暇な時間が生まれないように、業務でやることが無かったとしても、スキルアップの時間に充てたりしているので、暇な時間も有意義に過ごしていました。
忍耐力がある
上流工程から下流工程まで、インフラエンジニアがフェーズ問わずに行う業務は「障害対応」です。基本は下流工程で行いますが、顧客は設計、構築した担当にも原因究明を求めるケースが多いので、無関係とまではいきません。
障害対応は忍耐が必要です。1秒でも早い復旧を望まれるので、復旧するまでは忍耐力の勝負なのです。忍耐力に自信のある人は、インフラエンジニアに向いていると言えるでしょう。
デスクワークが多い
インフラエンジニアはデスクワークが多いです。顧客との打ち合わせや構築作業などで外出することもありますが、ほとんどは内勤業務です。今はテレワークも増えているので出社不要になっている会社も多く、業務の多くはデスクワークになります。
デスクワークが苦手という人はインフラエンジニアは向きません。デスクで黙々と作業が好きな人は、向いていると言えるでしょう。
社会の役に立ちたいと思っている
インフラエンジニアはITインフラを支える仕事です。インフラエンジニアがいなければ、ITインフラを維持することができず、経済は崩壊してしまうでしょう。
インフラエンジニアは無数にある仕事の中でも、随一の社会貢献性の高い仕事です。今の時代、通信が無いとほとんどの会社はビジネスが出来ません。ITが不要と思われていた業界も、どんどんDX化が進んでいます。
ITインフラは電気や水道、ガスに並ぶくらいのインフラ設備になっているので、社会貢献にやりがいを感じる人は向いていると思います。
インフラエンジニアはやめとけと言われる理由
ここまでインフラエンジニアが楽と言われる理由についてお話ししてきました。
楽である一方で、インフラエンジニアはやめとけと言われることもあります。
インフラエンジニアの欠点についてお話しします。
一つずつ解説します。
休日対応があるかもしれない
配属先や職制が上がると、休日対応があるかもしれません。
休日対応をしなければならない場合のほとんどはトラブル対応です。障害が発生して速やかに復旧させなければならないような事態の時に、休日対応が発生するかもしれません。
職制が上がると、自部署もしくは他部署から「エスカレーション」といって、判断を仰ぐような依頼が来ます。
ただ、エスカレーション先は責任者や役員レベルになるので、職制が上がるとプライベートが犠牲になる点はどの業界でも一緒ですね。
上流工程は残業がある
先ほど、下流工程は残業が少ないと言いましたが、上流工程は残業がほぼあります。1人の担当が複数の案件を抱えることも多く、残業ありきで稼働している部署が多いですね。
ただ、現在は36協定によって残業時間は規制されているので、多くの会社は36協定内で残業をしています。
ポイント
2018（平成30）年６月に労働基準法が改正され、３６協定で定める時間外労働に罰則付きの上限が設けられることとなりました。時間外労働の上限（「限度時間」）は、月45時間・年360時間となり、臨時的な特別の事情がなければこれを超えることはできません。臨時的な特別の事情があって労使が合意する場合でも、年720時間、複数月平均80時間以内（休日労働を含む）、月100時間未満（休日労働を含む）を超えることはできません。また、月45時間を超えることができるのは、年間６か月までです。
引用元：厚生労働省
現在は残業未払いの会社も減っているので、お金を稼ぎたい人にとっては好都合な仕事かもしれません。定時で退社したい人は、下流工程を選ぶことをおすすめします。
プレッシャーがかかる
インフラエンジニアはミスが許されない仕事です。ミス＝通信不可になる可能性が高く、通信不可の間はビジネス出来なくなるからです。
たとえば、某大手総合商社が新たに支店を立ち上げることを検討していて、あなたの会社にネットワーク構築・設計の依頼がありました。要件定義で話を詰めていき、以下のようなスケジュールで進めることになりました。
もし、6/18でネットワーク構築したにも関わらず、正常に通信ができなければどうでしょうか？
焦りますよね？
私なら焦ります。
だって、支店オープンまで3日しかないんだから。オープンまでに通信を使える状態にしておかないと、お客様が困るのは目に見えていますよね。
すると、プレッシャーとの闘いです。
エンジニアをしていると予定通りに進まないことは頻繁にあるので、プレッシャーを楽しめるくらいの気持ちで仕事をするのがベストです。
論理的思考力が必要
インフラエンジニアに限った話でありませんが、論理的思考力が必要です。
障害が発生したら原因と解決策を導かなければなりません。原因の切り分けと、適切な解決方法を論理的思考を用いて取捨選択していくのです。
私の所感ですが、数学が苦手な人はエンジニア向きではありません。高等学校で数学を学ぶ目的が「論理的思考力の育成」だからですね。
