見出し画像

ビジネス職でAWS資格9個なので、そろそろコツとか書く!

どもども、Shinshinです。

株式会社Fusicという福岡の会社でAWSのセールス・コンサルティングをしています。海外経験が長く英語も喋れるため、最近はグローバルな事業展開とかも兼任しています。

QiitaでFusicがアドベントカレンダー出すということで、遅からば参加しました。


「Qiitaというプラットフォーム的に何を喋ればいいかな〜?」と色々考えた結果、AWS資格とかいいんじゃないかなと思いました。

AWS資格は現在9個、社内では5番目か6番目くらいだと思います(上位4名は12冠)。

(自己紹介スライド)


クラウド界隈、AWS資格に関心がある方は多いですし、
エンジニア未経験で9個取ってるのは、クラウド業界まだ入れてない未来のクラウドエンジニアや、ビジネス職で技術も覚えていきたい人には刺さるかなーと思うので!

今回は以下のタイトルで話します:


1. そもそもビジネス職なのになんで資格頑張ってんの?

元々自分で理解しないと納得できないタイプの人間なので、「純粋なセールスロールで割り切れる人間じゃない」というのが結論です。

ただエンジニアになりたかったかと言えば答えはNOでした。大学の頃もプログラミングをかじってみたりみたいなことはありましたが、「書く仕事は自分には向かないな〜」とすぐ飽きた記憶があります。

ただ、大学で哲学とかいうよく分からん専攻だったせいか、考えることは好きです。
特に今のポジションだと、技術に没頭はしないけど、お客さんのニーズを聞いてAWSの幅広いテクノロジーを組み合わせながらソリューションを設計できるという点に関して、自分に合った能力の活かし方だと思っています。

そのためには、まずその"幅広いテクノロジー"を理解する必要があり、AWSの資格を取得することにより、それが得られるんじゃないかと思って始めました。


2. 取った資格の順番・難しかった資格ランキング

これまでに取った資格は以下の通りです:

(Databaseとった時に社内に書いた記事から抜粋)

21年4月に新卒でこの会社に入社しましたが、2年目の途中までは案外取得ペースは早くはなかったです。

難しかったランキングで言えば、
1. Advanced Networking(一生受けたくないw)
2. Solutions Architect Pro(一回落ちた)
3. SysOps Administrator(舐めてかかりすぎた)
4. Security
5. Advanced Machine Learning
6. Database
7. Data Analytics
8. Solutions Architect Asso
9. Cloud Practitioner

です。業務経験は当然ないですが、データ分析とかデータベースはそんなに苦戦しません。センスですね。


3. 試験に関する色んなコツ

先ほどの資格取得の経歴の時間軸を見て貰えば分かりますが、資格の半分は2023年に取得しています。

これの要因としては、

3.1 これまで取得した資格の蓄積で解ける問題が増えていく

個人的な感覚だと、資格5,6個取ってれば、残りの資格はそこの知識から応用してノー勉でも一定点数稼げます。

例えば、Advanced Machine Learningなんかは、MLの基礎的な問題が半分、もう半分がData Analyticsっぽい問題で構成されています(イコールではなく類似な問題)。

MLはあまり勉強せずに試験に臨みましたが、Data Analyticsそれなりに無双してたおかげで、ML基礎の問題で多少やらかしても合格まで漕ぎ着けました。

また、「試験感」みたいなものも鍛えられます。

これ言ったらAWSさんに怒られそうですが、AWS試験はつまるところAWSへの忖度だと思っています。
「AWSさん、この問題はこれを正解にしたいんだろ〜、へへっ」ってな感じでAWSの気持ちを忖度しながら回答すると案外合ってたりしてて、この辺はAWS試験を何度も受ける中で鍛えられる技術だと思います。

「忖度」と表現するとネガティブなイメージをもたれますが、考え方を変えると「AWSのベストプラクティスに忠実」であることと同義だと思います。胸張って忖度してください。

3.2 知らぬ間に同期で12冠レースが始まってた

突然こんなSlackがきて、
こうなりましたと

果たして健全な動機なのかとかは別として、競う相手がいることはいつだってありがたいことです。競う相手を見つけましょう。


↓、ここからは他のTipsをサラッと書いていきます:

3.3 生成系AIに頼る

みなさん大好きChatGPT、積極的に活用しましょう。

(普段英語で情報収集してるので、英語ですごめんさい)

最近の試験勉強はもっぱらこんな感じです。問題文も正解も、その解答も全てChatGPTにベタ張りしては、その中でbreakdownして欲しいものを指定しながら対話的に内容を理解していきました。

ただ、GPTに答えを期待するのは危険です。平気で間違った解答をしてきます。

- 問題文はこれです
- 答えはこれです
- その解説はこれです
- その前提を踏まえて、どうして〇〇が〇〇なんですか?

といった感じで、問題・答え・解答を固定した上で、その上で合理的な解答を生成させるようにしましょう。

また、何度か対話的に解説を聞くことで、そのものの輪郭を掴むことができ、より理解に繋がります。この辺は自然言語処理の強みを活かせた勉強法だなーと我ながら思います。

3.4 試験は先に取っておく

「自分を忙しくする」に近いですが、余裕がある時に試験を考え出すじゃ遅いです。余裕があろうがなかろうが思い立ったら試験とってしまっていいと思います。残りは勉強して受かるだけなので。

3.5 Outputしない勉強はクソ

人によって意見が分かれると思いますが、僕は参考書は全く読まないタイプです。「ほー」とか「へー」とかいう感情しか浮かばない勉強法はクソofクソだと思っています。

僕は常に能動的にしか物事を学ばないので、受動的に学ぶコンテンツは排除しています。Skill BuilderなりUdemyで能動的に問題を解いて、ChatGPTと能動的に"なんで"を突き止めていっています。

オススメの方法は、勉強や読書が終わったタイミングで、学習した内容を自分がちゃんと説明できるか独りプレゼンをしてみるといいと思います。

3.6 ロジカルに、でも大胆に!

選択肢に迷った時に中途半端(置きにいくよう)な答えを選ばないのも大切です。

答えに迷って、どれも70-80%の確信に辿りつかないようであれば、直感的に「ひょっとしてこいつじゃね?」と思う答えを選んだ方がいいと思います。

確率論の話なので正しい主張か分からないですが、30%の確率で間違える問題と70%の確率で間違える問題の2択では、どちらを選んでもどのみにリスクヘッジにはならないです。
その場合は、大胆に直感でリスクを取りにいった方が、少なからず試験中と試験後の迷いが消えます。

3.7 粘りすぎない

高い試験料を払っての受験、気持ち的にもがっつく気持ちが無意識に出るものですが、粘りすぎるのも逆効果だと思っています。

僕も苦戦したNetworking以外は基本190分の試験時間の中で、30分 - 1時間くらいは時間を余らせて退室しています。

後半は集中力が散漫しやすく、無駄に見直しに時間を割いて回答を間違えるリスクが高まります。
あえて予め見直し時間を制限することで、限られた見直し時間の中でメリハリをつけて集中して見直しできると思います。

試験ギリギリまで粘って不安なまま試験会場を出るくらいなら、落ちても潔く清々しくでましょう。再試験になったとしても受けるモチベーションが変わると思います。

3.8 キーワードをメモ用紙にマッピング

キーワード(特に知らないコンセプト)が試験に出てきたら、メモ用紙にマッピングしましょう。

メモ用紙に、以下のような形でキーワードをマッピングすることで、見直しの時に、関連問題を見比べることで間接的にその知らない物事の輪郭が掴めて、答えにたどり着けたりします:

Q1: Transit Gateway Attachments
Q2: IPv6 Dual Stack
Q3: EC2 + SQS
Q4: Appliance Mode
Q5: Transit Gateways or VPC Peering
Q6: Interface Endpoint or Gateway Endpoint for SQS

↑の例で言うと、Q1で問われていることが、Q5では前提条件として書かれていたり、Q6で迷った内容も、Q3の答えと照合した時に、整合性が取れたりします。

3.9 継続は力なり

僕の人生のバイブルの1つは、

です。

自戒の念も含まれますが、試験勉強だけやってないで、しっかり日々のアップデートをやってりゃ自ずと試験なんぞ受かってると思います。


4. 資格取得の意義(個人的考察)

まずビジネス側としてメリットとしては、

4.1 試験を通してITの用語を広くカバーできる

もちろん他のIT認定試験の方が広かったり、実際の業務に近い表現が多かったりすると思います。
ただ、僕のポジションで言えば、言うても前提知識はAWSです。

多種多様なお客さんと話すにあたって、そこが分からないと仕事にならないです。僕のビジネススキルの基盤としてAWS資格は有意義だと思います。

4.2 エンジニアリングのBest Practicesを知れる

(1)がお客さんとのコミュニケーションで重要だとしたら、(2)はエンジニアとのコミュニケーションで重要です。
エンジニアリングを売り物にしている会社なので、お客さんには常にベストなエンジニアリングを届ける必要があります。その中で、エンジニアだけじゃなくビジネス側がBest Practicesを知っていることは付加価値になると思っています。

僕は普段の業務で自分で技術調査もしますし、見積もりやアーキレビュー、最近だとエンジニア側から技術的な質問をされるケースも多くなりました。

お客さんのインターフェースがビジネス側の人間な分、エンジニアが出てくるものがお客さんの期待値を下回らないようにする(むしろ上回るようにする)ために、ビジネス側こそ技術に詳しくあれ!!!だと思っています。

そのためには継続的に技術にキャッチアップする必要があり、その1つとしての資格勉強だと思います。


まとめ

いかがでしたでしょうか?エンジニア未経験ビズ側で資格バンバン取ってる例は多分多くないので、是非参考にしてもらえればと思います。

より具体に内容聞きたい!カジュアルにお話ししたい!とうとうあれば、

からお声がけいただければと!ではでは。