面談室のホワイトボードに、拠点間のVPNとFWの構成図をすらすらと描いてくれた30歳のネットワークエンジニアが、構成図の端に「サーバー」と書いた小さな四角を置いたところでペンを止めました。「ここから先は、触ったことがないんです」。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、ネットワーク専任の方からクラウドやSREへの転職相談を受けると、ほぼ例外なくこの四角の前で話が止まります。今回は、回線設計やFW運用の経験がクラウド転職で評価される場面と、サーバー未経験が壁になる場面を求人票と面接の実例で切り分け、足りない領域をどの順で埋めるかをお伝えします。

今回は、次の内容に沿ってご紹介します。

  • ネットワーク専任の経験がクラウド求人で評価される場面と、「専門が狭い」と見られる場面の境目
  • 書類で落ちやすい記述と、面接で必ず飛んでくるサーバー寄りの質問
  • ハイブリッド接続・クラウドNW設計求人の必須要件の読み方と、入り口になる求人の見分け方
  • Linux、スクリプト、IaC、クラウドNW、コンテナと監視という足りない領域の埋め順
目次
  1. ネットワークエンジニアのクラウド転職で、サーバー未経験が問題になる理由
  2. 回線設計・FW運用の経験が評価される場面
  3. 「専門が狭い」と見られる場面、書類と面接の具体例
  4. SREの求人で問われるOS・コンテナ・IaC・監視、ネットワークだけでは足りない部分
  5. 入り口になる求人の見分け方、ハイブリッド接続・クラウドNW設計の必須要件
  6. 足りない領域の埋め順、Linux→スクリプト/IaC→クラウドNW→コンテナ
  7. 1番目はLinux、まず手を動かせる状態にする
  8. 2番目はシェルスクリプトとPython、変更を手作業から外す
  9. 3番目はクラウドのネットワーク設計とIaC
  10. 4番目はコンテナと監視、SREの入口に立つ
  11. 資格はどう使うか、CCNAは意味あるのか
  12. Hさんの例、構成図の「サーバー」で止まった30歳の転職
  13. ネットワーク専任の将来性、SREへの寄せ方は一つではない
  14. よくある質問
  15. まとめ、ネットワークの強みは入り口で使い、サーバー側は実務で埋める

ネットワークエンジニアのクラウド転職で、サーバー未経験が問題になる理由

結論から言うと、ネットワークの専門性そのものが否定されることはほとんどありません。問題になるのは、クラウドの求人が「ネットワークだけ分かる人」を想定して書かれていないことです。

オンプレミスの現場では、ネットワークとサーバーは担当が分かれているのが普通です。回線を引き、ルーターとスイッチを設計し、FWのルールを運用する人と、OSを入れてミドルウェアを立てる人は別のチームにいました。ところがクラウドでは、VPCを作る人がそのままEC2を立て、セキュリティグループを書き、ロードバランサーの向き先まで決めます。境界線が消えるぶん、ネットワークだけを切り出して任せるという発想が採用側から消えていきます。

dodaの職種図鑑によると、ネットワークエンジニアの平均年収は449.3万円(IT/通信系エンジニア平均は455.1万円、調査期間は2023年9月〜2024年8月、ページ更新は2025年1月31日)です。同じページでは、転職者の保有資格ではCCNAが35.9%で最多とされ、評価される経験としてクラウドの知識・導入経験も挙げられています(出典:doda「ネットワークエンジニアの仕事内容・年収・資格」)。

ここから読み取れるのは、資格でネットワークの基礎を示す人が多数派で、差がつくのはクラウドを実際に触った経験があるかどうかだということです。私の実感とも一致しています。CCNAを持っているネットワークエンジニアは書類上ほとんど区別がつかず、そこから先は「何を触ってきたか」で選考が分かれます。

なお、クラウドエンジニアとの違いを整理しておくと、ネットワークエンジニアは「通信経路とセキュリティ境界の設計・運用」が主軸で、クラウドエンジニアは「アプリが動く基盤全体の設計・構築・運用」が主軸です。後者はネットワークを含みますが、サーバー・ストレージ・権限・自動化まで含めて責任範囲になります。ここの範囲差が、そのまま転職時の壁の高さです。

回線設計・FW運用の経験が評価される場面

では、ネットワーク専任の経験はどこで効くのか。ここを先に押さえておかないと、「足りないものばかり数える」記事になってしまいます。私が現場で見てきた限り、評価される場面ははっきりしています。

  • オンプレ拠点とクラウドをつなぐハイブリッド接続(専用線・閉域網・VPN)の設計と切り替え
  • 複数アカウント・複数VPCをまたぐアドレス設計とルーティングの整理
  • FWルールの棚卸し、変更管理、通信要件のヒアリングから許可設計までの一連の運用
  • 障害時にパケットの流れを追って原因を切り分ける力

クラウドへ移行する企業にとって、いちばん事故が起きやすく、かつ社内に分かる人がいないのがこの領域です。アプリ開発の人はVPCピアリングとTransit Gatewayの使い分けで迷い、サーバーの人はオンプレのIP体系を知らないまま重複したCIDRを切ってしまう。こうしたところで、アドレス設計と経路の勘所を持っている人は即戦力になります。

もう一つ見落とされがちなのがFW運用の経験です。クラウドのセキュリティグループやネットワークACLは、見た目こそ違っても考え方はFWのルール設計そのものです。「この通信は誰の要望で、いつ、なぜ開けたのか」を追える運用をしてきた方は、変更管理や監査の場面で信頼されます。ルールを足すことより、使われていないルールを説明つきで減らしたことのある人が強い、というのが私の見方です。

障害切り分けも同様です。SREの現場でも、アプリのエラーが実はDNSの引き違いやMTUの不整合だったという話は珍しくありません。tcpdumpやパケットキャプチャを読んで「ここで落ちている」と言える人は、サーバー寄りのエンジニアよりも早く原因にたどり着くことがあり、その実績は面接でそのまま武器になります。

「専門が狭い」と見られる場面、書類と面接の具体例

評価される場面がある一方で、ネットワーク専任の方が書類や面接で足を取られる場面も、パターンが決まっています。

書類で落ちやすいのは、職務経歴書の技術欄がほぼネットワーク機器の名前とプロトコルだけで埋まっているケースです。たとえば次のような記述が並ぶ形です。

拠点間WAN回線の設計・構築、L3スイッチ・FWの設定変更、障害一次対応、手順書作成

これ自体は立派な経験です。ただ、クラウド寄りの求人を出している企業の人事や現場担当者は、OS、コンテナ、IaC、監視といった軸で経歴書を見ています。ネットワークの用語だけが並ぶ書類は、「サーバー側は何もやっていない」と読まれます。実際には触っていても、書かれていなければ存在しないのと同じ扱いです。

面接では、質問が必ずサーバー側に寄ってきます。私が相談者から聞いてきた質問を並べると、次のようなものです。

面接で聞かれやすいサーバー寄りの質問

  • 「Linuxでサービスが起動しない場合、どの順で確認しますか」
  • 「ネットワークの設定変更を、手作業ではなくコードで管理した経験はありますか」
  • 「監視でアラートが飛んだとき、ネットワーク以外の原因はどう切り分けますか」
  • 「コンテナ同士の通信はどのように成り立っているか、説明できますか」

どれも高度な質問ではありません。ただ、ネットワーク専任で過ごしてきた方は、答えられないというより、そもそも考えたことがないことに気づかされます。そこで沈黙すると、面接官の中で「専門が狭い」という評価が固まります。

一次面接でネットワークの経験を丁寧に語って好感触だったのに、二次面接のSRE側の面接官から「ところで普段はどんなOSを触っていますか」と聞かれて雰囲気が変わった、という話は何度も聞きました。最初の面接官は「ネットワークが分かる人が来た」と見ていて、二次の面接官は「うちのチームで一人で回せるか」を見ている。見ている軸が違うだけなのですが、候補者から見ると急に評価が落ちたように感じます。この面接官ごとの見ている軸の違いは、面接官のタイプ別に回答の重心を変える方法でも整理しています。

もう一つ、やっかいなのは年齢です。30代前半までのネットワーク専任なら、足りない領域は入社後に伸びる前提で見てもらえることがありますが、30代後半以降になると「自走できるか」を最初から問われます。この記事を読んでいる方が何歳であっても、サーバー側の入口に立つ時期は早い方が有利です。

SREの求人で問われるOS・コンテナ・IaC・監視、ネットワークだけでは足りない部分

ここからはSREへの転向を見据えた話です。ネットワークエンジニアがSREを目指すとき、求人上で必ず問われるのは次の4つです。

  • OS(主にLinux)の運用経験、プロセス・ファイルシステム・権限・systemd
  • IaC(Terraformなど)による構成管理と、そのレビュー・運用
  • コンテナ(Docker)とオーケストレーション(Kubernetes)の基本
  • 監視・可観測性、SLO、インシデント対応の経験

ネットワークの経験があると、この4つのうち「監視」と「インシデント対応」は入口に立ちやすい領域です。オンプレで24時間の障害対応をしてきた方は、SREの現場が求める「落ち着いて切り分ける力」を既に持っていることが多いからです。

逆に、最も時間がかかるのがLinuxとIaCです。ここはネットワーク専任の方に共通する弱点で、私の担当でも「ルーティングとFWは自信があるけれど、シェルスクリプトを書いた経験はほぼない」という方が少なくありません。

SREの肩書きの求人が実際にはどういう仕事なのかは、運用当番ばかりの「名ばかりSRE」もあるため注意が必要です。実態の見極めはSRE求人でTerraform・Kubernetesが並ぶのに運用当番しかない実態を扱った記事で詳しく書いています。また、SREとプラットフォームエンジニアのどちらを狙うかで迷う方は、プラットフォームエンジニア求人が少ない理由とSREとの違いも参考になります。

ここで私の考えを言っておくと、ネットワーク専任からSREへの最短ルートはSRE求人に直接応募することではないと見ています。SRE求人の必須要件は、OSとIaCと監視をまとめて問う構成が多く、ネットワーク専任のままでは書類段階でほぼ弾かれます。先にネットワークの経験が活きる「入り口」の求人で入り、そこで足りない領域を実務で埋めてから、社内異動か次の転職でSREに寄せるほうが、結果的に早いというケースを何度も見ています。

入り口になる求人の見分け方、ハイブリッド接続・クラウドNW設計の必須要件

では入り口になる求人とは何か。代表的なのが、ハイブリッド接続やクラウドのネットワーク設計を担当する求人です。ただし、タイトルだけで判断すると外れます。必須要件の書き方で見分けます。

私が担当領域で見てきた範囲では、この種の求人には次のような要件が並ぶ傾向があります(特定の求人の引用ではなく、傾向としてのまとめです)。

  • ネットワークの設計・構築・運用の実務経験が5年以上
  • AWSのDirect ConnectやTransit Gatewayなどを使った接続の運用経験
  • VPCを含むクラウド環境のネットワーク設計経験
  • 歓迎要件としてTerraformなどのIaC、Linuxの運用経験

ここで注目してほしいのは、サーバー・OS・IaCが必須ではなく歓迎に置かれているかどうかです。ネットワーク設計の経験年数が必須で、Direct ConnectやTransit Gatewayは「運用経験」止まり、LinuxとTerraformが歓迎なら、ネットワーク専任の方がまさに狙える入り口です。

一方で同じクラウドNW設計の求人でも、必須要件にLinuxの運用経験とTerraformでの構築経験が並んでいれば、実態は「クラウド基盤エンジニア」です。タイトルがネットワークでも、サーバー未経験では書類を通りにくくなります。

見分けるためのチェックポイントを、表にまとめておきます。

確認する欄入り口になる求人壁が高い求人
必須要件ネットワーク設計・運用の年数が中心Linux・IaC・コンテナの実務が必須
歓迎要件Terraform、Linuxは歓迎止まり歓迎にもKubernetes・CI/CDが並ぶ
業務内容拠点・クラウド間の接続、FWポリシー整備基盤の設計・構築・運用全般
チーム体制ネットワークの専任担当を置いている少人数で基盤を横断して担当

チーム体制の欄は求人票だけでは分からないので、カジュアル面談で「ネットワーク領域の担当は専任ですか、基盤全体の兼務ですか」と聞くのがおすすめです。専任と兼務では、入社後に求められる守備範囲がまるで違います。

求人サイトの検索結果で「ネットワーク」と入れると、大量のオンプレ運用の求人が出てきます。クラウド寄りの入り口を探すなら、キーワードに「AWS」「VPC」「閉域網」「ハイブリッド」を入れて、さらにその求人の必須要件を読み直すという二段構えが安全です。

足りない領域の埋め順、Linux→スクリプト/IaC→クラウドNW→コンテナ

足りない領域を埋めるとき、手当たり次第に学ぶとどれも中途半端になります。私が相談者に勧めている順番は次のとおりです。

ネットワークの経験を土台に、サーバー、IaC、コンテナへ領域を広げていくイメージ

1番目はLinux、まず手を動かせる状態にする

最初に埋めるべきはLinuxです。理由は、その後に続くIaCもコンテナも、結局はLinuxの上で動くからです。目標は資格ではなく、サーバーを一台立てて、プロセス・ログ・権限・ネットワーク設定を自分で確認できる状態です。

ネットワーク専任の方はipコマンドやss、tcpdumpは既に慣れていることが多いので、そこは有利です。足りないのは、systemdでサービスを管理する、journalctlでログを追う、パッケージ管理、ファイルシステムの容量とinodeの確認といった、サーバー側の日常作業です。クラウドの無料枠で十分に練習できます。

2番目はシェルスクリプトとPython、変更を手作業から外す

次に、繰り返し作業をスクリプトにする習慣をつけます。FWのルール棚卸しやコンフィグの差分取得など、ネットワーク運用の中にスクリプト化できる作業は意外とあります。自分の現場の作業を一つスクリプトにした経験があれば、職務経歴書に書けて面接でも語れます。

3番目はクラウドのネットワーク設計とIaC

ここで初めてクラウドのネットワークに入ります。VPC、サブネット、ルートテーブル、セキュリティグループ、Transit Gateway、VPN接続といった構成要素を、まずコンソールで作り、次にTerraformでコード化します。ネットワークの知識がある分、この段階の進みは他職種の方より速いはずです。

ここで1点だけ注意があります。AWS認定のAdvanced Networking Specialtyは、公式ページで試験の廃止が告知されており、日本語の公式ページでは最終受験日が2026年8月25日と案内されています。この記事の執筆時点(2026年10月)では受験できない可能性が高く、取得は目標にしません。資格を目的にするより、自分でVPCを組んでTerraformで再現した成果物のほうが、面接では確実に効きます。

4番目はコンテナと監視、SREの入口に立つ

最後にDockerとKubernetesの基礎、そして監視です。ネットワーク専任の方がコンテナで躓くのは、Pod間通信やServiceの仕組みを「ネットワークの知識でどう読み替えるか」を知らないことが多いからです。ここはむしろ、ネットワークの知識が他の人より速く効く分野です。

監視は、オンプレ時代のSNMPやNetFlowの経験を、メトリクス・ログ・トレースという観点に整理し直すだけで、かなり語れる内容になります。SLOやエラーバジェットの考え方は、SRE関連の公開資料で一通り目を通しておけば十分です。

この4段階をすべて終えてから転職活動を始める必要はありません。LinuxとIaCまで手を動かした時点で応募を始めるくらいが、現実的なタイミングです。残りは入社後の実務で埋められます。

資格はどう使うか、CCNAは意味あるのか

「CCNAは転職で意味があるのか」という質問もよく受けます。私の答えは、意味はあるが、それだけでは差がつかない、です。

先ほどのdodaのデータでCCNAが保有資格の最多とされているとおり、持っている人は多数派です。つまり、ネットワークエンジニアとしての最低限の基礎知識を示す証明にはなりますが、クラウド転職の場面では差別化の材料になりません。持っていることは前提で、問われるのはその先です。

クラウド転職で資格を取るなら、ネットワークの資格を積み増すより、AWSやAzureなどのアソシエイト水準で「クラウドを触った」ことを示すほうが効率的です。ただし、資格単体では交渉材料にならない点には注意が要ります。この辺りの現場感は、AWS認定資格を年収交渉で使うときの実例にまとめています。

私は資格を勉強の目標として使うのは賛成ですが、職務経歴書に資格名を並べて終わりにするのは勧めません。資格名の横に「VPCを自分で設計してTerraformで構築した」という具体的な成果が書いてあって初めて、採用側に伝わります。

Hさんの例、構成図の「サーバー」で止まった30歳の転職

冒頭のホワイトボードの話に戻ります。Hさん(30歳・経験8年)は、法人向けの拠点ネットワークの設計とFW運用を担当する、ネットワーク機器の構築・保守を手がける中堅SIerの社員でした。支店のネットワークを統廃合する案件で、Direct Connect相当の閉域接続の切り替えも経験していました。

最初に応募した3社では、書類通過が1社でした。通過した1社の一次面接で、Hさんは閉域網の切り替え手順を非常に分かりやすく説明できたのですが、二次面接で「Linuxは普段どの程度触っていますか」と聞かれ、「ほぼ触っていません」と答えて、その場の空気が変わったそうです。結果は見送りでした。

私がHさんに提案したのは、応募先の絞り込みと、並行して足りない領域を埋めることでした。必須要件の読み方は先ほどの表のとおりです。ネットワーク設計が必須でLinuxとTerraformが歓迎に置かれている求人に絞り、同時に、Hさんの自宅の検証環境にLinuxを入れて、ネットワーク設定のシェルスクリプト化に取り組んでもらいました。

3か月後、Hさんは職務経歴書の技術欄に「Linux(Ubuntu)での検証サーバー構築、シェルスクリプトによるFWルールの差分チェック」と、「AWS上でVPC・Transit GatewayをTerraformで構築し、拠点VPNとの接続を再現」を加えました。次の応募では5社中3社で書類が通り、うち1社から内定が出ました。

内定先はクラウド移行を進める事業会社のインフラチームで、年収は現職とほぼ同じです。入社後の半年はネットワーク領域が中心で、SREの業務は先の話になるという説明を、Hさんも納得したうえで承諾しています。もちろん全員がこの経過をたどるわけではありませんが、ネットワークで入って、サーバー側を実務で埋めていくという順番は、再現しやすい形だと私は見ています。

同じ「インフラ経験を活かしてクラウド側へ移る」でも、運用監視の経験をどう書くかで悩む方は夜勤の運用監視から構築職へ転職するときの職務経歴書の書き方も参考になります。

ネットワーク専任の将来性、SREへの寄せ方は一つではない

「ネットワークエンジニアに将来性はあるのか」という不安も、転向を考える方からよく聞きます。私の見方は、ネットワーク単体の専任は減るが、ネットワークが分かるクラウド・SREの需要は残るです。

dodaの別の解説記事では、クラウド利用企業の割合は2016年の46.9%から2020年の68.7%に増えたとされています(総務省「情報通信白書」令和3年版の引用で、やや古い数字です。出典:doda「クラウドエンジニアの仕事内容と将来性」)。数字の細部より、方向が一貫して移行側に向いている点が重要です。

クラウドに移った企業でも、閉域網で拠点とつなぐ、オンプレと並行運用する、セキュリティ要件でFWの考え方を持ち込むといった場面は残ります。ネットワークの知識を持つ人が、サーバーやIaCも扱えるようになると、希少性がむしろ上がります。

SREへの寄せ方も一通りではありません。ネットワーク寄りのSRE(通信基盤の信頼性を担当する)もあれば、セキュリティ側に寄せる道もあります。ネットワークとセキュリティの親和性を活かしたキャリアは、セキュリティエンジニア未経験可の求人はインフラ出身者が有利という話でも触れています。オンプレ全般からクラウドへ移る場合は、オンプレ中心のインフラエンジニアのクラウド転職を扱った記事も合わせてどうぞ。今回の記事はそちらよりも対象を「ネットワーク専任」に絞っている点が違いです。

よくある質問

サーバー未経験のネットワークエンジニアでも、クラウド求人に応募できますか。 応募はできます。ただし求人の選び方が重要で、ネットワーク設計・運用の経験が必須要件の中心になっている求人に絞ると、書類が通りやすくなります。LinuxやIaCが必須に並ぶ求人は、先に実務や検証環境での経験を作ってから応募するほうが無駄打ちになりません。

SREを目指すなら、最初からSRE求人に応募したほうがいいですか。 私は勧めません。SRE求人はOS・IaC・監視をまとめて問う傾向があり、ネットワーク専任のままでは書類で止まりやすいからです。ハイブリッド接続やクラウドNW設計の求人で入り、実務でサーバー側を埋めてからSREに寄せるほうが現実的です。

CCNAは転職で意味がありますか。 基礎知識の証明としては意味がありますが、保有者が多いため、それだけでは差がつきません。クラウド寄りの転職では、クラウド上でネットワークを実際に構築した成果物を併記することが重要です。

Linuxはどのレベルまで触れれば応募できますか。 サーバーを自分で立て、サービスの起動・ログ確認・権限設定・ネットワーク設定を一通り説明できる水準が目安です。資格の有無より、面接で手順を口頭で説明できるかどうかが見られます。

年齢が高いと、サーバー未経験の転向は難しいですか。 年齢が上がるほど、入社後に育てる前提では見てもらいにくくなります。ただ、ネットワークの設計・運用で培った判断力が評価される求人もあるため、早く動くことと、足りない領域の学習量を職務経歴書で示すことが大切です。

まとめ、ネットワークの強みは入り口で使い、サーバー側は実務で埋める

ネットワークエンジニアのクラウド・SRE転向で、回線設計やFW運用の経験が評価される場面は確かにあります。ハイブリッド接続、アドレス設計、障害切り分けは、クラウド移行を進める企業が実際に困っている領域です。

一方で、サーバー未経験のままでは「専門が狭い」と見られる場面も、書類と面接のどちらにもあります。見ている軸が違うだけで、ネットワークの力が低いわけではありません。ネットワークの強みを入り口の求人で使い、Linux、IaC、コンテナの順に実務で埋めていくという順番を、この記事で一番伝えたかったことです。

最初からSREの肩書きを狙うか、入り口の求人で経験を積むか。迷ったときは、必須要件の欄にLinuxやTerraformが必須で並んでいるか歓迎に置かれているかを見るだけで、その求人の壁の高さが分かります。まずは気になる求人を3件ほど開いて、その欄を読み比べてみてください。