aka
2024/11/23(金)にAWSが主催するパートナー向け特別ワークショップである「AWS Well-Architected Partner Program Bootcamp」に参加してきました。個人的な気付きも多かったため、忘備録も兼ねて記事にしようと思います。
AWS Well-Architected Partner Program Bootcamp とは
架空の企業のシナリオをもとに、AWS Well-Architected フレームワークに沿って、チームで現状(As is) のベストプラクティスの適用状況を分析し、将来 (To be) のアーキテクチャーを検討するワークショップです。
アジェンダ
- AWS Well-Architected Frameworkの説明
- Well-Architected Partner Programの説明
- W-A Bootcampルール説明
- 仮想顧客シナリオを読み込み
- 各柱毎に以下を実施 ※”持続可能性の柱”は時間の都合により未実施
- 概要説明
- 4人毎のチームに分かれ、仮想顧客に対してWell-Architected Review を実施
- チーム毎にまとめたAs Is (現状) と To Be (将来) を発表
受講目的
直近でAWSで構築するクラウド基盤の新規開発プロジェクトのリードを務める機会があり、より良い成果を残すためには今以上にクラウド設計・運用の広範な知識が必要であると感じ、次以降のプロジェクトに備えるため受講しました。
感想
- まとまったドキュメントとツールの存在が嬉しい
- AWS Well-Architected ホワイトペーパーやAWS Well-Architected Toolといった無料で使用できるドキュメントとツールが用意されており、AWSを用いた開発ではなくとも、開発全般を適切に進めていくための観点としてかなり参考になる内容が記載されているため、技術領域を問わず開発者としては非常に参考になるものだと感じました。
- 専門分野ごとのフレームワークの存在が実際のプロジェクトで使いやすい
- AWS Well-Architected Lensesという14個の専門分野別に分かれたフレームワークが存在しており、それぞれの専門分野毎に必要な観点が記載されています。実際の案件に入る前にこれらのフレームワークを確認しておくことでスムーズにキャッチアップができそうだと感じました。
- 非機能要件の確認に効果的に使える
- 例えばアーキテクチャ図を見た際に、機能要件を実現できていそうかどうかはアーキテクチャ図で記述されている内容を見れば分かることも多いですが、非機能要件に関わる部分はアーキテクチャ図で可視化されている内容を確認するだけでは適切なものになっているかどうか判断することは難しいです。しかし、Well-Architected Frameworkは非機能要件の確認に必要な観点が網羅的に記載されているため、チェックリストのように用いることで十分な確認ができると感じました。
- 活用するためのスキルは別で必要
- ここまで非常に有益なものであるという感想を記載していきたのですが、その一方で、実際のプロジェクトで活用できるかどうかは活用する人材のスキルに依存し、時には有用に使いきれない可能性もあると感じました。理由としては、実際のプロジェクトの中ではWell-Architected Frameworkは書いてあることを全て実施することは難しいからです。実際のプロジェクトでは顧客の予算、工数、セキュリティ、コンプライアンスといった制約の中で最適な開発をしていかなければいけません。つまり、最終的には必ず顧客のニーズを的確に把握し、どのベストプラクティスを優先するべきか?適用するべきか?といった取捨選択を行う必要があります。そのため、まんべんなくWell-Architected Frameworkに書かれている内容を適用しようとすると顧客のニーズに合わずに工数が超過してプロジェクトが立ち行かなくなったり、本当に集中しないといけない要件にフォーカス出来ず本筋ではない部分に工数を必要以上に掛けてしまうといった可能性あるため、部分部分で採用するかどうかを判断するために情報収集を行い整理し決断するスキルもまた非常に重要であると感じました。
参考:AWS Well-Architected Frameworkに関連する記事
AUTHOR