　こんにちは。技術本部サービスリライアビリティグループ（SRG）の yoshioka です。

　サイバーエージェントでは、毎年新卒エンジニア向けに技術研修を行っています。別々の部署に配属されて6年たった今でもその繋がりは続いています。技術研修だけでなく、新卒同期をよく知る良い機会でした。

　毎年研修の環境は先輩社員が用意しています。今年の技術研修ではAWS を利用することになり、社内の制度「ゼミ」の一つである実践AWSゼミのメンバー（有志）が中心となって環境整備を担当しました。大きく分けて2つの役割があります。

環境の構築と、その使用方法や制限について共有する
インフラメンターとして環境やインフラについての開発相談およびサポート

　具体的な開発については、各チームに対してメンターが複数人割り当てられているので、インフラに関連する相談を担当します。
その中で、22新卒として入社した89名のエンジニア達に対して何を整備すれば、安心安全に研修を進めることができそうかなどを議論しながら進めたので、その辺りをまとめて書きます。
　研修自体については、新卒 ebakazu くんが書いてくれたブログをご覧ください。

実践AWSゼミについて

　実践AWSゼミでは、AWSのサービスについて部署や職種、サービスを超えて、通常業務では触れない領域の知識や技術レベルを向上させることを目的に活動しています。具体的には blackbelt の動画を見て学んだり、AWSの資格試験の問題を解いたり、ハンズオン、週刊AWSをみんなで確認して議論するなどしています。

新卒技術研修の環境整備について

新卒技術研修では決められた予算内でのチーム開発を行なっています。環境を整備するにあたり、メンバーで「安全、安心に開発を進めるためのガードレールの適切な高さを考える」ことにしました。

具体的には以下の3点について、議論しました。

アカウントの管理方法
環境へのアクセス方法
権限の管理と禁止事項の決定

　新卒の中にはAWSに初めて触れる人もいるので、最低限のリスクヘッジが必要です。社内で発行する AWS アカウントには、CloudTrail でアクティビティログを後からトレースできるように設定しています。また、権限の強いIAM User のアクセスキーを発行して、インターネット公開してしまう可能性の排除なども考慮しなくてはなりません。

　そこで、社内の内製の認証認可基盤 PERMAN を用いた権限グループによる管理、認証を行うことにしました。一時的に AWS CLI を実行するための認証などが PERMAN の web console から簡単に行えるため、初めてAWSに触れる人でも扱いやすそうです。

　また、権限グループを管理者、インフラメンター、新卒の３グループを作成しました。インフラメンターへの制約は緩めにして新卒の依頼ベースで設定が可能にし、新卒の権限は IAM user の Create や role の update を行えないようにするなど厳しめに設定しました。

　後から、権限が厳しすぎて依頼が多くなったりしてしまったので、一部の制約を緩めたりしました。開発のしやすさとリスクヘッジのほど良いバランスをとることは難しいですね。

　禁止事項などをいくつか設定し、リスクヘッジを行うようにしました。

us-east-1, ap-northeast-1 以外のリージョンを使わない
デフォルトで使用できる大きなEC2インスタンスの使用禁止
Advanced Shield の使用禁止
security group inbound 0.0.0.0/0を禁止
ドメインは取らずに予め用意して、依頼ベースでサブドメインをNS登録して使えるようにする

　こういったセキュリティリスクの一部は、内製のセキュリティリスクを可視化するツール RISKEN による監視を導入することでカバーしています。

　また、Github Actions を研修の全チームで活用するとリソース的に厳しいこともあり、研修中に内製 Github Actions Runner基盤「myshoes」の「CyCloud-hosted runner」（プライベートクラウドの hosted runner）を提供してくれ、使ったリソースの予算も可視化してくれました。

環境の構築

環境の構築には Terraform を用いて行いました。また、禁止事項を制約するために AWS Config を用いる予定だったのですが、AWS アカウントを Organisation に所属させていないため一括で設定できないなどの制約がありました。その部分は担当者が手動で設定してくれました。また、設定が難しい部分は前述の RISKEN の監視に任せたり、各チーム予算をslack チャネルへ通知することでカバーすることにしました。

実際に通知が鳴ると、各チームで自発的に何が原因か調べて対応してくれたり、インフラメンターへ相談してくれるなど、きちんとリスクに対応できていたと感じました。

環境へ慣れてもらうために

AWS環境やインフラに触れるのが初めての人がいる場合、簡単な説明と実際に触れる機会があることが大事だと思います。一回やったことがあると、次からハードルが下がりますし、概念や単語が分からず調べることすらできないといった状況を防げるからです。
また、用意した環境について、以下のハンズオンをオンライン（Zoom）で行いました。

環境についてのハンズオン

現状の構成の説明と禁止事項について
1. AWS自体については AWSの方が別途講義を行なってくれました
2. AWSについての概念などを把握する資料の共有
3. 前述のRISKENの通知についての対応方法
アカウントへのアクセス方法（PERMAN）
1. Web Console
2. AWS CLI
踏み台を作ってアクセスしてみる
1. sshとセキュリティグループの設定
2. sshの禁止とSSM Agent (Plugin) でのアクセス確認

質問があったり、つまづいた場合は Zoom のブレイクアウトルームで、1対1、 1対N でサポートしました。また、スプレッドシートで進捗管理し、チェックがついていなければインフラメンター側から声をかけるなど、双方向でコミュニケーションできました。

インフラ相談の仕方

インフラを相談する時間が用意されていたので、設計についてのフィードバックをしたり、相談に回答したりしました。それ以降は、slack チャネルで投稿してもらい、定時時間内でのベストエフォートで回答する形にしました。
気軽に声をかけてもらえ、必要があれば Zoom で画面共有してもらいながら一緒に見ていくことができて良かったと思います。個人的にオフラインで相談を受けることも好きなので、研修会場へ足を運べば良かったなと思いました。

振り返ると…

環境整備や運営として

安心安全にサービス開発するために何が必要か予め議論したため環境整備がしやすかった。また、インフラメンター同士のディスカッションなどがやりやすかった。
メンターへのメンションが新卒からあり、技術的な部分での迷いを解決できて良かった。新卒同士で教えあっていることもあり、非常に良かった。
ハンズオンを行ったことにより、基礎的な部分は全員が触ったことがある状態を作ることができた。
誰が対応するのか、反応が早い人に負荷が集中してしまっていた。
アプリケーション側のメンターともっと連携できると良かった。

技術的な観点

予算内でリソースをうまく活用して開発するために、何が必要か、リソースについても改善する余地があると感じた。
PERMAN のおかげで管理しやすい環境が整備できた。
どうしても手動で設定する必要がある部分があり、それを自動化できると来年以降の環境構築の負担が減りそうだと感じた。
毎年変わる技術トレンドに合わせて、柔軟に対応できるようにルール化したり、対応基準を決めておけば良かったかもしれない。
最初から開発のしやすさとリスクヘッジのほど良いバランスをとることは難しいと感じたので、柔軟な対応をしていきたいと思った。

ここで紹介したのは一部ですが、運営観点でも、技術的な観点でも、良いKPTをまとめることができたので、来年へ向けてしっかり共有していきたいです。

最後に

エンジニア、人事も含めて、多くの先輩社員が新卒研修のために尽力した1ヶ月だったと思います。私がメンターやトレーナーを担当した世代の社員がトレーナーとしてすごく良いアドバイスをしている姿を見ると嬉しくなりました。安心、安全な環境でチーム開発をして、技術的にも、社会人としても成長してもらえる機会になったなら嬉しいと思います。

また、実践AWSゼミのメンバーが中心となって新卒研修の環境を整備した（＝普段仕事を一緒にしていない人と議論したり、情報共有してもらった）ことで、いろいろな学びや内製ツールに詳しくなったので、個人的に非常に良い機会でした。また、さまざまな内製ツールのおかげで楽に管理することができ、車輪の開発を防いで開発工数を削減するだけでなく、ノウハウの共有（セキュリティルールなど）も行えるのは、とてもありがたいと感じました。

アバター×仮想空間の進化におけるクリエイティブと技術

「実用可能な機械学習」を目指して：サイバーエージェントのデータをビジネスに適用するための研修「データモデリング入門」