現代のソフトウェア開発では、チームの自律性と開発速度が重要視される一方で、アーキテクチャの一貫性も求められる。この相反する要求に応えるのが、アーキテクチャアドバイスプロセス（Architecture Advice Process, AAP）である。AAPはThoughtworks Technology Radar 2025-04掲載のTechniques/Trialである。
AAPは、誰でもアーキテクチャの決定を下せる分散型アプローチである。ただし、決定前に必ず影響を受ける人々と関連する専門家から助言を求めることが条件となる。重要なのは、これが承認プロセスではないことだ。助言は求めるが、許可を得る必要はない。
従来の中央集権的なアーキテクチャ管理では、少数のアーキテクトが全ての決定を担っていた。しかし、AAPでは意思決定の権限を分散化し、影響を受ける人々と関連する専門家が"助言"で関与する。これにより、適切な人数を巻き込みながら、意思決定の権限を最適化し、信頼関係を築きつつ、承認待ちの遅延を、必要十分な助言の会話に置換できる。
AAPの核心はシンプルである。1つのルールと1つの制約条件で構成される。ルールは「誰でもアーキテクチャ上の決定を下せる」こと。制約条件は「決定前に2つのグループに相談する」ことである。第一に、その決定によって重要な影響を受ける全ての人々。第二に、決定領域の専門家である。
従来のアーキテクチャガバナンスは、アーキテクチャレビューボード（ARB）という中央集権的な組織によって行われることが多い。ARBは組織内のソフトウェア開発プロジェクトのアーキテクチャ面をレビューし、承認する責任を負うガバナンス機関である。
ARBの主な目的は、エンタープライズアプリケーションが組織の戦略目標、標準、ベストプラクティス、アーキテクチャガイドラインに沿って設計・開発・保守されることを確保することだ。通常、経験豊富なアーキテクト、シニア開発者、組織のビジネス要件と技術要件を深く理解する主要な関係者で構成される。
ARBは確かに一貫性の確保、リスク軽減、ビジネス目標との整合性、品質保証、知識共有といった利点を提供する。アーキテクチャ標準やパターン、ベストプラクティスを適用することで、組織全体にわたってアプリケーション開発の一貫性を確保し、チーム間の連携、保守、ソフトウェア開発を容易にする。
しかし、中央集権的なアーキテクチャ審査には重大な問題がある。決裁待ちの行列が生まれ、価値の流れ（フロー）を阻害しやすい。実際、State of DevOps Reportでは、外部の変更承認（Change Advisory Board：CABなど）は"counterproductive（逆効果）"で、ソフトウェア配信パフォーマンスと負の相関がある一方、形式的承認プロセスが変更失敗率の低下に結びつく証拠はないとされている。ThoughtworksのTechnology Radarは、この状況への実務的な代替案としてAAPを提示している。「誰でも決められる。ただし関係者と専門家から助言を得る」という分権アプローチにより、品質を損なわずにフローを最適化できると評価している。
cf. Scaling the Practice of Architecture, Conversationally - martinfowler.com
AAPの実装は非常にシンプルである。その核心は一つのルールと一つの制約条件に集約される。
ルール：誰でもアーキテクチャ上の決定を下せる
制約条件：決定前に、意味のある影響を受ける人々と当該領域の有識者に助言を求める
この考え方は、従来の会議ではなく会話を制度化し、承認待ちではなく助言収集を標準プロセスにする点が革新的である。意思決定者は承認を待つ必要がない。必要なのは適切な人々との対話と、その記録である。助言は採用義務はないが、傾聴し、どう扱ったかをADRに記録する。
AAPにおいて重要なのは、助言と意見を区別することである。助言とは経験・証拠に基づく推奨であり、必ず理由が伴う。一方、意見は好みや根拠の薄い主観的な判断である。効果的なAAPには、根拠のある助言が不可欠である。
例）「Xは社内SLOを満たさない」→助言（根拠あり）／「Xは嫌い」→意見（根拠薄）
AAPが組織にもたらす利点は多岐にわたる。
ボトルネックの排除：決定権は当事者（個人またはチーム）にあるため、拒否権によって開発が停止することがない。従来のような承認待ちの行列が発生しない。
速度向上：合意は要件ではないため、助言を収集した後は前進できる。全員の同意を得る必要がないため、意思決定が迅速化される。
境界の健全化：誰に影響するかを洗い出す過程が、システムの責務境界を明確にする効果がある。影響範囲の分析により、システム設計の妥当性も検証される。
所有権の増大：決めた人＝実行する人という原則により、説明責任が明確になる。自らの決定に対する責任感が高まり、より慎重で実効性のある決定が期待できる。
社会的信頼：助言を求め・与えるという相互の合意が組織文化となる。これにより、チーム間の信頼関係が深まり、知識共有が促進される。
AAPについて理解する上で、それが何を目的としないかを明確にすることが重要である。
承認プロセスではない：助言は求めるが、許可をもらう必要はない。決定権は意思決定者にある。助言者には拒否権がない。
全会一致の合意形成ではない：反対意見があっても、それを記録し、必要なガードレール（段階的リリースなど）を設けて前進してよい。コンセンサスを求めるプロセスではない。
アーキテクト不要論ではない：アーキテクトの役割は決裁者からファシリテーターへとシフトする。助言の場づくり、原則や可視化の整備といった支援業務により価値を発揮する。
これらの特徴により、AAPは従来のガバナンスプロセスとは根本的に異なるアプローチとなっている。
cf. Scaling the Practice of Architecture, Conversationally - martinfowler.com
AAPの効果を測定するためには、適切な指標が必要である。Xapoの実践例を参考に、以下のような指標が有効である。
意思決定リードタイム：ADRの状態遷移（Draft→Proposed→Accepted→Adopted〔本番反映〕）で計測する。意思決定から実装完了までの時間を追跡することで、プロセスの効率性を評価できる。
助言の可観測性：ADRのAdvice欄に助言者、要旨、日付を継続的に記録する。助言プロセスの透明性と参加度を可視化する。
エンジニアリング成果：デプロイ頻度やリードタイムなどのチーム指標と合わせて傾向を確認する。AAPの導入がチームのパフォーマンスに与える影響を総合的に評価する。
Xapoの実践では、ADRにAdoptedステータスを設け、意思決定から実装の到達までを追跡した。これにより、決定が実際に価値をもたらすまでのプロセス全体を可視化している。
ビットコインのオンラインバンクであるXapoはDDD／Team Topologies／AAPを併用し、Architecture Advice ForumとADRを同時に立ち上げた。初回から“遡及ADR”で実案件を題材にし、各チームやInfoSec/規制/運用/プロダクトを巻き込む公開の助言習慣を作った。さらにADRの運用をJira等に載せ替え、決定から本番反映までのリードタイムを可視化。合意主義への回帰を避ける工夫やプロダクト戦略の同席などの学びも報告されている。
cf. Decentralizing the Practice of Architecture at Xapo Bank - martinfowler.com
AAPの実装において、失敗につながる主要なパターンを理解することは重要である。
良い失敗：経験の浅い人が意思決定を行う際に生じる小さな失敗は、実際には価値のある学習機会である。こうした失敗は透明性を高め、迅速な特定と修正を可能にする。意思決定者は実装時に問題を認識するため、安全に学びを振り返り、共有できる。これらの失敗は受け入れ、助言フォーラムで学習として可視化・共有する。
参加の偏り：最も危険な失敗モードは、一部のコアグループのみが参加し、本来関与すべき人々が参加しない状況である。初期段階では成功しているように見えるが、実際には多様な視点を活用できていない。誰が貢献しているかに注意を払い、発言の少ないメンバーの意見も積極的に求めることが重要である。
プロセスの迂回：助言フォーラムで取り上げられることなく、ADRにも記録されない決定が発生することがある。これに対しては、学習機会として捉え、決定を下した人々と共にプロセスを改善する姿勢が必要である。外部プレッシャーや重要性の誤認識など、様々な理由があり得る。
シャドー・アーキテクチャー：最も危険なのは、アーキテクトが表面的にはAAPを支持しながら、舞台裏で従来の決裁を続けることである。これはAAPの利点を全て無効化し、信頼関係を破綻させる。アーキテクトは適切なタイミングで、適切な人々と、適切な会話をするファシリテーターとしての役割に徹する必要がある。
アーキテクチャアドバイスプロセスは、現代のソフトウェア開発における「速度と品質の両立」という課題に対する実用的な解答である。従来の中央集権的なアーキテクチャガバナンスが抱えるボトルネックを解消しながら、アーキテクチャの一貫性と品質を維持することができる。
AAPの成功は、組織文化の変革にかかっている。承認を求める文化から助言を求める文化へ、合意形成から透明な意思決定プロセスへ、そして決裁者としてのアーキテクトからファシリテーターとしてのアーキテクトへの転換が必要である。
しかし、これは一朝一夕に実現できるものではない。適切なツールの導入、継続的な教育、失敗から学ぶ文化の醸成が不可欠である。特に、参加の偏りやプロセスの迂回といった失敗パターンを理解し、継続的に改善していく姿勢が重要である。
AAPは、アジャイル開発やDevOpsといった現代的な開発プラクティスとも親和性が高い。チームの自律性を重視しながら、組織全体の整合性を保つこのアプローチは、今後ますます重要性を増していくであろう。
Thoughtworks Technology Radar 2025-04でAAPをTrialとして掲出。中央集権的なARBはワークフローを阻害し低パフォーマンスと相関するとし、「誰でも決められるが、影響者と有識者に助言を求める」分権的意思決定を推奨。ADRや助言フォーラムを組み合わせることで、品質を保ちながらフローを最適化でき、規制産業でも成功例が増えていると述べる。
Andrew Harmel-Lawによる包括的なAAPガイド。「自分は建築的決定を取るのをやめた」と宣言し、中心化した承認型から会話に支えられた分権型への転換を説く。AAPの核心と、それを支える四要素（ADRs、助言フォーラム、チーム発の原則、内製Tech Radar）による学習と整合のメカニズムを詳説。失敗パターンや適用手順も具体的に提示している。
ビットコインのオンラインバンクXapoでの実践報告。DDDとTeam Topologies、AAPを組み合わせ、Architecture Advice ForumとADRを同時立ち上げ。開発から経営まで幅広い関係者を招く週次フォーラムとADRのAdvice欄の充実により整合と学習を獲得。JiraでADRを管理し「Adopted」状態を加えて決定リードタイムを可視化するなど、運用計測の工夫も紹介。
Romain VasseurによるAAPの実装ガイド。Harmel-Lawのアイデアに触発され、AAPの目的セット（知識生態系の構築、透明性と信頼、チームの自律、軽量だが効く仕組み）を提示。ADRの読み手優先設計やGitHub Issue/Discussionを用いた実装案（ADRハブ、助言スレ、ラベリングなど）を示し、軽量かつ追跡可能な運用を提案。
Lindsey Tibbittsによる実務者視点のAAP紹介。承認ではなく助言を求める分権的意思決定モデルの効果として、ボトルネック排除、合意不要での速度向上、システム境界の強化、所有権の増大、社会的信頼の醸成を列挙。助言と意見の違い（根拠ある推奨vs根拠なき好み）を強調し、「許可ではなく知識を求め、仕事に近い所で決め、互いを信頼する」姿勢の重要性を説く。
Andrew Harmel-LawによるO'Reilly出版の書籍。「分権とエンパワメント」を中核に、アーキテクチャを"みんなの仕事"として成立させる手引き。第4章でAdvice Processのワンペイジャー等の補助資料と共に概念〜導入〜運用を体系化。ADRs、助言フォーラム、原則、Tech Radarなど章立てされた実装ガイドを併載し、最小セットで始め記録と場で育てる実装哲学を提示。
DevOps Research and Assessment（DORA）による年次レポート。外部の変更承認（Change Advisory Board：CABなど）が"counterproductive（逆効果）"で、ソフトウェア配信パフォーマンスと負の相関があることを実証。形式的承認プロセスが変更失敗率の低下に結びつく証拠はないとし、AAPの理論的根拠を提供している。