📝

富山からJAWS DAYS 2024に参加した学生の参加レポート

2024/03/05に公開

はじめに

こんにちは!みゃっちーです🦔@NqRu66lkcQ1tHOK
普段近くのコンビニまで徒歩30分。辺境の地に存在する学校で細々と勉強しているわけなんですが、この度、題名の通りJAWS DAYS 2024に参加してきました!

今年の4月から学生生活も終わり社会人ということで、いっぱい吸収して入社前に一段階成長するぞ! と意気込みを持って参加したんですが、また次も絶対参加したいと!と終わって思うようなとても有意義な時間を過ごすことができました。

JAWS DAYSってそもそも何?

JAWS DAYS 2024 のテーマは「LEAP BEYOND」です。東京では5年ぶりに、1つの会場に集まって行うリアルイベントとなります。リアルなイベントでは「ビジネスとテクノロジー」「地方と都市」「学生と社会人」など、さまざまなバックグラウンドを持つ人が同じ空間を共有します。この空間の中で、異なる価値観の人たちが、自分たちのコミュニティを飛び越えて偶然に出会う場を提供することで、新しい可能性を探っていきたいと考えています。
リアルの場だからこそ肌で感じられる楽しさ・盛り上がりの中で、いつもとは違う価値観と触れあえるような、たくさんのアイディアを実現していきたいと思います。JAWS DAYS 2024 で生まれた繋がりやチャレンジを通して、日本でイノベーションを起こしましょう!!

https://jawsdays2024.jaws-ug.jp/

スカラーシップ制度

日々様々な教材、AWS資格試験料、初任給までの家賃などでバイト代をすり減らして疲弊している僕は、この度学生に向けたスカラーシップ制度を利用させていただきました。

JAWS DAYS 2024 は、5年ぶりに東京にて対面イベントとして開催します。対面イベントのメリットがある一方で、昨年までのオンライン開催のように、地方在住の学生の方も気軽に参加することが難しくなってしまいました。そこで、JAWS DAYS 2024 では、スカラーシップ制度として【関東以外に在住の学生の方】を対象に、交通費と宿泊費を補助します。

https://jawsdays2024.jaws-ug.jp/about/scholarship/

当日

JAWSコミュニティに少しづつ参加し始めて半年、初めての大規模イベントへ富山からの参戦です。今までX(Twitter)でこんな人達みたいになりたいなと憧れていた沢山のつよつよエンジニアさんに会える、お話が聞けるということで行くことが決まった日から胸を躍らせていました。

出発の朝はまさかの雪!が少しの新幹線遅延だけで済みました。

東京に着いて、迷いながら会場に向かう道中で撮りました。事前にSNSで存在することは知っていましたが、生で見たとき「あれは!」と喜んでいました。

参加したセッション

1.CIer・SIer集まれ!!クライアントワークな私たちとAWSの良い関係を考えよう!


4月から自分もCIer・SIer?ということで、このパネルディスカッションを聞きました。各企業の成功の秘訣や、業務にあたる上で必要な考え方を聞けるとてもいいセッションで、この話を聞いて社会人になるのとならないでは将来大きな差が如実に出ると思う内容でした。

議題1 AWSバージョンアップ提案のコツ

日々たくさんのAWSサービスがバージョンアップされていく中でそれをどのようにお客さんに説明していくのか。

まず、常にバージョンアップ情報を把握し、以下のようなステップを踏む。

  • センサーを張る
    • AWSのヘルスチェックやアップデート情報を監視し、変更点を把握
  • 検証を行う
    • バージョンアップが確認されたら、速やかに検証
    • 影響が及ぶ可能性や追加機能を確認し、顧客への提案を検討
  • 提案をする
    • お客様に対して、アップデートの必要性とメリットを説明
    • クラウド移行のメリットも含め、提案

実際に提案する際は以下の点を意識しながら
・アップデートの種類(どうしても実装しなければいけない or 当初できなかったけど後から機能追加できるもの)を理解し、必要性やメリットを明確に伝える!
・クラウド移行のメリットも強調し、お客さんが上司に説明しやすい形で!

議題2 新機能がGAされたけど提案どうしてる?

まず、アップデートをキャッチアップできている人が少ないし、アップデートが多すぎて普通に生活していたら追うことが難しい。これを社内で解決するためにそれぞれいろんなことを実施している。

  • 新しい機能の検証ブログを見つけた場合に社内で共有する
  • 社内向けコラムでアップデート情報を配信する
  • 毎週集まってアップデートを共通する会を開くのもあり

そのうえで、新機能が導入できそうな案件を担当してる社員が気が付いていなければ、教えてあげられる環境を作る。→お互いの案件を大まかでも理解しておくこのが大切かも

またreinvent中はわくわくする人と、ドキドキする人がいるそう…(要件定義中や開発中に新しいやり方が出てきたりしちゃう可能性が)

どんな大ホームランを打てましたか?一番の成功事例は

共通して出していたのは、「お客さんの本当の課題を何なのか考えて、提案した仕組みが採用されること」 で、事例として挙がっていたのは下記のようなもの

もともとポータルサイトのリニューアルだったのが、よくよく課題を考えてみると問題点はIDの統合を行うことだった。→提案してみると課題の整理ができていなくて、ベンダーにお願いできていない状況だった。

店舗ごとの売り上げデータをS3上のエクセルにまとめて、各社が競い合える環境を作りたかった。→各店舗の比較が一目でわかるquicksightを提案し、AWSを扱える担当者を育成した。

また、このように提案ができるようにするためにはいろんな部署の垣根(金融部門×AWS部門など)を超えた連携も必須と。そして顧客の本当の課題を模索してプラスアルファの提案をするときはAWSの方を入れて一緒に話すのもいいかも。

クライアントさんに響いた口説き文句教えて!

口説くうえで持つべき考えとして、

  • いわれたことをやるんじゃなくて、お客さんの成長に必要なことを手助けするという意識をまず持つ。そしてシステムと文化を作っていく。
  • エンジニアは早とちりで新しいサービスを使いたがるけどお客さんはそうじゃない。
  • まだAWSがよくわかっていないお客さんに対しては、社内のエンジニア育成を一緒に訴求していくことも大切

Well-Architectedじゃないけどどう変える?

品質保証で開発が終わった後にしっかりできているかを調べるが、お客さんによっては、「マルチAZだけど、それ料金が2倍になるから1台でいいよ」といわれることも。その場合は改善期間を設けたりもする。

また社内でどのような構成がリスクが高いのかそもそも認識を共有したり、広げておくことが大切。

そもそも実際にやるとなったときに開発中に対応するために構成を変更したりするのは難しい部分もある。なのでできる限り早い提案段階からチェックシートを作って対応しておく必要がある。

2.Japan AWS Jr.Championsまでの道のりとこれから

AWSを触っている学生として、入社後まず目指したいのがAWS Jr.Champions!! ということで、選出されるまでの経緯や必要な考え方、また選出後の変化について学んできました。

登録の経緯について

前から募集ページはちらちら見てたけど、実際どんな風に決まるのか気になっていた。
https://aws.amazon.com/jp/blogs/psa/2024-japan-aws-jr-champions-criteria/

TISさんでは社内で応募したい人の募集があってすぐに申し込んだそう。圧倒的な行動力だ…

登録のメリットについて

登録のメリットについて次のようなものを上げていた

  • 今回のような登壇の機会がある
  • 他のJr.Championsの人と交流が図れる
    -「AWS Top Engineers」や「AWS Ambassadors」の方とお話する機会がある
  • コミュニティイベントや社内で、話しかけられる

メリットしかない!!!しかも全部普通じゃ中々できない貴重な経験。僕も頑張って目指そう…と話を聞いて、気が引き締まってモチベーションが爆上がりしたセッションでした。

3.国内東西リージョンでウォームスタンバイのDR設計をした話


東京リージョンで展開されているサービスにおいて、障害発生時に大阪リージョンにフェイルオーバーされるようにしたいという要件についての話だった。ただセッションになってるだけあって一筋縄ではいかないようで…

課題1 「リージョンごとのCognite間で認証情報が統一できない。」ということ。(知らなかった…)

Amazon Cognito ユーザープールはそれぞれ 1 つの AWS リージョン内に作成され、そのリージョン以外にはユーザープロファイルデータを保存しません。

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/security-cognito-regional-data-considerations.html

対処法としては、障害発生時に、前段のLambdaで東京リージョンへのアクセスが来た場合は大阪リージョンの認証情報に置き換える処理を追加したそう。

課題2 IaC の管理どうするか?

確かに東京リージョンへの構成変更があった場合に、大阪リージョンにもしっかりと繁栄させないといけない…

解決方法としては 「東京リージョンへのデプロイ時に大阪リージョンのCodeCommitにもPushするようPipelineを構築」 したそうです。当初大阪リージョンにはcodePiplineがなく迷っていたところちょうどサービスが開始したとか。

他にも共通リソース、東京リージョンリソース、大阪リージョンリソースに分けてディレクトリ管理することで管理を楽にしたそう。

4.次世代への種を蒔こう〜学生と社会人との交差点として、JAWS-UGができること〜


コミュニティに参加している学生たちが「参加しやすいコミュニティを実現するにはどうすればよいのか」について議論するということで楽しみにしていました!

僕自身、コミュニティに参加し始めたのは、社会人の人たちが案件や仕事をこなしていく中でわかったいろんな知見や経験の共有を聞きたい!からでした。

ですが、パネルディスカッションの中でもありましたが、 やはり学会発表的な固いイメージがあったり、大人の交流会みたいなイメージがあってなかなか参加しずらい。 イメージを持っている学生も多いという話もあってその通りだなと感じました。

まだ自分の参加が精いっぱいで、他の学生に参加を促すレベルには達していない僕ですが、早い段階でその高みに達している学生のお話を聞けたのはよかったです。

5.コンサルタントに聞く!AWS Security の守り方とセキュリティテストの実例


「AWS環境のセキュリティ」と聞くと、アクセス管理して、ログ管理してあのセキュリティサービスオンにして…というところで考えが止まっていました。

ですが、攻撃者の視点で以下のような脅威分析をすることも大切と。

  • どんな方法で
  • 受けるとどのくらいの範囲に影響があって
  • その攻撃にはどのくらいの技術が必要で
  • 防ぐには何をすればいいか

また、実際に攻撃をするぺネストレーション(侵入テスト)を求められるケースもある。
テストの例としては「attack path mapping」と呼ばれるものがあり、1つの脆弱性から企業が持つ資産(個人情報、技術資料など)への経路を複数のアプローチでmappingしていき、その経路を明らかにする手法などがあるそうです。

具体的なやり方や必要なツールなどは調べてみるとちらほら出てきますが、この視点で調べたりしたことがなかったので新鮮です。
https://www.hackthebox.com/blog/aws-pentesting-guide

ただ、行う際にはしっかりAWSへ申請が必要なものなど色々ルールがあるので注意が必要ですね。
https://aws.amazon.com/jp/security/penetration-testing/

6.技術書を書く技術:あなたの知識を世界に届けよう!!


いつもお世話になっている技術書の書き方や、作り方。ちょっと踏み込んだお金の話を聞けるセッションでした!

聞く前はどのくらい儲かるんだろうな…とわくわくしていたんですがそこまで現実は甘くないようで…技術書出版の専業で食べていける人はいないそうです。

戦略的なお話

初心者、中級者、上級者とピラミット上になっているため、初心者向けの技術書を書くのがいいらしい。ただ、ニッチな分野でシェアを取るのも戦略の一つ。など普段買い手だと考えないようなお話も聞けた。

そして気になるお金の話でしたが…なんと 増刷がないと時給換算で600~800円 になるそう。これはいつも書いてくださってる方々に感謝しかない…

文章を書くコツ

やはり、1行目を書きだすことが難しいからそこを何とかする方法を考えるのが大切!とのこと。
対処法として紹介されてたのは以下のようなもの。

  • ある程度の内容を箇条書きで書いておく
  • ChatGPTに書かせる(ただしほとんど修正は必要)

ちなみに東京にいく隙間時間に何か読もうかと、この2冊がリュックに入れてました。(サインお願いすればよかった…)

7.恒例!ソリューションアーキテクト怒涛のLT


最後はAWSのソリューションアーキテクトの方々のLTを見ました。さすが!と思わされるようなLTの連続で、人も沢山いたので50分間背伸びしてみていました。その中でも個人的な推しLTを紹介。

AWSのマルチアカウント管理で意外と知られていないOU設計の話

https://speakerdeck.com/pikosan0000/awsnomarutiakauntoguan-li-teyi-wai-tozhi-rareteinaioushe-ji-nohua

AWSのベストプラクティスは一つのAWSアカウントにリソースを詰め込むのではなく、複数アカウントを作成し、それを役割をまとめたグループ(OU)に分けるのが以下の観点からよいとされています。

  • セキュリティ境界
    →他のAWSアカウント同士のアクセスを明示的に設定できる
  • リソースの分離
    →サービスクォータ上限を分離したり、リソースへの共有を明示的に設定できる
  • 課金の分離
    →アカウント単位で請求が来るため、どのアカウントでいくら料金が発生したかわかる

そんなにいいことあるならOUで分けよう!となるんですが、どんなふうにOU分ければいい?設計すればいいの? って迷うんですよね...

このLTではそんなOUを設計するために必要な知識、情報が載ってるURL、OU分けの例、アンチパターンなどの情報が詰め込まれていました。(これからすべて読みつくし予定)

その他

おひるごはん!!!

実は当日の新幹線の中でお昼ご飯が出ることを知りました。すごいおいしかったです!
(数があったらしく、2つ頂きました🙏)

ノベルティ!!

頂いたステッカーはすべてPCに貼って、資料もすべて読まさせていただきます!
(いろんな会社の情報を見るの結構楽しい)

将来上京もしくは、リモートワークで会社を探す機会があるときは、この中のどこかに入ることができるような技術者になることを目標に今後も頑張っていきたいな。

さいごに

今回初めてJAWS DAYSに参加しましたが、率直な感想として 「楽しかった!行ってよかった!」 です。普段ただ生活していると、周りにここまでモチベーションを持って活動している人がいないので、「このくらいでいいかな」と甘えてしまう部分がどうしてもあります。ですがモチベーションや技術力の塊!みたいな人たちに囲まれるこのような機会があると 「自分はまだまだ頑張らないと」 と改めて気を引き締める貴重な機会になりました。

今は誰かに引っ張られてる僕ですが、いずれかは自分が引っ張っていき周りに影響を与えられるような人になっていきたいです。

このイベントに関わっていた運営さん、登壇者さん、その他参加者の方々ありがとうございました。

北陸勉強ブログ

Discussion