はじめに
こんにちは！スタイル・エッジでバックエンドエンジニアを担当しているtkpと申します。
突然ですが、皆さんは「AWSの資格を取ったが、実務での経験がもっと欲しい…」と感じたことはありませんか？
今回は、そんな方にピッタリのイベント「AWS Jam」に参加してきましたので、その様子をレポートとして皆様にお届けします！
AWS Jamとは、専用に用意されたAWS環境上で、チームで協力しながら様々な課題を解決していくハンズオン形式のイベントです。机上の学習とは違い、実際に手を動かしながらAWSスキルを試せるのが大きな特徴です。 （公式サイト：https://aws.amazon.com/jp/training/digital/aws-jam/)
今回AWS Jamに参加した私のスキルはというと、AWS SAAこそ保有しているものの、実務で日常的に触るのはAmazon EC2やAWS Lambdaなど一部のサービスのみ。Amazon VPCやAmazon S3の利用はありますが、構築や設定の変更などの経験はありませんでした。
だからこそ今回は、実務に活かせる具体的な知識を身に付けることを目標に参加を決めました！
いざ決戦の舞台へ。AWS Jam体験記
当日のイベントの流れ
AWS Jamには、AWS Summitのような公式イベントでの参加や個人開催など様々な形式があります。今回はクラスメソッド株式会社様にご協力いただき、弊社メンバー6名で社内開催のJamに参加しました！ 当日のAWS Jamはざっくりこのような流れで進みました。
| 時間 | 内容 |
|---|---|
| 11:00 ~ 12:00 | 自己紹介、AWS Jamの進め方や取り組むチャレンジの紹介 |
| 12:00 ~ 13:00 | 昼休憩 |
| 13:00 ~ 16:30 | AWS Jamイベント |
| 16:30 ~ 17:30 | クラスメソッド様による課題解説、感想の共有 |
チーム編成
当日はバックエンドエンジニアとSREエンジニアの中から2人1組のペアを3チーム作り参加しました。
私は先輩バックエンドエンジニアとペアを組みました。1年以上一緒に仕事をしたこともあり、相性は全チームの中で一番だったと自負しています（笑）
余談ですが、別のチームとなったSREエンジニアの先輩はさすがの強さを発揮しており、非常に手ごわいライバルでした。
そんな弊社のSREによる、サービスの信頼性向上に関する連載記事も公開中です。ぜひご覧ください！
techblog.styleedge.co.jp
挑戦した課題たち
今回のAWS Jamでは、弊社のマネージャーを含む企画チームがクラスメソッド様と相談しながら課題を選定し、主に業務で関わりが多いWebアプリケーションアーキテクチャ、ロギング、バケット、キューイング、ネットワークに関連する課題が用意されていました！ 全部で9問あり、このうち私たちが挑戦した課題は以下の通りです。
- 課題1：S3バケットでのアクセス制限
- 課題2：SNS、SQS、Lambdaを用いたイベント駆動型アーキテクチャの実装
- 課題3：3層アーキテクチャのエンドツーエンド通信の接続問題の解決
- 課題4：CloudWatch Logsでのマスキング処理
- 課題5：EC2インスタンス起動のトラブルシューティング
- 課題6：SQS、Lambdaの安全な通信の構築
本当はもっと解きたかったのですが、試行錯誤のうちにあっという間に時間が経ってしまいました…。
チームでの奮闘記
それぞれのペアで、AWSのマネジメントコンソールを操作するドライバーと、操作は行わずドライバーに指示を与えるナビゲーターに分かれて進めました！
また、チャレンジ中は各チームの得点状況がリアルタイムで確認できるので、「他のチームに抜かされた…」や「追いついてきた！」など、レースのようなヒリつきを感じました…！
結果と得られた学び
順位
最終結果は、参加した3組中2位でした！1位のチームとは課題一つ分の得点差でした…。
次回は知識と経験を身に付け、優勝を目指します！！
Jamから得られた2つの学び
実際にJamに取り組む中で、実際に手を動かして気づいた学びをご紹介します。
学び1：VPC内リソースとAWSサービスのプライベートな連携
AWSで開発を行う際、セキュリティの観点からLambda関数をプライベートサブネットに配置するケースは少なくありません。その際、当初は実行ロールに適切なIAM権限（例えば sqs:SendMessage）さえ付与すれば、SQSのような他のAWSサービスと通信できると考えていました。
しかしこれでは不十分で、プライベートサブネット内のリソースからVPC外のAWSサービスへアクセスするには、VPCエンドポイントの作成が必要でした。
VPCエンドポイントを利用することで、インターネットを経由せずにサービス間を接続できるというAWSネットワークの基本原則を、実際の挙動を通して深く理解できた瞬間でした。資格の知識として知ってはいましたが、この経験によって「どんなときにVPCエンドポイントが必要なのか」を身をもって理解することができました。
学び2：ネットワークの「繋がり」の重要性
Webアプリケーションの基盤となるネットワーク構成についても、解像度が格段に上がりました。
例えば、外部への通信のためにNATゲートウェイへトラフィックを向けるルートテーブル（0.0.0.0/0）を作成しても、それだけでは機能しません。そのルートテーブルがどのサブネットに適用されるのかを明確に関連付けて初めて、EC2インスタンスなどからの通信が意図した経路を辿ることができます。
ネットワーク関連は設定項目が多く、何をどこに設定すべきか分からなくなりがちですが、実際に手を動かして設定することで、個々のコンポーネントがどのように連携して通信フロー全体を構成しているのかを理解することができました。
イベントの満足度と新たな気づき
技術的なスキルアップはもちろんですが、AWS Jamというイベント形式そのものからも、多くの気づきを得ることができました。
- 実際に手を動かすことはもちろん、ペアで取り組んだためお互いに考えを言語化しながら進めたことで理解が深まった
- 今まで点として理解していた知識を繋ぎ合わせる経験を積むことができた
- 課題解決を通して、素直にエンジニアリングの面白さを感じた
座学も大切ですが、このような実践的な学習方法を今後の自己学習にも取り入れていきたいと思います。
学びを「次」に繋げるために
今回の経験から得た教訓
Jamでの体験を通して、今後の業務に活かせる2つの重要な教訓を得ました。
教訓1：トラブルシューティングの始点はログにある
今回、解決を目指した課題のほとんどは、ログの中に解決へのヒントがありました。例えば、タイムアウトエラーのログは通信経路を、権限エラーのログはIAMポリシーを見直すきっかけを与えてくれました。
エラーに直面すると、つい手当たり次第にトラブルシューティングをしてしまいがちですが、まずはログという「事実」を確認する基本動作こそが、最も確実で早い解決ルートだと改めて痛感しました。
教訓2：効率的な「調査力」もエンジニアの技術スキル
困っていることや分からないことの大半は、すでに世界中の誰かが経験し、解決策を残してくれています。もちろん自分で深く思考することも重要ですが、限られた時間で成果を出すためには、先人の知恵を効率的に探し出す「調査力」が不可欠だと体感しました。
最近では、GeminiのDeep Researchのように、情報収集を強力にサポートしてくれるツールも登場しています。こうしたツールを積極的に活用し、問題解決の速度と質を高めていくスキルも、意識的に磨いていきたいです！
私のネクストステップ
今回のJamでの学びを次に繋げるため、今後の目標を定めました。
まず、エラーと向き合い原因を特定する実践的なトラブルシューティングを通して、知識を「使えるスキル」へと深めることができました。この経験をさらに積むため、今後もJamに積極的に参加していきます！
またそれとは別に、今回のJamでは今まで知らなかった便利なAWSサービスや機能に触れる機会もありました。自分の「技術の引き出し」を増やして、より良い提案ができるようになるため、AWS SAP (AWS Certified Solutions Architect – Professional)の取得も次の大きな目標として挑戦します！
謝辞
今回のAWS Jamは、クラスメソッド株式会社様のご協力のもとで実現しました。
オフィスの提供や課題解説、懇親会のセッティングなど、手厚いサポートのおかげで、私たちはAWS Jamを心から楽しむことができました。
この場を借りて、クラスメソッドの皆様に御礼申し上げます。本当にありがとうございました！
おわりに～一緒に働く仲間を募集中！～
AWS Jamへの参加は、AWSの知識が深まっただけでなく、「チームで課題を解決する楽しさ」を再認識させてくれる素晴らしい体験でした。
スタイル・エッジには、このようにエンジニアが楽しみながら成長できる機会や、互いに刺激し合える文化があります。
今回のレポートで、少しでも私たちの働く環境に興味を持っていただけましたら、ぜひ採用サイトも覗いてみてください。
様々なポジションで新しい仲間をお待ちしています！
recruit.styleedge.co.jp
