お題のAWSアカウント(社内サービスのステージング環境)に対し
「Q Developerなど利用しながらWell-Architectedに沿った改善提案を作って発表！」
というワークショップを企画し、社内で開催してみました。

第1回ということで改善余地はありつつ、構成としてはよかったので第2回もできたらと考えています。
ワークショップ開催しようかな？という方の参考にもなれば幸いです。

背景・目的

  • これまで3回社内でWell-Arch Minibootcampを開催していたが、より実践に近く実際のワークロードを使ったワークショップもやりたい。
  • 環境調査などもAIと共に行うことが増えてきたが、人によって活用具合や方法は違う。触るきっかけや意見交換する機会を作りたかった。

ワークショップ内容

日時：12月18日(木) 15:00〜19:00(19時以降はそのまま懇親会)
人数：17名(運営で5チームに振り分け)
場所：12月1日に本社移転したので、早速ラウンジエリアを使ってみました。

お題

メール通知統合システムという社内サービスをお題にしました。
このシステムは私が所属している部署で開発し2021年から運用しています。あまり更新する機会のないサービスですが、アップデートの必要有無を見直すのにいい機会と考えました。
これのステージング環境アカウントに入って調査し、提案内容を作成してもらいます。
参加者は所属部署を問わず社内全体から募集しました。

お題環境

ワークショップ参加メンバーにIAM Identity Centerのユーザーを払い出し環境にアクセスできるようにしました。
ネタバレ防止のため前日までは「権限ほぼゼロ」でアタッチし、ログイン確認だけ済ませておいてもらいました。
そして当日以下の権限を運営側でアタッチしワークショップスタート。

ツール

ワークショップ内で以下を紹介

普段は何も使ってなくても「マネジメントコンソールからのAmazon Q」「Service Screener v2」はすぐに使えるので、あとは何を使うか各チームの判断に委ねる形にしました。
ここは後述しますが、次回以降は事前にセットアップしておいてもらうなり条件を揃えるのが良かったと考えています。

タイムテーブル

発表 & QA

各チームで、こちらのテンプレートを埋めて発表してもらう形にしました。

実際に発表された内容は各種設定の見直し、 GuardDuty や Security Hub 、Inspector 、などチームによってピックアップされた項目や優先順位は違いましたが、参考になるものが多かったです。
運用設計工数や権限・設定の移行テストを工数内訳に含んでくれている項目もありました。

QAであがった例としては以下のような質疑応答や突っ込み、議論への発展など。

  • 限られた工数の中で、この改善項目を優先しピックアップした理由
  • 必要最低限のIAM権限の特定のし方。あとから権限を絞る場合のリスクやテスト
  • VPCフローログの有効化入ってるけど、サーバレス構成だが必要そう？
  • 暗号化対象にしているこの◯◯◯って何が入ってました？
  • 依頼側になかった観点からの提案も良いが、まずは提示された課題にまっすぐ応えた提案も入れるべき
  • これはどういう脅威やリスクに対しての対策になっているか？
  • ちなみに普段どう優先順位きめてます？→リスクアセスメントや脅威モデリングの話に発展

発表の後は参加者で投票を行い「提案内容がよかったチーム」「レビュー方法がよかったチーム」の表彰を行いました。

懇親会

19時からはそのままラウンジで懇親会を開きました。
ワークショップの後は懇親会もセットで開くようにしています。同じ課題に向き合って議論しあった後、懇親会する流れは良いなと今回も感じました。
プロジェクターがあるので、飛び入り参加OKの1分自己紹介、AWSさんにはLTもしてもらいました。

振り返り

参加後アンケートでは今回を機に初めて触ったツールや、使い方ができた、プロンプトの工夫の共有やチームで取り組む中で経験値の多いエンジニアからいろいろ聞けたという意見もありました。
改善点としては調査・提案作成の時間はもう少し欲しかったという意見が多数。


運営チームで年明けに振り返り会をする予定です。
そこの場でKPTなどに落とし込む前段階として、ここでは私目線で「よかったこと」「改善余地/アイディア」をざっと羅列してみます。

よかったこと(≒Keep)

  • 実際のワークロードを題材にしたことで、提案内容に対してリアルな意見が出た
  • 工数の縛りを設定することで、ただベストプラクティスを羅列したものではなく、現実的なアクションとしての提案になった
  • チーム振り分け
    • 応募アンケートで収集した情報から、AIやツールの利用経験、Well-Archレビュー経験が偏らないよう考慮
    • 所属、ロケーションができるだけ偏らないよう考慮

改善余地/アイディア(≒Problem/Try)

  • 取り組み時間はもう少し長く取る(想定する段取り内訳を考えて時間設計する)
  • 「ここまでは準備しておいて」とツール条件を揃えておく。セットアップフォローはSlackやオフィスアワーで
  • 会の雰囲気は発表時にコメントする人選でもコントロールできそう（誰でも参加しやすい会、実践に近い緊張感ある会など）
  • 環境や資料から読み取れない部分はお題提供者にヒアリングを推奨する。ここも実務のトレーニングになる形を考えてみる
  • Well-Architectedの各項目に対して、社内で解釈や判断基準を揃えているので、それらもインプットとして利用できるように用意しておく（参考記事）
  • フィードバックとしてツールセットやテンプレートに落とし込み

終わりに

Well-Architected のベストプラクティスに書かれていることや AI による調査結果や提案してきた内容そのままではなく、それがベストプラクティスである理由を理解し、実際のアーキテクチャや運用と照らし合わせ優先順位を判断する必要があります。人間側に知見や能力があり AI にも適切なインプットをしたうえで、本質的な提案に落とし込めているかが大事だと改めて感じました。

第1回ということで準備不足なところもありましたが、参加してくれた人たちは協力的でアンケートも翌日午前には全員分集まり感謝です。