#Career #Infrastructure #AWS
01｜体育教師からエンジニアへ
前職は、体育教師だった。まさに異業種からの転職である。学生時代の私はバスケットボールに打ち込み、酷くその競技の魅力に引き寄せられた。日夜、ボールに触れ、上達を感じることが心地よくて仕方なかった。高校時代には公立校には珍しい部員50名相当の部員がいた。彼らを束ねる主将を任されたりもした。大学では強豪校に進み、挫折とそこから成長するプロセスを学んだ。卒業後、夢を諦めれず、体育教員として働く側で実業団に所属し練習に励み、プロの入団試験に挑戦した。約2年の挑戦後、24歳の私はトライアウトによる結果ではなく、自分自身の心の限界を理由に夢を断念した。
その後、教員として働く道も考えたが、より大きな変化を求めて、ずっと少しずつ学んでいた英語を本気で学びたく、フィリピンへ半年間の留学を決めた。また、学生時代からの友人にエンジニアがいた。彼にエンジニアの仕事の話を聞いたことをきっかけに、Googleで「英語 ITエンジニア」と調べ、ワクワクしたことを今も思い出す。少し話ははしょぐが、そこから色々準備をして、IT×英語を学べるカリキュラムを強く打ち出している学校に決めた。そして、その半年後に留学から帰国、SES企業に就職した。今現在、インフラ保守エンジニアとして働いている。
ITエンジニアといっても、開発、インフラ、ネットワーク、セキュリティなど様々な分野がある。なぜ、自分が「インフラ」を選んだのか、理由は明確だった。それは、安定思考な職と裏側で支える仕組みを知っていることがシンプルにかっこいいと感じたからだ。そして付け加えると、クラウド技術が台頭してきたことでキャリアをブーストできると考えたことも大きな理由の1つだった。
02｜未経験から始まったインフラエンジニア1年目
さて、未経験からITエンジニアに転職した2025年10月。私はSESとして初めて現場へ参画した。最初に感じたことといえば、新鮮さからくる好奇心だった。何もかもがはじめてで、「これから第2のキャリアがスタートするんだ！」と息巻いた。主に自治体の情報システム環境における運用保守を担当し、サーバの監視・ログ確認、問い合わせ対応、アカウント・認証関連の作業、仮想環境上でのLinuxサーバ構築、バックアップ運用など、インフラ運用に関わる幅広い業務を経験した。また、Windows Serverのバージョンアップやセキュリティ製品の移行にも携わった。1年間を通じて、単に手順を実行するだけでなく、障害の切り分けや影響範囲を考えながら対応することの重要性を学んだ。
一番驚いた経験は、やはり専門用語の壁だった。会議中に話している内容がほとんどわからないのだ。まるで留学中のグループトークみたいだった。1年経った今、だいたいこんな話をこんな意味合いで話しているんだろうなというレベルにはなったが、実際に割って入っていけるかといったら難しい。とにかく、転職前から耳にしていたエンジニアの専門用語で会話についていけないあるあるは本当だった。
とにもかくにも、未経験の私は失うものがないのでできるだけ質問に質問を重ねて、最初はあまり業務では特に苦労しなかった（先輩方に感謝）。システムがどう動いているかはわからないが、マニュアルや手順書、先輩が伴奏してくれたおかげでなんとか、業務にも慣れていった。中でも、色々な電話を取りまくった。中には電源が入らないからパソコンが壊れたんだと電話をしてきたお客様がいた。現場にかけつけると、ただ電源ケーブルがコンセントに刺さっていないだけなど、おっかなびっくりな電話もあった。だが、この1年でエラーや不具合対応に対する対応ははやくなっていったと、そこに成長を感じている。
また1年間オンプレの現場で経験を積む中で、少しずつ「運用する側」から「自分で環境を作る側」に興味が移っている自分にも気づいていた。
03｜オンプレの現場で「インフラ」を知る
AWSを初めて強く意識したきっかけは今も覚えている。留学前にITエンジニアについて熱心に調べていた頃、ある動画にAWSパートナー企業の代表がAWSについて話しているのを見たことがきっかけだった。「これだ」と直感的に感じた。留学中の間は、カリキュラムとしてPHPを中心として主に開発プロセスについて学ぶものだった。日々、英語でプログラミングの授業を受けるのはチャレンジングでとても楽しかった。
授業を通して、IT全体に触れる中で、現役のエンジニアたちと話す中で、自分はクラウド・インフラの方向に進みたいと改めて考えるきっかけとなった。カリキュラム修了後、クラウドエンジニアを目指すことを決意し、AWSエンジニアを募集する会社へ応募した。たまたま縁があり、微経験者も採用中とのことで今の企業に合格をもらった。
社内の方と話をして、現在は「まずオンプレのインフラ運用保守で基礎を積む」という名目でオンプレ案件に参画した。とはいえ、クラウドのキャリアを作りたい私は、自己学習でUdemyの学習や社内プロジェクトで立候補をして認証周りを担当させてもらうなどできるだけの行動を起こした。
04｜なぜAWSなのか
留学中、そして今の会社に入社してからも、AWSの学習は続けていた。その中でいくつか変化というか知識の見え方も変わっていることに気がついた。知識0の状態からオンプレ現場で1年経験したからこそ、
「サーバってこういうものなのか」
という実感が少しずつ出てきた。その状態でAWSを学び直したことで、
「あ、オンプレでやっていることが、AWSではこういう形になるのか」
とふんわりしていたイメージが少しずつくっきり片鱗が理解できるようになってきた。
最初はAWSサービスを覚えることから始めた
- EC2
- VPC
- IAM
- S3
- Lambda
- CloudWatch
- RDS
- Route 53
- ELB
- CloudFormation
- CDK
などAWSにはたくさんのサービスとそれらの名前・役割がある。留学中や留学前にもAWSコンソールの無料枠をつかったハンズオン学習はやっていたが、点で何もわからなくてハンズオン学習がなかなか前に進めないいらいらもしていただろう。アカウント設定やコスト管理で少し痛い目にもあった。。。
学習していく中で「サービス」ではなく「構成」を考えるようになったことも大きい。例えば、EC2を知っているではなく、どんなネットワークに配置して、どのような経路で通信し、どの権限を与え、どう監視するのかを考えるようになった。手を実際に動かして、生の現場とAWS学習を比較することで「知識と実践の違い」を肌で感じた良い経験だと捉えている。
05｜自社プロジェクトでAWSを実際に使ってみる
まず自社プロジェクトの背景について話しておく。私が所属している会社はAWSパートナーである。AWSパートナーとして利用できるAWSクレジットを有効活用するため、社内で各々現場に出向いている社員が案を出し、発足した新しいプロジェクトが、社員が自己学習の場ととしてAWS環境を触れる基盤を作る、という目的のプロジェクトだ。
AWS環境を触らせてもらえる機会に飢えていた私はすぐに手を上げて5名体制のメンバーとして参画。当初はAWS・認証基盤領域が未経験に近い状態で、リーダーが即席で作成した構築方針の資料を確認しながら、
- IAM Identity Center
- Microsoft Entra ID
- SAML
- SCIM
- Permission Set
などをキャッチアップしていった。最初にIAM Identity Centerそのものを理解するための検証を実施した。やったこととしては、以下だ。
- IAM Identity Center有効化
- AWSアカウント接続
- ユーザー作成
- Permission Set作成
- AWSアカウントへのAssignment
- PowerUserAccessでのログイン確認
- ReadOnlyAccessとの権限差確認
実際に手を動かしてみることで、Permission Setで権限を定義し、それをAWSアカウントにAssignmentすることで、ユーザーがその権限を使ってAWSへログインできる、という基本的な仕組みを理解していった。
当時はIAM Identity Centerというサービス名を知っている程度で、Permission SetやAssignmentがどういう役割を持っているのかも曖昧だった。しかし、実際にユーザーを作成し、権限を設定し、ログインしてみることで、それぞれの役割が少しずつつながっていった。
IAM Identity Centerの基本的な仕組みが少しずつ分かってきたところで、次に考えたのが「この権限付与を自動化できないか」ということだった。
そこで、AWS Lambdaからboto3を利用してIAM Identity CenterのAPIを呼び出し、ユーザーにPowerUserAccessの権限を自動で付与する検証を始めた。実際にLambdaからcreate_account_assignment()を呼び出し、AWSアカウントへの権限付与を自動化する。これまでコンソール上で手作業として行っていた操作を、プログラムから実行するという初めての経験だった。
最初からうまくいったわけではない。Lambdaを実行すると、AWS APIからAccessDeniedが返ってきた。
ここで初めて、「Lambdaを動かせばAWSの操作ができる」というわけではなく、Lambda自身にもAWS上で何をしてよいのかを決めるIAM権限が必要だと基礎概念を実感した。
06｜1年間で何が変わったのか
1年前の自分と比べて、できることが増えた。サーバの構築やお客様との業務範囲の区分けや責任範囲の理解。資料作成のなかで培った手順に落とすまでの工程など、業務で行った内容はサーバやネットワーク知識以外の部分が成長したように感じる。それに最近気づいたことがある。それは日常的に会話が論理的に理解できて、情報を伝える力と一番今ほしい情報を相手から引き出せるように話す力が、身についたように感じる。これは業務の中でお客様と会話することが多かったことが要因だ。それが、市役所の手続き、引越しの際の手続きなどあらゆる日常での会話がスムーズに、ロスなく行えるようになったし、1回で相手の言っている内容を理解できるキャパが増えたように感じている。
もっと業務的な内容でいくと、エラー解析の手順とフローが身についたこと。エラーが発砲した際にどこからみていくのかを1つ1つみていく心構え？みたいなのが身についたと思う。なんだよそれ、ただのメンタル論でスキルじゃないじゃんと思われるかもしれないが、思った以上にエンジニアにとってこれは大事だと感じている。この心構えがあるかないかで、ミスが減ったり、作業工程が大幅に減らし、結果的にポジティブな影響をもたらしてれると私は信じている。
もう少し具体を話すと、エンジニアとエラーは切っても切り離せないものだと思う。このエラーが示す理由はいつも明確で、何かがシステムで起こっているからエラーが起こっているのだ。当たり前だ。だけど、エラーに直面した際に、「エラー！？どうしよう、、、。治るかな」と毎回、感じているのと、「よし、今度はどんな道筋でエラー解決できるのか楽しみだな」（ちょっとポジティブすぎるか）みたいに考えることができるかで、課題解決に至るまでの手に入れられる情報と時間が格段に違うように思う。まあ、とはいえ毎度エラーがでるのであればそうゆうちょうなことをいっていられないが。
とにかくエラーに対する抵抗感は以前より薄れていて、エラーが出た時に冷静に1つ1つ切り分けてしていくスキルはこれからも重宝するべきだと感じている。
07｜これからどんなエンジニアを目指すのか
世間的な言葉でいえば、市場価値の高いエンジニアになりたいと思う。市場において引くて数多の技術者はやはり食いっぱぐれないだろうから。どう実現するかはこれからの状況次第で変わるが、やることはバスケットボールでも、教員でも、同じだと思っている。誰もやらないような退屈な基礎をどれだけ自分と向き合ってやれるか。小手先のテクニックやスキルは現場や時間と共に身につくと思うが、基礎がしっかりしていることの価値はとても高いと思う。そういう選手は簡単に怪我をしないし、本質的に物事を捉えることができて、時間はかかっても結果的に最短で価値が出せると私は強く感じている。土台、基礎がしっかりしたエンジニアになることがジュニアレベルの私の今するべきことだ。
そして、もう少し踏み込んで、これからはいろんな経験を積みたいと思っている。それがモダンなスキルを必要とするプロジェクトに参画することなのか、リーダー経験を積んでだれかを引っ張る側に回ることなのか、はたまた自分自身でサービスを作って価値を提供する側なのか。今はまだ全くと言っていいほど先が見えていない。今見えているのは、クラウドエンジニアとしての基礎体力をつけて、将来自分でアーキテクトを考えて提案し、課題解決を実行することができるエンジニアになりたい。
コメント