インフラエンジニアのクラウド未経験転職、志望動機の書き方

求人票の「必須要件」欄にある「AWS実務経験2年以上」の一文を見て、応募ボタンを押す指が止まる——オンプレ環境しか経験のないインフラエンジニアから、こういう相談をよく受けます。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、クラウド未経験を理由に応募を諦める人と、同じ経歴のまま書類選考を通過していく人の差は、技術力そのものより「オンプレの経験をクラウドの言葉にどう翻訳したか」で決まっていることがほとんどです。今回は、求人票の必須要件の読み解き方と、職務経歴書・面接でオンプレ経験を言語化する具体的な書き方を、実例を交えてお伝えします。

目次

1. インフラエンジニアがクラウド未経験のまま転職するとき、最初にぶつかる壁
2. オンプレとクラウド、業務のどこが同じでどこが違うのか
3. オンプレの経験をAWS/GCPの言葉に翻訳する対応表
4. 求人票の必須要件をどう読むか、「実務経験〇年」の解釈幅
5. 志望動機・職務経歴書の書き方、Before/Afterの実例
6. 面接で「クラウド未経験ですが大丈夫ですか」と聞かれたときの答え方
7. AWS認定資格は取っておくべきか、学習の優先順位
8. クラウド案件への転身で年収はどう変わるか
9. 未経験から入りやすい隣接職種、遠回りに見える求人が近道になる
10. よくある質問に答えます
11. まとめ、オンプレの経験は「翻訳すれば」武器になる

インフラエンジニアがクラウド未経験のまま転職するとき、最初にぶつかる壁

doda「IT人材不足はなぜなのか？」では、経済産業省の試算として、需要の伸び率が高位シナリオで推移した場合に2030年で最大約79万人のIT人材が不足するという数字が紹介されています。あくまで複数シナリオのうち上振れ側の試算値ですが、オンプレの運用スキルだけでなく、クラウド基盤を扱えるインフラ人材への需要も含めて今後の不足幅を見ているものだと私は読んでいます（出典：doda「IT人材不足はなぜなのか？」）。

需要が伸びているなら未経験でも入りやすいはずですが、実際に求人票を開くと「AWS実務経験2年以上必須」「クラウド基盤の設計・運用経験」といった条件が並び、オンプレ一筋のインフラエンジニアはそこで応募をやめてしまいます。人材不足という追い風と、目の前の求人票の必須要件が、感覚として噛み合わないわけです。

この噛み合わなさが起きる理由は単純で、採用側は職務経歴書だけではオンプレ経験がクラウド業務に転用できるかを判断できないからです。冗長構成の設計やキャパシティプランニングをやってきた人でも、それを「クラウドの言葉」で書いていなければ、書類選考の担当者はAWSのAという文字も読み取れません。翻訳する作業を放棄したまま応募すると、能力があっても落ちます。

書類選考の担当者は、応募が集中する求人ほど1通あたりに時間をかけられません。オンプレの実務内容が箇条書きで並んでいるだけの職務経歴書は、読み手側がクラウド用語に変換する手間を負わされることになり、その手間を払ってまで読み進めてもらえるとは限らないのが実情です。翻訳の作業は、本来なら採用側がやってくれてもいいはずですが、実際には応募者側が済ませておかないと選考の土俵にすら上がれません。

オンプレとクラウド、業務のどこが同じでどこが違うのか

物理サーバーの調達には数週間かかりますが、EC2インスタンスの起動は数分で終わります。ここだけ見ると「オンプレの知見はクラウドでは通用しない」と感じるかもしれませんが、私が現場で見てきた限り、変わっているのは主に実装手段であって、判断の骨格はかなり共通しています。

冗長化の考え方が分かりやすい例です。オンプレでは負荷分散装置とサーバーを二重化して、片系が落ちても止まらない構成を組みます。クラウドではこれをマルチAZ構成とELBによる負荷分散の組み合わせで実現しますが、「単一障害点を作らない」という設計思想そのものは同じです。監視も同様で、Zabbixやプラットフォーム標準の監視ツールで閾値を設定し、平常時の状態を基準に異常を検知するという発想は、CloudWatchやCloud Monitoringに置き換わってもそのまま使えます。

違うのは、変更の反映速度と、変更の記録の残し方です。オンプレでは構成変更の多くが手順書とExcelの台帳で管理されますが、クラウドではTerraformやCloudFormationのようなIaC（Infrastructure as Code）で構成をコード化し、変更履歴をGitで追うのが基本になります。ここは経験がなければ素直に「未経験です」と認めるべき領域で、無理に「知っています」と言い張ると面接で崩れます。

もう一つ、面接でよく見落とされるのがコストに対する意識の違いです。オンプレでは機材の購入時にまとめて予算承認を取れば、あとは減価償却の範囲で使い続けられます。クラウドは使った分だけ毎月請求が変動するため、設計段階からコストを見積もり、無駄なリソースを止める判断まで運用の一部として求められます。オンプレの現場でも「予算内でどう機材を回すか」を考えてきた経験はあるはずなので、この視点を職務経歴書に書き添えると、クラウドのコスト管理への意識があることが伝わります。

オンプレの経験をAWS/GCPの言葉に翻訳する対応表

オンプレでやってきたことを、クラウドの概念に一対一で置き換えると、職務経歴書に書くべき言葉が具体的に見えてきます。この作業を私は「翻訳」と呼んでいますが、実際にやることは難しくありません。オンプレで扱っていた技術要素を書き出し、それぞれがクラウドの何に相当するかを1行ずつ当てはめていくだけです。私が実際の添削で使っている対応の一覧を挙げます。

この表のポイントは、右列をそのまま「できます」と書かないことです。オンプレの経験が土台になっている、という書き方に留めるのが正確で、面接で深掘りされたときにも矛盾しません。「経験がある」と「応用できる」を混同すると、面接で技術的な質問が来た瞬間にボロが出ます。

もう一つ、実際に添削していて伝えているのは、5項目すべてを職務経歴書に詰め込まないことです。応募先の求人票が「監視体制の構築」を強調しているなら監視の行、「ネットワーク移行」を強調しているならVPCの行というように、求人票の言葉に合わせて2〜3項目に絞って厚く書いた方が、採用側には刺さります。全部を並べると、逆にどこが強みなのか読み手に伝わらなくなります。

求人票の必須要件をどう読むか、「実務経験〇年」の解釈幅

求人票の「必須」と「歓迎」を分けて読む人は多いのですが、私が見ている限り、それだけでは足りません。同じ「クラウド実務経験2年以上」という一文でも、企業によって指している中身の幅がかなり違うからです。

ある企業では、本番環境でクラウド基盤を丸ごと設計・構築した経験を指しています。別の企業では、オンプレ基盤とクラウドが混在する環境で、一部の移行作業やハイブリッド運用に関わった経験を含めています。後者であれば、オンプレ経験者が「移行プロジェクトの一部を担当した」という実績を持っていれば応募条件に届く可能性が十分にあります。求人票の文言だけでこの幅を判断するのは難しいので、私はエージェント経由の応募であれば、担当者に「必須要件のクラウド実務経験は、どの程度の関与を想定していますか」と先に確認するよう勧めています。

ポイント： 求人票の必須要件は「実務経験の年数」という数字ではなく、「その企業が想定している関与の深さ」で読む。同じ文言でも、設計を丸ごと任せる求人と、移行・運用の一部を任せる求人では、オンプレ経験者にとっての通過難易度がまったく違います。

実際に相談で見せてもらった2社の求人票を比べると、この違いがよく分かります。1社は「AWS環境の設計・構築・運用の実務経験2年以上（要件を満たさない場合、選考をお見送りする可能性があります）」という書き方で、年数と例外のなさを明記していました。もう1社は「クラウド環境での運用経験、またはオンプレ環境での大規模インフラ運用経験」という書き方で、オンプレ経験を明確に代替要件として認めていました。同じ「クラウド実務経験」という言葉が入っていても、後者のように代替要件が併記されている求人は、オンプレ経験者にとって現実的な選択肢になります。

見分け方としては、募集背景の文章もヒントになります。「クラウドネイティブな基盤をゼロから構築するフェーズ」と書かれた求人は、実務経験なしでの通過は正直厳しめです。一方「オンプレからクラウドへの移行を推進」「ハイブリッド環境の運用改善」と書かれた求人は、オンプレの知見そのものが評価対象になるため、未経験からでも狙いやすいと私は判断しています。

必須要件のすぐ下にある歓迎要件（尚可条件）の並びも見ておくべきです。歓迎要件に「オンプレ環境からの移行経験」「大規模インフラの運用経験」のような文言が入っている求人は、採用側がオンプレ出身者を歓迎要件のレベルでは想定しているというサインなので、必須要件の「クラウド実務経験」がやや厳しめでも、面談や書類の書き方次第で拾ってもらえる余地があると私は見ています。逆に歓迎要件までクラウド関連の用語で埋まっている求人は、素直に難易度が高いと判断した方が無難です。

志望動機・職務経歴書の書き方、Before/Afterの実例

実際にあった相談を紹介します。データセンター事業者に所属し、自社データセンターの電源・空調・ネットワーク運用を20年近く担当してきたMさん（45歳）は、クラウド未経験のまま、クラウドインフラの運用を強みとする企業への転職を考えていました。職務経歴書の「保有スキル」欄で、「AWS：実務経験なし」とだけ書いた行を前に、提出前の相談に来られたのが最初のやり取りです。

Before（最初の職務経歴書）は、こう書かれていました。「データセンターの運用保守業務全般を担当。電源・空調設備の監視、障害対応、ネットワーク機器の設定変更を行う。AWS：実務経験なし」。事実は正確ですが、この書き方では、担当した業務がクラウド運用のどの部分に対応するのか、採用側には一切伝わりません。

After（書き直した後）は、「複数系統の電源・空調の冗長構成を前提とした運用設計を主導。単一障害点を作らない考え方はAWSのマルチAZ構成の思想と共通すると理解しており、業務外でVPC・EC2・CloudWatchの検証環境を構築し設計の対応関係を確認済み」という書き方に変えました。「実務経験なし」の一行で終わらせず、独学で埋めた範囲まで具体的に書くことで、採用側が「どこまで任せられるか」を判断できる材料になります。

書き直した後、Mさんは応募した3社中2社で書類選考を通過しました。落ちた1社は「クラウドネイティブな基盤をゼロから構築するフェーズ」と募集背景に明記されていた求人で、これは前段で触れた「実務経験の解釈幅が狭い求人」に該当していたと、私は振り返って見ています。通過した2社はどちらも、募集背景に「オンプレ資産の移行」という言葉が入っていた求人でした。

志望動機の文章も同時に書き直しています。Beforeは「貴社のクラウド事業に興味を持ち、新しい技術を学びたいと思い応募しました」という、上位記事でもよく見かける一般論型でした。Afterでは「20年近く物理インフラの可用性を担保してきた立場から、次はソフトウェアで可用性を作る側に回りたいと考えています。検証環境でのAWS学習を通じて、冗長化の設計思想が土台から共通していることを確認できたのが応募の決め手です」という、経験と志望理由を接続した書き方に変えました。「興味があります」で終わる志望動機は、翻訳作業を放棄した文章と同じだというのが、添削をしていて感じることです。

面接で「クラウド未経験ですが大丈夫ですか」と聞かれたときの答え方

書類選考を通過したMさんは、一次面接で現場のインフラリーダーから「クラウドの実務経験がありませんが、正直なところ大丈夫だと思いますか」と直接聞かれました。ここでの答え方が、書類の翻訳がどこまで本物かを試される瞬間です。

Mさんは「大丈夫だと思います」ではなく、「電源・空調の冗長構成を設計するとき、常に『どの1点が壊れても全体を止めない構成か』を最初に考えていました。AWSのマルチAZ構成も同じ発想だと理解していて、検証環境で実際にAZを1つ落として挙動を確認しました」と、自分の思考プロセスと、検証で埋めた行動をセットで答えました。面接官が知りたいのは「クラウドを触ったことがあるか」ではなく、「初めて触る技術に対してどう学ぶ人か」だと私は見ています。

「未経験です」で終わらせず、埋めるためにどう動いたかまで語れるかどうかが、通過と不通過を分ける一番の分岐点でした。

二次面接では部門長から「45歳という年齢で、若手が多いクラウド運用チームに入ることへの抵抗はないか」という、年齢に踏み込んだ質問も出ました。Mさんは「自分より若いメンバーの方が、クラウドの実装には詳しい場面が増えると思っています。その代わり、障害が起きたときに慌てず切り分ける手順は、こちらが教えられる立場になれると考えています」と答え、経験の長さを上下関係ではなく役割分担として説明しました。最終的に内定を得た提示年収は現職より約40万円高い水準で、オンプレ経験を正当に評価してもらえた結果だと私は捉えています。

AWS認定資格は取っておくべきか、学習の優先順位

「資格を取ってから応募すべきか」という質問もよく受けます。結論から言うと、応募自体は資格の有無にかかわらず始めてよいというのが私の考えです。ただし、書類選考の通過率を上げたい、あるいは応募できる求人の幅を広げたいなら、AWS認定のSolutions Architect - Associate（SAA）から着手するのが定石です。

SAAはオンプレのインフラ経験がある人であれば、学習期間の目安は1〜2ヶ月程度で、ネットワーク・冗長化・可用性設計といった既知の概念をAWSの用語に置き換えるだけで理解が進む範囲が多いというのが実感です。資格取得それ自体が転職の合否を決めるわけではなく、あくまで「学ぶ姿勢の証明」と「用語の翻訳が正しくできている証明」として機能します。

順番としては、まずSAAで全体像をつかみ、応募先の求人がネットワーク寄りならネットワーク専門資格、運用・監視寄りならSysOps Administratorに進む、という求人ベースの選び方を私は勧めています。SAP（Solutions Architect - Professional）はオンプレの実務経験があっても学習だけで到達するのは難しく、実務でクラウド設計に関わってから狙う資格だと考えておいた方が現実的です。

資格を取ってから動くか、取得中のまま動くかで悩む人もいますが、応募先の書類選考が資格を待ってくれるとは限りません。SAAの学習が半分ほど進んだ段階で並行して応募を始めても遅くはないというのが、私が見てきた実例からの感覚です。資格を年収交渉の材料としてどこまで使えるかについては、AWS認定資格は年収交渉に効くか、インフラエンジニアの実例で具体的な実例を紹介しているので、あわせて参考にしてください。

応募先がGCPを使っている場合はAssociate Cloud Engineerが同じ位置づけの資格になります。出題範囲はAWSのSAAとかなり重なっていて、コンピューティング・ネットワーク・ストレージの基本設計とIAMによる権限管理が中心です。私の感覚では、AWSとGCPのどちらを先に学んでも、もう一方の学習コストは大きく下がります。用語の対応関係さえ押さえれば、概念を二重に覚え直す必要はほとんどありません。

クラウド案件への転身で年収はどう変わるか

doda「インフラエンジニアの将来性を考察」によれば、サーバーエンジニアの平均年収は464万円、ネットワークエンジニアは447万円という実測値が示されています。50代のネットワークエンジニアに限ると734万円まで上がる一方、若い世代では伸び幅が緩やかで、年齢を重ねた分だけオンプレの守備範囲を広げてきた人が高く評価される構造がうかがえます（出典：doda「インフラエンジニアの将来性を考察」）。

私が担当した案件を見ても、オンプレ専業のまま年収レンジの天井にぶつかっている40代インフラエンジニアは少なくありません。クラウド案件に領域を広げることは、年収の天井を押し上げる現実的な手段の一つです。オンプレ経験の蓄積を「古い経験」ではなく「クラウド理解の土台」として提示できるかどうかが、同じキャリアの長さでも評価に差がつく理由になっています。なお、隣接領域であるセキュリティ職への転向を考えている場合は、セキュリティエンジニア未経験可求人はインフラ出身者向けでも、同じ「必須要件の読み方」の構造を扱っているので参考になるはずです。

未経験から入りやすい隣接職種、遠回りに見える求人が近道になる

「クラウド未経験可」を明言した求人がそもそも少ない、と感じる人もいると思います。そういうときは、クラウド専業のポジションだけでなく、隣接職種を経由するルートも検討する価値があります。

代表的なのが、オンプレとクラウドが混在する環境の運用保守ポジションです。移行プロジェクトが進行中の企業では、既存のオンプレ基盤を守りながらクラウド側の運用にも徐々に関わるという募集の仕方をしていることが多く、オンプレの実務経験がそのまま即戦力として評価されます。

もう一つは「SRE」を名乗る求人ですが、これは名称だけで判断すると痛い目を見ます。実態が監視当番の延長にとどまっている求人も少なくないので、面談で「トイル削減にどれだけ予算と時間を割いているか」を確認する必要があります。この見分け方はSRE求人「名ばかり」の実態、年収が伸びない理由で詳しく解説しているので、SRE求人を検討している方は合わせて確認してください。

遠回りに見えるこれらの求人を経由する最大の利点は、業務としてクラウドに触れながら学べることです。独学の検証環境だけでは、本番のトラフィックやコストの制約下での判断力は身につきません。1〜2年、混在環境やSRE隣接職種で実務としてクラウドに触れてから、フルクラウドの求人に応募し直す人を何人も見てきましたが、そのときの職務経歴書は「実務経験あり」に変わっているので、応募できる求人の幅が一段広がっています。

求人票の職種名で言うと、「クラウド移行エンジニア」「基盤運用エンジニア（クラウド化推進）」「インフラエンジニア（オンプレ・クラウド両対応）」あたりが、この種のポジションに当たります。「クラウドエンジニア」「SRE」だけの単独名称で募集している求人よりも、オンプレとの併記がある求人票の方が、実務経験なしのオンプレ出身者にとっては現実的な入口になりやすいというのが、私の実感です。

よくある質問に答えます

ここまでの内容と重なる部分もありますが、相談の場でよく同じ形で聞かれる質問を、あらためて短くまとめておきます。求人票を前にして迷ったときは、この4つに立ち返ってもらえれば判断がぶれにくくなるはずです。

まとめ、オンプレの経験は「翻訳すれば」武器になる

クラウド未経験のインフラエンジニアが転職で苦戦する理由の多くは、経験不足そのものではなく、オンプレでやってきたことをクラウドの言葉に翻訳しないまま職務経歴書に出してしまうことにあります。冗長化、監視、キャパシティプランニング、ネットワーク設計——これらはクラウドでも形を変えて必要とされ続ける判断です。

求人票の必須要件は年数の数字で判断せず、募集背景まで読んで関与の深さを見極める。職務経歴書には「経験なし」で終わらせず、独学や検証で埋めた範囲を具体的に書く。面接では「未経験です」の先に、どう学んだかを語る。この3つを押さえられれば、クラウド未経験は応募をやめる理由にはなりません。オンプレの経験は、正しく翻訳すれば、クラウド案件でもそのまま武器になります。

上位の解説記事の多くは、志望動機のテンプレートや資格ロードマップの提示で終わっていますが、実際に選考を左右しているのは、テンプレートに沿った言い回しではなく、自分の経験をどこまで具体的に翻訳できているかです。私がMさんの職務経歴書に赤入れをしたときも、書き加えたのは新しい実績ではなく、すでにMさんの中にあった判断の基準を、採用側が理解できる言葉に置き換える作業だけでした。オンプレ一筋で来たことを引け目に感じている人ほど、実は翻訳できていないだけの経験を多く抱えていると、私は現場で感じています。