はじめに
長らく資格というものを食わず嫌いしていましたが、エンジニア7年目にして初のエンジニア系の資格試験 (AWS Certified Cloud Practitioner / CLF-C02) を受験しました。
正直、「そろそろSAAくらい持ってなきゃな」という気持ちから踏み台的な感覚で取り組んだものでしたが、思いの外楽しく学習できました。
ある程度AWS以外の領域で経験を積んだエンジニアにとっても十分に意義を感じることができるものだったので、その感想をシェアするために記事を書きました。
実務経験と前提知識
受験を決めたときのステータスは以下のような感じ。
- 30年物の業務パッケージに含まれる一サービスのエンジニア部門で、業務機能とインフラ・CI/CD周りそれぞれの保守・改善を計6年ほど経験
- ソースコード量が100万行単位の巨大サービスだが、サービス全体の共通機構やインフラ、自社の他サービスとの連携部分やCI/CDパイプラインの構成などは大まかには理解できている
- AWSの知識は自社プロダクトに関係あるもの中心。理解が曖昧だったり、名前すら知らないサービスも多い
- 最近会社が契約しているSkill Builderのライセンスをもらい、使ったことがないサービスも少し触り始めた
受験までにやったこと・結果
※既に世の中に情報はごまんとあり、試験の難易度的にも詳説するほどではないので簡単に
本格的に学習を始めたのは受験の1~2週間前で、夕飯後・寝る前など終業後のスキマ時間でひたすらPing-tの問題集を解き、知らない分野の解説を頭に叩き込みました。
仕上げに公式の模試を解いて、「これはいけそう」と感じた夜のうちに翌々日の会場試験を申し込み、サクッと合格 (967/1000) しました。
(思いのほか高スコアだったので受かるだけならもっと雑でもよかったかも)
勉強してよかったこと
普段開発しているプロダクトへの理解と、AWSの幅広いサービスの概念的理解が合わさることで、「自分が扱うプロダクトをどうクラウドネイティブに進化させよう」と考えるフックが劇的に増えるなど、プロダクトへの向き合い方が変わりました。
例えがあまりよくないのですが、雑に挙げると、
プロダクトに「DBのキュー用のテーブルをポーリングしたり、スケジュールをトリガーに処理を実行するデーモン」がある状態でAWSのサービスを学ぶ
⇒「キューはSQSにして、定期実行のトリガーはEventBridgeが使えるな?」などと気づく
のようなアイデアが山ほど浮かびました。
簡単には知っているサービスも以前から多くありましたが、体系的な説明を読み込むことで解像度が全く変わり、出てくるアイデアの量や質が上がっていくのを実感しました。
資格試験などの体系的な学習は、実務経験や他の技術的知見と組み合わせることで、今後の発展に繋がるアイデアを生み出すことに繋がると強く感じました。
なぜCLFなの?実務にはSAAくらい持ってないと足りなくない?
他の記事でも言われている通り、実務でAWSを本格的に活用するには、最低でもSAA相当の知識を持っていたほうが良いとは思います。
一方、CLFではWell-Architectedフレームワークや責任共有モデルといった基本の考え方や、個々のサービス自体に対する知識を問われます。
↑で書いた「今後の発展に繋がるアイデアを生み出す」ことに繋げるには、SAAで出てくるようなより実践的な考え方だけではなく、CLFで問われるような細かい知識に対しても引き出しを増やしておくことが重要なのだと思います。
(ずっと細かいところまで覚えていろとは言わないが、頭の中にSAA単体よりも解像度の高いインデックスを張ることができる)
また、これは知識習得に対する好みの要素もあると思いますが、個人的には「SAAで出てくるようなユースケースに応じたサービスの使い分けのような覚え方からいきなり入る」よりも「CLFくらい薄く広い知識で、一旦実務ベースで思考してみてから、SAAの学習で答え合わせをする」くらいのほうが、より柔軟な考え方を身に着けられる気がして好きだったりします。
冒頭にも書いたように、SAAを受ける踏み台、より正確に言うと「合格者向けの半額バウチャーがあると報奨金の手取りが増えるから」という感じで受けたので、かなり嬉しい誤算でした
結論
- 基礎固めは「基本概念や個々の要素技術に対するインデックスを頭の中に増やす」ことに意義がある
- そのために基礎系の資格を取るのは意外と有用
- 目の前の実務への深い理解と組み合わせて、今後の発展に繋がるアイデアをたくさん生み出して実行していこう