はじめに
2025 年、私は SES 企業で働くインフラエンジニアとして、自社開発企業への転職を目指しました。
結果として、選考に進んだ企業すべてに落ちました。
1. 活動背景と技術スタック
まず、2025 年時点での私のスタックは以下の通りです。
AWS（実務 4 年）
- VPC / EC2 / S3 / RDS / Aurora
- ECS / Lambda / Route53
- CloudWatch / IAM / KMS
- ElastiCache / Secrets Manager
インフラ・運用
- Linux / Windows Server
- VMware / Docker
- Zabbix / JP1
- Shell / Ansible / Jenkins
ネットワーク
- L2〜L3 / VLAN / QoS
- 障害対応 / 設計・運用
スタックだけを見ると、インフラ周りの運用・構築を幅広く経験しているように見えると思います。
ただし、このあと触れる「敗因」の部分に繋がりますが、深さより広さのキャリア であることが課題でした。
2. どんなキャリアを目指していたのか？
私が目指していたのは クラウド × 自動化 × SRE に近い領域のエンジニア。
- 短期目標（1-2 年）
- Terraform を中心とした IaC の実務での確立
- CI/CD 開発フローの習熟
- クラウドネイティブ設計の基礎固め
- 中期目標（3-5 年）
- 可観測性（Observability）
- SRE のプラクティスの実践
- 長期目標（5 年以上）
- インフラ / SRE のスペシャリスト
つまり、「運用して終わり」 ではなく、継続的改善に関わるエンジニア を目指して転職活動を進めました。
3. なぜ全敗したのか？ その理由を冷静に振り返る
ここからがこの記事の核心です。
私自身が「選考で落ち続けた理由」を、客観的に振り返って整理します。
① 即戦力レベルのスキルが足りなかった（特に IaC と監視）
企業が欲していたのは
- Terraform を実務で回してきた人
- Datadog / New Relic などの可観測性ツールを使いこなせる人
私は Terraform・監視ツールの知識はあるものの
- SIer/SES で実案件として回した経験が浅い
- 運用チームの一員のため 主体的に設計する側ではなかった
この差は非常に大きかったと痛感しています。
「触れる」と「仕事として回して成果を出した」は全く別物
と何度も突きつけられました。
② SES での実務では経験しにくい “顧客折衝力” が不足していた
面接で企業からよく聞かれたのが
- 「要件定義の経験はありますか？」
- 「プロダクト側の開発チームとの折衝は？」
- 「技術選定の場に参加したことは？」
SES の場合、どうしても「下流工程に寄りがち」なのは事実。
これを言い訳にしたくはないのですが、経験として足りないのも事実でした。
③ 面接で “自分の欲求” が強すぎた
面接でよく話していたのが
- 「もっと技術的なチャレンジがしたい」
- 「手作業の環境から、IaC や自動化された現場に移りたい」
これは本音ですが、採用側からすれば
“あなたが当社に入社すると、どんなメリットがありますか？”
という視点が抜けて見えてしまったと思います。
企業は
- 「何ができるのか」
- 「どんな価値を出せるのか」
を知りたいのに、私はその視点を十分に言語化できていませんでした。
4. 使った転職サービスと結果
転職ドラフト / Findy / LAPRAS / Forkwell と複数サービスを利用しましたが、結果は すべて選考落ち or カジュアル面談で終了。
ただし、サービスの体験自体はそれぞれで得るものがあり、エージェントの質やスカウトの傾向なども分かりました。
5. 今回の転職活動で得たもの
全敗という結果だけを見るとネガティブですが、振り返ると明確にプラスになったものがあります。
① 市場価値の現実を知れた
- 何が足りていないのか
- どれが「評価される経験」なのか
- どの技術が市場で求められているのか
これらが明確になったのは大きな収穫でした。
② アウトプットを継続する意味を理解した
LAPRAS の「市場価値スコア」を通じて、Zenn や GitHub で発信することの重要性を実感できました。
- スキルの可視化
- 学習履歴の証明
- 転職活動での「説得力」
これらにつながることを理解しました。
③ “欠けているスキル” が具体化されたことで、次の行動が明確になった
次にやるべきことが明確になりました。
- Terraform の実案件クラスのハンズオン構築
- Datadog / New Relic などの可観測性の体系的な学習
- 監視 → 分析 → 改善 の流れを個人で再現
- IaC・CI/CD のポートフォリオ化
- 選考で語れる成果を「自分で作る」
これは、今回の失敗がなければ得られなかった視点だと思っています。
6. 今後の戦略（第二ラウンドの転職活動への準備）
次回同じ失敗を繰り返さないために、今後は以下を行動計画として動いていきます。
① Terraform × AWS × CI/CD のポートフォリオを作る
- VPC / ECS / RDS を Terraform で構築
- GitHub Actions で自動デプロイ
- 監視は Datadog or CloudWatch メトリクスで可視化
実案件レベルの“語れる成果”を作る。
② 可観測性ツール（Datadog 等）の学習
- Dashboard
- APM
- Log 管理
- SLO 設定
- アラート設計
SRE の基盤となる部分の学習を強化。
③ 面接回答を「企業視点」に変える練習
- 自分の経験 → 企業にどう貢献できるか
- 課題 → 解決策 → 自分の役割
- ただの希望ではなく「提供価値」を語る
ここが改善できれば、選考突破率は大きく変わると確信しています。
④ 学習時間を「先に確保する」仕組みづくり
これは直接の選考結果とは関係ないものの、今後もう一度チャレンジするための前提条件 だと感じています。
客先常駐という働き方の都合上、業務後にまとまった学習時間を取ることが難しく、これまではどうしても「空いた時間で勉強する」という受け身のスタイルになっていました。
その結果、学習時間が日によって大きくブレてしまい、スキルの積み上げが不安定になっていたと思います。
今後は、
- 常駐先付近のコワーキングスペースを早朝から活用する
- 出勤前に 1〜2 時間、学習に充てる時間を“先にブロックしておく”
といった形で、意志ではなく仕組みで学習時間を確保する よう工夫していこうと考えています。
転職活動に再挑戦する頃には、「学習時間が足りない」ではなく、「これだけ継続してきた」と胸を張って言える状態を目指します。
⑤ 資格
昨今ネット上では「エンジニアは資格がなくても、経歴さえあればやっていける」という情報が錯綜していると思います。
かくいう私も、そのような情報を鵜呑みにしてしまい今日まで過ごしてきました。
しかし、今回の転職活動でお見送りになった理由として「即戦力ではない」が半数以上を占めていました。
環境のせいにするのは簡単ですが、SES ではいわゆる「上流工程の経験」を積みにくく、企業に対して価値を示しづらいのも事実です。
技術を磨くことに意識が偏り、他の武器になり得る要素に目が向いていなかった点も大きな反省です。
今後は技術だけでなく、より深い知識も必要になってくることも鑑み、資格取得に向けて行動したいと思います。
何より、AWS 認定を取得することで「自分の経験を自分の言葉で語る」だけでなく、ベンダー公式の認定として第三者評価を得られるはずです。
この点もおろそかにせず、取り組みたいと思います。
7. おわりに（失敗は“次の踏み台”にする）
転職活動で全敗したことは正直つらかったです。
ただ、それ以上に
「キャリアを見直す、大きなきっかけになった」
と今では感じています。
私は SES 出身なのでハンデがある部分もあります。
でも、それを言い訳にせず、足りないところを補って次の挑戦に向けてまた積み上げていきます。
同じように転職活動で苦しんでいる人にも、この棚卸しが少しでも勇気になれば幸いです。