クラウドエンジニアへの転職で準備したこと｜資格の次にやること

「クラウドエンジニアに転職するにはどうすればいいですか」という問いを、周りから聞かれることがあります。

私はこの問いに対して、最初に正直なことを言わなければなりません。私は転職エージェント経由の転職をしたことがありません。 私がやったのは、同じ会社の中でオンプレ運用担当からAWS移行案件の担当に移るという社内異動です。

この記事は、転職エージェントを使った転職の成功体験談ではありません。私の社内異動の準備で実際にやったこと、公開求人を読んで感じた「こういう準備が効くのか」という観察、そしてインフラエンジニアが転職を考えるときに最低限確認しておくべきことを整理したものです。

転職を考えているなら、実際の求人票と転職サービスへの登録・相談が、私のこの記事より具体的で自分の状況に合った情報を持っています。個人差がある話であることを前提に読んでもらえればと思います。

私がやった「転職準備に近いこと」の全体像

まず、私が実際に何をしたかを正直に書きます。社内異動という形でしたが、準備の考え方は転職と共通する部分があります。

社内でオンプレからAWSへ移った経緯

私は2018年頃から約5年間、オンプレミスのサーバ・ネットワーク運用を担当していました。業務内容は、物理サーバの死活監視・障害対応・ルーターやスイッチの設定変更・バックアップ確認などです。24時間監視体制の一員として、インシデント対応も経験しました。

2023年に、社内でAWS移行プロジェクトが立ち上がりました。私はこのプロジェクトに参加したいと思い、当時の上長に手を挙げました。上長に「AWS移行の担当としてやっていける」と説得するために、私が準備したことが本記事の原体験です。

転職という形ではありませんでしたが、「今の担当範囲から違う技術領域に移る」という構造は、転職での職種変更と通ずる部分があります。その経験をもとに書きます。

実務経験の棚卸しをした

まず、それまでの5年間に自分が実際に担当したことを書き出しました。「どんな環境を担当したか」「どんな障害対応をしたか」「どんな設定変更をどういう判断でやったか」を箇条書きにしていきました。

書き出してみると、自分が思っていたより多様なことを経験していたことに気づきました。一方で、「担当したことはあるが説明できない」ものも多かったです。たとえば「BGPの設定をやったことがある」のは事実でも、「BGPのパス選択の仕組みをどう使ったか」を説明できるかというと怪しかった。この「やったことはあるが説明できない」を「説明できる」状態にすることが、準備の核心だと感じました。

棚卸しの結果を見ると、担当範囲が広い一方で、「なぜそうしたか」を言語化できているものが少ないということが分かりました。この問題は、転職の書類や面接の準備で直接響きます。書類に書けること・面接で話せることの量が、そのまま選考での評価に影響するからです。

説明できる設計判断を2〜3個用意した

技術面接では、実務経験の内容を聞かれます。「どういうシステムを担当しましたか」から始まって、「なぜその構成を選んだのですか」「そのときにどんな課題があって、どう解決しましたか」という流れで深掘りされます。

この深掘りに対応するために、「説明できる設計判断」を2〜3個用意しました。具体的には、「〇〇という要件があって、A案とB案を検討したうえでA案にしたのはこういう理由からです。B案を採らなかった理由はこれです」という形で言語化できるエピソードです。

準備していたエピソードの一つは、ルーターの二重化構成についてです。コスト削減の提案を受けたときに、なぜ単一化ではなく二重化を維持すべきかを経営層に説明した経験です。これは「スペック」ではなく「判断」の話なので、どの技術スタックの面接でも基本的な考え方として使えます。

SAAを取得して基礎知識を整えた

並行して、SAAの勉強を始めました。オンプレの経験があったので、AWSの各サービスを「どのオンプレコンポーネントと対応するか」という視点で整理すると理解が進みました。EC2はVMに近い、RDSはデータベースサーバの管理部分をAWSが担う、Route53はDNSに当たる、という読み替えです。

SAAを取ることで、AWS移行プロジェクトに参加するための「基本的な範囲は把握している」という説明ができるようになりました。また試験の勉強でAWSの設計パターンを一通り確認できたのは、移行担当になってから実際に役立ちました。

資格の勉強は「知識の網羅的な確認」として機能します。実務ではどうしても担当範囲に偏りが出るため、試験の勉強で「自分がまだ触っていない領域」を確認できます。これは移行担当として動く前の準備として有効でした。

求人票から読み取れる「転職に効く準備」

私の経験だけでなく、公開求人を読んで感じた「これが準備として機能しそう」という観察を共有します。

必須要件に書かれているものを確認する

クラウドエンジニアの転職求人で最も多く見た必須要件は「AWSを使った実務経験○年以上」です。必須要件は「これがないと書類で落ちる」という条件です。

必須要件として書かれている実務経験の内容を確認することで、今の自分がどの求人に応募できるかの目安になります。実務経験が不足しているなら、応募する前に経験を積むか、より下位のポジションから入るかという判断になります。

ポジションの定義も求人によって違います。「クラウドエンジニア」という名前でも、設計・構築が中心のポジション、運用・監視が中心のポジション、アーキテクトとして要件定義から関わるポジションと幅があります。求人票の業務内容欄を細かく読むことで、そのポジションが自分の目標と合っているかが分かります。

歓迎要件から「加点になること」を知る

歓迎要件に書かれているものは、あれば評価が上がる要素です。AWS認定資格が歓迎要件に入っている求人は多く、特にSAA以上が求められているものが多い印象でした。

また歓迎要件にはAWS認定以外にも、Terraform等のIaCツール経験、Kubernetes経験、Ansible等の構成管理ツール経験、セキュリティ系の知識などが書かれていることがあります。これらは「取っておくと選考での評価に影響する可能性がある」スキルです。

自分が応募したいポジションの求人票を複数確認して、歓迎要件に共通して出てくるスキルを把握しておくと、準備の優先順位を付けやすくなります。

インフラエンジニア特有の強みを言語化する

オンプレ経験からクラウドエンジニアへ移る場合、オンプレ経験が弱点ではなく強みとして機能する部分があります。

特に「物理ネットワークの知識」「ディスク・メモリ・CPUなどの物理リソースの感覚」「障害対応の経験と切り分けの手順」は、クラウドでも使える基礎です。クラウドの上位レイヤーが吸収する部分が増えたとしても、基礎知識があると理解の速度が違います。

「VPCのサブネット分割を設計するときに、オンプレでのVLAN設計の知識が使える」「ストレージのIOPS要件を見積もるときに、物理ディスクの感覚が参照点になる」といった形で、オンプレ知識とクラウドの業務を橋渡しする説明ができると、面接での印象が変わります。

オンプレ経験からクラウドへの移行についてはオンプレ運用からクラウドへ移るときにつまずいたことにも詳しく書いています。

ドキュメントと調整の経験を言語化する

意外と大事だと感じたのが、ドキュメントと調整の経験です。「設計書を書いたことがある」「開発チームや営業と要件をすり合わせたことがある」「社内レビューで指摘を受けて修正した経験がある」「ベンダーとの折衝をした経験がある」といったことが、シニアポジションの求人では重視されます。

これは「純粋な技術」ではなく「技術を仕事にした経験」です。技術の知識だけある人ではなく、チームや業務の中で技術を使ってきた人を求めているという意図を、シニアポジションの求人票からは感じます。

技術以外の経験も棚卸しして、職務経歴書に書き出しておくことが準備として有効です。

資格の次にやること

「AWS資格を取った。次は何をやればよいか」という問いへの私なりの整理を書きます。

資格で習得した知識を実務に接続する

SAAやSAPを取ったあと、その知識を実際の業務や個人プロジェクトに接続することが「資格の次にやること」の第一歩です。

たとえばSAAの勉強で「マルチAZ構成」を学んだなら、実際に試してみる、または担当業務でこの構成が使われているかを確認するという動きが考えられます。実際の構成を自分で触った経験があると、面接での説明に具体性が増します。

知識と経験の差は、「説明できるかどうか」の具体性の差として現れます。試験の問題に答えられることと、実際の案件でこう判断したと説明できることは違います。後者になるためには、何らかの形で実際に手を動かした経験が必要です。

個人での検証環境を作る

AWS無料利用枠や小さなEC2インスタンスを使って、個人で動作確認できる環境を作ることは、実務経験の積み上げとして有効です。

私の場合は、試験の勉強で学んだ構成を実際に作ってみることを繰り返しました。「こう動くはずだ」と理解していたものが実際に試してみると違う挙動をすることがあります。その試行錯誤の経験が面接での「実際に試してみたこと」として使えます。

たとえばVPCのピアリング設定をやってみると、ルートテーブルの更新が必要なことやセキュリティグループの設定が双方向に必要なことを体感できます。これは試験の勉強で「知っている」と、実際に「やったことがある」では説明の厚みが違います。

ただし個人の検証環境は、企業が運用する本番システムのスケールや制約とは違います。「個人で試したことがある」のと「本番で担当したことがある」は評価として違うということを前提にしておくことが必要です。

ドキュメントを書く習慣をつける

個人プロジェクトや検証環境の内容をドキュメントとして書き残す習慣をつけることをおすすめします。

なぜその構成にしたか、どういう問題が起きてどう解決したかを文章で残しておくと、面接で「説明できる実績」として使いやすくなります。技術ブログでもよいですし、GitHubのREADMEでもよいです。社内での勉強会資料という形でも構いません。

「アウトプットがある」というのは、採用の場で「学び続けている人だ」という印象を与えます。これは資格の有無とは別の軸の強みです。

IaCの基礎を触っておく

転職先の求人でTerraformやCloudFormationが歓迎要件に挙がっている場合は、基礎的な使い方を触っておくことが有効です。

IaC（Infrastructure as Code）は、インフラをコードで宣言的に管理する仕組みです。オンプレ経験がある場合、「手動で設定を変更する」という感覚とは異なるため、最初は戸惑う部分があります。しかし基本的な書き方を覚えれば、テンプレートを読むことはできるようになります。

採用の場では「TerraformでVPCを作成したことがある」という経験があると、IaCを扱う環境への適応が早いという印象を与えられます。

私は転職エージェントを利用したことがありません。転職エージェントのサービス詳細・対応職種・登録方法については転職エージェントナビの公式サイトでご確認ください。転職の成否や年収の変化には個人差・企業差があります。

転職活動の書類と面接の準備

転職を具体的に進める段階での準備についても整理します。

職務経歴書の書き方

クラウドエンジニアへの転職での職務経歴書では、以下の要素を意識して書くことが効果的だと思っています。

「担当したシステムの概要」「使用した技術・ツール」「担当した業務の範囲」「実際に行った設計判断や問題解決のエピソード」の4点を、各職歴ごとに書くことが基本です。

資格は職歴の後か別の資格欄にまとめて記載します。取得年月と認定名を書くのが一般的です。資格の記載だけでなく、職歴の中で「この資格に関連する実務を担当した」ということが分かるように書くと、資格と実務が連動して伝わります。

職務経歴書の書き方に迷ったら、応募先の求人票の必須要件・歓迎要件の記述を見て、それに対応する形で自分の経験を整理するという方法があります。求人票と職務経歴書を並べたときに、要件に対応する経験が見えやすくなるような書き方を意識します。

技術面接の対策

技術面接では、実務経験を元にした判断の話を求められます。「なぜこの構成を選んだのか」「どういう代替案があって、なぜその選択をしたか」「どういうトレードオフを意識したか」といった問いに答えられる準備が必要です。

準備の方法として、過去の案件で「説明できる判断エピソード」を2〜3個用意しておくことをおすすめします。面接で話せる具体的な話があると、技術の話が抽象論にならず深みが出ます。

また、基本的なAWSの概念（VPC・サブネット・セキュリティグループ・IAMの基本）について口頭で説明できるか確認しておくことも有効です。SAAの学習内容がそのまま準備として使えます。

「なぜその設計にしたか」「他の選択肢との比較でどう判断したか」という観点で自分の経験を整理しておくと、深掘り質問にも対応しやすくなります。

オンプレ経験の提示方法

オンプレ経験からクラウドへ移行する場合、オンプレ経験を「弱点」として提示するのではなく、「クラウドに接続できる強み」として提示することが重要です。

「オンプレでこういうことをやっていた。このオンプレの知識が、クラウドのこういう場面で活きる」という形で対応関係を示すと、経験の価値を説明しやすくなります。

たとえば「物理ネットワークの運用経験があるので、VPCのサブネット設計やセキュリティグループの設定の意図を理解して実装できる」のように、オンプレ経験とクラウドの業務を橋渡しする説明です。

採用担当者がオンプレ経験をどう評価するかは企業や担当者によって違いますが、活かせる部分を自分で言語化しておくことは準備として有効です。

転職後の最初の期間をどう乗り越えるか

転職後の話は、私の社内異動の経験から書きます。

新しい環境のルールと慣習を把握する

どんな環境でも、最初の数週間は「ここのルールと慣習を把握する」期間として使うことが重要です。クラウド環境の場合、IaCで管理されているルール・命名規則・監視の設計方針・コストアラートの設定など、ドキュメントに書かれていないことも多いです。

私がAWS移行担当に移ったとき、最初に困ったのは「何がどこで管理されているか分からない」という状況でした。Terraformのコードを読んで構成を把握し、内部ドキュメントを読んで設計方針を確認するという作業から始めました。

「分からない状態を素直に認めて、確認しながら動く」というのは、最初のうちの大事な姿勢です。

質問する習慣をつくる

新しい環境での最初のうちは、分からないことを積極的に質問する文化を作ることが重要です。長い目で見ると「入ったばかりで質問をよくした人」の方が、早く戦力になる場合が多いです。

ただし質問の仕方には気を付けています。「これはどういう意味ですか」という漠然とした質問より、「○○を理解しようとしているが、△△の部分が分からない。□□という理解で合っていますか」という形で聞く方が、相手への負担が少なく答えてもらいやすいです。

AWS認定の学習が役立つのは、こういう場面でも同様です。SAAで一通りの概念を学んでいれば、先輩の説明を聞いたときに「そういえば試験で見た構成だ」という文脈の接続ができます。これが吸収の速度に影響します。

小さな成果を積み上げる

最初のうちは大きなプロジェクトより、小さなタスクを丁寧に完了させることに集中します。ドキュメントの更新・設定変更の確認・モニタリングのダッシュボード整備など、チームの役に立つことを地道にやる期間が、信頼の土台を作ります。

転職後の慣らし期間の話は転職に限らず、社内異動でも同じでした。最初の3ヶ月は「使えるかどうか見られている期間」という感覚で動いていました。

まとめ

• 私は転職エージェント経由の転職をしたことがなく、体験は社内異動の範囲内
• 実務の棚卸しと「説明できる設計判断」の言語化が転職準備の核心
• 求人票の必須要件を確認することで、現在の自分がどの求人に応募できるかが分かる
• オンプレ経験はクラウドへの移行で「弱点」ではなく「クラウドに接続できる強み」として使える
• 資格の次にやることは、資格で学んだ知識を実務に接続すること
• 転職書類では資格と実務経験を合わせて提示することが効果的
• 転職後は新しい環境のルール把握と小さな成果の積み上げを意識する
• 転職の成否には個人差があり、具体的な条件は求人票と転職サービスへの確認が確実

AWS資格が年収に与える影響についてはAWS資格で年収は上がるのか、転職市場での評価についてはAWS資格は転職でどう評価されるかもあわせてご覧ください。

資格学習と転職準備を並行するとき

資格の勉強をしながら転職準備を進めることは可能ですが、それぞれに必要な種類の作業が異なることは意識しておく価値があります。

試験勉強と実務の棚卸しは別の作業

SAAやSAPの試験勉強は「AWSのサービスと設計概念を体系的に習得する」作業です。一方、転職準備の実務棚卸しは「自分が何をやってきたか、どんな判断をしたか」を言語化する作業です。この2つは目的が違うため、同時に進めると混在することがあります。

私の場合は試験勉強を先に区切りをつけてから実務棚卸しに集中するという順番にしました。試験で学んだ設計パターンの語彙を持った状態で実務を振り返ると、「これはマルチAZ設計を採用した案件だった」「このときIAMロールの最小権限を考えた場面があった」という形で整理しやすくなります。

勉強期間中に担当の幅を広げる

資格取得の勉強をしている期間に、業務で触れるサービスや担当する設計の幅を広げていくことは有効です。VPC設計に携わる機会があれば積極的に担当する、CI/CDパイプラインの構築が社内で必要になったときに手を挙げる、といった形で学習内容と実務を近づけると、職務経歴書に書ける内容が増えていきます。

「資格を取るための勉強」と「転職書類に書ける経験を積む」を並行させるには、現在の業務の中でどの部分を手掛けているかを意識的に管理することが重要です。担当範囲を広げるために上長に相談することも選択肢の一つです。

資格取得に向けた学習方法についてはAWS SAAの難易度と勉強時間に詳しく書いています。オンプレからクラウドへの移行を経験する際のつまずきについてはオンプレ運用からクラウドへ移るときにつまずいたことも参考にしてください。