Well-Architected Frameworkで改善施策を立案する手順を徹底解説

当社デロイト トーマツ ウェブサービスはAWSより「Well-Architected パートナー」の認定を得ており、多くのお客様のワークロードのレビュー及び改善を行ってきました。また、同様に当社は「内製化支援推進 AWS パートナー」の認定も得ており、お客様の内製を推進しています。

AWS Well-Architected Frameworkを活用したワークロードの改善には一般にAWSのSAや我々のような「Well-Architectedパートナー」が多いですが、「内製化支援推進 AWS パートナー」としてこれをお客様自身でできるようなご支援をすることもあります。

そこで本ブログでは、内製でWAFR（Well-Architected Framework Review）を実施する方法を、AWSのドキュメントおよび当社の支援事例を交えながら紹介いたします。

Well Architected Frameworkの歴史

まずはWell Architected Frameworkの歴史についてです。2022年のre:Inventの中で以下のセッションがあります。

• AWS re:Invent 2022 - The well-architected way (ARC210) - YouTube
• ARC210_The-well-architected-wayスライド

こちらのセッションでは、以下のスライドでWell-Architected Frameworkの歴史が紹介されています。

（出典）ARC210_The-well-architected-way

Well Architected Frameworkは当初AWSのソリューションアーキテクト(SA)が行うものでした。そこからFrameworkとなり、2018年にお客様自身でレビューをできるツールとしてAWS Well Architected Toolのサービスがリリースされました。

• 新発表 – AWS Well-Architected Tool – クラウドベストプラクティスのレビューツール

以下の記載がある通り、AWS Well Architected ToolはAWSのSAの参加を必要とせず、お客様のレビュー依頼のニーズに応えるためにセルフサービス化したものです。

AWSのソリューションアーキテクト(SA)はお客様と共に、毎年、数千ものWell-Architectedレビューを実施しており、レビューを実施したお客様からは「レビューが大変価値のあるものだった」「レビュー結果をシステム改善に活用している」とのお声をいただいています。一方で、今まではすべてのお客様からのレビュー依頼にはお応え出来ていませんでした。

そこで、すべてのお客様にWell-Architectedレビューを実施いただけるように、私たちはAWS Well-Architected Toolを開発しました。このセルフサービス形式のツールは、お客様が自身でワークロードのレビューを実施出来るようにデザインされています。レビューへのAWSのSAの参加は必要ではなく、お客様は任意のタイミングでワークロードのレビューが出来ます。

WAFRのレビュープロセスのガイダンス

では、Well Architected Frameworkの活用について、AWSの提示しているレビュープロセスを確認してみましょう。

「AWS Well-Architected – 安全で効率的なクラウドアプリケーション」のページで、フレームワークの概要や6つの柱等の説明が記載してあります。また、そこからホワイトペーパーへのリンクを飛ぶことで、以下のレビュープロセスのページを見つけることができます。

• レビュープロセス - AWS Well-Architected フレームワーク

原則として、こちらの概要ページやホワイトペーパーを参考にしながらWAFRを進めていくことになります。

ホワイトペーパーとしてはこれより詳細化されているものはありません。これは先述の概要ページにも記載がある通り、Well-Architected Frameworkの各設問の予備項目はあくまで設計するための核となる戦略とペストプラクティスを経験から作成したものであるためです。

この経験を元に作られたこのフレームワークを活用しながら、実際にワークロードへ適用させるフェーズはお客様にて実施する必要があります。また、上記のWebページに以下の記載があるように、W-A PartnerやAWSからの支援を仰ぐ事が可能です。

AWS Well-Architected パートナープログラムのメンバーは、AWS Well-Architected Framework についての徹底したトレーニングを受講し、ベストプラクティスの実装、ワークロード状態の測定、サポートが必要な分野の改善を行うことができます。

より詳細化したガイダンスの必要性

ここまで見てきた通り、WAFRを実際のワークロードに適用させるにはW-A Toolの活用に加え、お客様によりそれをワークロードに適用させるためのWAFRの知見が必要になります。内製化を実現するためには、ここをAWSのSAやWell-Architected パートナーに依頼するのではなく、お客様自身で実施する必要があります。そこで、このフェーズを支援するツールとして、以下のAWSブログが公開されています。

• Well-Architected Framework Review の実施方法 – パート 1 | Amazon Web Services ブログ
• Well-Architected Framework Review の実施方法 – パート 2 | Amazon Web Services ブログ
• Well-Architected Framework Review の実施方法 – パート 3 | Amazon Web Services ブログ

これはAWS がお客様と多数の WAFR を実施した際に学んだ教訓のいくつかを共有するもので、各ステップの詳細を説明しています。これに則ることで、ホワイトペーパーより詳細なガイダンスを得ることができ、より具体的な進め方のノウハウを得ることができます。

具体的には、パート1, 2, 3の各記事が下図のPREPARE, REVIEW, IMPROVEに対応しています。

（出典）Well-Architected Framework Review の実施方法 – パート 1 | Amazon Web Services ブログ

しかし、このブログ記事を踏まえた上でもさらに課題があります。
AWSはWAFRのレビュー観点および改善のガイダンスをホワイトペーパーおよびブログ記事を通じて公開し、WAFRを行うツールとしてWell Architected toolを提供していますが、改善を行うツールは提供していません。

上記ブログ記事だと、パート3の「1- リスクの特定」を行うツールとしてWell Architected Toolが提供されていますが、「2」から「4」に相当するツールは提供されていません。（以降、簡略化のため下記をStep1, 2, 3, 4と表記します。）

• 1- リスクの特定 （別名：改善機会）
• 2- リスクの理解
• 3- 規範的なソリューションの決定
• 4- 実装と追跡

本ブログ記事の残りの部分では、お客様のご了承を得た上で、実際に当社が行った事例を公開します。
万能のアプローチではありませんが、WAFRを内製化するための一例としてご活用ください。

WAFRの結果を元にした改善施策の具体的な実施方法

Step1 リスクの特定 （別名：改善機会）

このフェーズについてはWell-Architected Toolが提供されているため、詳細の紹介は割愛します。
お客様のご要望および工数の都合により、レポートの発行および、この段階でピラーを絞り後続のステップへと進むことにしました。

Step2 リスクの理解

ブログ記事を参考すると、以下の6つの設問を念頭に、Step1で特定したリスクの理解を深めるフェーズが必要となります。

• リスクが影響を及ぼす可能性はどの程度か？
• お客様への影響は何か？
• 結果としてのビジネスへの影響は何か？
• リスクを完全に排除できるか、それとも軽減するのみか？
• 誰がリスクを負っているか？
• 誰がリスクの排除や軽減のための改善作業を担うか?

ブログ記事で以下の記載があるように、このフェーズでは運用担当者や部門責任者を交えながら、これらのリスクについてディスカッションするフェーズとなります。

主要なステークホルダーやビジネスオーナーにこれらの質問に答えてもらうことで、焦点を当てるべき最も重要なリスクのリストの作成と、それらに対処するための時間を予測するのに役立ちます。

今回の事例では、検出されたHRIについてホワイトペーパーおよび上記の設問を参考にしながらワークロードの実態についてディスカッションを行い、その結果を表計算ソフトに入力していきました。
なお、ここで記載しているホワイトペーパーとは、例えばOPS01-BP01の項目であれば以下のドキュメントのことを指します。

• OPS01-BP01 Evaluate external customer needs - Operational Excellence Pillar

一つの設問につき15分の時間枠でディスカッションを行い、これを設問数だけ繰り返しました。

Step3 規範的なソリューションの決定

ブログ記事では方法として

このステップでは、追加の調査、ディスカッション、概念実証の構築が必要になる場合があります。

と紹介されており、これ以上の情報は載っていません。

一般に当社がWell Architected 認定パートナーとしてソリューションをご提案する場合、ソリューションはホワイトペーパーを参照しながらご提案します。

一例として

• OPS01-BP01 外部顧客のニーズを評価する - オペレーショナルエクセレンスの柱

の場合、お客様が抱えられているリスクと以下のような記載を参考にしながら「開発チームと運用チームがビジネス目標を共有できるように、定期的に意見交換できる場を設ける」というようなソリューションを提示することが考えられます。

ビジネスニーズの理解: ビジネスの成功は、ビジネス、開発、運用の各チームを含むステークホルダー全体で目標を共有し、理解を深めることで実現できます。

今回の事例でも、上記のようにホワイトペーパーの記載およびStep2でのディスカッション内容を参考にしながら、Step3も15分の時間枠でディスカッションを行いました。

実際には、Step2, 3で各設問合計30分ずつの枠を確保し、これを設問ごとにディスカッションを行いました。表計算ソフトを利用し、以下のようにディスカッション結果を整理して記入しました。行ごとに各30分ディスカッションをするイメージです。

ここまでのディスカッションが完了すると、表計算ソフトにStep2とStep3のディスカッション結果が記入されている状態になります。これを生成AIに読み込ませてソリューションのサマリを作成したり、人の目でソリューションとして整理することでStep3を完了としました。

Step4 実装と追跡

実装と追跡というタイトルではありますが、ブログ記事内ではStep1-4のサイクルが回っている様子を表す図として以下が紹介されています。

（出典）Well-Architected Framework Review の実施方法 – パート 3 | Amazon Web Services ブログ

この図では「Step4 実装と追跡」は以下の2要素に分類されます。

• Prioritize improvements（優先順位付け）
• Implement & track improvements（実装と追跡）

Prioritize improvements（優先順位付け）

このうち優先順位付けについては、ブログ記事の中でアイゼンハワースタイルのプロットが紹介されています。

（出典）Well-Architected Framework Review の実施方法 – パート 3 | Amazon Web Services ブログ

こちらを活用してもよいですし、今回のお客様事例では重要性（Impact）と労力（Ease）の他にも考慮する観点が多々あったため、表形式に情報を整理し、独自で優先順位付けを行うこととなりました。

Implement & track improvements（実装と追跡）

実装については、優先順位付けしたものをBacklog等で管理をしながら一つずつ行っていくこととなります。
追跡については定期的にWAFRを行うことで行う事が可能です。これはWell Architected Toolでマイルストーンという機能が提供されているので、こちらを使うと有効です。

• マイルストーン - AWS Well-Architected Tool

本来はアプリケーションのマイルストンに合わせてWAFRを行うべきですが、今回のお客様の要件には合わなかったため、半年または一年のサイクルで繰り返すことで、常にワークロードを変化に対応させることができます。

KPI

最後にKPIについてです。
「Step1 リスクの特定」を行うことでレポートが発行され、高リスクの問題 (High Risk Issues, HRI) と中リスクの問題 (Medium Risk Issues, MRI) という形で可視化されます。
一見これをそのままKPIとして数を減らして行くのが簡単そうですが、それは推奨されていません。
クラウド環境のKPI設定のガイダンスとしては、以下のブログが参考になります。

• クラウドパフォーマンス指標 (KPI) を用いたクラウドバリューの測定方法 | Amazon Web Services ブログ

KPI を定めるうえで重要なことは、達成したいビジネスの成果や顧客が得られる価値を起点にして検討を始めることです。これは、ゴールに向けて正しく進んでいるかを測定するために必要な KPI を特定、決定するということです。また、ファイナンス部門とテクノロジー部門を跨ぐ共通言語で KPI を作成し、その効用と価値を社内で公開することでより効果を高めることができます。

Well-Architected FrameworkのHRI, MRIはワークロード上のリスクを可視化するための数値であり、上記に記載のあるような達成したいビジネスの成果や顧客が得られる価値を起点に考えられたものではありません。
Well-Architected Frameworkはあくまで改善のためのツールとして利用し、KPIは別途定める必要があります。

具体的なKPIには本記事では触れませんが、以下のブログ記事ではAWSの事例を通して得られた共通のテーマに関するKPIの例が記載されています。

• クラウドへの道しるべ：成功のための重要業績評価指標（KPI）とは | Amazon Web Services ブログ

ビジネス価値を測定するためのKPI の選定は、顧客満足度、業務効率、収益成長などへの影響を直接測定する分野に焦点を当てるべきです。万能のアプローチは存在しませんが、事例をとおしていくつかの共通テーマが見いだせてきています。以下は、ビジネス価値の柱ごとにみるKPI の例になります。

これらの情報を参考にKPIを設定し、Well-Architected Frameworkを通じてワークロードの評価および改善を行うことでより効果的なクラウド活用を実現する事が可能です。

まとめ

ここまで、WAFRから改善施策の実行までの流れをより詳細に紹介しました。
WAFRを行う場合は、まずはAWSが提供しているホワイトペーパーを参照することが重要です。そこでより具体的な方法が知りたい場合はAWSが公開しているブログを参照し、その上で具体例が知りたいという場合は本ブログをご活用ください。

本ブログ記事がAWS Well Architected Framework活用およびその内製化の一助となれば幸いです。

tecchan

プロジェクトリード / スクラムマスター / エンジニア

金融業界のSIerにて5年間勤務。大小様々な規模の案件にてプロジェクトマネジメントを経験後2022年5月にDWSへ入社。最先端の技術を用いる開発業務を担当。最近では先端技術への理解とマネジメントの経験を活かし、スクラムマスターとして案件を推進。AWS認定資格全12種取得。認定スクラムマスターPSMⅡ取得。