「何でも屋」社内SEとして6年
中堅メーカーの情報システム部に配属されてから、私は6年間、社内ITのほぼ全レイヤーを薄く担当してきました。AD/DNS/DHCPの管理、Office 365の運用、PCキッティング、ヘルプデスク、ベンダー折衝、SaaS選定、ネットワーク機器の保守。何を聞かれても「ある程度は答えられる」けれど、専門領域を1つ持っているかと聞かれると、即答できませんでした。
社内SEは便利屋として重宝されますが、市場価値という観点では「広く浅い」が裏目に出やすい職種でもあります。30歳を迎え、転職市場で自分のスキルを言語化しようとしたとき、自分の履歴書のあまりの薄さにショックを受けました。
クラウド移行プロジェクトが転機に
決定打は、社内のオンプレ基幹システムをAWSへ移行するプロジェクトに、ユーザー部門代表として参加したことでした。コンサルとSI'erが主導するなか、私は「現場業務をいちばん知っている人」として要件定義に関わりましたが、技術的な議論にはほとんど入れませんでした。
VPCピアリング、IAMロール、Auto Scaling、RDSのMulti-AZ。一つひとつの単語は知っていても、「なぜそう設計するのか」を自分の言葉で説明できない。ベンダー任せにすればプロジェクトは進みますが、運用フェーズに入った瞬間に主体性を失うことがわかっていました。
その日から、私は社内SEから「クラウドエンジニア／SRE」へキャリアを切り替えると決めました。
基礎の穴埋めから始める
まず痛感したのが、Linuxとネットワークの基礎不足です。私は普段Windowsしか触らない人間でしたから、sshでEC2に入ってsystemctlを打つ、というたったそれだけの操作に怯えていました。
『新しいLinuxの教科書』を頭からハンズオンで通し、シェル、プロセス、ジョブ、cron、systemd、ファイルパーミッションを手で覚えました。ネットワークは『マスタリングTCP/IP 入門編』で再構築し、サブネット計算、ルーティング、TCP/UDPの違いを言葉にできるようにしました。
AWSは『AWS基礎からのネットワーク&サーバー構築』を写経しながら、自分のアカウントでVPC・サブネット・IGW・ルートテーブルを手で組み、EC2にNginxを立て、ALB配下に置くところまでやりました。本でしか知らなかった概念が、コンソール上の絵と一致した瞬間、「あ、これは私にも理解できる」と確信できたのを覚えています。
IaCとコンテナで「再現可能なインフラ」へ
社内SE時代の最大のストレスは、「手作業でしか直せないインフラ」でした。ベンダーが入れた構成は構成図はあってもコード化されておらず、変更履歴は人の記憶です。属人化したノウハウが退職と共に消えていく恐怖は、社内SEなら誰もが知っているはずです。
『Terraform 実践入門』でIaCの思想を学び、自分の検証用VPCを丸ごとTerraformで管理するところから始めました。terraform planで差分を見るあの体験は、社内SE時代の私にとっては魔法そのものでした。
コンテナは『Docker/Kubernetes 実践コンテナ開発入門』で写経し、ECS Fargateでミニアプリを動かす構成を組みました。「なぜECSが社内オンプレより運用が楽なのか」を、自分のサービスで実感できたのは大きかったです。
転職とこれからのキャリア
8ヶ月の集中学習の後、私はSaaS企業のSREチームへ転職しました。社内SEで培った「業務側の言葉とITの言葉を翻訳する力」は、開発者と非エンジニア部門の橋渡しが必要なSREの現場で、想像以上に評価されました。
直近の仕事は、社内全エンジニアが使うCI環境のTerraform化と、各サービスのSLO定義のファシリテーションです。技術力では先輩に及びませんが、「全社業務を俯瞰できるSRE」というポジションは、私のキャリアと相性がよかったと感じます。
社内SEから抜け出したい人へ
「広く浅い」は、武器にできる文脈とできない文脈があります。クラウドエンジニアやSREの世界では、「業務とITをつなぐ翻訳者」としての社内SE経験は確実に強みになります。エンジニア集団の中で「ユーザー部門の心がわかる人」というポジションは想像以上に貴重で、私はそれを早い段階で自覚することで、自信を取り戻していきました。
ただし、技術的な深みを1つは作る必要があります。私の場合はAWS×Terraform×Linuxを軸に選びました。手を動かして、自分のAWSアカウントで何かを「壊して直せる」ようになったとき、ようやく転職市場での自己紹介が変わりました。月数千円の自己投資で得た検証環境は、6年分の社内SE経験を市場価値へ翻訳する装置になったと思っています。
