インフラエンジニアのキャリアマップ ― クラウド・ネットワーク・社内SE・コンサルへの移行の仕方

移行先から探す：クラウドエンジニアネットワークエンジニア社内SEITコンサルタント

フェーズマップが「工程を上がる」話だったのに対して、このページは「領域を横に移る」話です。監視・運用・保守・構築で積んだ経験は、捨ててから次に行くものではありません。企業側も、ゼロから育てるつもりで中途採用はしません。「この人の経験の、ここがうちの仕事に接続する」と読めるかどうかで、書類が通るかが決まります。

だから順番はこうです。先に自分の市場価値を測る（今の経験が、移行先の企業からどう値付けされるかを知る）。次に、武器になる部分と足りない部分を分ける。最後に、足りない部分を現職で作るか、資格で補うか、書類の見せ方で接続するか決める。移行の成否は、勉強量ではなくこの仕分けで決まります。

全体マップ：現在地 × 移行先

現在地は、フェーズマップの工程で置きます。移行先との「距離」は3段階です。

• 近い：今の経験の過半がそのまま武器になる。書類の書き方（翻訳）と、ピンポイントの補強で届く
• 一段挟む：直行の書類は弱い。現職での経験の作り直しや、隣の工程・領域を1つ挟むと現実的になる
• 大きく跳ぶ：仕事の進め方そのものが変わる。年収の方向は上でも、適性と準備期間の見極めが先

読み方の注意を2つ。1つ目、距離は「能力の優劣」ではありません。社内SEへの「近い」は、技術の深さではなく、守備範囲の広さと調整の経験が接続しやすいという意味です。コンサルへの「大きく跳ぶ」も、技術が足りないのではなく、仕事の成果物が「作ったもの」から「決めたこと・まとめたこと」に変わるからです。

2つ目、この表は一般的な傾向です。個別の企業・求人では逆転します。だからこそ、面談で提示される求人の工程と年収帯を見て、自分のケースで測り直す必要があります。

横移動で、企業が見ているもの（共通の物差し）

職種を変える応募では、企業は3点を見ています。4職種とも共通です。

1. 隣接経験の「翻訳」ができているか

移行先の言葉で、今の経験を語れるか。たとえば運用保守の障害対応は、クラウド側では可用性と復旧の判断、社内SE側では利用者対応と影響判断の経験として読めます。経験そのものより、「接続の説明」が書類にあるかどうかが効きます（運用保守→クラウドの翻訳の具体例は、記事「運用保守から設計構築・クラウドへ移る転職の進め方」にまとめています）。

2. 判断の持ち越しができるか

フェーズマップで書いた通り、企業が買っているのは製品知識ではなく「どこまで任せられるか」です。手順の内側の経験だけだと、職種が変わった途端に価値がゼロに見えます。切り分け、優先順位づけ、方式の選択といった判断の経験は、領域をまたいでも持ち越せます。書類に判断が書かれているかどうかが、横移動の書類の生命線です。

3. 足りない部分を自覚して、埋める動きをしているか

未経験領域があること自体は、マイナスではありません。中途採用は全員どこか未経験です。落とされるのは、不足を自覚していない書類と、「勉強中です」で止まっている書類です。何が足りないと分かっていて、現職・資格・個人の検証環境で何をしたかまで書けている人は、「入ってから伸びる側」と読まれます。

クラウドエンジニア

実態：何をする仕事か

AWSやAzureなどのクラウド基盤の設計・構築・運用をする仕事です。現場の言葉で言うと、「サーバーとネットワークを、データセンターではなくクラウドの部品の組み合わせで作る仕事」。オンプレの構築と地続きの部分（構成を決める、パラメータを決める、移行の段取りを組む）と、クラウド特有の部分（責任共有モデル、従量課金の設計、マネージドサービスの選定、IaCによる構築の自動化）が半々です。

求人の実態として、「クラウドエンジニア」の看板でも中身は2種類あります。移行・構築中心の仕事と、クラウド環境の運用・監視中心の仕事です。年収も伸び方も違うので、求人票では「移行・設計の比率」と「運用の比率」を切り分けて読んでください。

インフラ経験のどこが武器になるか

• 構築の経験全般：構成を決める、テストで不整合を見つける、移行の段取りと切り戻しを組む。この進め方はクラウドでもそのまま使えます
• 障害対応と切り分け：クラウドでも障害は起きます。影響範囲の見極めと復旧の優先順位づけは、可用性設計の素地として読まれます
• 運用の視点：監視設計、手順化、属人化の解消。「作って終わり」にしない視点は、クラウド運用の現場で不足しがちな能力です
• ネットワークとセキュリティの基礎：VPCやルーティング、ファイアウォールの考え方は、オンプレの知識が土台になります

不足しがちな要素と埋め方

• クラウド固有の設計作法（責任共有、マネージドサービスの使い分け、コスト設計）：現職で作りにくい筆頭です。資格の勉強と個人の検証環境での構築で補うのが現実解で、書類では「検証で何を作り、何を確認したか」まで書くこと。「勉強しました」だけでは材料になりません
• IaC・自動化の経験（Terraform、CloudFormation等）：現職がオンプレ中心だと作りにくい領域です。小さくても自分でコード化した構築物があると、面接の会話が具体になります
• 書類での見せ方：オンプレの経歴をクラウドの言葉に翻訳すること。担当範囲・判断・後始末の書き方は職務経歴書ガイドの型がそのまま使えます。資格は、経験の代わりではなく「未経験領域を補強する材料」として資格欄と職務経歴の両方に接続させます（資格の効き方は資格マップ参照）

移行の現実的なルート

構築・設計の経験がある人は直行が現実的です。運用・保守中心の人は、2つのルートがあります。1つは現職・現案件で移行や更改の場面を取りに行き、「決める側に部分的に立った経験」を作ってから動くルート。もう1つは、クラウド環境の運用・保守の求人から入り、現場で構築側へ寄せていくルートです。後者は入りやすい反面、運用中心のまま固定されるリスクがあるので、面談で「構築・移行の案件比率」と「工程を上がった社内事例」を必ず確認してください。

年収の方向感

公開情報ベースの目安では、クラウド職は同じ工程のオンプレ職より高めのレンジで募集されることが多く、構築・設計寄りで450万〜700万円台、設計・上位で800万円台以上も見られます（2026年11月1日に公開情報で確認した目安。企業規模・商流・役割で大きく変わります）。ただし運用中心のクラウド求人は、オンプレの運用と大きく変わらないレンジもあります。「クラウド」という言葉自体に上乗せがあるのではなく、工程と判断の範囲に上乗せがある、という読み方をしてください。

向いている人・向いていない人

• 向いている：新しいサービスや仕様を追い続けるのが苦にならない人。構成の正解が更新され続ける領域なので、学び直しが止まると価値が下がります
• 向いていない：腰を据えて同じ環境を長く見たい人。クラウドの現場は移行と更改の連続で、環境が固定されにくい働き方です（働き方優先なら、得策マップの軸3＝事業会社・社内SEが先です）

書類と面接で突かれるポイント

• 「クラウド未経験」をどう埋めてきたか。検証環境で作ったもの、資格の取得時期と順番で見られます
• オンプレの判断経験を、クラウドの設計判断に接続して語れるか。「オンプレしか知らない人」に見えた瞬間に、未経験者と同じ土俵に落とされます
• コストと可用性のトレードオフを考えたことがあるか。マネージドサービスを「便利だから」で選ぶ回答は、設計側の席では弱く読まれます

ネットワークエンジニア

実態：何をする仕事か

ネットワークの設計・構築・運用をする専門職です。ルーティング、スイッチング、ファイアウォール、負荷分散、拠点間接続といった「つなぐ側」の基盤を担います。サーバー系と違い、担当領域がはっきりしている分、専門性の深さがそのまま市場価値になる職種です。障害時の影響が全社・全拠点に及ぶため、切り分けの速さと正確さが現場で強く求められます。

求人の中身も幅があります。大規模ネットワークの設計・構築を担う席と、運用・保守中心の席では、求められるものも年収レンジも違います。あわせて、近年はネットワークのクラウド化・仮想化（クラウド側のネットワーク設計、SD-WAN等）を含む求人が増えており、「オンプレのネットワークだけ」の守備範囲は少しずつ狭くなっています。

インフラ経験のどこが武器になるか

• ネットワーク寄りの運用・保守経験：障害の切り分け、構成変更、通信の疎通確認。ネットワーク職では、この現場感がそのまま実務力として読まれます
• サーバー側の知識：ネットワーク専門職の中で、サーバー側の事情が分かる人は調整の場面で重宝されます。移行では「専門外が分かる専門職」として差別化になります
• 拠点・利用者との調整経験：回線や拠点ネットワークの仕事は、現場調整の連続です。調整の実績は書類に必ず書いてください

不足しがちな要素と埋め方

• 設計の経験：運用・保守から入る人が一番詰まる段差です。現職で更改・増設の場面を取りに行き、「構成を決めた経験」を小さくても作ること。作れない場合は、保守の書類に「方式の選択に関わった場面」を取り出して書くことから始めます
• 資格による裏づけ：ネットワークは4職種の中で、資格が最も経歴の裏づけとして機能する領域です（資格マップ参照）。とくに領域を移る人は、経験の不足を資格で補う設計が効きます
• クラウド側のネットワーク：VPC設計やクラウド接続の知識は、現職がオンプレだけだと不足します。クラウドの入門資格と検証で補うのが現実的です

移行の現実的なルート

サーバー系からの移行は、「一段挟む」が基本です。サーバーとネットワークの両方を見る構築・運用の現場で、ネットワーク寄りの担当範囲を広げてから専門職に寄せるルートが現実的です。いきなり設計の専門職を狙うより、構築のネットワーク求人から入り、設計へ上がる段取りのほうが、書類の通りも入社後の立ち上がりも安定します。ネットワーク寄りの保守経験がある人は、構築への直行も十分に狙えます。

年収の方向感

公開情報ベースの目安では、運用・保守中心で400万〜550万円台、構築で500万〜700万円台、設計・上位で700万〜900万円台が見られるレンジです（2026年11月1日に公開情報で確認した目安）。専門職のため、設計の席に上がれるかどうかでレンジが大きく分かれます。逆に運用中心のままでは、年数だけ重ねてもレンジが伸びにくい職種でもあります。

向いている人・向いていない人

• 向いている：地味な切り分けと検証を丁寧に積める人。1つの領域を深く掘ることに満足感がある人
• 向いていない：技術の幅を広く持ちたい人。専門職は守備範囲が固定されやすく、領域の外の経験が積みにくい面があります

書類と面接で突かれるポイント

• 触った機器とプロトコルの具体性。「ネットワーク運用を担当」では読めません。扱った規模（拠点数、台数、回線種別）と、自分の担当範囲を言い切ってください
• 障害の切り分けを、順序立てて説明できるか。面接では事例ベースで必ず聞かれます
• 設計の席を狙う場合、「決めた構成と、その理由」。捨てた案まで語れると、保守と設計の段差を越えたと読まれます

社内SE

実態：何をする仕事か

事業会社の中で、自社のシステムとIT環境全体を見る仕事です。現場の言葉で言うと、「作る人」ではなく「自社のITの窓口であり、判断する人」。基盤の運用、社内問い合わせの対応、ベンダーとの調整、更改や導入の企画まで、守備範囲の広さがこの仕事の本体です。会社の規模で中身が大きく変わります。情シス部門が複数人いる会社では領域分担がありますが、1人情シス・数名の部門では、ヘルプデスクから基盤、セキュリティ、予算管理まで全部が守備範囲になります。

得策マップの軸3（働き方）で書いた通り、夜勤・交代勤務から降りたい人の第一の選択肢ですが、「楽な仕事」ではありません。手を動かす深さの代わりに、広さと調整で評価される仕事への転換です。そこを誤解したまま移ると、入社後のズレが大きくなります。

インフラ経験のどこが武器になるか

• 運用・保守の経験全般：自社システムを「止めない」ことが社内SEの土台の価値です。障害対応と影響判断は、そのまま社内の利用者対応に接続します
• 一人で持った範囲・窓口の経験：少人数で回す職場では、「チームの一員」の経歴より「自分が窓口だった経験」が強く読まれます
• ベンダー・他チームとの調整：社内SEの仕事の多くは、自社とベンダーの間の調整です。常駐側・受託側で調整役だった経験は、立場が替わっても価値になります
• 幅の広さ：サーバー、ネットワーク、PC・端末、セキュリティと浅く広く触ってきた経歴は、深さ勝負の職種では弱みでも、社内SEでは強みに反転します

不足しがちな要素と埋め方

• 企画・予算の視点：更改計画の整理、見積の比較、稟議の資料作り。手を動かす側だけだった人には不足しがちな要素です。現職で更改や更改提案に関わった場面があれば、書類で必ず取り出してください
• 社内調整の言葉：利用部門との折衝、経営層への説明。面接では「技術を、技術に詳しくない相手に説明した経験」が聞かれます。現職の調整場面を、面接で語れる事例として整理しておくこと
• 書類での見せ方：ユーザー数と拠点数、「一人でどこまで持ったか」を書くこと。技術の深さの列挙ではなく、守備範囲の広さと仕組み化の実績（問い合わせを減らすためにやったこと等）で書くのが、社内SEの書類の型です（職務経歴書ガイドの「社内SE系」の章とあわせて読んでください）
• 資格：守備範囲の広さを裏づける資格（応用情報、セキュリティ系、ITIL等）が、技術の深さの資格とは違う効き方をします（資格マップ参照）

移行の現実的なルート

4職種の中で、最も直行しやすい移行です。運用・保守の経験があれば、書類の書き方を社内SE向けに寄せることで届く求人が多い領域です。SES・客先常駐からの移行の具体的な手順は、記事「SES・客先常駐から事業会社・社内SEへ抜ける手順」にまとめています。注意点は行き先の実態確認です。「社内SE」の肩書きでも、実態が客先常駐に近い求人や、ヘルプデスク専任の求人が混ざります。面談で、情シス部門の人数、担当範囲、夜間・休日の対応体制、残業の実績を必ず数字で確認してください。

年収の方向感

公開情報ベースの目安では、400万〜650万円台が中心的なレンジで、大手事業会社や情シスの管理寄りの席では700万円台以上も見られます（2026年11月1日に公開情報で確認した目安）。得策マップでも書いた通り、年収の伸び幅は緩やかな会社が多い職種です。年収の最大化が目的の移行先ではありません。働き方と、守備範囲の広さに見合う提示かどうかで判断してください。逆に、提示が今より大きく下がる場合は、部門の人数と担当範囲が釣り合っているか（1人情シスに安い提示、という構図になっていないか）を疑う材料になります。

向いている人・向いていない人

• 向いている：腰を据えて同じ環境を長く見たい人。技術の深さより、調整と段取りで成果を出すことに抵抗がない人
• 向いていない：手を動かす技術で評価されたい人。設計・構築の最前線にいたい人。社内SEは「決める・頼む・調整する」側に寄るため、技術の手触りは薄くなります

書類と面接で突かれるポイント

• 技術の話しかできないと、「情シスとしての守備範囲」が伝わりません。調整・折衝・仕組み化の場面を、書類と面接の両方で用意してください
• 「なぜ受託・常駐を離れたいのか」の理由。ネガティブな理由（常駐が嫌だから）だけだと、「うちでも同じ不満を持つのでは」と読まれます。社内SEでやりたいことの言葉が必要です
• ベンダーに「頼む側」の経験や意識。見積もりの妥当性を見た場面、ベンダーの提案に意見した場面があると、判断する側の素地として読まれます

ITコンサルタント

実態：何をする仕事か

顧客のITの課題に対して、構成や進め方を「決める側・まとめる側」に立つ仕事です。要件定義のさらに手前、課題の整理、技術選定、計画作り、関係者の合意形成が成果物になります。得策マップの軸6でも触れた通り、年収レンジの上限が高い一方で、成果が「決めたこと・まとめたこと」で測られる働き方への転換が求められます。

求人の看板には要注意です。「コンサルタント」の肩書きでも、中身がPMO（プロジェクト管理の支援）中心の会社や、実質的に上流工程の常駐に近い会社があります。戦略・要件定義に入るのか、管理支援が中心なのかは、面談で必ず切り分けてください。

インフラ経験のどこが武器になるか

• 要件定義・設計の経験：構成を決めた、選定の理由を説明した、という経験は、コンサルの仕事の直接の土台です
• 障害と運用の現場感：「作った後に何が起きるか」を知っていることは、企画・設計の場面で机上の案と現場の案を分ける材料になります。運用出身であることは、この職種では弱みではなく差別化の軸になります
• 調整と折衝の実績：顧客、ベンダー、社内の利害の違う相手をまとめた経験。その場面の多さと相手の層が、そのまま読まれます

不足しがちな要素と埋め方

• 資料作成と説明の型：提案資料、比較表、稟議資料を「決めてもらうため」に作る経験。技術資料を作ることとは別の技能です。現職で選定資料や提案書に関わった場面があれば、それが最も強い材料になります
• 業務側の言葉：顧客の業務課題を技術の構成に翻訳する力。技術の正しさではなく、費用対効果と業務影響で語る訓練が必要です
• 書類での見せ方：技術名の一覧はほぼ読まれません。「何を決める場にいたか」「誰をどうまとめたか」で書くこと。要件定義フェーズの書類の書き方（フェーズマップ参照）が、そのままこの職種の書類の型になります
• 資格：技術資格の効きは弱めです。体系知識の裏づけ（高度試験等）は効く場面がありますが、決定打にはなりません（資格マップ参照）。資格より、決めたことの実績の言語化が先です

移行の現実的なルート

「大きく跳ぶ」移行なので、段取りが要ります。現実的なのは2ルートです。1つは、SIerの要件定義・設計の席で「決める経験」を積んでからコンサルへ移るルート。もう1つは、コンサル会社のPMO・アソシエイト層の席から入り、担当領域を企画側へ寄せていくルートです。どちらのルートでも、面談で「担当するのは戦略・要件定義か、PMOか、その比率」を確認すること。年収の上限の高さだけを見て入ると、仕事の中身とのズレで消耗します。

年収の方向感

公開情報ベースの目安では、600万〜900万円台がよく見られるレンジで、上位のファームやマネージャー層では1,000万円を超える募集もあります（2026年11月1日に公開情報で確認した目安）。4職種の中で上限が最も高い一方、評価の物差し（売上、顧客評価、稼働等）が会社ごとに厳しく、レンジの下限側の席（PMO中心）では、SIerの設計職と大きく変わらない提示もあります。「コンサルだから高い」ではなく、「決める範囲と責任の重さに高い値がつく」という、フェーズマップと同じ構造で読んでください。

向いている人・向いていない人

• 向いている：資料作成や折衝が苦にならない人。正解のない場面で、自分で案を作って決めてもらう進め方に抵抗がない人
• 向いていない：手を動かして作ること自体に仕事の手応えを感じる人。成果物が「決まったこと」になる働き方に物足りなさが残る場合は、上流のSIerのほうが得策なことが多いです

書類と面接で突かれるポイント

• 「決めたこと」の具体性。担当した技術ではなく、選定・判断・合意形成の場面を、理由と捨てた案まで語れるか
• 顧客の業務課題をどう捉えたか。技術の話に終始すると、「現場は強いが、コンサルは別の仕事」と判断されます
• なぜコンサルなのか。インフラの上流（要件定義・設計）と何が違うと思っているか、自分の言葉で説明できるか

まとめ：横移動の前にやること

職種の移行で失敗するパターンは、能力不足ではなく順番の間違いです。行き先を決める前に市場価値を測っていない。足りない部分の仕分けをせずに、勉強と資格取得から始めてしまう。書類の翻訳をせずに、同じ書類を職種違いの求人に出してしまう。

順番はこのサイトの他のマップと同じです。工程マップで現在地を置く。このページで行き先との距離と、埋めるべき不足を分ける。得策マップで会社の形を決める。そして職務経歴書ガイドの型で、経験を移行先の言葉に翻訳する。面談は、その翻訳が市場でどう読まれるかを測る場としても使えます。

移行しない、という結論も含めて、測ってから決めてください。