はじめに
こんにちは。普段は主にScala/TSを使い、meviyの切削サービスのWebアプリケーションの開発をしている大﨑です。
私が業務でAWSを使い始めてから、気づけば8年弱ほどの月日が経っていました。日々の業務ではECSやLambda、S3、DynamoDBといったサービスをよく利用し、自分はそれなりにAWSを知っている方だと思っていました。
しかし、ある時ふと「自分の知識は担当領域に偏った点でしかなく、VPCやIAMなど基盤部分や全体像を俯瞰するAWSの基本的な知識が抜け落ちているのではないか？」と思いました。
この記事では、長年AWSを使ってきたエンジニアが、自分の知識の偏りに気づき、体系的な学び直しとして「AWS認定ソリューションアーキテクト – アソシエイト（SAA-C03）」に挑戦した体験をまとめています。
特に、以下のような方に読んでいただけると嬉しいです。
- 同様にAWSを長年利用していて、このような心当たりのあるエンジニア
- 「今更SAAなんて…」と思っているが、体系的な学び直しに興味がある方
学習開始前のスキル
まず、学習開始前の私のスキルセットを率直に書き出してみます。
主に使ってきたサービス
Webアプリケーション開発者として、日常的に以下のサービス群には触れたことがあり、ある程度の知識と経験がありました。
- コンピューティング: ECS, EC2, Lambda
- API・フロントエンド: ELB(ALB), API Gateway
- ストレージ・DB: S3, DynamoDB, RDS
- ログ: CloudWatch
馴染みの薄かった/意識してこなかった分野
一方で、インフラの根幹をなす部分や、自分の経験外の領域については、ほとんど知識がありませんでした。
例えば、ネットワーキング分野では、VPCのサブネットやルーティング、Direct Connect、Transit Gateway、セキュリティグループ、ネットワークACLなどの詳細については概念的には知っているものの、これまであまり細かく意識してきませんでした。
他にも、組織統制やガバナンスの観点、データ分析やストリーミング基盤のサービスについても、ほとんど触れてこなかったため、知識が浅い状態でした。
そしてEC2のような馴染みのあるサービスであっても、Placement GroupやElastic Fabric Adapter（EFA）などの応用的な機能には業務上触れる機会がありませんでした。
通常のWebアプリケーション開発ではあまり意識する機会の少ない部分ではありますが、これらの分野の知識が抜け落ちていることに改めて気付かされました。
まとめると、特に以下の分野の知識が不足していました。
- ネットワーキング： VPCの応用（ルーティング詳細、Transit Gateway等）、Direct Connect, Route53などなど・・・
- 組織統制： AWS Organizations, Control Tower, IAMのポリシー設計
- データ分析基盤： Kinesis Family, Glue, EMRなど
- 既存サービスの応用機能： EC2のPlacement Group, EFAなど
このギャップを埋めることこそが、今回の最大の課題でした。
学習戦略
AWS経験者として、闇雲に全範囲を学ぶのは非効率だと考え、まず「知識の穴（弱点）」を正確に特定し、そこを集中学習するスタイルを取りました。学習には主にPing-tのWeb問題集を利用しました。
【第一段階：部品知識のインプット】
[Ping-t 分野別問題] → [各分野全問正解] → [全サービスの仕様をインプット]
↓
【第二段階：アーキテクチャ思考の養成】
[Ping-t 模擬試験モード] → [正答率9割以上] → [合格レベル到達！]
第一段階 サービス単位の「部品知識」を完璧にする
この段階では、まず各サービスが「何をできるのか」を一つひとつ正確に理解することを重視しました。Ping-tの分野別問題を活用し、各分野で満点が取れるまで繰り返し演習を行いました。特にVPCやIAM、Kinesisなど、これまであまり触れてこなかった分野については重点的に取り組みました。
サービス同士の連携や全体像は一旦脇に置き、それぞれのサービスの特徴や仕様、できること・できないことを「部品スペック」として徹底的にインプットすることに専念したフェーズです。
第二段階 アーキテクチャ思考を鍛える「総合演習」
第二段階では、個々のサービス知識を組み合わせて、実際の要件（コスト、可用性、パフォーマンスなど）に応じた最適なシステム設計力を養うことを重視しました。具体的には、Ping-tの「模擬試験モード」や、Well-Architected Frameworkの観点で作られた総合演習問題に取り組みました。
このフェーズでは、単なる知識の暗記ではなく、実際のアーキテクチャ設計に必要な「総合力」を問われるため、より実践的な思考が求められます。
ここで私は本番と同数の総合演習問題をランダム出題する総合演習を2回実施し、どちらも正答率95%前後、解答時間も1回40分程度で終えられるようになりました。この段階で、合格に必要な知識とスピードがしっかり身についたと実感しつつありました。
三日坊主にならないための工夫
学習を継続するためには、具体的なKPIを設定することが重要だと感じました。はじめ私は「1日5問以上Ping-tの問題を解く」といったようなシンプルな目標を立てましたが、これは状況に応じて柔軟に調整しました。
学習初期は、まず習慣化を優先し、負担を減らすために「5問」からスタートしました。試験日が近づき、必要な学習量が見えてきた段階で「15問」に増やすなど、目標を動的に変えていきました。
また、時間の確保も工夫しました。平日は出勤前と夜寝る前の時間を学習に充て、休日は日中にまとまった時間を確保して、平日に達成できなかった分のキャッチアップや追加の問題演習に取り組みました。1日に30問以上解くような日もありましたが、そういう日は特に集中して学習できたと感じています。
息抜きとして土日のどちらかは平日と同じペースに抑える、休日に模擬試験をやってみるなど、メリハリをつけることも意識していました。
学習中に心がけたこと
学習自体は3〜4ヶ月程度かけてじっくり取り組みましたが、その中で特に効果的だったと感じたポイントを3つ挙げてみます。
1. AIアシスタントを使い、「なぜ？」を徹底的に深掘りする
今回の学習で最も効果的だったのが、Ping-tに搭載されているAIアシスタント機能の活用です。
活用方法には、大きく2つの使い方がありました。1つめは「理解の確認」です。正解の解説を読んでも納得できない場合に、「この回答が正しいのは、〇〇という理由だからですか？」と自分の言葉で解釈した内容をAIに投げかけ、認識のズレがないかを対話しながら確認しました。これを繰り返すことで、曖昧だった部分がクリアになり、理由づけとセットでインプットすることで理解が深まりました。
2つめは「記憶の定着」です。例えば、「なぜそのAWSサービスは、そういう名前になったのか？」とAIに質問してみることで、サービス名の由来や設計思想、技術的な背景を知ることができました。「なぜ 'Elastic Beanstalk' という名前なのか」「EFAは何の略か」といった問いを通じて、専門用語がストーリーと結びつき連想できるようになることで、記憶に残りやすくなりました。こうした使い方によって、単なる暗記ではなく、より効率的に知識を自分の中に定着させることができたと感じています。
2. なんとか毎日問題と向き合う
毎日最低◯問解く、という目標を設定したのは、少しずつでも問題を解き進めていって、習慣づけをすることで、全くやめてしまう、という状況に陥ることを回避しました。
1問も解かない日が続くと、学習のモチベーションが下がり、再開するのが億劫になってしまうことがあるからです。逆に、毎日少しずつでも問題を解いていれば、学習のリズムができて、継続しやすくなります。また、日によっては気分が乗って多く解けるような日も出てきて、そういう日には目標を上回るペースで進めることもできました。
特に初期段階は、学習の習慣化が最も重要だと感じていたので、無理のない範囲で毎日問題と向き合うことを心がけました。数問解いてじっくり解説を読み込んだりしようとすると、どうしても時間がかかってしまって焦る気持ちもありますので、少しずつでも前に進むことを優先していました。慣れてくると、自然と学習のペースも上がっていきました。
3. 受験日を決めてしまう
ある程度学習が進んできて、分野別問題や総合演習問題を一周したような段階で、受験日を1ヶ月後、などに決めて申し込んでしまうのも効果的でした。受験日が決まると、そこに向けて逆算して1日◯問といった学習計画を立てやすくなりますし、モチベーションも高まります。 今のペースで間に合うかどうかは毎週確認しながら、必要に応じて学習量を増やすなどの調整もしやすいです。
4. 学習する範囲を絞る
AppRunnerといった比較的新しいサービスなどを学習対象から外すなど、「割り切る」戦略も有効でした。Ping-tなどの学習サービスで扱われていない分野は、基本的に本番でも出題されないと考えて問題ないと思います。ただし便利なサービスもあるので、興味があれば学習の過程でそういったサービスについても軽く触れてみるのも良いかもしれません。
いよいよ試験本番
試験本番では、これまで自分が弱点だと感じていたVPC間の接続パターンや、Organizationsを活用したマルチアカウント戦略など、普段の業務では意識しづらかった分野がやはりよく問われました。
一方で、LambdaやECSといった馴染みのある分野も、単なる機能知識だけでなく「どのようにVPC内のリソースと安全に連携させるか」「他に制約がある時にはどう対応するか」といった、より広いアーキテクチャ設計力が試される内容が多かった印象です。
Ping-tで繰り返し学習した知識は本番でも非常に役立ち、「まったく知らない」と感じた問題はごくわずかでした。仮に数問落としても、十分に合格ラインに到達できている手応えがありました。
模擬試験では1周40分ほどで解けていたものの、本番では緊張もあり、問題文を慎重に読み進めた結果、約100分かかりました（試験時間は130分）。本番特有の空気感もあるので、余裕を持った時間配分が大切だと感じました。
なお、本番中にはわからない問題にフラグをつけて後で見直すこともできるので、わからない問題に時間をかけすぎないようにするのもポイントです。わからない問題は一旦飛ばして、最後に見直すといったやり方も有効です。
試験の結果としては、9割を上回るスコアで合格することができました。
まとめ：なぜ8年目の今、SAAを受ける価値があったのか
今回、SAAの学習を通して得られた最大の収穫は、実務で身につけたサービスごとの「点の知識」が、AWS全体のアーキテクチャという「体系的な知識の面」へと進化したことでした。
そして何より、学んだ知識は日々の業務にも役立っています。サービスの設計や改善を考える際に、「他の構成やサービスを使えばもっと良くできるかもしれない」といった視点が自然と持てるようになりました。これは、以前よりも幅広い選択肢を意識できるようになったことの表れだと感じています。今後の技術選定や設計において、より広い選択肢と深い洞察を持って臨めるようになったと実感しています。
もし、かつての私と同じように長年の経験の中で知識の偏りを感じている方がいれば、ぜひ知識の棚卸しと体系化、そして日々の業務をより良くするための「新しい視点」を得るために、SAAの学習と受験に挑戦してみてはいかがでしょうか。
