この記事はNHN テコラス Advent Calendar 2025 の 22 日目の記事です。

はじめに

こんにちは、25新卒未経験エンジニアの RENA です。
今回は NHN テコラス恒例の新卒課題「AWS 実践提案道場」というトレーニングに挑戦しました。

本記事では、この課題概要から実際の取り組み過程、学んだことや振り返りまでを、IT未経験者の視点から体験談としてレポートさせていただきます。

AWS 実践提案道場とは

AWS 実践提案道場とは、AWS が提供するエンジニアやプリセールスの方向けの実践トレーニングです。
本来は複数人のチームで数時間かけて取り組むこの課題に、今回は私 1人で 2週間かけて挑戦しました。
実施目的は、AWS サービスのアーキテクチャと、その提案方法を知ることです。

トレーニングの流れ：

• 「AWS 移行案件」の疑似 RFP を受け取る

• 構成についてリサーチ

• プレゼン資料の作成

• 疑似顧客役の先輩社員を相手にプレゼン

前提条件

以下がこの課題に取り組む際の前提条件です。

• 実施期間：2週間

• 参加者：私のみ

• AWS の知識：SAA 合格レベル

• 許可された行為：インターネット使用と教育担当者への相談

• 禁止された行為：生成 AI 使用禁止

• プレゼン時間：20~30分
  先輩 2名に顧客役を担当していただき、最後に質疑応答を行う
• 追加項目：Well-Architected Framework の柱の推奨事項を3つ取り上げる

ステップ１：情報収集

まずは依頼内容の確認です。
主な内容はこちら

• 人気 SNS 動画配信サービスが AWS への移行を検討中

• ユーザは主に日本におり、1年で 1万人から 100万人に増加予定

• 現行システムは一般的な 3層構成
• データセンター内の別システムとも連携しており、AWS 移行後もこれらのシステムと安定的に接続する想定

• CTO の課題：ユーザの急増を支え、高い可用性とパフォーマンスを実現する

これらを実現する構成を作成し、提案するための情報収集から始めます。

事前リサーチ

実践提案道場、開幕です。
☻：いざ、スタート！
☻：…え、どこから始めればいいの？

よくわからないまま、「動画配信」や「AWS」というキーワードで検索を始めました。
その結果、 Elemental MediaLive という、テレビなどのライブ配信向けのサービスを発見しました。

Elemental MediaLive の特徴：

• 生配信向けにライブ動画をエンコードする

• 高品質

• スケーラブル

• マルチ AZ 対応

• リザーブドインスタンス（RI）やディスカウントプランなど、料金プランの充実

• ☻：あと、名前がドヤってる感じがあって好き

☻：これだこれ！！！いいの見つけた！

これを利用した構成を考え始めましたが、すぐにあることに気が付きました。

☻：Elemental MediaLive…複雑すぎる。

Elemental MediaLive はライブ配信に最適なサービスではあったものの、マイクロサービスに基づいたアーキテクチャ構成だったのです。
今回、現行システムが使用しているのは 3層構造だったため、利用するにはモノリスを分解する必要があり、その手段として Strangler Fig パターンというものも必要になります。

☻：あ…むずい！

そう、モノリスの分解は基本的に難易度が高いのです。
そのため、Elemental MediaLive の使用は諦め、現行システムの構成を以下の AWS サービスで置き換えることに。

• サーバ→ EC2 と RDS

• NFS→ EFS

• ファイヤウォール→ WAF

この AWS アーキテクチャ常連たち（？）で勝負です。

ステップ２：構成図作成

さて、構成のイメージがついたところで構成図作成開始です。
アーキテクチャ図作成ツール・ Draw.io を使用し、作成開始。

ところがこちらも難しく、思うようにいきません。

☻：EC2 や RDS、EFS が何かは分かるし、コンソールで触ったことはあっても、構成図でどこに位置するかなんてわからない…
☻：WAF って構成図上でどこだっけ？

ここでもとりあえず検索をかけ、インターネット画像をたくさん見ましたが、またまた困惑です。
構成図に絶対的な正解はないため、見ている構成によってはリソースの場所が違うのです。

そうこう苦戦しながら、作成した 1つ目の構成図がこちら。

☻：ふー、これで次にいける！！！
と、思ったのも束の間。

☺教育担当者さん：これでちゃんと外に接続できるんですか？
☻：へ？

ご指摘を受け、NAT Gateway を追加。

また、この課題の条件として「Well-Architected の推奨事項を3つ取り扱う」というものがあったため、構成図がある程度描けた時点で以下の Well-Architected の柱を取り上げることにしました。

• 運用上の優秀性の柱（OPS10-BP01）：EventBridge や SNS を利用したアラーム通知システム

• 信頼性の柱（REL02-BP01）：Site-to-Site VPN と Direct Connect の二刀流を利用することで接続の単一障害点をなくす

• パフォーマンス効率の柱（PERF02-BP05）：Auto Scaling を使う理由について

☻：わお、使うリソースが一気に増えた。

最終的に完成した構成図がこちらです。
Site-to-Site VPN と Direct Connect の両方を使用し、Auto Scaling Group も使っています。

また、こちらが Well-Architected の運用上の柱から選んだ事項のアラート監視システムです。

これで構成図作成は完了です。

ステップ３：プレゼン準備

事前リサーチが済み、構成図も完成したところで、顧客役の先輩方にプレゼンする準備を始めました。今回の顧客役の先輩方は、このとても凄いお二方。

• Tさん：この AWS 提供トレーニングをテコラス向けに作った 2025 Japan AWS Top Engineers 選出者の凄い方。主食はカロリーメイト。

• Iさん：Tさんが教育を担当した 2025 Japan AWS Jr. Champions 選出者の凄い方。

☻：ががが、がんばろう…！

以下の順番で発表することを考え、プレゼン資料を作成しました。

• 挨拶

• 前提確認

• 構成案

• 1つ1つのリソースの説明

• Well-Architected の推奨事項を交えた説明

• まとめ

この時作成した資料の一部がこちらです。

話す内容を想像しながら資料作成は順調に進んだものの、実務で AWS の実践提案をしている凄いお二方の前で実践提案すると思うととても緊張しました。

本番で失敗しないようたくさん準備しましたが、プレゼンと質疑応答の準備をするにあたり、わからないことがとても多いことに気づきました。

具体的にわからなかったこと：

• 実際の提案の流れ

• どんな質問が飛んでくるか

• それに対しどんな答えを用意するべきか

これらが想像つかず、頭を抱えながらサービスについての回答をメインに準備しました。
Direct Connect と Site-to-Site VPN の違いや CloudFront のメリット、NAT Gateway が必要な理由、などなど。

コストについても気になりましたが、架空のシチュエーションであるため、具体的に AWS Pricing Calculator で打ち込むべき数字がわかりませんでした。

☻：お金のことはわかんないしスキップしちゃお！
そう思い、コストに関しては何も用意せずに本番に挑み、後にこれが大きな間違いだったと気づくのでした。
いざ、発表へ。

ステップ４：発表・質疑応答・フィードバック

発表

さあ、発表が始まりました。
今回は、実際の顧客提案を想定してオンライン形式で行われました。

発表の時の実際の発表の一部がこちらです。
☻：Techo-Games 株式会社の T様、I様、本日はお集まりいただき、ありがとうございました！
☻：今回、AWS にオンプレ環境からの移行、そして現行システムと今後も接続を続ける、という認識で間違いございませんか？
☻：Auto Scaling というのは…Direct Connect とは…

発表の際は用意したスライドを使いながらなるべく丁寧に話したつもりでした。
「つもり」でした…はい。

質疑応答

プレゼンが終わり、質疑応答の時間になりました。

• 「合計いくらぐらいですか？」
• 「月、いくらですか？」
• 「100万人に増えた時の構成ですか？それとも移行した直後の構成ですか？」
• 「サーバレスにできますか？」
• 「SLA 99.99に遵守できますか？」

☻：え、わかんない。SLA ってなに？！
☻：逃げろー！！！

「後日、改めてご連絡します！」

と、どう答えたらよいかわからず、焦りから何度も逃げました。
何も準備できていなかったし、まだまだ経験も知識も足りないことを実感しました。

当時の状況のイメージ図がこちら。

フィードバック

質疑応答が終わり、フィードバックの時間が始まりました。
以下が主なご指摘でした。

• 「必ず～～です」などと言い切りはせず、「ドキュメントベースでは」などと前置きすること
• 特にコスト面など、相手が知りたい情報を与えること
• 資料では構成のビフォーアフターを見せたり、大事なところをズームすることで、話についてきやすくすること
• あくまで提案なので、こちらが提示した答えが唯一の正解ではないことを意識すること

なるほどと、自分がまだまだだと実感しながら、プロ目線でのアドバイスがいただけてありがたいなと思いました。

フィードバック後、Iさんが直接「言いすぎてたらごめんね！」とフォローしてくださり、Tさんも「応援するよ！」と励ましてくださりました。
☻：あ、優しい…！
☻：次もっと頑張ろう。頑張って追い付こう。

まとめ

わからないことが多く、とても大変な課題ではありましたが、以下の貴重な学びがありました。

• 提案する構成に絶対的な正解はなく、あくまで1つの提案として扱うこと

• 構成図の描き方や、リソースについての理解

• 顧客が聞きたいことを意識すること

その他、SLA とは何か、Direct Connect と Site-to-Site の具体的な違い、リソースが VPC 内なのか外なのかなど、AWS の知識の面でも理解できていないことがたくさんあることに気づかされました。

私の課題記録は以上となりますが、他の構成の仕方もたくさんあります。
こちらは今回、疑似顧客役を務めてくださった Iさんの実践提案道場の実施記録です。
私の時とは違い、サーバレス構成であったり、セキュリティ対策も強化しているのが特徴です。
同じ 1つの課題に対し、色んな構成や考え方があるので、併せてご覧ください。

NHN テコラスでの新入社員研修 -AWS実践提案道場編-

最後までお読みいただき、ありがとうございました！

 

おまけ

2025 Japan AWS Jr. Champions 選出者の Iさんのブログページがこちらです。
Tech Blog > henge

2025 Japan AWS Top Engineers 選出者の Tさんのブログページがこちらです。
Tech Blog > Cold-Airflow

また、この T先輩が毎日食べているカロリーメイトを知らない方は、ぜひカロリーメイトをお調べください。
新たな発見があるかもしれません。

NHN テコラスの採用情報はこちら