こんにちは。れいです。
AWSエンジニアを目指していますが、転職後にどのような経験ができるか知りたいです。
こういった疑問に答えます。
本記事の内容
- AWS未経験の私が1年間ベンチャーで働いて経験したこと
本記事の信頼性
- AWS関連の資格を5つ取得済(CLF/SAA/SOA/DVA/SAP)
- AWSをコア技術とするベンチャー企業でエンジニアとして働いている(2年目)
ちなみに、それぞれの資格の勉強方法については以下にまとめているので、気になる方はどうぞです。
本記事の想定読者
- AWSエンジニアを目指している方
- AWSエンジニアとしてのキャリアパスを知りたい方
AWS未経験の私が1年間ベンチャーで働いて経験したこと
前提として、私は1度転職を経験しています。
AWS関連のスキル状態は以下のような感じです。
- 転職前：AWS未経験
- 転職後：AWSを経験
今回は以下フェーズで私がAWS関連で経験したことを共有します。
それぞれ解説します。
- 転職前
- 転職後 1年目
- 転職後 2年目
転職前
転職前は主に以下を行いました。それぞれ解説します。
- アソシエイトレベルの資格取得
- 既存プロジェクトの設計書読込
- 仮想プロジェクトでAWS設計・構築実施
アソシエイトレベルの資格取得
以下理由でまずはAWS関連の資格のうち、アソシエイトレベルまで取得しました。
- 転職前はAWSの知識が全くなかったため
- 転職前は前職の仕事が落ち着いており、時間に余裕があったため
- 資格取得により、努力ができる人財だと評価してもらえると思ったため
具体的には、CLF,SAA,SOA,DVAまで取得しました。
ただ、資格取得を目的としていたこと、それぞれのサービスを実際に使ったことがなかったことから、理解は深まらなかった印象です。
私の場合は、転職先に事前に評価してもらいたいと考えていたこともあり、一定の目的は達成できたかなと考えています。
既存プロジェクトの設計書読込
次に、既存プロジェクトの設計書の読込を行いました。
これにより、どのサービスをよく使うのかを理解することができました。
しかし、実際に自分で構築したわけではないので、ここでもそれぞれのサービスに関して理解が深まらなかった印象です。
仮想プロジェクトでAWS設計・構築実施
次に、既存プロジェクトを参考に、仮想プロジェクトでAWS設計・構築を行いました。
この作業を通じて、エラーと戦いながら実際にAWS設計・構築を経験でき、触ったサービスに関して理解が深まりました。
この経験から、自分で考えて設計し、エラーと向き合いながらガチャガチャ構築する作業をしないと自分の血肉にならないと感じました。
これからAWSをコアとするエンジニアになりたい人は、この意識を常に持っておくと良いと思います。
転職後 1年目
実際に転職先に入社してからは、大きく以下のことを行いました。
それぞれ解説します。
- プロフェッショナルレベルの資格取得
- 既存システムのAWS移行経験
- AWSシステムの運用保守・設計・構築
プロフェッショナルレベルの資格取得
会社の上司からは「プロフェッショナルレベルの資格は急いで取る必要はない」と言われていましたが、以下理由でプロフェッショナルレベルの資格取得を決めました。
- 本資格取得により会社から奨励金をもらえるため
- プロフェッショナルレベルを取得し、資格の勉強から手離れしたいと思ったため
- 周りでプロフェッショナルレベルを取得してる人がいなく、差別化になると考えたため
ただ、実際に勉強してみるとアソシエイトレベルと比べて段違いに難しかったです。
幸いにもベンチャーに転職後は暇すぎず忙しすぎずという感じだったので、本資格の勉強にそれなりに時間を充てることができました。
最終的には、以下の記事でも書いているとおり、2ヶ月ほどでSAPを取得することができました。
既存システムのAWS移行経験
最初に携わったプロジェクトで既存システムのAWS移行を経験しました。
最初のプロジェクトとしては貴重で良い経験だったと思います。
本プロジェクトを通じて、以下を学ぶことができました。
- 他システムからAWSに移行する上での考慮ポイント
- VPCやEC2やRoute 53などのAWSの基本サービス
AWSシステムの運用保守・設計・構築
上記で記載したプロジェクトとは別にいくつかプロジェクトを行なっていました。
それらを通じて、以下を経験しました。
- AWSを用いたシステムの運用保守
- AWSを用いたシステムの改善及びそれに伴うAWS設計・構築
- LambdaやDynamoDBなどを用いたサーバレスシステムの設計・構築
TwitterなどのSNSをみていると運用保守に関してネガティブな意見がありますが、運用保守を経験しないとシステム検討時に運用保守観点の考慮ができないと思うので、経験はしておいた方が良いと思います。
ただ、運用保守ばかりだとAWS関連の知見が全く伸びないので、その点は注意が必要です。
私の場合はベンチャー企業ということもあり、1人で色々携わらないといけないため、様々な工程やAWS関連のサービスに触れることができました。
AWS関連の知見を伸ばしたい人は、ベンチャー企業への転職を狙うのが良さそうです。
私が大手からベンチャーに転職した経緯に関しては以下記事でまとめていますので、気になる方はどうぞです。
転職後 2年目
転職して現在2年目ですが、今は以下のようなことに携わっています。
それぞれ順番に解説します。
- 新構成のAWSシステム設計・構築
- 新規案件の工数見立て
- 新技術のR&D
新構成のAWSシステム設計・構築
転職後1年目は既存プロジェクトの構成をベースに、AWSシステム設計・構築をすることが多かったです。
今は担当領域が広がり、新構成のAWSシステム設計・構築も担当しています。
新構成といえど、過去の知見を最大限生かしつつ、新しいトピックは調べて構成を検討するイメージです。
このレベルになると、AWSに関して自分の知見が伸びた感じがするので、自信がついてきます。
新規案件の工数見立て
次に、工数や費用の見立ても行なっています。
具体的には、「AWSを用いた新システムを構築したい」という依頼に対して、要求をもとに大枠の構成を考えて、必要工数や費用を見立てています。
これまで工数や費用見立てを実施したことがなかったですが、過去先輩が実施した内容を参考に対応しています。
こういうタスクを経験すると自分でプロジェクトをまわせている感覚になり、さらに自分に自信がつきます。
新技術のR&D
新構成のAWSシステムの設計・構築や新規案件の工数見立てを行うにあたって、新技術を扱う場合があり、そのR&Dを行うこともあります。
正直、以下理由でこのタスクが1番好きです。
- 技術的な知見を伸ばすことができるから
- 新しい技術に触れることができて楽しいから
- 仕事中の時間を使って学ぶことができるから
周りから信頼を勝ち取ることで、このようなおいしいタスクを経験できます。
目の前のタスクを確実にこなして信頼を獲得しつつ、おいしいタスクがあれば手をあげるのが良さそうです。
まとめ
今回は、AWS未経験の私が1年間ベンチャーで働いて経験したことをまとめました。
AWSは会社によってはなかなかタッチさせてもらえないことが多いです。
しかし、1人が様々な領域を担当することが多いことから、ベンチャー企業であれば割と経験できます。
AWSをコアとしたエンジニアになりたい人はベンチャーのような小規模な企業に転職しましょう。
私がベンチャーに転職した時の経験談は以下にまとめているので、気になる方はどうぞです。
