Well Architectedフレームワークを使ってプロダクトをレビューしてみた

Well Architectedフレームワークを使ってプロダクトをレビューしてみました。

kimura.kosuke

2021.12.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

1. はじめに

CX事業本部 IoT事業部の木村です。先日からチーム内でWell Architected(以下「W-A」と表記します。) フレームワークのレビューを実施しています。

項目が多かったり、記述の解釈で困ったりと少々迷うこともありましたので、われわれのチームでどのように実施しているかについて書いていきます。

こちらから確認ができます。

素のドキュメントがとっつきづらい場合は、こちらの記事も大変参考になります。

[初心者向け]AWS Well-Architected ドキュメントの歩き方

また、レビュープロセスのドキュメントも公開されており、実践するにあたり参考になります。

私たちのチームではサーバーレスな構成でIoTプロダクトを作成しています。そのため、以下のレンズを適用しました。

ただし、質問数だけでそれぞれ52問、9問、35問となり、合計96問。その中に個別のチェックリストがあり、それぞれの回答を考えるだけで相当な時間がかかります。また、それらをチームで同期的なコミュニケーションの中で進めるとなると時間がいくらあってもたりません。

ということで、レビュープロセスを極力守りながら、時間の効率よく進められるよう以下のように実施しました。

レンズごとに全ての柱を進めるのではなくて、柱を一つ指定してレンズ横断でレビューを実施しました。基本のW-Aフレームワークで検討した事項が、他のレンズでは具体的な内容になっていることも多いです。項目ごとの関連性が意識され、コンテキストチェンジを防ぐことができるので、レビューの効率が上がりました。

また、チーム内で優先度を話し合い、

という順番で取組みました。

Google Spread Sheetを使用して、レビューを実施しました。 ↓こんな感じ

Well Architected Toolも検討しましたが、以下の理由で使用を見送りました。

一方で、Well Architected Tool自体は関連リソースへのリンクが充実していたり、レビュー結果が一眼で分かったりと非常に有用なツールだと思います。

同期的なコミュニケーションですと時間がかかりすぎてしまうため、以下のような順序でレビューを進めました。

1.は適切な担当者を決めて一次回答を一気に書きます。主にエンジニアが書くようにしています。その際、わからないところや不明瞭なところはチェックしておきます。

2.については、できるだけ多くのメンバーに目を通してもらう必要があります。1.でチェックしたところを重点的にレビューするようにすると効率的です。また、基本W-AのOPS1, OPS2のようなビジネス全般にかかわる事項は早々に切り上げて、3.で重点的に話すようにします。

3.では、質問事項とその回答の理解は2.で予め担保されているという前提で、対応策の優先順位を決めることに注力して行います。そこで対応策のメニューが出揃ったら、以降のスプリントミーティングで優先度を話し合って着手していきます。

担当者による一次回答、非同期レビュー、同期的レビューを終えても理解できないチェックリストの項目も何個かありました。その場合は、AWSのSAの方に相談しました。抽象的な質問でも、周辺事項をヒアリングした上でかなり具体的な回答をいただけるので大変ありがたかったです。

実際に取り組んでみると、W-Aのドキュメントは思ったよりも具体的な対応策が書かれているなという印象を持ちました。また、IoTやサーバーレスなどの各レンズではさらにその傾向が強まります。すぐにでも実装に活かせそうなアドバイスも数多くありました。

また、W-Aフレームワークは抽象度が高い記述がある一方で、非常に網羅的なチェックリストになっています。それまで気づくことすらなかった事項をリストアップすることができるので、一通りチェックをこなしたあとはプロダクトにかなり自信をもつことができます。

一方で、全てのレビューをこなすのはそれだけでも大変です。また、全てに適合することはおそらく不可能で、ビジネス的な優先度の話になってくると思います。チームの状況に合った方法を見つけることが大切だなと思いました。