はじめに
これまでの章で、アーキテクチャ設計の基盤となる考え方を整理してきました。
| 章 | テーマ | 問い |
|---|---|---|
| 第3章 | 構造 | どう分けるか |
| 第4章 | 特性 | なぜそれを選ぶか |
| 第5章 | 抽出 | どう見つけるか |
ここまでの章が「アーキテクチャをどう設計するか」を扱っていたのに対し、第6章が問うのは別の問いです。
「そのアーキテクチャは、時間が経っても維持できるのか？」
現実のソフトウェア開発では、開発が進むにつれてコードは変わり、チームメンバーも入れ替わり、要件も変化し続けます。意図して守る仕組みを持たないアーキテクチャは、時間とともに必ず崩れていきます。本書でも次のように述べられています。
アーキテクトは、プロジェクトのあらゆる局面でアーキテクチャ特性を分析し続ける必要がある
これが本章のテーマである「アーキテクチャ特性の計測と統制」が必要とされる理由です。
なぜ「計測」が必要なのか
アーキテクチャ特性には、パフォーマンス・可用性・モジュール性など様々なものがあります。しかしこれらの特性には共通の問題があります。定義が曖昧なのです。
「高パフォーマンス」「高可用性」「保守しやすい」といった言葉は、人によって意味が異なります。本書でも「一般的に使われているアーキテクチャ特性は、意味が曖昧なものが多い」と指摘されています。
曖昧なまま設計に持ち込めば、チーム内での認識がずれ、評価の基準も揃いません。だからこそ、特性を具体的な指標として定義し数値化する「計測」が必要になります。
なぜ「統制」が必要なのか
アーキテクチャ上の決定を下しても、それが守られなければ意味をなしません。開発者が意図せず逸脱する、パフォーマンス最適化の過程で構造が崩れる、チームの入れ替わりによって設計の意図が伝わらなくなる。こうした事態は、明示的な仕組みなしには避けられません。
設計は「作ること」より「守り続けること」の方が難しい。これが「統制（Governance）」が必要とされる理由です。
本章で扱うこと
本章では、アーキテクチャを維持し続けるための仕組みとして、次の2点を扱います。
アーキテクチャ特性の計測
曖昧な特性をどう定義するか、どのように数値化するか、どのレベルで測るべきか。
アーキテクチャ特性の統制
設計をどう守るか、チーム全体にどう浸透させるか、適応度関数による自動化監視をどう活用するか。
本章の位置づけ
第6章を加えることで、アーキテクチャ設計の流れが一つながりになります。
| 章 | テーマ | 問い |
|---|---|---|
| 第3章 | 構造 | どう分けるか |
| 第4章 | 特性 | なぜそれを選ぶか |
| 第5章 | 抽出 | どう見つけるか |
| 第6章 | 維持 | どう守り続けるか |
設計は作って終わりではなく、測り続け、守り続けて初めて価値を持ちます。第6章は、アーキテクチャを静的な成果物ではなく「生きたもの」として扱うための章です。ここからは、アーキテクチャを運用するフェーズに入ります。
📖ソフトウェアアーキテクチャの基礎
本書は、O’Reilly Media から出版された『Fundamentals of Software Architecture: An Engineering Approach』 の日本語版です。著者の Mark Richards と Neal Ford が、アーキテクチャを工学的視点から捉え直し、理論と実務を橋渡しする知見をまとめた一冊です。
https://www.oreilly.co.jp/books/9784873119823/
目次（全24章）
1章 イントロダクション
1.1 ソフトウェアアーキテクチャの定義1.2 アーキテクトへの期待
1.2.1 アーキテクチャ決定を下す
1.2.2 アーキテクチャを継続的に分析する
1.2.3 最新のトレンドを把握し続ける
1.2.4 決定の順守を徹底する
1.2.5 さまざまなものに触れ、経験している
1.2.6 事業ドメインの知識を持っている
1.2.7 対人スキルを持ち合わせている
1.2.8 政治を理解し、かじ取りをする
1.3 アーキテクチャと交わるもの
1.3.1 エンジニアリングプラクティス
1.3.2 運用とDevOps
1.3.3 プロセス
1.3.4 データ
1.4 ソフトウェアアーキテクチャの法則
第I部 基礎
2章 アーキテクチャ思考
2.1 アーキテクチャと設計2.2 技術的な幅
2.3 トレードオフを分析する
2.4 ビジネスドライバーを理解する
2.5 アーキテクティングとコーディングのバランスを取る
3章 モジュール性
3.1 定義3.2 モジュール性の計測
3.2.1 凝集度
3.2.2 結合度
3.2.3 抽象度、不安定度、主系列からの距離
3.2.4 主系列からの距離
3.2.5 コナーセンス
3.2.6 結合度とコナーセンスのメトリクスを統合する
3.3 モジュールからコンポーネントへ
4章 アーキテクチャ特性
4.1 アーキテクチャ特性の（部分的な）リスト4.1.1 アーキテクチャの運用特性
4.1.2 アーキテクチャの構造特性
4.1.3 アーキテクチャの横断的特性
4.2 トレードオフと少なくとも最悪でないアーキテクチャ
5章 アーキテクチャ特性を明らかにする
5.1 アーキテクチャ特性をドメインの関心事から捉える5.2 要件からアーキテクチャ特性を抽出する
5.3 事例：シリコンサンドイッチ
5.3.1 明示的な特性
5.3.2 暗黙的な特性
6章 アーキテクチャ特性の計測と統制
6.1 アーキテクチャ特性の計測6.1.1 運用面の計測
6.1.2 構造面の計測
6.1.3 プロセス面の計測
6.2 統制と適応度関数
6.2.1 アーキテクチャ特性の統制
6.2.2 適応度関数
7章 アーキテクチャ特性のスコープ
7.1 結合とコナーセンス7.2 アーキテクチャ量子と粒度
7.2.1 事例：Going、Going、Gone
8章 コンポーネントベース思考
8.1 コンポーネントの分類8.2 アーキテクトの役割
8.2.1 アーキテクチャの分割
8.2.2 事例：シリコンサンドイッチにおける分割
8.3 開発者の役割
8.4 コンポーネントを識別する流れ
8.4.1 初期コンポーネントを識別する
8.4.2 コンポーネントに要件を割り当てる
8.4.3 ロールや責務を分析する
8.4.4 アーキテクチャ特性を分析する
8.4.5 コンポーネントを再構成する
8.5 コンポーネントの粒度
8.6 コンポーネント設計
8.6.1 コンポーネントの発見
8.7 事例：「Going、Going、Gone」におけるコンポーネントの発見
8.8 アーキテクチャ量子再び：モノリシックアーキテクチャと分散アーキテクチャの選択
第II部 アーキテクチャスタイル
9章 基礎
9.1 基礎的なパターン9.1.1 巨大な泥団子
9.1.2 ユニタリーアーキテクチャ
9.1.3 クライアント／サーバー
9.2 モノリシックアーキテクチャと分散アーキテクチャ
9.2.1 誤信1：ネットワークは信頼できる
9.2.2 誤信2：レイテンシーがゼロ
9.2.3 誤信3：帯域幅は無限
9.2.4 誤信4：ネットワークは安全
9.2.5 誤信5：トポロジーは決して変化しない
9.2.6 誤信6：管理者は一人だけ
9.2.7 誤信7：転送コストはゼロ
9.2.8 誤信8：ネットワークは均一
9.2.9 分散コンピューティングにおけるその他の考慮事項
10章 レイヤードアーキテクチャ
10.1 トポロジー10.2 層の分離
10.3 レイヤーの追加
10.4 その他の考慮事項
10.5 このアーキテクチャスタイルを採用する理由
10.6 アーキテクチャ特性の評価
11章 パイプラインアーキテクチャ
11.1 トポロジー11.1.1 パイプ
11.1.2 フィルター
11.2 事例
11.3 アーキテクチャ特性の評価
12章 マイクロカーネルアーキテクチャ
12.1 トポロジー12.1.1 コアシステム
12.1.2 プラグインコンポーネント
12.2 レジストリ
12.3 コントラクト
12.4 事例とユースケース
12.5 アーキテクチャ特性の評価
13章 サービスベースアーキテクチャ
13.1 トポロジー13.2 トポロジーの種類
13.3 サービスの設計と粒度
13.4 データベース分割
13.5 アーキテクチャ例
13.6 アーキテクチャ特性の評価
13.7 このアーキテクチャスタイルがふさわしいとき
14章 イベント駆動アーキテクチャ
14.1 トポロジー14.2 ブローカー
14.3 メディエーター
14.4 非同期の能力
14.5 エラー処理
14.6 データロスの防止
14.7 ブロードキャスト能力
14.8 リクエスト・リプライ
14.9 リクエストベースとイベントベースの間を取る
14.10 ハイブリッドなイベント駆動アーキテクチャ
14.11 アーキテクチャ特性の評価
15章 スペースベースアーキテクチャ
15.1 一般的なトポロジー15.1.1 処理ユニット
15.1.2 仮想ミドルウェア
15.1.3 データポンプ
15.1.4 データライター
15.1.5 データリーダー
15.2 データ衝突
15.3 クラウドとオンプレミス
15.4 レプリケーションキャッシュと分散キャッシュ
15.5 ニアキャッシュの考慮
15.6 実装例
15.6.1 コンサートチケット販売システム
15.6.2 オンラインオークションシステム
15.7 アーキテクチャ特性の評価
16章 オーケストレーション駆動サービス指向アーキテクチャ
16.1 歴史と哲学16.2 トポロジー
16.3 分類
16.3.1 ビジネスサービス
16.3.2 エンタープライズサービス
16.3.3 アプリケーションサービス
16.3.4 インフラストラクチャサービス
16.3.5 オーケストレーションエンジン
16.3.6 メッセージフロー
16.4 再利用...と結合
16.5 アーキテクチャ特性の評価
17章 マイクロサービスアーキテクチャ
17.1 歴史17.2 トポロジー
17.3 分散
17.4 境界づけられたコンテキスト
17.4.1 粒度
17.4.2 データ分離
17.5 API層
17.6 運用面での再利用
17.7 フロントエンド
17.8 通信
17.8.1 コレオグラフィとオーケストレーション
17.8.2 トランザクションとサーガ
17.9 アーキテクチャ特性の評価
17.10 参考文献
18章 適切なアーキテクチャスタイルを選ぶ
18.1 アーキテクチャにおけるトレンドの変遷18.2 判断基準
18.3 モノリスの事例：シリコンサンドイッチ
18.3.1 モジュラーモノリス
18.3.2 マイクロカーネル
18.4 分散型のケーススタディ：Going、Going、Gone
第III部 テクニックとソフトスキル
19章 アーキテクチャ決定
19.1 アーキテクチャ決定に関するアンチパターン19.1.1 資産防御アンチパターン
19.1.2 グラウンドホッグデーアンチパターン
19.1.3 メール駆動アーキテクチャアンチパターン
19.2 アーキテクチャ上重要なもの
19.3 アーキテクチャデシジョンレコード
19.3.1 基本構造
19.3.2 ADRを保存する
19.3.3 ドキュメントとしてのADR
19.3.4 標準のためにADRを用いる
19.3.5 事例
20章 アーキテクチャ上のリスクを分析する
20.1 リスクマトリックス20.2 リスクアセスメント
20.3 リスクストーミング
20.3.1 特定
20.3.2 合意
20.3.3 軽減
20.4 ユーザーストーリーリスク分析
20.5 リスクストーミング例
20.5.1 可用性
20.5.2 弾力性
20.5.3 セキュリティ
21章 アーキテクチャの図解やプレゼンテーション
21.1 図解21.1.1 ツール
21.1.2 標準ダイアグラム：UML、C4、ArchiMate
21.1.3 図解ガイドライン
21.2 プレゼンテーション
21.2.1 時間を操る
21.2.2 段階的な構築
21.2.3 インフォデッキとプレゼンテーション
21.2.4 スライドは物語の半分
21.2.5 不可視化
22章 効果的なチームにする
22.1 チーム境界22.2 アーキテクトのパーソナリティ
22.2.1 コントロールフリーク
22.2.2 アームチェアアーキテクト
22.2.3 効果的なアーキテクト
22.3 どうやって管理する？
22.4 チームの警告サイン
22.5 チェックリストの活用
22.5.1 開発者のコード完成チェックリスト
22.5.2 ユニットテストと機能テストのためのチェックリスト
22.5.3 ソフトウェアリリースのためのチェックリスト
22.6 ガイダンスの提供
22.7 まとめ
23章 交渉とリーダーシップのスキル
23.1 交渉とファシリテーション23.1.1 ビジネスステークホルダーとの交渉
23.1.2 他のアーキテクトとの交渉
23.1.3 開発者との交渉
23.2 リーダーとしてのソフトウェアアーキテクト
23.2.1 アーキテクチャの4つのC
23.2.2 プラグマティックでありながらもビジョナリーであること
23.2.3 手本を示してチームをリードする
23.3 開発チームに溶け込む
23.4 まとめ
24章 キャリアパスを開く
24.1 20分ルール24.2 パーソナルレーダーの開発
24.2.1 ThoughtWorksテクノロジーレーダー
24.2.2 オープンソースのビジュアライゼーションビット
24.3 ソーシャルメディアの使用
24.4 別れの挨拶
付録A 自己評価のためのチェックリスト
参考文献
訳者あとがき
索引
関連書籍
6.1 アーキテクチャ特性の計測
アーキテクチャ特性を設計に取り入れる際、最初にぶつかる壁があります。「どうやって測るのか？」という問いです。
アーキテクチャ特性の計測が難しい理由
本書では、計測が難しい理由として主に3点が挙げられています。
定義が曖昧である
「高パフォーマンス」「高可用性」「保守しやすい」といった言葉は、人によって解釈が異なります。本書でも「一般的に使われているアーキテクチャ特性には、意味が曖昧なものが多い」と指摘されています。
定義が統一されていない
同じ「パフォーマンス」という言葉でも、開発者・アーキテクト・運用担当がそれぞれ異なる指標を見ています。チーム間の共通言語がなければ、議論も評価も噛み合いません。
特性は複合的である
多くの特性は単一の指標では測れません。パフォーマンスひとつをとっても、レイテンシー・スループット・応答時間といった複数の要素で構成されています。
計測の3つの視点
本書では、アーキテクチャ特性の計測を3つの観点から捉えることを提案しています。
6.1.1 運用面の計測
システムの振る舞いを測る視点です。代表的な指標としては、レスポンスタイム・スループット・エラーレート・CPU使用率などが挙げられます。
ここで注意が必要なのが、「パフォーマンス」という言葉の多義性です。本書では「パフォーマンスという言葉は、文脈によって意味が異なる」と指摘されています。ユーザー視点では画面表示の速さ、DevOps視点ではデプロイ時間、ビジネス視点では処理完了までの時間を指すことがあります。
同じ言葉を使っていても、測っている対象が異なる可能性があります。計測において最初に行うべきは、「何を測るか」を明確に定義することです。チームが共通の測定基準を持たない限り、数値を集めても意味をなしません。
6.1.2 構造面の計測
コードや設計の内部構造を測る視点です。代表的な指標として、循環的複雑度（Cyclomatic Complexity）・結合度・凝集度などがあります。
なかでも本書が重点的に紹介しているのが循環的複雑度です。コードの複雑さを定量化するメトリクスであり、分岐が増えるほど値が高くなります。テストケース数の目安としても活用されます。
図のように、コードの流れをグラフとして捉え、ノード（処理の単位）とエッジ（処理間の接続）の数から複雑度を算出します。
CC = E - N + 2
E：エッジ数、N：ノード数
複雑度が高いコードは、バグが増えやすく、理解が難しく、変更のリスクも高まります。本書でも「複雑度が高いコードは、保守性や品質に悪影響を与える」と述べられています。
ただし、数値だけで判断することには注意が必要です。複雑度が高くても問題にならないケースもあり、文脈を踏まえた解釈が求められます。
6.1.3 プロセス面の計測
開発プロセスそのものを測る視点です。デプロイ頻度・リリース時間・テスト時間・バグ発生率などが対象となります。
本書が強調するのは、アーキテクチャは開発プロセスにも影響を与えるという点です。テストに数週間かかる構造はアジリティを損ない、デプロイに数ヶ月かかる構造では市場の変化に対応できません。コードの構造が優れていても、プロセスが機能しなければ設計の価値は発揮されません。
計測の本質
3つの視点を整理すると、以下のようになります。
| 視点 | 対象 | 代表的な指標 |
|---|---|---|
| 運用面 | システムの振る舞い | レスポンスタイム、スループット |
| 構造面 | コードの内部構造 | 循環的複雑度、結合度 |
| プロセス面 | 開発の流れ | デプロイ頻度、リリース時間 |
計測できないものは改善できません。ただし、数値はあくまで判断材料であり、文脈を無視した数値の追求は本質を見失うリスクをはらんでいます。
アーキテクチャ特性の計測とは、曖昧な概念に共通言語を与え、チームが同じ基準で設計を評価できる状態をつくることです。
6.2 統制と適応度関数
前節では、アーキテクチャ特性をどのように「測るか」を整理しました。本節では次の問いに進みます。「測った特性をどうやって維持し続けるのか？」
なぜ「統制」が必要なのか
アーキテクチャは一度設計すれば終わりではありません。コードは日々変更され、チームメンバーは入れ替わり、仕様も変化し続けます。意図して守る仕組みを持たないアーキテクチャは、時間とともに少しずつ崩れていきます。本書でも「アーキテクチャ特性を維持するには、継続的な統制が必要である」と述べられています。
6.2.1 アーキテクチャ特性の統制
従来の統制手段としては、コードレビュー・ドキュメント・アーキテクトによるチェックが一般的です。しかしこれらはすべて人に依存しており、レビュー漏れや認識のズレが生じやすく、チームやコードベースが大きくなるほどスケールしません。本書でも「人手による統制だけでは限界がある」と指摘されています。
そこで必要になるのが、自動化された統制の仕組みです。
6.2.2 適応度関数（Fitness Function）
本章の核心となる概念が 適応度関数（Fitness Function） です。本書では「アーキテクチャ特性を客観的に評価するための仕組み」と定義されています。平たくいえば、「設計ルールを自動チェックする仕組み」です。
設計ルール
↓
適応度関数（テスト・ツール）
↓
違反を検出
アーキテクチャをテスト可能なものとして扱う、というのが基本的な発想です。
適応度関数の具体例
本書ではいくつかの具体例が紹介されています。
① 循環依存の検出
モジュール間で A → B → C → A のような循環依存が生じていないかをチェックします。JDepend などのツールで自動検出が可能です。
A → B → C → A という循環依存がコンポーネント間でどのように生じるかを示している図です。
② モジュール構造の検証
レイヤードアーキテクチャにおいて、プレゼンテーション層がデータ層を直接参照するといったレイヤー違反を検出します。ArchUnit を使うことで、設計ルールをコードとして定義し自動検証できます。
プレゼンテーション・コントローラー・サービス・永続化という層の構造を示す図です。
③ 循環的複雑度のチェック
前節で紹介した循環的複雑度が一定の閾値を超えた場合にビルドを失敗させることで、コードの複雑化を継続的に抑制できます。
④ プロセス指標の監視
デプロイ頻度やビルド時間といったプロセス指標を CI/CD パイプライン上で継続的に監視します。
適応度関数の種類
| 種別 | 内容 | 例 |
|---|---|---|
| 静的 | コード解析・依存関係チェック | JDepend、ArchUnit |
| 動的 | パフォーマンステスト・負荷テスト | 本番相当環境でのテスト |
| 自動 | CIパイプラインで実行 | PRのたびに自動チェック |
| 手動 | 定期的なレビュー | 四半期ごとのアーキテクチャレビュー |
理想は可能な限り自動化することです。実務上のイメージとしては、Pull Request のたびに適応度関数が実行され、違反があればマージをブロックする、という運用になります。
進化的アーキテクチャとの関係
適応度関数は、進化的アーキテクチャ（Evolutionary Architecture） という考え方と密接に結びついています。アーキテクチャは固定された成果物ではなく、継続的に進化するものであるという立場です。
適応度関数があることで、設計を変更しても意図しない劣化が即座に検出されます。これにより、変化への対応と品質の維持を両立できます。
本書ではNetflixの Simian Army も紹介されています。意図的に障害を発生させてシステムの耐性を検証するカオスエンジニアリングの手法であり、可用性というアーキテクチャ特性を「実際に試す」適応度関数の一例といえます。
まとめ
| よくある失敗 | 問題 |
|---|---|
| ドキュメントだけで管理する | 誰も守らなくなる |
| 手動チェックのみに頼る | 抜け漏れが生じる |
| 計測だけして終わりにする | 改善につながらない |
アーキテクチャは「守る仕組み」を持って初めて成立します。設計ルールをコードとして定義し、CIパイプラインで継続的に検証する。この仕組みを持つかどうかが、アーキテクチャが長期にわたって機能し続けるかどうかの分かれ目です。
良いアーキテクチャは、テストされている。
まとめ
第6章では、アーキテクチャ特性をどのように測り、どのように守り続けるかという設計の「運用フェーズ」を扱いました。各節のポイントを振り返ります。
6.1 アーキテクチャ特性の計測
アーキテクチャ特性は定義が曖昧であり、同じ言葉でも文脈によって意味が変わります。単一の指標で測れるものでもなく、複数の要素で構成されています。そのため、運用面（パフォーマンス・可用性）・構造面（複雑度・結合度）・プロセス面（デプロイ・テスト）という3つの観点から計測する必要があります。
6.2 アーキテクチャ特性の統制と適応度関数
アーキテクチャは時間とともに崩れていきます。コードレビューやドキュメントといった人手による統制には限界があり、自動化された仕組みが不可欠です。その中心となるのが適応度関数（Fitness Function）です。設計ルールをコードとして定義し、循環依存の検出（JDepend）・レイヤー違反のチェック（ArchUnit）・パフォーマンス測定といった形で継続的に違反を検出します。
進化的アーキテクチャ
適応度関数によって、アーキテクチャは固定された成果物ではなく継続的に進化するものとして扱えるようになります。Netflixの Simian Army に代表されるカオスエンジニアリングも、設計を「実際に試す」ことで品質を担保する適応度関数の一形態です。変化と品質を両立する、この設計思想が進化的アーキテクチャの本質です。
終わりに
第3章では「構造（どう分けるか）」、第4章では「特性（なぜそれを選ぶか）」、第5章では「抽出（どう見つけるか）」を扱いました。第6章ではさらに踏み込み、「それをどう維持し続けるか」というアーキテクチャの現実に向き合いました。
ここで見えてきたのは、アーキテクチャは「設計するもの」ではなく「継続的に育てるもの」であるという視点です。どれだけ優れた設計であっても、測らなければ崩れに気づけず、守らなければ形骸化し、試さなければ本当に機能しているかどうかも分かりません。設計は運用されて初めて意味を持ちます。
適応度関数という考え方は、アーキテクトの意図をコードに落とし、チーム全体で共有し、自動的に守り続けるための強力な仕組みです。「良いアーキテクチャとは、変化に耐えるものではなく、変化を受け入れながら進化できるものである」という本書の姿勢は、この仕組みによって初めて実現されます。
第6章までで、アーキテクチャ設計の基盤となる流れが揃いました。
| 章 | テーマ | 問い |
|---|---|---|
| 第2章 | 思考 | どう考えるか |
| 第3章 | 構造 | どう分けるか |
| 第4章 | 特性 | なぜそれを選ぶか |
| 第5章 | 抽出 | どう見つけるか |
| 第6章 | 維持 | どう守り続けるか |
第7章では「アーキテクチャ特性のスコープ（どこまで適用するか）」を扱います。設計の原則を理解したうえで、より実践的な設計判断そのものに踏み込んでいきます。