参加者から発表者へ　日本 CTO 協会新卒合同研修で登壇してきました

みなさん、こんにちは。プラットフォームグループの木山です。業務では Synergy!の AWS 基盤やメールサーバーの運用を行っています。

私が昨年参加者として学びを得た「日本 CTO 協会の新卒合同研修」に、今年は発表者として登壇しました。本記事では、登壇までの流れやその過程で得た学びについてお伝えします。特に、これから発表の機会に挑戦しようとしている若手エンジニアのご参考になれば幸いです。

登壇のきっかけ

今年の 2 月ごろに日本 CTO 協会の 24 卒研修で知り合ったメンバーで勉強会がありました。そこで発表していた株式会社アンチパターンに所属する同じ 24 卒の穴田さんから、日本 CTO 協会 25 卒向け合同研修の AWS 回で一緒にカリキュラムを作成し、発表しないかというお話がありました。日本 CTO 協会の研修や勉強会に参加する中で、自分も発表者として参加したいという気持ちがあったためすぐに参加の旨を伝えました。

テーマ選定

AWS の社員の方と背景やカリキュラムのゴールの認識をすり合わせるため、数回にわたって MTG を行いました。背景としては、今年の研修において、AWS ではAWS JumpStart イベントの内容を研修内容として提供する予定があり、それだけでは物足りない方向けに、より高度な内容のコンテンツを提供したいというものでした。主な要望としては以下です。

オフライン形式で 1.5 時間の研修を企画したい
ハンズオンにするか、講義形式にするかは自由に決めていい
研修を交流の場として活用し、24 卒と 25 卒で情報交換や刺激し合うことを期待している
社会人として 1 年間業務を経験する中で、どのような知識が役に立ったかを盛り込んでくれるとより良い

カリキュラムテーマの選定にあたっては、これらの背景、昨年参加した自身の経験、そして以下の項目について穴田さんと話し合い作成していきました。

様々なバックグラウンドを持つ新卒の方が参加するため、特定のテーマに絞りこみすぎると、研修内だけの学びで完結してしまい、その後の学習に結びつきにくい
今年の研修でもISUCONがあるため、それを共通のテーマとして AWS リソースを活用してほしい
実際に 1 年働いてみて、プロダクトの構成や、AWS リソースのデリバリー方法を身に付けたため、それをカリキュラムに組み込みたい

※「ISUCON」は、LINE ヤフー株式会社の商標または登録商標です。

テーマは以下の様に決定しました。

テーマ
ISUCON を題材に、AWS サービスを用いた Web アプリケーションのパフォーマンス改善
概要
Terraform を用いて AWS 上に Private-isu をデプロイし、AWS リソースを活用して段階的にパフォーマンス改善を行っていく
学べる事
実践的な Web サービスで使われる AWS インフラの構築体験
ログやメトリクスを取得/分析する手法
IaC (Infrastructure as Code)を使った環境構築

パフォーマンス改善の体験はどの分野エンジニアでも無駄にならず、問題の可視化と分析、そして解消というサイクルはあらゆる問題解決に共通する考え方です。また、合同研修にISUCONが入っている事も考慮しました。

ハンズオンカリキュラムの構築

テーマを決定したのち、実際に AWS リソースを中心にパフォーマンスチューニングができるかを確認していきました。このフェーズでは AWS リソースを構築し動作確認を行う必要があったため、対面で朝から晩までモクモクと作業をしていました。
また、いわゆる『黒本』（達人が教える Web パフォーマンスチューニング）を参考に AWS リソースのみでチューニングの再現ができないかを試し、スコアを上げていました。行ったこととしてはボトルネックの可視化とその解消です。DB を Aurora に切り出し、Performance Insights でクエリを確認したり、ALB+Athena でアクセスログを可視化し、CloudFront でキャッシュを張るなどです。途中で Private-isu を AWS で構築するための AMI ID が切り替わったことによるエラーやコンソールから手動で構築したリソースを Terraform に書き起こす部分に手間取りました。
作業内容としては、最終的な構成用に記載された Terraform をそれぞれのフェーズごとへの切り分けや、事前の環境構築を無くすために作業用のインスタンスを用意する Cloudformation の構築などです。
穴田さんとの二名でカリキュラムを作成する中で、時間の制約などから本体には組み込めなかった構成や、さらなる改善点などを、クロージング資料として別途用意しました。
以下の構成図は初期段階と最終段階を比較したものです。

構築フェーズでは明確な役割分担はなく、お互い同時にチューニングを試しました。カリキュラムを作成する際には、作業時のログを残していたため、余裕のある方が資料に情報を追加していく形式でした。

研修当日

全体で 102 名の受講者のうち、私たちが提供するカリキュラムには 12 名が参加してくれました。
研修当日はオープニング資料で研修の概要とゴール、用語を紹介したのちカリキュラム資料を共有しそれぞれで進めて貰いました。私と穴田さんを含めた 24 卒 3 名と AWS 社員の方 2 名の合計 5 名が、巡回しながら質問に対応しました。
その中で、ハンズオン実施中に発生した実行エラーや手順で詰まった際の質問はもちろん、それ以外にもカリキュラムで利用している AWS 各サービスのメリットや業務で IaC をどれだけ活用しているのか、提示されたシステム構成の意図に関する技術的な質問がありました。
このように相当な熱量をもって参加して頂けたのでこちらとしても非常に手応えを感じ、刺激を受けました。
クロージングでは最終的な構成の説明と、AWS Well-Architected Frameworkを用いた更なる改善方法を話しました。

カリキュラムは以下の GitHub で公開しています。
https://github.com/KiyamaMizuki/Private-isu-scoreup-for-AWS/tree/main

懇親会 LT

また研修だけでなく懇親会での LT もしました。登壇者は、24 年卒の AWS 社員の方、穴田さん、そして私でした。
私からは「AWS 使いすぎ注意！コスト管理と Slack アラート構築」について発表しました。カリキュラムを作成する中で 1 万円以上のコスト請求が来たことから、この研修を終えて新たに AWS アカウントを作成するであろう参加者向けにコストアラートの構築方法をテーマにしました。
カリキュラムを一時間動かした際のコストをクイズ形式で出し、1 日、1 週間放置してしまった際にはどれだけ請求が増えるかを伝え、意識して貰った後にコストアラートの構築方法を紹介しました。参加者は飲食しつつも LT にも真剣に耳を傾けてくださったため話しやすかったです。

LT 資料は以下です。

今回の経験で得た学びと気づき

今回の登壇を通じて様々な学びと気づきを得ることができました。
その中でもピックアップして以下に記載します。

自己紹介の必要性
ハンズオンでは研修内容を伝えることに気がいって、制作者や参加者の目の前で話しているのが誰であるかを紹介するページを用意していませんでした。
LT 資料には記載していたのですが、発表する際には必ず自己紹介のページを一枚記載しようと思いました。また、場の空気を和らげるために、自己紹介にアイスブレイク要素を取り入れることも試していきたいです。
アウトプットの意義
登壇前はハンズオンを時間内に全部終わらせる参加者がいないか、LT で発表する内容は参加者にとって既知のことではないのか、と不安でした。
ですが、研修中にはたくさんの質問を頂いたり、LT でも反応をいただくことができました。参加者にも新たな知識や視点を提供できることからアウトプットには意味があると感じました。
人に教えることでの気づき
使用したことのない AWS リソースを使えたのはもちろん、参加者に伝える事を意識して情報を整理したため自分自身の理解が深まりました。
今回はプレゼン形式の研修ではなく、ハンズオン形式の研修だったため過不足なくドキュメントを作成する能力が向上したと感じています。

おわりに

昨年、参加者としてこの研修を受けた際に、エンジニアとしての知見だけでなく 24 卒同士の横のつながりも構築する事ができました。その繋がりから今年は登壇や LT をする機会をいただくことができて、本当に幸運なことだったと改めて感じています。この登壇を通じて得られた学びを糧にこれからは受け身ではなく、自ら積極的にイベント、勉強会に参加して知見を外部に発信していきたいと思います。
この記事が、これから技術研修に参加される方や、発表の機会に挑戦しようとしている方々の、何か少しでもお役に立てれば幸いです。