DevOpsへの転職は遅くない?30代・40代から始めるキャリアチェンジの実例と学習ステップ

Published on: | Last updated:

30代未経験からDevOpsへ。これ、無理ゲーじゃない?

最近よく考えるんだけど、30代後半で未経験からDevOpsエンジニアになるって、正直どうなんだろう?って話。周りはもうキャリアのまとめに入って、シニアだのリードだの言ってる歳なのに、「はじめまして、ジュニアです」って。面白いキャリアを辿った人の話を聞く機会があって、その道筋がすごく参考になったから、ちょっとメモ代わりにまとめてみる。

結論から言うと、鍵は「社内転職」、もっと言うと「プロダクションサポート」からのステップアップだったみたい。いきなり外部の未経験求人に応募するのとは、ワケが違うんだよね。

ステップ1:くすぶってた「社内SE」時代

キャリアのスタートは、多くの人がイメージするような、キラキラしたIT企業じゃなかったらしい。どっちかっていうと、いわゆる「社内SE」とか「情シス」みたいな感じ。経理の机の下に潜り込んでLANケーブルを配線したり、プリンターのトナー交換したり。ああ、あの感じね。わかる人にはわかるはず。

でも、そこでただの便利屋で終わらなかった。Windowsサーバーだけじゃなくて、だんだんインフラ寄りの仕事が増えてきた。例えば、有償だったVMwareの代わりに無償のProxmoxにリプレイスしたり、拠点間のネットワークを安定させたり、地味な定型作業を自動化したり。この時点ではまだ「DevOps」的なやり方じゃなかったけど、確実に「Ops」側の経験を積んでたわけだ。

正直、こういう経験って「DevOpsやりたいです!」って人には遠回りに見えるかもしれない。でも、後から考えると、この「泥臭い」経験がめちゃくちゃ効いてくるんだよね。

ステップ2:「プロダクションサポート」っていう名の養成所

で、転機が訪れる。ある金融系の会社に「プロダクションサポート」としてジョインしたこと。これがすごく重要だったみたい。

プロダクションサポートって何するの?って話だけど、要するに本番環境の門番。システムの安定稼働を守る最後の砦みたいなチーム。

  • 本番環境のシステムを監視して、異常があれば対応する。
  • ユーザーからの問い合わせ(一次対応で解決しなかったやつ)のエスカレーション先。いわゆるL2、L3サポート。
  • リリースの管理とか、インシデント管理もやる。
  • 何かぶっ壊れたときに、どこを叩けば直るか知ってる人たち。

このチームにいる人たちの9割近くが、元システム管理者。特にLinux系の知識が豊富な人が多かったらしい。だから、求められるスキルも必然的にLinux、ネットワーク、監視(ZabbixとかGrafana)、Web技術…みたいな感じ。正直、ここに入った当初は「Linux?ログ?何それ美味しいの?」状態で、1週間でクビになると思ってた、なんて話も(笑)。

でもね、このチーム、実は社内の「人材輩出工場」だったんだって。システムの隅から隅まで、どう動いてるか一番理解してるのがこのチームだから。プロダクションサポートを辞めた人のほとんどが、開発、QA、そしてDevOpsみたいな他のチームに社内異動していく。これ、すごくない?外から門を叩くより、ずっと確実なルートじゃん。

プロダクションサポートの日常:次々発生するアラートとの戦い
プロダクションサポートの日常:次々発生するアラートとの戦い

ステップ3:知識を「使える」スキルに変える学習法

仕事に慣れてくると、欲が出てくる。「もっと深く知りたい」って。で、DevOpsのコースを受講することにした、と。まあ、よくある流れだよね。でも大事なのはここから。

研修で学ぶことって、どうしても総花的になりがち。Docker、KubernetesAnsible、クラウド…色々やったけど、広く浅くって感じ。で、ここで気づくわけだ。「これ、実践で使わなきゃ全部忘れるな」って。

じゃあ、どう実践する?「会社の仕事でやらせてください!」なんて、いきなり言えるわけない。そこで出てきたのが「ペットプロジェクト」っていうアイデア。でも、よくある「ToDoアプリ作りました」みたいなのじゃなくて、同僚に相談して、ガチの課題をもらったんだって。

これがすごい。例えば、「Ansibleで設定ファイル管理するプレイブック書いてみて」とか。Kubernetes、Git、Docker…ジュニアが知るべきことが全部詰まった、リアルなプロジェクト。しかも、チームがタスクを振ってくれて、進捗も見てくれる。時々ミーティングにも呼ばれて…まあ、当時は話の4割も分からなかったみたいだけど(笑)。

正直、この時期が一番キツかったらしい。本業のシフト勤務、研修の課題、家族との時間、そしてペットプロジェクト。20代ならまだしも、30代半ばでやるもんじゃないって。頭の回転も違うし、睡眠3時間じゃ体がもたない。でも、目標があったから走りきれたんだろうね。

独学と「社内ペットプロジェクト」って何が違うの?

これ、気になるところだと思うから、ちょっと比較表にしてみた。感覚的なものだけど。

比較ポイント よくある独学 社内ペットプロジェクト
リアリティ どうしても「練習問題」感が抜けない。架空のシナリオだし。 ガチのやつ。実際に動いてる、あるいは動かす予定のシステムが対象。緊張感が違う。
フィードバック どこから?Stack Overflow?メンターでもいない限り、ほぼゼロ。 先輩から直接。「この書き方じゃダメ」とか、コードレビューがもらえる。これが一番デカい。
技術選定 流行りの技術をとりあえず触る、になりがち。なぜそれを使うのか?までは考えにくい。 「なぜうちの会社ではTerraformじゃなくてAnsibleなのか」みたいな、背景まで学べる。
モチベーション 孤独な戦い。飽きたら終わり。まあ、いつでもやめられるしね…。 「手伝ってくれてる先輩に申し訳ない」っていう、良い意味でのプレッシャーがある。簡単には投げ出せない。
実績として 「自分で作ったポートフォリオです」って言える。まあ、悪くはない。 「社内の〇〇プロジェクトで、〇〇を担当しました」って言える。説得力が段違い。
深夜の自己学習:膨大な情報と格闘するデスク
深夜の自己学習:膨大な情報と格闘するデスク

ステップ4:ついにDevOpsチームへ。でも、ここが本当のスタート

ペットプロジェクトと研修が終わる頃には、DevOpsの主要なツール(Docker, Kubernetes, Git, Ansibleとか)は一通り触った状態になってた。で、ついに目標だったチームへの異動が叶う。

そう、晴れてジュニアDevOpsエンジニアに!ゴール達成!…かと思いきや、もちろんここからが本番。

ここでも会社の仕組みが面白い。異動後は「バディ制度」で、経験豊富な先輩が一人ついてくれる。もちろん、他のメンバーも見て見ぬふりするわけじゃなく、アメとムチで育ててくれる感じ。「よくやった!」って褒められることもあれば、「帽子が吹っ飛ぶくらい」怒られることもあったとか。でも、絶対に見捨てはしない。分かるまで徹底的に付き合ってくれる。

あと、新人の仕事として、チーム内のチャット対応とか、他部署とのやり取りを担当する。これによって、会社の仕組みをさらに深く理解していくわけだ。

で、DevOpsチームって結局何してるの?

「DevOpsとインフラチーム」って、なんか秘密結社みたいに聞こえるじゃん?サーバーのランプが明滅してて(クラウドだから見えないけど)、パーカー着た人たちがモニターに囲まれて「kubectl apply...」とか囁いてるイメージ。

やってることは、だいたいこんな感じらしい。

  • サーバーへの魔法の儀式:開発者が作ったものが、ちゃんとユーザーに届くようにする。コマンドラインという名の杖を振るう魔法使い。不正な侵入者を防ぐ結界も張る。
  • 自動化、あるいは「賢い怠け者」:同じ手作業を繰り返すのが大嫌い。スクリプトやツールで全部自動化する。
  • コンテナはマトリョーシカ:Dockerコンテナにサーバー入れて、そのコンテナをサービスにして、そのサービスをまたコンテナに入れる…みたいな。IT界のマトリョーシカ人形。
  • 監視とログとの添い寝:CPU、メモリ、ディスク使用率…測定できるものは何でも監視するのが大好き。何かあればログを抱きしめて原因究明。

こういうDevOpsの役割って、例えば海外のカンファレンスとか「State of DevOps Report」みたいな資料を見ると、開発から運用まで一気通貫で見るスーパーマンみたいに描かれがち。でも、日本の会社だと、まだインフラチームと開発チームが分かれてて、DevOpsエンジニアはその「架け橋」的な役割を担うことも多い。だから、会社によって仕事の範囲が全然違うのは、知っておいた方がいいかも。求人票の「業務内容」はマジで熟読すべき。

理想的なCI/CDパイプライン:自動化されたスムーズな流れ
理想的なCI/CDパイプライン:自動化されたスムーズな流れ

まとめ:結局、大事なことって何だっけ

この一連のキャリアチェンジの話を聞いてて、結局大事なのはいくつかのシンプルなことなんだなと思った。

まず、**臆せずに人に聞くこと。** 最高の情報は、それを「やってる」人が持ってる。ネットの記事もいいけど、生の声には敵わない。

それから、**学ぶのに遅すぎることはない、って信じること。** もちろん、20代の方が有利なのは間違いない。でも、30代、40代でも、強い目的意識があれば何とかなる。というか、何とかするしかない。

そして何より、**近道を探さないこと。** プロダクションサポートみたいな一見遠回りに見える経験が、後でめちゃくちゃ効いてくる。泥臭い仕事から逃げない。結局、DevOpsだろうが何だろうが、仕事ってそういう地道なことの積み重ねなんだろうね。

もしあなたが今、キャリアに悩んでて、新しい技術スタックの学習に苦労してるなら、まずは社内に目を向けてみるといいかもしれない。「プロダクションサポート」みたいな、システム全体を見渡せる部署はないか?そこで経験を積んで、次のステップに進む。そんなルートも、あるんじゃないかな。

あなたはどうやって新しい技術を学びましたか?もしよかったら、あなたの「ペットプロジェクト」の話も聞いてみたいです。

Related to this topic:

Comments

  1. Guest 2025-06-28 Reply
    息子、ITの世界で頑張ってるんだね。DevOpsって難しそうだけど、学びの姿勢すごいよ。うちの会社の研修プログラムとかも紹介できるかもしれないから、今度ゆっくり話そうね。
  2. Guest 2025-06-23 Reply
    うーん、ITの世界って本当に変化が速いよね。わが子にも、柔軟性と学び続ける姿勢が大切だって伝えたいな。DevOpsって、単なる技術じゃなくて、チームワークと成長の姿勢が肝心なんだろうな。
  3. Guest 2025-06-08 Reply
    息子のキャリアって、こんな感じなんだ?DevOpsって難しそうだけど、どうやって勉強し始めたの?現場の雰囲気とか、どんな感じだったか気になるなぁ…
  4. Guest 2025-06-07 Reply
    うーん、DevOpsって結構大変そうだよね。私も現場で苦労した経験あるし、チームの温度感とか、コミュニケーションの難しさ、よく分かるわ。インシデント対応とかマジでストレスたまるよね。でも、成長のチャンスでもあるから、がんばって!
  5. Guest 2025-05-01 Reply
    素晴らしいキャリアの旅ですね!特にDevOpsを学ぶためのプロジェクトについてもっと聞きたいです。どんな具体的な挑戦がありましたか?また、チーム間連携での工夫などもあれば教えてください!
  6. Guest 2025-04-29 Reply
    正直に言うと、プロダクションサポートは大切だけど、DevOpsの学びに集中しすぎると現場の実情を見失う可能性もあると思うよ。バランスが大事じゃないかな?
  7. Guest 2025-04-17 Reply
    あなたのキャリアのスタートについて興味深いですね。でも、EXANTEでのプロダクションサポートって、具体的にどんなことをしているんですか?チーム間連携が重要だと言っていますが、実際にはどうやって連携を強化しているのでしょうか?