この記事が書くこと
- 「AWSエンジニア」ってなんぞ？
- 「AWSエンジニア」ってどういう需要？
- 資格取得とは別の武器について
読んで欲しい人
- インフラ、AWSエンジニアを目指して就職、転職活動をしている方
- 上記関連資格の取得やそれに向けた勉強を行っているが、ぶっちゃけあんまり上手くいってない方
- いざAWSエンジニアで求人してる会社に入ってみたら「何か違った」という経験をお持ちの方
1.「AWSエンジニア」とは？
日頃からTwitter(X)を覗いていると、AWSエンジニアなるものになるために、AWS関連の資格を取得し、就職もしくは転職活動に励んでいる方をよく目にします。
もちろん資格取得に向かって勉強し、実践に備えることは有益なことであるというのは、おそらく多くの人が納得するところです。
しかし、私が気になっているのは、求人にも掲載されてる「AWSエンジニア」という職種は、具体的にどのような業務をすることになるのだろうかということです。
ご存知のように「AWS」は大手クラウドプロバイダー及びそれが提供するサービスの総称です。
「バックエンドエンジニア」→主にバックエンドの開発領域を担うエンジニア
「フロントエンドエンジニア」→主にフロントエンドの開発領域を担うエンジニア
「インフラエンジニア」→インフラの構築・運用・改善等の業務を担うエンジニア
「AWSエンジニア」→AWSの開発をするエンジニア？
わかっています。おそらく最後のエンジニアは、「AWSを扱う」という意味合いで使われているのだと思います。ただ例えばDockerは、AWS同様現代の開発現場にはなくてはならない技術ですが、いまだ「Dockerエンジニア」という求人は見たことがありません。
またAWS同様、大手クラウドプロパイダーのGoogleやMicrosoftが提供するクラウドプラットフォームの名前を冠したエンジニアはあまり見かけません。なぜでしょうか。
2.「AWSエンジニア」が求められるわけ(採用側)
2.1.「AWSエンジニア」がやる仕事とは？
私は普段、主な業務としてはバックエンドの開発やインフラ構築・運用を担っています。
また、弊社はまだ比較的小規模な組織で、採用基準等は我々エンジニアが話し合って決めたりしています。ですから、あくまでこれから話す「採用側の意見」は、そうした採用について考える機会のある1エンジニアの意見に過ぎませんし、またそれは所属組織を代表するものでもありません。
まず、私が所属する会社では「AWS」を普段の業務で使用していますが、求人の使用技術の欄に書くことはあれど「AWSエンジニア」として求人を行うことはありません。(多分)
理由としては「考えたことがなかった」というのが正直なところです。また「AWS」といっても、そのサービス内容は豊富で、マイクロサービスアーキテクチャを基盤とする時には、アプリケーションロジックをAWS Lambda上で動かしますし、ETL要件にはAthenaやGlueを使う事もありますし、CloudFront,ALBを使用してインフラの冗長化を図る事もあります。
このようにAWSサービスを様々な用途で使用するものの「AWSエンジニア」として応募してくださった方を採用した際に、実際にその方の担当する業務が、その方のやりたいことに本当にマッチするのか不安ではあります。
また「AWS触れればなんでもいいです」な人よりかは、そういったものは技術スタックを見るなり、面談なりで判断していただき(実際その方の希望次第で、AWSを使ったサービス開発やインフラ構築・運用ができる環境ではあります)、事業内容を見てくれたり、そのような技術を使って「何をしたいか」がぼんやりとでもある方と一緒に働きたいと思っています。
上記のような採用方針がある場合「AWSエンジニア」として求人を出すことにあまり旨味を感じないですが、もしこうした形の求人を行うとしたら、どのようなメリットがあるかを考えてみます。
2.2.「AWSエンジニア」として採用活動を行うケース
一つは、ビジネスとして「何をしたいか」にはあまり関わらず「AWSというサービス自体をたくさん触っていき、知識を深めたい」という方を採用したい場合です。実際にAWSを中心とした技術的なコンサルティングを行っているような企業様は、このような「AWSエンジニア」という枠で採用活動をおこなっているところもありました。確かにそうした技術コンサルを行う企業様は、AWSに関する知識などがあるに越したことはないので、そもそもAWSそのものに関して興味があるか、もしくはすでにある程度詳しい人を求めるのには合理性があると思います。
次にあり得るのは、AWSを使用するしないにあまり関わらず「一定程度学習意欲のある方を採用したいケース」でしょうか。「AWSエンジニア」として求人を出すことである程度興味を持ってくださる層がいると見込める場合、こうした採用形態をとることもあるかもしれません。ただ本稿が指摘するように「AWSエンジニア」の業務内容は多様なため、面接を重ねる過程で業務内容に関するある程度の合意が取れていないと、後々ミスマッチが生じるケースもあるかもしれません。
3.「AWSエンジニア」を目指すわけ(求職者側)
3.1.自分語り
求職者側はどのようなことを考えて「AWSエンジニア」を目指すのでしょうか。完全に主観になってしまって恐縮ですが、私が就活時代になぜ「AWSエンジニア」という求人を見て就職活動を行わなかったのかという経験ベースで書きます。
端的にいえば、バックエンド側の開発ができるということを念頭に置いていたので、その中でAWSを使おうが使わまいが、あまり気にしていなかったというのはあります。ちなみに、個人でEC2×RDSさらにCode系サービスを使ってインフラ構築するみたいなことは経験していましたが、その時はそれ自体にあまり面白さは見出せませんでした。
ただ一つの観点として、自分の志望する会社が技術スタックとして「必要があればAWSなどクラウドサービスを柔軟に採用できる組織であるか」というのは見ていました。
3.2.「フルスタックエンジニア」に近しい何か
自分が就活していたのは約2年前です。そもそも「AWSエンジニア」という募集形態そのものをあまり見ない気もしましたが「フルスタックエンジニア」というのは流行っていたなと思います。今も流行っているかもしれません。その時は確かに「どんな分野でも対応できて強そう」とか思っていましたが、今考えれば様々な業務に当たって、必要な技術を学び結果として「フルスタックのようになる」のであって、最初から目指すのはちょっとおかしかったなと思います。
もちろん様々なことに柔軟に対応できるエンジニアはかっこいいですし、自分も就活当初「フルスタックエンジニア」という中身が曖昧なものにゆくゆくはなりたいなと思っていました。ただ自分の場合いきなり「フルスタックエンジニアになりたい」ではなく、まずは「バックエンドの開発を主軸に取り組みつつ」ゆくゆくは「様々な領域で活躍できるエンジニアになりたい」と考えていました。こうした軸としてやりたいことがあったおかげで、まずは最低限自分の掲げたやりたいことができるかどうかで判断できたのはよかったなと思っています。
今こうして振り返ると「フルスタックエンジニア」は、特にやりたいことが決まっていないけれど、何となく「潰しが効きそう」という感覚に基づいて、使われていた(いる)言葉だったのかもしれません。
3.3.自分が「AWSエンジニア」を目指すとしたら
結果として、入社して様々なAWSサービスを使用することになったわけですが、確かに要件に基づいて使用するAWSサービスを選定し、実際にインフラ構築等おこなっていく過程は楽しいです。ただAWS自体を触るのが楽しいというよりかは「実際に要件に基づいてああでもないこうでもないと考えたり、実際に各種サービスを上手に使いこなし、仕事をうまく進めることが楽しい」という方が正確かもしれません。ここで一つ思うのは、こういう楽しさは実際に設計構築を体験してみて、初めて感じることができるものだなと思っています。したがって、触っていないうちから「AWSを扱うエンジニアになりたい」という動機が出るのは、自分の感覚からすると結構不思議なのですが、おそらくそれは前項で言ったように、とにかく様々なサービスを知っておいて「潰しを効かせたい」という思いがあったりするのではないでしょうか。
以上述べたように自分の場合、いきなり「AWSエンジニアになりたい」という思いを持つことは考えにくいですが、興味を持って調べたり使ったりするサービスがある中で、それを使用する機会がある業務に携わりたいと考えていた可能性はあるなと思いました。 「CloudWatch好きなんですけど、御社でメトリクス見たりするのに使ってたり、もしくは使わせてもらえる機会って言えば作ってもらえますか？」とか聞いていたかもしれません。
あと一口に「AWSサービスを使っています」と言っても、実際に一から構築する機会があるのか、そもそも既存のものを改善する業務なのか等も入社した後やりたいことができるかの指標になってきます。もちろん「構築したい」と言いつつ、構築しようとした経験がないと「本当に？」となるので、ちゃんと触りながら就活すると思います。
4.納得のいく企業選びをするために多分重要な考え方と戦略
4.1.やっぱり「何をしたいか」は大事
やはり自分の軸を見つける上で「面白い」「好き」「興味ある」という感覚があったことは、すごく良かったなと思います。
個人的には「AWSの認定資格取得に向けてとりあえず勉強しています」という方も一定程度魅力的ですが「このサービスについて気になったんで、調べてみたり使ってみたりしてるんですけど、こんな使い方とかしてるんですか？」など積極的に聞いてきてくれる方にはより「この人入ってきてから活躍してくれそう」といういわゆる「即戦力感」が漂う気はしています。また、そうした「自分の軸を持つこと」は、採用者側への印象を良くするだけでなく、自分自身が納得のいく企業選びをするための選択肢拡大に十分に役立つと考えています。なぜなら潰しが効くから「AWSエンジニア」という肩書きにこだわって就職活動をしていた方は、自分の軸がぶれていたことで、かえって自らの選択肢を狭めてしまっていましたが、別に自分が望む経験をできるなら、それが「インフラエンジニア」と呼ばれていようが、ただの「エンジニア」と呼ばれていようがどうでもいいわけです。
4.2.意外と穴場なんじゃないかと思う企業の性質
特にどんどんインフラの構築経験積みたいみたいな人は、小中規模の会社で、受託なり自社なりで複数案件持ってる、もしくは定期的に新規案件が入ってくる会社は狙い目だと思います。まず、新規案件が入ってくるというのは、それだけ手を挙げて任せてもらえる機会があるということですし、小中規模の会社はアプリケーションエンジニアこそいるけど、インフラに関しては大体決まった人がやってるみたいなケースは、多いのではないでしょうか。(違ったらごめんなさい。)
ですから、面接時に入社後のチャンスの数として「どれだけ新規案件が入ってくるか」と「インフラを触るエンジニアが現状どれだけいるか」を聞いてみるといいかもしれません。
4.3.さらに「即戦力感」を出すためには
実際に最近の開発現場ではどのようにインフラ構築・管理・運用しているかを知るといいと思います。
古くからシステムを持っている組織は、なかなかそうはいかないケースもあると思いますが、これから新しくシステムを組むとなって、インフラ構築のほとんど全てをAWSのマネコンから設定するような所は、段々と減ってきているのではないでしょうか。ある程度規模が大きくて、インフラでチーム持っている会社はTerraform、そうでない会社も最近イケイケのAWS CDKを使ってコードベースでインフラ構成管理をし始めていると思います。こうした現場で実際に使用されている技術を理解して、さらに自分で触ってみた経験があると「即戦力感」マシマシです。ちなみにうちはインフラとしてチームを持っていないこともあり、基本CDKで管理しています。メンバーは基本アプリケーションエンジニアがバックグラウンドなので、そういう意味でも親和性が高いんですよね。
5.新たな武器を携えて
5.1.IaC意外と理解できる
とはいえ、IaC(Infrastructure as Code)の考え方とかなんか難しそうだし…
わかります。でも意外とそんなことないです。むしろAWSやインフラに関して様々なことを勉強している人にこそ、学んで感動してほしいです。書き方をちょっと覚えるだけで、自分が作りたいインフラをささっと構築できます。お片付けも楽ちんで時短にもなります。そして、その少し違った方向の努力で、採用現場で「即戦力」として振る舞えるようになっていただきたいです。AWSの資格試験に向けて努力して学習できるのはかなりすごいことだと個人的に思うので、あとはその知識を活かす場所を用意できれば、より実りある就職活動につながるのではないでしょうか。
なので、簡単にではありますが、この記事でおすすめのCDKの学習順序を紹介させてください。(Terraformは使ってないのであんまりわかりません。ごめんなさい。)
5.2.CDKおすすめの学習順序
STEP1 概念を知る
まずはIaCやCDKそのものの概念について学びましょう。AWSではAWS Blackbeltという動画形式で各種サービスの解説をしてくれる学習媒体があります。CDKに関してもシリーズ化されているので、まずはその動画をご視聴いただきたいです。このシリーズは全部で三回で、おそらく一回見ただけではよくわからないと思うので、ハンズオンを触った後など繰り返し視聴するようにしてください。
STEP2 実際にTypeScriptを学習し、ハンズオン形式でサーバレスの構成を組んでみる
何となくのコンセプトを掴んだ後に、実際に実践に移っていきます。CDKを書くために必要なTypeScriptの記法を学びつつ、AWSが用意したworkshopを用いて実際にサーバレスアプリケーションをAWS環境にデプロイしていきます。
STEP3 より実務的な構成を作る
AWSはBLEA(baseline-environment-on-aws)というアーキテクチャテンプレートを公開しています。
これは、EC2,ECS,サーバレスサービス等を使用した一般的なアーキテクチャのユースケースに関して、AWSがガイドラインを用意してくれているものになります。実務でもまずこの構成を参考に、そこに様々な必要となるサービスを加えることが多く、非常に勉強になるものです。
今後、この構成を参考に私が作成したハンズオンを公開することを予定しています。ぜひ上記ハンズオン等行ったあとに、取り組んでいただけると幸いです。
6.最後に
実は本稿を書いたきっかけの一つは、自分自身が様々な学習体験をしてきて失敗もしてきた中で「こういうことに早くから気づけたらよかったな」と思ったことがある、というのがあります。自分の場合、幸い現状満足いく環境で働くことができていますが、運の要素も多分にあると思っていて、そうでなかった未来も全然ありえたわけです。
やはり、自分の転機になったのは「自分がやってきた範囲で気持ちよく努力をする」というのは意外と多くの人ができることだったりして、そこより一歩「このままでいいのかな？」と自らに問い、そもそもの目的や自分の気持ちと真っ向から向き合った上で必要なら軌道修正することの重要性に気づいたことな気がしています。
本稿が、自分のキャリアに悩む皆様にとって、働きたい姿ややりたい業務についてもう一度考えるきっかけになれば幸いです。
風邪等まだまだ流行っておりますので、てうが(手洗いうがい)しっかりして楽しく健康にエンジニアしていきましょう。