1. はじめに
「うちのサービス、マイクロサービスに移行した方がいいですか？」
「レイヤードアーキテクチャとクリーンアーキテクチャ、どっちが正解ですか？」
設計の議論で、こうしたやり取りをよく見かけます。
こうした問いへの定番の返答は「それは要件によるかな」ですが、では「要件による」の先で、具体的にどう判断するのかが分からず、結局立ち止まってしまうことが多いのではないでしょうか。
アーキテクチャの選択は、後工程のコスト構造を一番大きく左右する判断です。
データベースを差し替える、レイヤー構成を変える、同期通信を非同期に変える
——どれもプロダクトが大きくなってからだと痛みを伴います。
それなのに「経験豊富なアーキテクトの勘で決まる」という空気もあって、
体系的に学ぶ機会が意外と少ないと感じていました。
この記事では、アーキテクチャ設計を「スタイルのカタログから選ぶ作業」としてではなく、品質要求を起点にした意思決定プロセスとして整理してみます。
何を根拠に判断し、どのように設計を進め、どう評価するか。
一連の流れとして眺めると、冒頭の質問の「正しい返し方」も自然に見えてきます。
2. TL;DR
- アーキテクチャは「品質要求 → スタイル選択 → 設計の具体化 → 評価」という意思決定プロセス。スタイルの好みではなく、品質属性と5つの考慮事項（Economy / Visibility / Spacing / Symmetry / Emergence）が判断軸になる
- 設計は文脈表現 → アーキタイプ定義 → コンポーネント分解 → インスタンス化の4ステップで段階的に具体化する。判断はADR（アーキテクチャ意思決定記録）で残す
- 評価にはATAMやPBARなどの手法があり、アジャイル開発でもWalking Skeletonと品質レビューでアーキテクチャ設計は両立できる
3. アーキテクチャとは何か ── 「大きな絵」の正体
アーキテクチャ設計の進め方を語る前に、
まず「アーキテクチャ」という言葉が何を指しているかを揃えておきたいところです。
この単語は立場によって指すものがけっこう違っていて、
共通理解がないまま議論しても議論が空中戦になります。
3-1. アーキテクチャの定義 ── 構造と判断の集合
建物の「アーキテクチャ」を思い浮かべると、
外観のシルエットだけを指す言葉ではないことが分かります。
各部材がどう統合されているか、周囲の環境とどう調和しているか、
目的にどう適合しているか、内装の細部はどうか。
そして、それらを支える「数千の大小の判断」の集合体です。
ソフトウェアのアーキテクチャも似た構造をしています。
具体的には次の3つを定義するものとして捉えられます。
- データと処理コンポーネントの構造
- コンポーネント間の相互関係（呼び出し、データの受け渡しなど）
- コンポーネントの外部から見える性質
ここで「コンポーネント」と呼んでいるものは、
プログラムモジュールやクラスのような小さい単位から、
データベースやミドルウェアのような大きい単位まで含みます。
アーキテクチャはこれらを横断する「全体構造」を扱うので、
特定のクラスの内部実装には踏み込まないのがポイントです。
そして大事なのは、
アーキテクチャは「動くプロダクト」ではなく「表現」だという点です。
実装する前に設計の良し悪しを分析し、代替案を比較し、
リスクを下げるための地図のような存在で、どんな設計の出発点もここから始まります。
3-2. なぜアーキテクチャに早く向き合うのか
アーキテクチャ設計の重要性は、よく次の3点で語られます。
- コミュニケーションの土台になる: 開発者・PM・運用・ビジネス側が同じ絵を見て話せる
- 早期の判断を可視化する: 後工程に大きく波及する判断を、早い段階で顕在化させる
- 構造モデルとして転用できる: スタイルやパターンは別のシステムにも応用できる
裏を返すと、間違ったアーキテクチャ判断は後工程すべてに波及し、
修正コストがどんどん膨らみます。
「アーキテクチャは最も早く行われる設計判断であり、変更コストが最も高い」
とよく言われるのは、この非対称性を指しています。
3-3. 4つのメタファー ── 立場によって異なる「アーキテクチャ」の意味
同じアーキテクチャ図を見ても、立場が違うと見え方が変わります。
代表的な見え方として、次の4つのメタファーが挙げられます。
┌──────────────────────────────────────────────────────────┐
│ アーキテクチャ記述 (Architectural Description, AD) │
├──────────────────────────────────────────────────────────┤
│ ① 設計図メタファー : 開発者 「実装の地図」 │
│ ② 言語メタファー : PM/マーケ 「合意のための共通語」 │
│ ③ 意思決定メタファー : プロジェクト管理「トレードオフの産物」 │
│ ④ 文献メタファー : 保守担当 「過去の判断の記録」 │
└──────────────────────────────────────────────────────────┘
│
複数のビューでまとめて記述する
▼
(ISO/IEC/IEEE 42010 が定義する AD の考え方)
開発者にとってアーキテクチャは「実装に落とす設計図」ですが、
PMやマーケから見ると「他部署と話を合わせる共通言語」になります。
プロジェクトマネージャーは「コスト・性能・保守性などのトレードオフの結果」として捉え、保守担当者は「過去の判断が残された資料」として扱います。
ここで知っておきたい用語が アーキテクチャ記述（Architectural Description, AD） です。
これは、複数の「ビュー」（視点ごとの表現）を束ねて1つのシステムを記述したもの、
と理解しておけば十分です。
アーキテクチャは1枚の図では表現しきれないので、視点ごとに図やドキュメントを分けて、
それらをまとめて記述として扱います。
なお、ADの考え方を整理した国際標準としてISO/IEC/IEEE 42010があり、
現行版は2022年版です。
設計の現場で意識しておきたいのは、
「自分が今書いている図は、誰の、どの視点のためのものか」を常に把握しておくこと。
同じ図を全員に見せて噛み合わない会話になるのは、
ビューの切り替えに無自覚なケースが多い印象です。
4. 何を根拠に判断するか ── 品質属性・考慮事項・判断の記録
アーキテクチャの全体像が掴めたところで、
次の問いは「実際に何を根拠に判断するのか」です。
直感や好みではなく、品質に対する要求と設計上の考慮事項に基づいて判断する。
そしてその判断は記録に残しておく——という3点セットを押さえると、議論の足場ができます。
4-1. 品質属性 ── 機能要件の裏にある判断基準
アーキテクチャを選ぶ根拠は「何を作るか（機能要件）」だけではなく、
「どう作るか（品質属性）」にあります。
品質属性は、機能要件の裏側で常に効いてくる非機能の特性です。
よく出てくる代表選手は次のあたりです。
- 信頼性 / 可用性
- 性能 / スループット / レイテンシ
- セキュリティ
- 保守性 / 変更容易性
- 拡張性 / スケーラビリティ
- テスト容易性
- ポータビリティ / 移植性
- 再利用性
- 相互運用性
これらをどの優先度で扱うかが、そのままアーキテクチャ判断の出発点になります。
「性能がボトルネックになるシステムなのか、保守性を優先したいシステムなのか」
で取りうる構造はかなり変わります。
品質属性を整理するときに地味に効くのが、
構造に踏み込む前に制御とデータの問いを立てることです。
- 制御: 制御はどう管理されるか? 階層はあるか? 同期か非同期か? 制御は共有されるか分散されるか?
- データ: コンポーネント間でデータはどう流れるか? 連続的か散発的か? 渡されるのか共有されるのか?
たとえばIoTデバイスのセンサーデータを扱うシステムで、
制御の置き方を2通り考えてみます。
- 中央オーケストレーター型: 中央が同期でデバイスに指示する。応答性が手堅い半面、中央が落ちると全停止する
- 各デバイス自律型: デバイスが非同期に発火する。耐障害性や拡張性は上がるが、可観測性の設計が難しくなる
同じ機能要件でも、ここを変えるだけで重視すべき品質属性は大きく変わります。
先に制御とデータの問いを立てておくと、
必要な品質属性が浮き上がってきやすくなります。
4-2. 5つの考慮事項 ── 判断の拠り所
品質属性が「何を最適化するか」の軸だとすると、
次に紹介する5つは「どんな性質を備えていれば良い設計なのか」の軸です。
ソフトウェアアーキテクチャの分野で整理されたもので、
覚えておくと議論で使いやすい5点セットです。
| 考慮事項 | 意味 | 軽視すると起きること | 例 |
|---|---|---|---|
| Economy（経済性） | 抽象化で不要な詳細を排除し、簡潔に保つ | 機能や階層が増えて保守不能になる | 使われない汎用フレームワーク導入で複雑化 |
| Visibility（可視性） | 設計判断とその理由が後から辿れる | 「なぜこの構造？」が誰にも分からなくなる | 主要な依存関係を図に明示する |
| Spacing（間隔） | 関心の分離。モジュール境界の引き方 | 過度に分けると断片化し、不足だと結合が肥大 | サービス境界を業務単位で切る |
| Symmetry（対称性） | 一貫性・均衡。対になる操作が揃う | API表面が荒くなり、利用者が混乱する |
open()があるならclose()がある |
| Emergence（創発性） | 自己組織化された振る舞いを許容する | リアルタイム要件を吸収できない | イベント駆動で順序を予め決めない |
注意したいのは、これらは独立ではなく相互作用するということ。
たとえばSpacing（分離）はEconomy（経済性）に強化されることもあれば弱体化されることもあります。
きれいに分けすぎると今度は全体像が見えなくなり、Visibilityが落ちます。
アーキテクチャの侵食について
コードを読んでもアーキテクチャ記述は明示的には現れません。
そのため、保守活動の中での小さな修正が積み重なって、
当初のアーキテクチャからじわじわとズレていく現象が起きます。
これを「アーキテクチャの侵食」と呼びます。
この侵食を防ぐ仕組みは、評価手法の章でも改めて取り上げます。
4-3. 判断を記録する ── ADRとSOAD
判断の根拠が整理できても、それを記録に残さないと、
半年後に自分でも理由を思い出せなくなります。
意思決定そのものを1つの「ビュー」として扱おう、というのがここでの話です。
実務で使われる軽量な仕組みが
ADR（アーキテクチャ意思決定記録, Architectural Decision Record） です。
アジャイル現場では、次の最小構成で書かれることが多いです。
- Title（タイトル）
- Context（背景・前提・制約）
- Decision（決定内容）
- Status（提案中 / 承認済み / 棄却）
- Consequences（決めた結果として何が起きるか）
もう少し詳しく書きたい場面では、より構造を増やしたテンプレートも使われます。
たとえば次のような項目立てです。
┌──────────────────────────────────────────────────┐
│ ADR (Architectural Decision Record) │
├──────────────────────────────────────────────────┤
│ Design Issue : 解こうとしている設計上の問題 │
│ Resolution : 採用したアプローチ │
│ Category : 設計カテゴリ (データ/構造/統合 …) │
│ Assumptions : 前提となった仮定 │
│ Constraints : 環境的な制約 (技術標準・既存資産) │
│ Alternatives : 検討した代替案と棄却理由 │
│ Argument : なぜその選択をしたか │
│ Implications : 採用したことによる影響 │
│ Related items : 関連する判断・関心事・成果物 │
└──────────────────────────────────────────────────┘
この技術は特にAI時代で開発速度が上がったからこそ必要なものなのかと考えています。
「最初は『とにかく作って直す』を繰り返すが、
やがて『先に判断を明示的に書くべきだ』と気づく」
プロトタイプを何回か投げているうちに、「繰り返す価値のある判断」が見えてきて、
それがチームや組織の中で再利用できる設計の型として定着していく。
記録がなければ、何度も同じ議論を繰り返すことになります。
組織レベルでこの記録を蓄積する仕組みが
SOAD（サービス指向アーキテクチャ意思決定） です。
役割としては次の2つで構成されます。
- ガイダンスモデル: 「このスタイル×このジャンルではこういう設計問題があり、こういう品質属性を比べる」という知識ベース
- 意思決定モデル: 実際のプロジェクトで何を判断したかの記録
運用は2方向の循環で行います。
- テーラリング: ガイダンスモデルから意思決定モデルへ、必要なものだけ取り出して使う
- ハーベスティング（収穫）: 終わったプロジェクトの学びをガイダンスモデルへ還元する
判断を記録することの最大の価値は、
自分の中で「いつイノベーションし、いつ既存のアーキテクチャを使うか」
の境界が引けるようになることだと感じています。
5. スタイルの引き出しを持つ ── 判断の「選択肢」を知る
判断軸が揃ったら、次は「選択肢」の知識です。
品質要求に応じてどのスタイルを候補に挙げるかを判断するには、
各スタイルの構造的な特徴と、得意な品質属性をざっくり把握しておく必要があります。
ここではスタイルを「カタログ的に詳しく解説するもの」ではなく、
判断材料の引き出しとして扱います。
5-1. スタイルとパターンの違い
似ているけれど混同しやすい2つの概念から整理します。
- アーキテクチャスタイル: システム全体の構造に適用される設計の型。コンポーネント / コネクタ / 統合の制約 / セマンティックモデルの4要素で記述される
- アーキテクチャパターン: スタイルより限定的な範囲で、特定の振る舞い上の問題に対する構造的な解法
3つの違いで対比させると分かりやすいです。
| 観点 | スタイル | パターン |
|---|---|---|
| スコープ | システム全体 | 特定の側面（一部分） |
| 性質 | 構造の「型」を提供する | 構造に「規則」を課す |
| 対象 | 全体構造の整理 | 特定の振る舞い（同期、並行、割り込み等）の解決 |
実際のシステムでは、1つのスタイルに収まることのほうが少なく、
複数のスタイルとパターンを組み合わせるのが普通です。
5-2. 主要なアーキテクチャスタイル
ここでは代表的なスタイルを、構造のイメージと得意な品質属性で並べます。
深掘りせずに比較表として眺められるくらいに留めます。
| スタイル | 構造の特徴 | 得意な品質属性 | 適用場面の例 |
|---|---|---|---|
| Data-Centered | 中央データストア + 周辺クライアント | 統合性 / 拡張性 | DWH、共有DB上のCRUDシステム |
| Data-Flow（パイプ&フィルター） | データを順次変換するフィルターをパイプで連結 | 再利用性 / 変更容易性 | バッチ処理、ETL、ストリーム処理 |
| Call-and-Return | 制御階層に基づく呼び出し（メイン/サブ、RPC） | 修正容易性 / スケーラビリティ | 業務システム、分散RPC |
| Object-Oriented | データと処理をクラスにカプセル化、メッセージで連携 | 保守性 / 再利用性 | ドメイン中心の業務アプリ |
| Layered | 外側から内側へ段階的に低レベル化する層構造 | 保守性 / 移植性 | OSライク、汎用Webアプリ |
| MVC | Model / View / Controller で関心を分離 | 保守性 / テスト容易性 | Webアプリのサーバサイド、GUIアプリ |
ASCII図で代表的な3つの構造を眺めておきます。
[Data-Centered] [Data-Flow]
┌────┐ ┌────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ C1 │ │ C2 │ │filter│─▶│filter│─▶│filter│
└─┬──┘ └──┬─┘ └──────┘ └──────┘ └──────┘
│ ┌──┐ │
▼ ▼ ▼ ▼ [Layered]
┌────────────┐ ┌────────────────────────┐
│ Repository │ │ User Interface │
└─┬───────┬──┘ ├────────────────────────┤
▲ ▲ │ Application Functions │
┌─┴─┐ ┌──┴──┐ ├────────────────────────┤
│ C3│ │ C4 │ │ Utility Services │
└───┘ └─────┘ ├────────────────────────┤
│ OS Interface │
└────────────────────────┘
各スタイルを少しだけ補足します。
-
Data-Centered: クライアントは中央リポジトリを介して間接的にやり取りする。
受動型（リポジトリ）と能動型（ブラックボード：データ変化時に通知）がある -
Data-Flow: 各フィルターは上下流の内部を知らない。
入出力の形さえ揃っていればフィルターの差し替えが容易 -
Call-and-Return: 機能を制御階層に分解。
階層を分散配置するとリモートプロシージャコール型になる - Object-Oriented: クラス階層と協調関係（コラボレーション）の組み合わせで構造を表す
- Layered: 外側がUI、内側がOS連携。中間層にユーティリティやアプリ機能を配置する
- MVC: もとはGUIアプリ向け。Webアプリのサーバサイドフレームワーク（Rails / Laravel等）で長く中核として使われてきた。フロントエンドは現在コンポーネントベース（React / Vue等）に主役が移っているが、関心の分離の原型として価値は変わらない
繰り返しになりますが、実システムでは複数のスタイルが組み合わさるのが普通です。
たとえばレイヤード + データ中心、Call-and-Return + Layered、といった具合です。
5-3. 現代のスタイルの位置づけ
「はじめに」で例に挙げたマイクロサービスやクリーンアーキテクチャといった現代スタイル。
これらは、上で整理した古典的スタイルの組み合わせや進化形として捉えられます。
- マイクロサービス: Call-and-Return（RPC型に加え非同期メッセージングも採用）+ サービスごとに独立したデータストア（Database per Service）。スケーラビリティと独立デプロイ性を最適化したスタイル
- イベント駆動アーキテクチャ: Data-Flow の非同期版。応答性と疎結合を最適化
- クリーンアーキテクチャ / ヘキサゴナル: Layered の系譜に依存性逆転の原則を組み合わせ、依存方向を内側（ドメイン）に強制することで保守性とテスト容易性を最適化
- サーバーレス: Call-and-Return を関数単位に細分化し、運用コストとスケーラビリティを最適化
ここで強調したいのは、
新しいスタイルが出てきても、判断のやり方は変わらないという点です。
「このスタイルは、どの品質属性を最適化するためのものか」を見れば、
自分のシステムに合うかどうかは前のセクションで整理した枠組みを用いて判断できます。
スタイル名のキャッチーさに引きずられないことが、
結局のところ意思決定プロセスの質を保つコツだと感じています。
6. 設計プロセスの4ステップ ── 構造を段階的に具体化する
判断軸とスタイルの引き出しが揃ったら、
いよいよ「実際にどう設計を進めるか」の話に入ります。
アーキテクチャ設計は一発で全体を決めるのではなく、
4つのステップで段階的に具体化していきます。
反復を前提にしているのがポイントで、
最後のステップで矛盾が見つかったら前のステップに戻ります。
6-1. ステップ1：文脈の表現 ── システムの「外」を定義する
最初にやるのは、システムの外側の世界を描くことです。
具体的には、対象システムと相互作用する外部エンティティを洗い出します。
- 上位システム（このシステムを呼び出す側、依存する側）
- ピアシステム（対等にやり取りする他システム）
- アクター（人間、UIデバイスなど）
- 下位要素（このシステムが利用するセンサー、外部API、外部DBなど）
これらと対象システムとのインターフェースを並べた図が アーキテクチャコンテキスト図（ACD） です。
流入・流出するすべてのデータを、この段階で粒度を揃えて特定しておきます。
UMLには文脈表現専用の図が無いので、ユースケース図 / クラス図 / コンポーネント図 / アクティビティ図 / シーケンス図などを組み合わせて表現します。
実務では、ここで「外部APIがいくつあって、どれが落ちるとサービス全体が止まるか」を洗い出すだけでも、後の品質属性の議論がぐっと具体的になる印象があります。
6-2. ステップ2：アーキタイプの定義 ── 核となる抽象を見つける
次に、システムの振る舞いの核となる抽象を取り出します。
これをアーキタイプと呼びます。
クラスに近いですが、実装詳細は含まない「役割の抽象」です。
たとえばホームセキュリティのようなシステムであれば、次のような抽象が考えられます。
- Node: 入出力要素のまとまり
- Detector: 何かを検知する装置の抽象（センサー類）
- Indicator: アラーム発報など出力の抽象
- Controller: ノードのアーム/ディスアーム（有効化/無効化）を担う制御の抽象
ここで大事なのは、
そこそこ複雑なシステムでも、必要なアーキタイプは少数ということです。
自分も「全クラスを抽象化しないと」と気負ってしまうことがあったのですが、
コア抽象は4〜6個程度に収まることが多く、これがアーキテクチャの基盤になります。
要件モデルの分析クラス（業務分析で出てきたクラス図など）から導出できることが多いので、ゼロから発明する作業ではないのも安心材料です。
6-3. ステップ3：コンポーネントへの分解 ── 構造を具体化する
アーキタイプを土台に、実装に近いコンポーネントを導いていきます。
コンポーネントの導出元は大きく2つです。
- アプリケーションドメイン: 業務領域のエンティティに対応するコンポーネント。要件モデルの分析クラスから導出する
- インフラストラクチャドメイン: メモリ管理、通信、データベース、タスク管理など、業務とは直接関係ないが不可欠な部品
ステップ1のACDで描いたインターフェースを処理する特化コンポーネントもここで派生します。
GUIのように、それ自体が大きなサブシステムを必要とするケースもあります。
ホームセキュリティの例だと、トップレベルのコンポーネントとしてこんな感じの分解になります。
- 外部通信管理（External Communication Management）
- コントロールパネル処理（Control Panel Processing）
- 検知器管理（Detector Management）
- アラーム処理（Alarm Processing）
各コンポーネントは反復的に詳細化していきますが、属性や操作の細部までは詰めません。
それは次の章（コンポーネントレベルの設計）の仕事です。
この段階では「箱と矢印」レベルで全体構造が立ち上がっていれば十分。
そう割り切るのが進めやすかったです。
ここで5章のスタイル知識が効いてきます。
「外部通信管理 + 検知器管理 + アラーム処理」を眺めて、コンポーネント間の関係を組み立てる選択肢を考えます。
Call-and-Returnで組むのか、内部にData-Flow（パイプ&フィルター）を持ち込むのか、データ中心で共有ストア経由にするのか。
スタイルはこの分解段階で選択肢として呼び出す引き出しになります。
6-4. ステップ4：インスタンス化 ── 具体的な問題で「証明」する
ここまでの設計はまだ高レベルの抽象で、頭の中のホワイトボード絵に近い状態です。
最後に、具体的な問題（具体的な機能・シナリオ）にアーキテクチャを適用して、
設計が機能することを示す段階に入ります。
ホームセキュリティの例だと、たとえば次のような具体化を行います。
- 検知器管理コンポーネントが、インフラ層のスケジューラコンポーネントと連携する
- スケジューラが各センサーオブジェクトをポーリングする
- 同じレベルの具体化を他のコンポーネントについても行う
このステップは「プロトタイプ」に近い役割で、
アーキテクチャが現実の文脈で破綻していないかを早めに確認できます。
ここで矛盾が見つかったら、ステップ2や3に戻って修正します。
反復前提の進め方が、このプロセスの肝です。
7. 設計判断を評価する ── 「本当にこのアーキテクチャでいいのか」
設計プロセスを通じて候補のアーキテクチャができたとして、
「本当にこれでいいのか」をどう確認するか。
アーキテクチャは比喩的に「賭け」と表現されることがあります
——その賭けが報われるかを確かめるのが、このセクションの話です。
7-1. ATAM ── トレードオフの体系的分析
代表的な評価手法に ATAM（アーキテクチャトレードオフ分析手法） があります。
ソフトウェア工学の研究機関で提唱された手法で、
ここでは流れを掴みやすいよう6ステップに圧縮した形で紹介します。
ステップ5の感度分析と、ステップ6のトレードオフポイントの特定がATAMの中心です。
たとえば「サーバー数」というアーキテクチャ要素を考えると、増やせば性能は上がるけれどコストも上がる。
つまりサーバー数は性能とコストの両方に効くトレードオフポイントになります。
こうした要素を可視化することで、
「どこを動かすと何が壊れるか」が分かるようになります。
6ステップを1回まわしたら、結果に応じて候補を絞り、
残った候補をさらに詳細化して再度ATAMを適用——という反復で精度を上げていきます。
ATAMの正式なステップ数について
ATAMの正式な手順は、2フェーズ・全9ステップ（ATAMの提示／ビジネスドライバの提示／アーキテクチャの提示／アプローチの特定／品質属性ユーティリティツリーの生成／アプローチの分析／シナリオのブレストと優先順位付け／アプローチの再分析／結果の提示）として整理されています。
本記事ではアジャイル文脈で要点を掴みやすくするため、感度分析・トレードオフポイントの特定という分析の中核を強調する6ステップに簡略化しています。
7-2. アーキテクチャレビュー ── 早期に問題を見つける
ATAMのような体系的手法以外にも、より日常的な評価手段がアーキテクチャレビューです。
要件レビューと違って、全ステークホルダーを集める必要はなく、
開発チームメンバー + 外部の専門家、というメンバー構成で行われることが多いです。
ただ、現実問題としてステークホルダーごとに見る場所はけっこう違います。
- アーキテクト: 長期的な非機能要件
- シニアマネージャー: ビジネス目標との整合
- プロジェクトマネージャー: 納期・予算
- エンジニア: 技術的関心・自分の担当領域
これらを単に並べると衝突しがちなので、賢明なアーキテクトはチーム（とステークホルダー）の合意を意識的に作る役割も担います。
業界でよく使われるレビュー技法は次のあたりです。
- 経験ベース推論
- プロトタイプ評価
- シナリオレビュー
- チェックリスト
レビューはプロジェクト初期だけのイベントではなく、
外部コンポーネントを取得した後など節目ごとに繰り返すのが望ましいです。
よくつまずくのは、「アーキテクチャの成果物自体が不十分でレビューが完了できない」というケース。
先のADRが効いてくる場面でもあります。
7-3. PBAR ── 軽量なパターンベースレビュー
ATAMはしっかりしている代わりに、
短いビルドサイクルやタイトな期限のプロジェクトには重すぎることがあります。
そんなときに使えるのが
PBAR（Pattern-Based Architecture Review, パターンベースのアーキテクチャレビュー） です。
PBARを実施するタイミングの目安は、Walking Skeletonが完成した直後です。
Walking Skeletonとは、最優先の機能要件と、最も挑戦的な品質属性をサポートする最小の動作するアーキテクチャのプロトタイプを指します。
短い準備時間と短いレビュー時間で、変化する要件に追従できるのが強みです。
PBARは6つのステップを反復します。
- ユースケースをウォークスルーしながら、最重要の品質属性を議論する
- アーキテクチャ図と要件の関係を議論する
- 使われているアーキテクチャパターンを特定し、システム構造とパターンを照合する
- 各パターンが品質属性に与える影響を分析する
- 議論の中で挙がった品質課題を整理する
- 短いサマリーをまとめ、必要ならWalking Skeletonに修正を入れる
アジャイルチームとの相性の良さがPBARの売りで、
スプリント運用と無理なく組み合わせられます。
7-4. アーキテクチャ適合性チェック ── 設計の侵食を防ぐ
設計が立派でも、実装が進む中で要件の矛盾・技術的困難・納期プレッシャーが押し寄せます。
すると、定義したアーキテクチャから少しずつズレていきます。
これが先ほど考慮事項のところで触れたアーキテクチャの侵食です。
定期的に「いまの実装は当初のアーキテクチャモデルと一致しているか」を確認する仕組みがあります。
それが SACA（Static Architecture-Conformance Analysis, 静的アーキテクチャ適合性分析） です。
アーキテクチャモデルの形式（UML等）を使って、
コンポーネントの静的構造と相互作用が崩れていないかを評価します。
実務的には、このモデルが作業の計画・割当・進捗評価のベースにもなります。
レビュー手法を一覧で整理しておきます。
| 手法 | 適用場面 | 必要なコスト | チーム規模 | 精度 |
|---|---|---|---|---|
| ATAM | 大規模 / 重要システムの本格評価 | 高（数日〜） | 中〜大 | 高 |
| PBAR | アジャイル / 小規模 / 短サイクル | 低（半日〜1日） | 小 | 中 |
| チェックリスト | 定常レビュー / 早期スクリーニング | 低 | 小〜中 | 低〜中 |
| 経験ベース推論 | 熟練者による初期判断 | 低 | 個人〜小 | 個人依存 |
| プロトタイプ評価 | 不確実性の高い要素の検証 | 中（実装コスト） | 小〜中 | 高 |
| SACA（適合性チェック） | 実装の継続的監視 | 中（ツール整備） | 中以上 | 中〜高 |
「常にATAM」ではなく、状況に応じて重さの違うレビューを使い分けることが、
現実的に評価サイクルを回すコツです。
8. アジャイル開発でのアーキテクチャ設計 ── 「Big Design Upfront」にならないために
ここまでの設計プロセスや評価手法は、
ともすると「最初に全部設計するウォーターフォール」に見えるかもしれません。
アジャイル開発との折り合いはどうつけるのか——というのが最後に残る問いです。
よく聞く2つの立場を並べると次のようになります。
- アーキテクチャ設計を敬遠する立場: 「Big Design Upfront（事前に全部設計する派手なやつ）」と同一視されるためアジャイルとは相容れないという見方
- 早めに注力すべきとする立場: 要件・ステークホルダー・グローバルユーザーが多い複雑なシステムでは、アーキテクチャ設計に早めに労力を割く価値があるという見方
両者は対立ではなく、程度問題として扱うのがしっくりきます。
[アジャイルでのアーキテクチャ設計サイクル]
┌─ ユーザーストーリーを収集 ────┐
│ │
▼ │
アーキテクチャストーリーを抽出 │
│ │
▼ │
Walking Skeleton を構築 │
│ │
▼ │
スプリントごとに品質をレビュー │
│ │
▼ │
Progressive Sign-off で │
段階的に承認 │
│ │
└────── 次のスプリントへ ─────┘
アジャイルとアーキテクチャを共存させるための代表的な手立ては次の5つです。
- ユーザーストーリーから要素を予測: ストーリーから暗示されている構造（共通的な認可、永続化、通知など）を早めに見出す
- Walking Skeleton: 最小限の動作するスケルトンをプロトタイプとして組み、最重要の機能要件と挑戦的な品質属性を初期段階で検証する
- ストーリーボーディング: アーキテクトがアーキテクチャストーリーを提供し、プロダクトオーナーがビジネスストーリーと優先順位付けを行う
- スプリントごとの品質レビュー: アーキテクトが非機能要件で定義された品質をチェック。問題があればスプリントに参加する
- Progressive Sign-off（段階的承認）: 進化していくプロダクトをプロトタイプ完了ごとにドキュメント化・承認する
もう1つ覚えておきたいのがRDA（Responsibility-Driven Architecture, 責任駆動アーキテクチャ）という考え方です。
アーキテクトを「上から命令する独裁者」ではなくサーバントリーダーとして位置付け、
いつ・どのように・誰がアーキテクチャ判断をするかに焦点を当てます。
アジャイルの哲学（チームへの権限委譲）と整合する考え方なので、現場で「アーキテクトと開発チームの関係をどう設計するか」を議論するときの足場になります。
プロジェクトの終わりには、各スプリントでレビューされてきたアーキテクチャと、対応する成果物のセットが手元に残る。
これがアジャイル × アーキテクチャの目指す状態です。
9. おわりに
冒頭の「マイクロサービスに移行した方がいいですか？」という問いに、
もう一度戻ってみます。
この問いに正面から答えるのが難しいのは、問いの中に判断の根拠が無いからでした。
この記事で整理した道具立てを並べると次の通りです。
- 判断の根拠: 機能要件の裏にある品質属性（性能・保守性・セキュリティ等）と、設計上の5つの考慮事項（Economy / Visibility / Spacing / Symmetry / Emergence）
- 判断の記録: ADRとして残し、組織的にはSOADで蓄積する
- スタイルの扱い: 「カタログから選ぶもの」ではなく、判断軸に応じて呼び出される引き出し
- 設計プロセス: 文脈表現 → アーキタイプ定義 → コンポーネント分解 → インスタンス化の4ステップを反復しながら具体化する
- 評価と侵食対策: ATAMやPBARで評価し、SACAで実装が当初の構造から侵食されていないかを監視する
- アジャイルとの両立: Walking Skeleton と Progressive Sign-off で、スプリント運用に組み込める
アーキテクチャに「絶対的な正解」は無いと感じます。
けれど、「根拠のある判断」は確かに存在する。
品質要求を起点に判断し、判断を記録し、評価を繰り返すことで、アーキテクチャという「賭け」の勝率は少しずつ上げていけます。
冒頭の質問に対する自分なりの返し方は、いまではこうなりました
——「品質要求を一緒に整理させてください、その後で候補を比較しましょう」と。