37歳から始めたDevOps転身記：未経験からジュニアエンジニアになるまでの実践的ロードマップ

## 自己紹介
こんにちは、アバカルと申します。37歳で、現在はEXANTEでジュニアDevOpsエンジニアとして働いています。
「この年齢でまだ駆け出しかよ」と笑われることもありますよね。確かに、同世代の多くはIT業界から離れ、大工や農家に転向する頃かもしれません。でも、僕の場合はただ純粋な好奇心に導かれて、夢だった職にたどり着いたんです。

この記事では、そんな僕の道のりをできるだけ細かく、そして分かりやすくお伝えしようと思います。

## 第1章：始まり
小さな町で生まれ育った僕にとって、ITの世界は「大企業のMacBookやiPhone」のような華やかなものではありませんでした。
最初はごく普通のWindows管理者として、会社でプリンターのカートリッジを交換したり、経理部の机の下を這い回ったりする日々。

（※補足情報を反映した調整例：
当時はオンライン講座も今ほど充実しておらず、独学で古い技術書を漁るのが主流でした。特にネットワーク構築の基礎を学んだ『TCP/IP入門』という分厚い本が、今思えば転職のきっかけになったかもしれません…）

時が経ち、私は様々な経験を積んできました。役に立つものもあれば、そうでないものも。2018年にはガスプロムという企業で部門長に「レベルアップ」。仕事の内容は多岐にわたりましたが、ここからがまさにOPS業務と呼べるような仕事の始まりでしたね。同僚たちと一緒に、有料ソフトを無料の代替品に置き換えていったんです。VMwareからProxmoxへの移行、遠隔地間の安定した通信環境の構築、日常業務の自動化（とはいえ、まだDevOps的なやり方ではありませんでしたが）。でもね、時間ばかりが過ぎて給料は上がらない、モチベーションも下がる一方で、結局ほとんどのメンバーが新しいチャンスを求めて去っていきました。

第2章：EXANTEのプロダクションサポート
2021年、運命のいたずらと元（というか現）同僚の誘いで、私はEXANTEのプロダクションサポートチームにジョインした。EXANTEは独自の取引プラットフォームを持つ証券会社だ。クライアントは複数通貨対応の単一アカウントで、世界50以上の市場を横断して取引できる。主な顧客層はプロのトレーダーや機関投資家ってところかな。

そうして2021年7月、プロダクションサポートの世界に足を踏み入れたんだけど、これがまあ大変だった。新しい技術のオンパレードに、情報の洪水、そして未知の金融業界。仕事そのものだけでなく、まるでアメリカ映画のワンシーンみたいな世界──主人公が超高層ビルの屋上から飛び降りるあの感覚──に放り込まれた気分だった。

（※技術面の補足として）プロダクションサポートってのは、システム監視や障害対応が主な任務で、PrometheusやGrafanaといったツールを使いこなす必要がある。それに加えて、チーム間の連携やドキュメンテーションのスキルも求められるんだよね。

まあ、とにかく、私は自分の選択をして進んできたわけだけど。**プロダクションサポートチームの組織について少し説明しよう**

基本的に、ここはレベル2〜3のテクニカルサポートを担当しているチームだ。主な役割は、本番環境の監視とシステムの異常事態への対応、それにローカルなインシデントの解決。一般ユーザーの問題（ファーストラインで解決できなかったもの）から、特定のシステムコンポーネントに関連するトラブルまで、幅広くカバーする。加えて、リリース管理やインシデント管理、本番環境全体の運用も担っている。プロダクションサポートエンジニアってのは、要するにこんな感じの仕事をする人たちだ：

- 本番システムをスムーズに動かし続ける
- トラブル発生時には即座に消火作業（いわゆる「火消し」）をする
- リリースを管理する
- 何かが壊れたとき、「知識のハンマー」で叩くべき場所をちゃんと知っている

ちなみに、こういう業務を効率化するために、CI/CDパイプラインの理解や自動化ツール（GitHub ActionsやJenkinsなど）の活用、DockerやKubernetesを使った環境構築、それにPrometheusやGrafanaのような監視ツールの導入なんかも、実は結構重要なスキルになってくる。現場で役立つスキルばかりだから、覚えておいて損はないよ。

私の同僚のほぼ90%は元システム管理者で、主にLinuxに関する知識を持っています。プロダクションサポートエンジニアとして必要なスキルには、Linuxの知識、ネットワークの理解、ZabbixやGrafanaなどのモニタリング、ウェブ技術が含まれます。特に株式取引に関連するスキルは非常に評価されています。新しく入った人間には、このオンボーディングが冒険そのものです。6週間続き、その間に膨大な情報量に圧倒されることになります。その結果、プロダクションサポートエンジニアはシステム全体を最も包括的に理解している存在となります。このため、このチームはITオペレーションやそれ以外でも才能を育てる場となっています。チームを離れる同僚の4人中3人は社内で開発やテスト、DevOpsなど別の職種へと移行します。

私がこの仕事を始めた時、「Linux？ログ？どうやってこれをこなせばいいんだろう？1週間で解雇されちゃう！」と心が叫びました。しかし、不安が渦巻く中でも生活費も必要でしたし、給料も良かったので、自宅から働けるという魅力的なリモートワーク環境にも惹かれました。COVID後では、そのような特典は素晴らしいものでした。

## 第3章：学び

11月までにはすっかり慣れてきた私は、更なる成長への意欲が湧いてきました。周囲の膨大な新情報によってもっと理解したいと思い始めた私は、DevOpsコースを受講することに決めました。このコース料金の半分は会社負担という嬉しい特典付きです。それ以来、私は学生となり将来のDevOps専門家としてITプロフェッショナル養成ラインへの一員になりました。

ここで少し「DevOps & インフラストラクチャ」チームについて紹介しましょう。「DevOps & インフラストラクチャ」という部門について想像してください。彼らはいわく「常に灯りが点いている」と言います。そしてサーバーはSF映画さながら光っている（実際にはその光を見ることはありませんが）。彼らが集まる場所ではフード付きパーカー姿で数多くのモニターに囲まれ、「kubectl apply」「terraform plan」「docker-compose up」などと小声で呪文を唱えています。

**彼らはいったい何をしているのでしょうか？**

- **サーバー上での魔法儀式**：基本的にはデベロッパーたちが作成したものがユーザー全員に機能するよう保証しています。彼らはいわば魔法使いですが、その杖はコマンドラインです。また、不正侵入者から守るためのお守りも施します。

- **霧深いクラウド征服**：彼らはいわゆる「雲」の中で活動しています。ただし夢見ているわけではなく、その中でサーバーやアプリケーションを運営しています。

- **自動化または「怠け者だけど賢い」**：DevOpsエンジニアたちは繰り返し行う手作業から解放してくれるスクリプトとツールがお気に入りです。

- **コンテナ、それは新しい入れ子細工**：同僚たちはサーバーをコンテナ内にしまったりサービス内へ収納したりできます！DockerとはIT界隈ではロシアのお土産物語とも言える入れ子細工なのです。

- **監視とログとの親密さ**：DevOpsエンジニアたちはメトリクス（CPU使用率やメモリ使用量、ディスク容量）を監視すること、大好きなんですよね。

- **目立たないフロントラインヒーロー**：全て順調なら誰にも覚えてもらえません（問題なし！）。しかし、小さなサービス障害が発生すると皆叫びます。「助けて！私たちのDevOpsどこ？」そうすると彼らはもう現場へ飛んできていて、一方手にはレンチ、一方手にはPythonスクリプトという状況です。

DevOpsおよびインフラエンジニア達は舞台裏マスターとしてITバレエの安定性と優雅さを確保しています。「コーダーブラザーフッド」、システム管理者、おまじない的要素すべて融合された存在と言えるでしょう。すべて順調ならその魔法も目立ちません。でも何か壊れると唯一彼らだけがログという古代文字を書き解き適切なお呪い（コマンド）によって再度我々技術社会をご復活させてくれる存在なのです。

私自身、この訓練には多く時間消費しましたし、多岐に渡るテーマについて学ぶ内容でした。しかし、すべて詰め込まれただけなので未来何とか対処できる程度しか把握できませんでした。

ちなみに、私はNetologyのコースで学んでいました（宣伝じゃないですよ、みんなそれぞれ好きなものを選べばいいですから）。全体的に見れば、コース内容は分かりやすく、教材の伝え方も悪くなかったんですが、いくつか「苦い瞬間」もありました。例えば、講師の中には明らかにスキル不足な人もいて…まあ、それは彼らに任せておきましょう。幸い、そういう人は多くありませんでした。

勉強を深めるうちに、実践なしでは絶対にやっていけないと気づいたんです。知識って、使わないとただ脳のシワに埃をかぶせていくだけの無駄なものになっちゃう。鋭い読者なら「仕事で学べばいいじゃない？」と思うかもしれません。その通りなんですけど、いきなり現場に行って「じゃあ私が全部直しますね！」なんて言えるわけないですよね。

そこで思いついたのが、この新鮮な知識を実際に使えるプロジェクトを立ち上げること。まだ未熟なスキルでも、何か形にできるんじゃないかって。ちょうどジュニアDevOpsエンジニアとして成長するには、CI/CDパイプラインの理解とか、AWSやAzureといったクラウドサービスの実務経験、AnsibleやTerraformを使った自動化なんかが役に立つみたいですし。

ちょっとした補足ですが、プロダクションサポートの仕事はシフト制だったので、仕事と勉強、家族との時間、そして自分のプロジェクトとの間で柔軟に時間を割り振ることができました。正直、きつかったですけどね。こういうことは35歳でやるより、20代でやるべきなんですよね。20代なら脳の回転も速いし、3時間睡眠でもなんとかなるし、腰も痛くならない（子供の宿題なんてなおさら）。でも目標は決まっていたし、次のステップはシンプルでした：プロジェクトを進めること。

あれこれ考えすぎず、さっさと同僚に相談してみたんです。みんな喜んで協力してくれました。迷う間もなく、「ジュニアが知っておくべきこと全部網羅したプロジェクト」をでっち上げてくれたんです。最初の課題はAnsibleのセットアップから設定、プレイブックの作成とテストまで。KubernetesにGit、Dockerとか、やりたかったことが全部詰まってました。明確な目標と締切がある、実践的なプロジェクトだったんです。

（ちょっと余談ですが、チーム連携を強化するには、SlackやTeamsみたいなコミュニケーションツールを使ったり、定期的に進捗確認のミーティングを挟んだりするのが効果的ですよね。ドキュメントをしっかり作って共通認識を持つのも大事だなーって、このプロジェクトを通じて改めて思いました。）

チームはタスクを割り振って進捗を管理し、時々私をブレインストーミングの会議に招いてくれたんだ（正直なところ、当時は話の4割も理解できてなかったけど、今では_核心がわかってる_）。その合間に実際のタスクが入るたびに対応し、解決策をドキュメントにまとめていた。すべてが一気に加速して――メインの仕事は通常通り続くし、勉強も進むし、得た知識を_ペットプロジェクト_に応用するし。全てを両立させるのが本当に大変で、何度「もっと早く気づいてれば…」と後悔したかわからないけど、歴史に「もしも」はないからね。## 第4章: ジュニアDevOps・IT運用部門

プロジェクトと研修がほぼ終わりに近づいた頃、私はDevOpsエンジニアとしてのキーツール——DockerやKubernetes、クラウドソリューション、Git、Ansibleなど——にだいぶ慣れてきた。無事に研修を修了し「DevOpsエンジニア」の認定も受けたものの、まだ本当の意味でのDevOpsエンジニアには程遠いと感じていた。あとはチームを移動して、より複雑なプロジェクトでプロフェッショナルたちと共に実力を証明するだけ。これが最大の目標だった。

ちなみに、EXANTEにおけるプロダクションサポートチームは、社内の"内情"に精通したメンバーで構成されている。このチームから他部署へ異動する際は優先的に考慮される——成長する社員を高く評価する企業方針だし、受け入れ側のチームも社内サービスの仕組みや全体の流れを既に理解している新人を歓迎するからだ。

そしてついに異動が実現し、私はジュニアDevOpsとしてのスタートを切れた！目標達成！

オンボーディングについて少し補足すると、このチームでは"バディ制度"を採用している。要は、経験豊富な先輩社員がメンターとして付くわけだが、他のメンバーが傍観しているわけじゃない。「飴と鞭」式の指導が基本で——調子が良ければ褒められるが、ミスをすれば「次のキャリアは自動車整備士か大工でも考えた方がいいんじゃないか」と思うほど強く叱られる（笑）。でも、決して見捨てたりはしない。どこを間違えたのか、どう修正すべきかを完全に理解できるまで、とことんサポートしてくれるんだ。

新しいメンバーは、内部のチームチャットを担当し、他部門の同僚とのコミュニケーションを図り、彼らの問題を解決しながら会社の具体的な事情について深く理解していく役割があります。**要するに、この旅は続いており、働きながら学び成長していくことが求められます。**ここで、ITオペレーションの階層構造や責任分担について簡単な図で説明します。

**プロダクションサポート**
プロダクションサポートエンジニアはL2-L3レベルの技術サポートを提供します。彼らの最も重要な責任は、生産環境の状態を監視し、システム全体に影響を及ぼす異常事態に対応し、局所的なインシデントを処理することです。

**モニタリング**
彼らは私たちのインフラストラクチャーの目として機能します。このチームの主な任務は、インフラパフォーマンスにおける変化を監視し、大きな事故が発生する前にそれを防ぐことです。ZabbixやELK、Graylogなど、一連の標準ツールを使用しています。

**DevOps & インフラストラクチャー**
Opsチームはサーバーとネットワークを管理し、ITインフラストラクチャーの安定性を確保しています。一方でDevOpsはプロセス自動化と開発と運用との橋渡し役となり、リリース速度向上に貢献しています。

**チーム間の相互作用方法**
次に、私たちがどのように相互作用しているかについて簡略化したケースをご紹介します。以下がその流れです：1. モニタリングチームがシステム内で異常行動を検知すると、その情報収集後、自動または手動でプロダクションサポートまたはインフラ部門へ事件報告します。 2. 次にプロダクションサポートエンジニアがこの事件に対処（処理時間SLA：5分）し、その重大度（軽微から重大まで）を判断します。その後モニタリングチームから提供された予備情報分析が行われ、不足している場合にはログ確認など追加調査も行います。 3. もし問題がDevOps関連だと仮定すると、その情報が担当者へ送信されて調査されます。その過程で必要なら他部署とも協力して解決策にあたります（例えばアプリケーションクラッシュの場合）。

この例はいささか誇張されていますが、大多数の場合同様な形で問題解決されています。また、生産支援チームでは注意すべきインシデント統計も溜まっていき、それについて会議（通称「インシデント会議」）も開催されます。このミーティングには誰でも参加できるためブレーンストーミングセッションとして利用されます。

## 第5章：結果と感謝
最後になりますが、この旅から得た気づきをまとめました：- **コミュニケーション:** 最良のお知らせは実際その場面にいる人々から得られるものです。 - **質問することを恐れないでください。**- **学ぶことには遅すぎるということはありません**, 特に40歳でも（ただし若いうちや他責任によって気負わず学ぶ方が良いですが）。 - **どんな行動にも報酬があります**, 良いものも悪いものも含めて。 - **努力しましょう**, DevOpsや家族関係など何事にも。

## 特別感謝
この道中支えてくれた方々への感謝を書いておきたいと思います: Zhenya, Ilya, Lida, Dima, Asylbek, Sasha、それからもちろん家族にも、本当に助けてもらいました。」