ソフトウェアアーキテクチャの基礎④ 第4章 アーキテクチャ特性

はじめに

前回の記事（第3章）では、モジュール性（Modularity）という観点から、「良い構造とは何か？」について整理しました。

• 凝集度・結合度・コナーセンス
• モジュールとコンポーネントの違い
• 変更に強い構造とは何か

といった観点を通して、
アーキテクチャの“ 構造 ”そのものに踏み込みました。

では次に考えるべき問いはこれです
「その構造は本当に正しいのか？」

同じ構造であっても、

• パフォーマンスを重視するのか
• 可用性を優先するのか
• セキュリティを最優先するのか

によって、最適な設計は大きく変わります。

ここで登場するのが、本章のテーマである
「アーキテクチャ特性（Architecture Characteristics）」 です。

本章では、以下のような問いに向き合います。

• アーキテクチャ特性とは何か？
• なぜ設計に大きな影響を与えるのか？
• どの特性を優先すべきなのか？
• トレードオフはどのように考えるべきか？

第3章で「構造」を理解した今、
第4章ではその構造を評価するための軸を手に入れていきます。

📖ソフトウェアアーキテクチャの基礎

本書は、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　自己評価のためのチェックリスト
参考文献
訳者あとがき
索引
関連書籍

アーキテクチャ特性とは何か

ソフトウェアを設計するとき、まず考えるのは「要件」です。

• 何ができるべきか？
• ユーザーは何をしたいのか？

しかし実際には、それだけでは不十分です。

---

システムは2つで構成される

システムは大きく分けて2つの要素から成り立ちます。

システム = 機能要件（What） + アーキテクチャ特性（How）

• 機能要件 → 「何をするか」
• アーキテクチャ特性 → 「どう実現するか」

→ この2つが揃って初めて“良いシステム”になります

アーキテクチャ特性とは

本書では、アーキテクチャ特性を次のように定義しています。

ドメイン（業務要件）とは独立して、
システムの成功に大きな影響を与える設計上の重要な側面

例えば

• パフォーマンス（どれくらい速いか）
• スケーラビリティ（どれくらい拡張できるか）
• セキュリティ（どれくらい安全か）
• 可用性（どれくらい止まらないか）

これらは「機能」ではないけど、超重要な特性です。
「何を作るか」ではなく、 「どう作るか」「どのレベルで満たすか」 に関わる要素です。

---

「非機能要件」と呼ばない理由

一般的には「非機能要件」と呼ばれますが、本書ではこの呼び方を避けています。

理由としては、

• 「非」という言葉が重要性を下げてしまう
• 実際には“最重要クラス”の要素だから

だからあえて本書では、「アーキテクチャ特性」と呼称します。

アーキテクチャ特性の3つの条件

本書では、アーキテクチャ特性は次の3つを満たすものとされています。

---

① 明示的：ドメインに依存しない

アーキテクチャ特性は、特定のビジネス領域に依存せず、どのシステムにも共通して求められます。

• ECでも金融でも共通
• ビジネス内容に関係なく必要

例

• セキュリティ
• 可用性
• パフォーマンス

---

② 暗黙的：構造に影響を与える

アーキテクチャ特性は、単なる要件ではなく、システムの構造そのものに影響を与えます。

例えば：

• 高いスケーラビリティ
  → マイクロサービス / 分散構成

• 高いセキュリティ
  → 認証・認可の分離

コードレベルではなく、「設計レベル」で影響が出るのが特徴です。

---

③ システムの成功に不可欠

重要なのは、「すべてを満たすこと」ではなく何を重視するかを選ぶことです。

• 特性を増やすほどシステムは複雑になる
• すべてを満たすのは現実的ではない

そのため、アーキテクトは優先順位を決める必要があります。

---

明示的 vs 暗黙的

アーキテクチャ特性には、次の2つの側面があります。

明示的

• 要件として明文化されている
• SLAなどで定義される

例

「レスポンスは200ms以内」

---

暗黙的

• 明文化されていないが、前提として求められる
• ドメイン知識や文脈から導かれる

例

金融システム → 低レイテンシー
SaaS → 高可用性

書かれていなくても「当然満たすべきもの」として扱われます。

---

以上を踏まえると
アーキテクチャは 「構造(どう分けるか)」 ＋ 「特性(なぜその構造なのか)」 で決まるといえ
アーキテクチャ特性とは、 設計の“評価軸” と言えるのです。

---

4.1 アーキテクチャ特性の分類

前節では、アーキテクチャ特性が
「システムの品質を決める設計の軸」
であることを見てきました。

「アーキテクチャ特性って具体的にどんな種類があるの？」

本書では、アーキテクチャ特性を大きく3つに分類しています。

---

① 運用特性（Operational Characteristics）

システムが「どのように動くか」に関する特性

「速いか？止まらないか？耐えられるか？」

用語	定義
可用性（Availability）	システムがどれくらいの期間利用できるか（24時間365日稼働する場合には、障害が発生した場合に迅速にシステムを稼働できるようにするための措置が必要となる）。
継続性（Continuity）	障害復旧能力。
パフォーマンス（Performance）	ストレステスト、ピーク分析、使われる機能の使用頻度、必要となる容量、応答時間の分析などが含まれる。パフォーマンスの受入れには、数か月にわたる独自の作業が必要になることもある。
回復性（Recoverability）	処理の持続性要件（例：災害時にシステムをどれだけ早くオンラインに戻す必要があるか）。これはバックアップ戦略とハードウェアの複製の要件に影響する。
信頼性／安全性（Reliability / Safety）	システムがフェイルセーフである必要があるのか、人命に影響を与えるようなミッションクリティカルなものであるのかを評価する。障害が発生した場合、会社に多額の費用がかかるだろうか？
堅牢性（Robustness）	実行中にインターネット接続が切れた場合や、停電やハードウェア障害が発生した場合に、エラーや境界条件を処理できるかどうか。
スケーラビリティ（Scalability）	ユーザー数やリクエスト数が増えてもシステムが動作する能力。

実務での例

• ECサイトでセール時に落ちないようにする
• APIのレスポンスを100ms以内に抑える
• トラフィック増加時に自動スケールする

設計への影響

運用特性を重視する場合、システムの設計は主にインフラ構成やアーキテクチャに大きな影響を受けます。

具体的には、以下のような設計要素が重要になります。

• キャッシュの導入
• 負荷分散（ロードバランサ）の活用
• 分散アーキテクチャの採用

これらはすべて、システムの可用性やパフォーマンス、スケーラビリティを向上させるための重要な要素です。

---

② 構造特性（Structural Characteristics）

システムの「構造そのもの」に関する特性

「変更しやすいか？理解しやすいか？」

用語	定義
構成容易性（Configurability）	エンドユーザーが（使い勝手の良いインターフェイスを介して）ソフトウェアの設定を簡単に変更できること。
拡張性（Extensibility）	新しい機能をプラグインで追加可能にすることをどれだけ重視しているか。
インストール容易性（Installability）	必要なすべてのプラットフォームへのインストールの容易さ。
活用性／再利用性（Leverageability / Reuse）	複数の製品で共通のコンポーネントを利用できること。
ローカライゼーション（Localization）	データフィールドの入力画面や問い合わせ画面、レポート、マルチバイト文字の要件、単位や通貨などが多言語に対応していること。
メンテナンス容易性（Maintainability）	変更の適用やシステムの拡張がどれだけ簡単に行えるか。
可搬性（Portability）	システムは複数のプラットフォームで動作する必要があるか？（例：フロントエンドはSAP DBだけでなくOracleに対しても動作する必要があるか？）
アップグレード容易性（Upgradeability）	サーバーやクライアント上で、このアプリケーション／ソリューションの旧バージョンから新バージョンへのアップグレードを簡単・迅速に行える能力。

実務での例

• 責務ごとにモジュール分割する
• テストしやすい構造にする
• 依存関係を整理する

設計への影響

構造特性を重視する場合、システムの設計は主にコード構造やアーキテクチャ設計に大きな影響を受けます。

具体的には、以下のような設計アプローチが重要になります。

• レイヤードアーキテクチャ
• クリーンアーキテクチャ
• モジュール設計の最適化

これらは、保守性や拡張性、再利用性といった品質特性を高めるための重要な要素です。
つまり、構造特性を重視する設計では、「どのように動かすか」よりも「どのように構造化するか」に重点が置かれます。

---

③ 横断特性（Cross-Cutting Characteristics）

システム全体に横断的に関わる特性

「どこにでも関係してくるやつ」

用語	定義
アクセシビリティ（Accessibility）	色覚障害や難聴などの障害を持つユーザーも含め、すべてのユーザーのアクセスしやすさ。
長期保存性（Archivability）	データは一定期間後にアーカイブまたは削除する必要があるか？（例：顧客のアカウントは3か月後に削除されるか、あるいは廃止されたものとしてマークされ、将来アクセスできるようにセカンダリデータベースにアーカイブされる）。
認証（Authentication）	ユーザーが何者かを確認するためのセキュリティ要件。
認可（Authorization）	ユーザーが（ユースケース、サブシステム、Webページ、ビジネスルール、フィールドレベルなどによって）アプリケーション内の特定の機能にのみアクセスできることを保証するセキュリティ要件。
合法性（Legal）	システムはどのような法的制約の中で運用されているか（データ保護、米企業改革法、GDPRなど）、会社はどのような権利留保を要求しているか？アプリケーションの構築方法やデプロイ方法に関する規制はあるか？
プライバシー（Privacy）	従業員から取引を隠せるか（取引が暗号化されていて、DBAやネットワークアーキテクトでさえも取引を見ることができなくなっているか）。
セキュリティ（Security）	データベース内でデータを暗号化する必要があるか？社内システム間のネットワーク通信を暗号化する必要があるか？リモートユーザーのアクセスにはどのような認証が必要か？
サポート容易性（Supportability）	アプリケーションにはどの程度の技術サポートが必要か？システムのエラーをデバッグするには、ログなどをどのようなレベルで整えておく必要があるか？
ユーザビリティ／達成容易性（Usability / Achievability）	アプリケーション／ソリューションでユーザーが目標を達成するのに必要なトレーニングのレベル。ユーザビリティの要件は、他のアーキテクチャ上の課題と同様に真剣に扱われる必要がある。

実務での例

• 認証・認可の統一
• ログの一元管理
• 分散トレーシング

設計への影響

横断特性を考慮する場合、システム全体に対する共通的な仕組みの設計が重要になります。

具体的には、以下のようなアプローチが挙げられます。

• ミドルウェア化
• 共通基盤の設計
• AOP（Aspect-Oriented Programming）的な仕組み

これらは、ログ出力や認証、トランザクション管理などの横断的な関心事を、個々の機能から分離して適用するための重要な手段です。

3つの関係性

これら3つは独立しているように見えて、実際には相互に影響し合いながら設計されます。

実務での理解

例えば、以下のような要件を考えてみます。

• 高パフォーマンス（運用特性）
• モジュール分割（構造特性）
• セキュリティ（横断特性）

これらは個別に考えるものではなく、すべてが絡み合いながら設計される必要があります。

例えば：

パフォーマンスを上げるためにキャッシュを導入すると、セキュリティ設計にも影響する
モジュール分割の仕方によって、認証・認可の適用範囲が変わる

このように、1つの意思決定が他の特性に波及するのが実務の難しさです。

よくある勘違い

すべての特性を満たそうとする

現実的にはかなり難しいです。 どこかを良くすると、別のどこかに影響が出ることがほとんどです。

特性を後から考える

後から対応しようとすると、設計ごと見直しになるケースも多いです。 最初の段階でざっくりでも考えておくだけで、後がかなり楽になります。

1つだけ最適化する

例えばパフォーマンスだけを優先すると、コードが読みにくくなったり保守が大変になったりします。 バランスを見ながら調整していくのが重要です。

一番大事なポイント

アーキテクチャ特性は「選択」と「優先順位」がすべて

• アーキテクチャ特性は3つに分類される

  • 運用特性（動き）
  • 構造特性（形）
  • 横断特性（全体）

• それぞれが設計に異なる影響を与える

• すべてを満たすことはできない

• トレードオフと優先順位が重要

4.2 トレードオフと「最悪でないアーキテクチャ」

ここまでで、アーキテクチャ特性には

• パフォーマンス
• 可用性
• セキュリティ
• モジュール性

など、さまざまな観点があることを見てきました。

では次の問いです
「全部満たせばいいのでは？」

結論：それは難しい

アーキテクチャ設計において、
すべての特性を同時に最大化するのは現実的ではありません

---

トレードオフの関係

アーキテクチャ特性は、多くの場合 トレードオフの関係 にあります。
ある特性を優先すると、別の特性に影響が出ることがよくあります。

代表的なトレードオフ

1. パフォーマンス vs 可読性

• パフォーマンス重視
  → 最適化された複雑なコードになりがち

• 可読性重視
  → シンプルだがパフォーマンスは控えめ

2. スケーラビリティ vs 一貫性

• スケーラビリティ重視
  → 分散システム

• 一貫性重視
  → 単一DB

CAP定理のトレードオフに近い話

3.セキュリティ vs 利便性

• セキュリティ重視
  → 多段認証などで手間が増える

• 利便性重視
  → シンプルなログイン体験

4.モジュール性 vs パフォーマンス

• モジュール分割
  → 呼び出しが増え、オーバーヘッドが発生

• 密結合
  → 高速だが変更に弱い

---

アーキテクチャに唯一の「正解」は存在しない

ここが重要なポイントです。
ではどう考えるべきか？

ここで出てくるのが「最良」ではなく「現実的にバランスの取れた選択」をする
最悪でないアーキテクチャ（Least Worst Architecture） という考え方です。

すべてを満たそうとすると、

• 設計が複雑になる
• 開発コストが増える
• 結果的にどれも中途半端になる

といった状態になりがちです。

実務での考え方

「何を優先して、何を許容するか」を決めることが重要です。

例1：スタートアップ

• 優先：開発スピード
• 許容：セキュリティや可用性の一部妥協

例2：金融システム

• 優先：安全性・一貫性
• 許容：開発スピードや柔軟性

---

トレードオフの判断軸

では、どうやって判断するのか？

ここで重要になるのが第2章「アーキテクチャ思考」に出てきた ビジネスドライバー です。
「ビジネス上の目標をどれだけ支援できるアーキテクチャ」を選ぶ観点です。

判断基準

• ビジネス的に何が最も重要か
• どの特性が成功に直結するか
• どこまでなら許容できるか

例

• ECサイト

  可用性 > パフォーマンス > セキュリティ

• 銀行

  セキュリティ > 一貫性 > パフォーマンス

よくある失敗

なんとなく全部やろうとする

❌ 破綻します

技術だけで判断する

❌ ビジネス無視

将来を考えすぎる

❌ 過剰設計

一番大事なこと

アーキテクチャとは「選択」と「妥協」である

• アーキテクチャ特性はトレードオフ関係にある
• すべてを満たすことはできない
• 「最悪でない選択」をすることが重要
• 判断基準はビジネスドライバー
• 設計は常に妥協の上に成り立つ

まとめ

第4章では、アーキテクチャ特性という観点から、
「なぜその構造を選ぶのか？」という設計の判断軸を整理しました。
本章のポイントを振り返ると

• アーキテクチャ特性とは何か

  • システムの品質を決める設計上の重要な要素（How）

• 特性の分類（3つ）

  • 運用特性（動き）
  • 構造特性（形）
  • 横断特性（全体）

• トレードオフの本質

  • すべての特性を同時に満たすことはできない
  • 常に「選択」と「妥協」が必要

• 最悪でないアーキテクチャ（Least Worst）

  • 最適解ではなく、文脈における現実的な最善を選ぶ

• 判断の基準

  • ビジネスドライバーに基づいて優先順位を決める

終わりに

第3章では「どのように構造を作るか」を見てきましたが、
第4章では「なぜその構造を選ぶのか」という視点に踏み込みました。

ここで見えてきたのは、
アーキテクチャの本質は構造そのものではなく、

「どの特性を優先し、どこで妥協するか」という意思決定

にあるということです。

同じ構造であっても、

• パフォーマンスを優先するのか
• 可用性を重視するのか
• セキュリティを最優先するのか

によって、その評価は大きく変わります。

つまりアーキテクトとは、

「最適な構造を作る人」ではなく、
「文脈の中で最適なバランスを見つける人」

と言えます。

また、良いアーキテクチャとは、

すべてを満たす完璧な設計ではなく、
制約の中で最も合理的な選択を積み重ねた結果

と言えます。

第4章までで、

• 第2章：思考（どう考えるか）
• 第3章：構造（どう分けるか）
• 第4章：特性（なぜそれを選ぶか）

という、アーキテクチャの基盤が揃いました。

次章（第5章「アーキテクチャ特性を明らかにする」）では、
この特性をどのように抽出し、設計に落とし込むのかを具体的に見ていきます。
ここからは「判断」から「実践」へと進んでいきます。