レビュープロセス

アーキテクチャのレビューは、徹底的な調査を促進する非難のないアプローチにより、一貫した方法で行う必要があります。話し合いで行う簡易なプロセス (数日ではなく時間) であり、監査ではありません。アーキテクチャレビューの目的は、対策を必要とする重大な問題や改善可能な領域を特定することです。レビュー結果は、お客様のワークロードの扱いやすさを改善する一連のアクションになります。

「アーキテクチャ」セクションで説明したとおり、各チームメンバーがアーキテクチャの品質に責任を持つ必要があります。Well-Architected フレームワークに基づいてアーキテクチャを構築するチームメンバーには、形式ばったレビューミーティングを開催するよりも、アーキテクチャを継続的にレビューすることをお勧めします。レビューを継続することで、チームメンバーはアーキテクチャの変化に応じて回答を更新したり、機能を提供しながらアーキテクチャを改善したりすることができます。

AWS Well-Architected フレームワークは、AWS がシステムとサービスについて内部でレビューを行う方法に適合しています。これは、アーキテクチャのアプローチに影響を与える一連の設計原則と、根本原因分析 (RCA) でよく取り上げられる領域が軽視されないようにするための質問を前提としています。内部システム、AWS のサービス、またはお客様に重大な問題があるときは、RCA を検討し、使用するレビュープロセスを改善できるかどうかを確認します。

レビューは、変更が難しい「一方向ドア」を避けるために、設計の早い段階で製品ライフサイクルの主要なマイルストーンで適用し、その後は運用開始日の前に適用する必要があります。（多くの決定は、リバーシブルの双方向ドアです。これらの決定には軽量なプロセスを使用できます。一方向ドアは反転するのが困難または不可能であり、ドアを作成する前にさらに検査する必要があります。） 本番稼働開始後に新しい機能の追加や技術の実装の変更を行うにしたがい、ワークロードは進化し続けるようになります。ワークロードのアーキテクチャは経時的に変化します。アーキテクチャを進化させるにつれてアーキテクチャの特性が劣化しないように、適切な予防策を取る必要があります。アーキテクチャを大幅に変更するときは、Well-Architected レビューを含めて、一連の予防プロセスに従う必要があります。

1 回限りのスナップショットまたは独立した測定としてレビューを活用するには、すべての適切な担当者を話し合いに参加させる必要があります。レビューを実施したことにより、チームが実装した内容を初めて本当に理解したということはよくあります。別のチームのワークロードをレビューするときに有効な方法は、そのアーキテクチャについて何度か気軽に話し合うことです。ほとんどの質問に対する回答はそれで得られます。その後、数回の会議で曖昧な領域や気付いたリスクについて解明したり、掘り下げたりすることができます。

会議をすみやかに進行するために、次のアイテムをお勧めします。

レビューが完了すると、ビジネスの状況に基づいて優先順位を付けることができる問題の一覧が提示されます。それらの課題がチームの日常業務に及ぼす影響を考慮する必要もあります。これらの問題を早期に解決すれば、繰り返し発生する問題を解決する時間を、ビジネス価値を創出するための時間に充てることができます。課題に対処する際にレビューを更新することで、アーキテクチャの改善具合を確認できます。

レビューの価値は 1 度やってみると明らかになりますが、新しいチームでは最初に抵抗があるかもしれません。レビューの利点をチームに知らせることで、次のような反論に対処できます。

組織内の他のチームと数回のレビューを実施すると、テーマに関する問題が見つかることがあります。例えば、特定の柱または主題に関して多くの課題を抱えているチームが複数、存在するかもしれません。すべてのレビューを総合的に検討し、それらの主題の問題に対処するのに役立つメカニズム、トレーニング、またはプリンシパルエンジニアリングの回答を見つける必要があります。