2025年5月17日（土）に大阪のグランフロント大阪（gusuku Ashibinaa OSAKA）にて、JAWS-UG DE&I と AWS Startup Community 関西共催のコミュニティイベント「 Amazon Q DeveloperワークショップとスタートアップなLT大会」を開催しました。当日はAWS Startup Community 関西側として、Amazon Q Develoepr を使った開発ワークショップのランナーをやりました。

AWS の DA による CloudWatch Application Signals 紹介セッション

当日はワークショップの前に、AWS Developer Advocate の山口さんによるセッションがありました。「 CloudWatch Application Signals 」の紹介だけでなく、なぜこの機能が必要かや関連するキーワードとして「 SLI / SLO / エラーバジェット / バーンレート」などを紹介していただけました。

アプリケーションやウェブサイトなどを運用する中で、「このサイトは、何%の稼働率を維持すべきか」を取り決めることが重要です。 Amazon や GitHub / Stripe ですら 100% の稼働率を達成することはできておらず、確保できる予算やダウンしたことで発生するビジネスへの影響などをもとに、事業への悪影響を最小化する割合を取り決めする必要があります。

今回のセッションでは、稼働率を決めた後の取り組みや考え方が紹介されていました。年間での稼働率を決めた時に、どのようにアラートを出すか。落ちるたびにアラートを出す方法がシンプルではありますが、その場合はアラート量が増加してノイズになるか、無視されやすくなるリスクがあります。そこで年間で利用できるエラーの量を「エラーバジェット」として設定し、そのバジェットがどれくらいのペースで消費されているかを計測する「バーンレート」という考えが紹介されました。年間で有給をどのように消化していくかや、ボーナスなどをどのようにやりくりしていくかなどを、サービス・アプリケーションにも適用するようなイメージでしょうか。

このような考え方を実行することで、「バーンレートやバジェットに余裕があるから、ちょっとチャレンジングな開発やリファクタリングなどの技術負債返済などをやってもいいかも」のような判断ができるのはよさそうです。

残念ながら紹介された CloudWatch Application Signals は、利用することの多い言語（ Node.js / PHP ）や AWS サービス（ AWS Lambda ）などではまだ利用できない様子でした。ただ、このような SRE 方面の考え方や取り組みは非常に興味がありますので、今後も情報をチェックしていきたいと思います。

Amazon Q Developerハンズオンワークショップ

セッションの後は、Amazon Q Developer をテーマにしたハンズオンワークショップを開催しました。

当日は Amazon Q Developer の日本語化などに取り組まれているスタッフが参加してくださっていたため、「 Amazon Q Developer とはどんなプロダクトか？」などの紹介セッションも急遽開かれました。この内容は、オンラインで開催されたイベントのアーカイブでもチェックできるということですので、気になる方はぜひチェックしてみてください。

当日利用したワークショップは、 AWS が Workshop Studio で公開されている資料や環境を利用していました、こちらの URL から内容を確認できますので、ぜひお試しください。なお、ご自宅などで試される場合は、「自分の AWS アカウントでワークショップを実行する」から開始されることで、 ご自身の AWS アカウントで試すことができます。

LT や懇親会なども開催されました

ワークショップ終了後、自分は家庭の都合で離脱しました。が、 3本の LT や懇親会なども開催されたとのことです。オフラインならではの体験を重視するコミュニティですので、イベント内での学びを深掘りしたり、自分の中での仮説を話してフィードバックを得るなどの活かし方ができると思います。

次回について

JAWS-UG DE & I は 6/14 に次のイベントが予定されています。AWS Startup Community も夏頃にイベントを企画予定ですので、ぜひこちらもご参加ください！

みなさま、ご参加ありがとうございましたー