ソフトウェアアーキテクチャの基礎⑤ 第5章 アーキテクチャ特性を明らかにする

はじめに

前回の記事（第4章）では、アーキテクチャ特性という観点から、「なぜその構造を選ぶのか？」という設計の判断軸を整理しました。

• アーキテクチャ特性とは何か
• 運用・構造・横断という分類
• トレードオフと「最悪でないアーキテクチャ」

といった観点を通して、
アーキテクチャの“評価軸”を理解してきました。

次に考えるべき問いはこれです
「そのアーキテクチャ特性は、どうやって見つけるのか？」

実務では、

• 要件にすべて書かれているわけではない
• ステークホルダーごとに重要視するものが違う
• 暗黙的に求められている品質も多い
  といった状況がほとんどです。

つまり、「重要な特性は、自動的には見えてこない」
ここで登場するのが、本章のテーマである
「アーキテクチャ特性を明らかにする」というプロセスです。

本書では、アーキテクチャ特性を特定することは、

アーキテクチャを検証したり、
既存の設計の妥当性を判断するための最初のステップである

と述べられています。

本章で扱うこと

これまでの流れを整理すると

• 第3章：構造（どう分けるか）
• 第4章：特性（なぜそれを選ぶか）
• 第5章：抽出（どう見つけるか） ← 今ここ

本章では、アーキテクトがどのようにして
「本当に重要な特性」を見つけるのか

を、次の観点から見ていきます。

• ドメインの関心事から特性を捉える方法
• 要件から特性を抽出する方法
• 実際の事例を通した特性の導出プロセス

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

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

5.1 アーキテクチャ特性をドメインの関心事から捉える

前節では、アーキテクチャ特性は「自然に見えてくるものではなく、意識的に抽出する必要がある」ことを見てきました。

では、どこからその特性を見つければよいのでしょうか？
その出発点となるのが ドメインの関心事（Domain Concerns） です。

ドメインの関心事とは何か

ドメインの関心事とは、そのシステムが解決すべきビジネス上の重要な課題や目的を指します。

例えば

• ユーザー数はどれくらいか？
• システムはどのくらいの負荷に耐える必要があるか？
• どのような操作が重要か？
• どの程度の安全性が求められるか？

など

本書では、

アーキテクチャ特性を導き出すには、ドメインの関心事を理解することが重要である

とされています。

では、なぜドメインから考えるのか？
それはアーキテクチャ特性は技術からは生まれないからです。

例えば、

• 「マイクロサービスにするか？」
• 「キャッシュを使うか？」

といった技術選択は、ドメインの要求があって初めて意味を持つものです。

---

✖NGパターン

「とりあえずスケーラブルにしたい」

この言葉には「なぜスケーラビリティが必要なのか」という根拠が欠けています。

〇正しい考え方の流れ

第４章で述べられたようにシステムは大きく分けて2つの要素から成り立ちます。

システム = 機能要件（What） + アーキテクチャ特性（How）
　　　　　　「何をするか」　　　　　「どう実現するか」

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

アーキテクチャ特性を決定する際は、以下の順序で思考することが重要です。

ユーザー数が急増する可能性がある → スケーラビリティが必要 → 分散構成を検討

つまり、ドメイン → アーキテクチャ特性 → 設計 という順序で導くべきです。

ドメインからアーキテクチャ特性へ変換する

本書では、ドメインの関心事を「アーキテクチャ特性へ翻訳する」という考え方が示されています。

ドメインの関心事	アーキテクチャ特性
ユーザー数が多い	スケーラビリティ
高速な応答が必要	パフォーマンス
安全な取引が必要	セキュリティ
長時間稼働が必要	可用性

このように、ドメインの言葉を「〜性（-ility）」という形式に変換することが、設計の出発点となります。

実務でありがちなミスを整理します。

• ドメインを見ずに設計する
  技術トレンドや特定の技術スタックを起点にすると、ビジネス要件とのミスマッチが生じます。

• すべての特性を重要視する
  優先順位のない設計は破綻します。特性間にはトレードオフが存在するため、重要度の選別が不可欠です。

• 表面的な理解にとどまる
  「ユーザーが多い → スケーラビリティが必要」という対応関係を把握するだけでは不十分です。どの程度のスケール要件なのか、コストとのバランスはどうかといった定量的な検討が必要になります。

本書が強調しているポイント

本書の中で特に重要な一文があります。

すべてのアーキテクチャ特性をサポートするアーキテクチャは存在しない

つまり、重要な特性を見極め、取捨選択すること自体が設計行為 であるということです。

ステークホルダーとの関係

アーキテクチャ特性は、立場によって重要視するものが異なります。

ステークホルダー	主な関心事
ビジネス	市場投入スピード
開発者	保守性
運用	可用性

それぞれの関心事が異なる以上、ステークホルダーとの対話を通じて優先度を合意することが不可欠です。

「言語の違い」という構造的な問題

ここで見落とされがちなのが、アーキテクトとドメインのステークホルダーが「異なる言語を話している」という問題です。

アーキテクトが語る言葉：スケーラビリティ、可用性、耐障害性、相互運用性
ステークホルダーが語る言葉：市場投入までの時間、ユーザー満足度、競争上の優位性、合併・買収

この「ロスト・イン・トランスレーション」問題を解消するのが、前述のドメイン → アーキテクチャ特性への翻訳です。ステークホルダーの言葉をそのまま受け取るのではなく、その背後にある複数の特性を読み解く必要があります。

5.2 要件からアーキテクチャ特性を抽出する

前節では、アーキテクチャ特性はドメインの関心事から導くべきものであることを確認しました。本節では次のステップとして、「実際の要件からどのように特性を見つけるか」を整理します。

要件に明示されているとは限らない

本書では以下のように述べられています。

アーキテクチャ特性の中には、要件文書に明示されているものもある

しかし重要なのは、その続きです。ほとんどの場合、設計上重要な特性は要件に明示されていません。アーキテクトには、要件を「そのまま読む」のではなく「解釈する」姿勢が求められます。

例：「1000人の学生が同時にログインする」

一見するとただの制約条件ですが、この一文から読み取れるアーキテクチャ特性は複数あります。

要件の記述	解釈	アーキテクチャ特性
同時アクセス1000人	負荷が高い	スケーラビリティ
10秒以内に完了	応答時間の制約	パフォーマンス
常時利用可能	停止が許容されない	可用性
個人情報を扱う	保護が必要	セキュリティ

要件の「裏にある意味」を読み取ることが、特性抽出の本質です。

アーキテクチャ・カタ（Architecture Kata）

本書では、この読み取り能力を鍛える演習として アーキテクチャ・カタ が紹介されています。短時間で設計し、チームで議論しながらアーキテクチャ特性を抽出する訓練です。

本書はアーキテクトに求められるコアスキルを次のように定義しています。

アーキテクトは、ドメインの問題から重要な特性を導き出す能力が必要

要件を見て特性を見抜き、設計に落とし込む。この一連のプロセスがアーキテクトの本質的な仕事です。

見落とされがちな「追加コンテキスト」

要件に書かれていない情報が、特性の決定に大きく影響することがあります。

先ほどの学生ログインの例で考えてみます。要件には「1000人が同時にログインする」とだけ書かれていたとします。しかしドメイン知識として「ユーザーは学生であり、試験前に一斉にアクセスが集中する」という背景を知っていれば、導かれる特性は変わります。

• 弾力性（Elasticity）：急激なアクセス増加に対して動的にスケールできる必要がある
• スケーラビリティ：ピーク時の同時接続数に耐える必要がある
• 可用性：試験前という重要なタイミングでの停止が許容されない

この例が示すように、アーキテクチャ特性はドメイン知識によって大きく変わります。「書かれていない前提」を読み取る力が、アーキテクトには不可欠です。

よくある失敗パターン

• 要件をそのまま受け取る
  記述を額面通りに受け取るだけでは、背後にある設計上の意図を見逃します。

• 明示された特性しか見ない
  要件に「スケーラビリティが必要」と書かれていなければ考慮しない、という姿勢は危険です。暗黙の要件こそが設計の分かれ目になることが多くあります。

• 数値だけを見る
  「1000人」という数値に着目するあまり、「なぜ1000人なのか」「どのタイミングで集中するのか」という文脈を見落とすケースが典型的です。

実務で使える思考フレーム

要件からアーキテクチャ特性を抽出する際の思考ステップを整理すると、次のようになります。

1. 要件を読む：何が書かれているかを把握する
2. 意味を考える：なぜその制約が存在するのかを考える
3. 特性に変換する：どの「〜性（-ility）」に対応するかを特定する

5.3 事例：シリコンサンドイッチ

ここまで、ドメインから特性を導く方法（5.1）と要件から特性を抽出する方法（5.2）を整理しました。本節では、それを具体的なケースに適用してみます。

本書では 「シリコンサンドイッチ」 という架空のフードデリバリーシステムを題材に、アーキテクチャ特性の抽出プロセスを解説しています。システムの概要は以下のとおりです。

• オンラインでサンドイッチを注文できる
• 注文・決済・在庫などの機能を持つ
• 多くのユーザーが利用する想定

一見シンプルなシステムですが、ここからどのようにアーキテクチャ特性を導き出すかが、このセクションの主題です。

5.3.1 明示的な特性

まず、要件として明確に記述されている特性から確認します。

たとえば要件に次のような記述があるとします。

• 多くのユーザーが同時に利用する
• 注文処理は迅速に行う必要がある
• システムは常に利用可能であること

この場合、各記述から以下の特性が直接導けます。

要件の記述	アーキテクチャ特性
同時利用ユーザーが多い	スケーラビリティ
処理が速い必要がある	パフォーマンス
常に使える必要がある	可用性

スケーラビリティと弾力性は別物である

アーキテクトが最初に着目すべきはユーザー数です。シリコンサンドイッチは現在数千人規模ですが、将来的には数百万人規模への成長が想定されています。このような状況で求められるのが スケーラビリティ です。本書では次のように定義されています。

パフォーマンスを深刻に低下させることなく、多数の同時使用ユーザーを処理する能力

注意すべきは、要件文書に「スケーラビリティが必要」とは書かれていないという点です。「期待されるユーザー数」という形で記述されており、アーキテクトはそのドメイン言語をエンジニアリングの言葉に翻訳する必要があります。

また、スケーラビリティと混同されやすい特性として 弾力性（Elasticity） があります。両者は似ていますが、測定対象が異なります。

特性	測定対象	典型的なパターン
スケーラビリティ	同時使用ユーザーの総数	時間とともに緩やかに増加する
弾力性	トラフィックのバースト	短時間で急増・急減を繰り返す

スケーラビリティは図1のように同時使用ユーザー数が段階的に増加していく状況への対応能力です。一方、弾力性は図2のようにトラフィックが短時間で急激に増減するバースト状況への追従能力を指します。フードデリバリーサービスであるシリコンサンドイッチの場合、ランチタイムに注文が集中するという性質上、スケーラビリティと同時に弾力性も重要な特性として検討する必要があります。

この2つを同一視して設計すると、「平均的な負荷には耐えられるが、ピーク時に落ちる」という典型的な障害パターンに陥ります。

明示的な特性は比較的読み取りやすい反面、これだけで設計を完結させようとすると大きなリスクを抱えることになります。

5.3.2 暗黙的な特性

設計上重要な特性の多くは、要件文書に明示されません。シリコンサンドイッチを例に、代表的な暗黙的特性を見ていきます。

ドメインの性質から導く

シリコンサンドイッチにはオンライン決済があり、ユーザーの個人情報を扱います。これらは要件に明記されていなくても、以下の特性が必然的に求められます。

状況	アーキテクチャ特性
決済処理がある	セキュリティ
個人情報を扱う	セキュリティ・プライバシー
注文データの整合性が必要	信頼性

可用性と信頼性はとくに混同されやすい特性です。可用性が「サイトにアクセスできること」を保証するのに対し、信頼性は「接続している間、サイトが安定して稼働し続けること」を保証します。断続的に接続が切れ、何度もログインし直す必要があるサイトでは、ユーザーは購入を完了させようとは思わないでしょう。両者は似た概念ですが、設計上は区別して扱う必要があります。

セキュリティについても同様です。すべてのシステムに共通する暗黙的な特性ではありますが、「暗黙的である」ことと「常に高い優先度で設計に組み込む必要がある」ことは別の話です。シリコンサンドイッチの場合、決済処理をサードパーティサービスに委託する設計であれば、一般的なセキュリティ慣習（クレジットカード番号をプレーンテキストで扱わない、不必要な情報を保存しないなど）に従う限り、アーキテクチャレベルで特別な構造を設計する必要はなく、アプリケーション設計の範囲で対応できます。

カスタマイズ性

シリコンサンドイッチには、地域ごとのメニューやレシピの違い、地域限定の販売条件といった要件が含まれています。場所によって動作が変わるこの性質を カスタマイズ性 と呼びます。
通常、カスタマイズ性はアプリケーション設計の領域に属しますが、それを支えるために特別な構造が必要になる場合はアーキテクチャ特性として扱われます。ただし、この特性はシリコンサンドイッチの成功に不可欠というわけではなく、アーキテクチャレベルでサポートしない設計を選択しても、アプリケーション設計の工夫で代替できます。

特性の優先順位づけ：「最も重要でないもの」を決める

アーキテクチャ特性を洗い出したあと、チームが行うべき重要な作業があります。それは「最も重要な特性はどれか」ではなく、「最も重要でない特性はどれか」を問うことです。

どれかを取り除かなければならないとすれば、それはどの特性か。この問いを立てることで、成功に本当に必要な特性が浮き彫りになります。暗黙的な特性の多くは普遍的な成功を支えるものであるため、アーキテクトは一般的に明示的な特性の方を優先して削減の候補とする傾向があります。

シリコンサンドイッチの場合、最も優先度を下げられる運用特性はおそらく パフォーマンス です。これは「パフォーマンスを無視してよい」という意味ではなく、スケーラビリティや可用性と比較したとき、パフォーマンスを最優先にしない設計を選択できるという意味です。

なお、アーキテクチャ特性の過剰な盛り込みはシステムを不必要に複雑にします。各特性は互いに影響し合うため、特性を増やすほど設計の複雑度は上がります。本書にはこのような言葉があります。

アーキテクチャに間違った答えはない。高くつくものがあるだけだ。

アーキテクトに求められるのは、正確な特性のセットを見つけることに固執するのではなく、重要な構造要素を正しく見極め、少なくとも最悪でないトレードオフの集合を選択することです。

---

種別	読み取り方	見落とすリスク
明示的な特性	要件をそのまま読む	低い
暗黙的な特性	ドメイン知識から導く	高い

実務上、設計ミスの原因になりやすいのは後者です。書かれていないがゆえに見逃しやすく、それが本番障害やセキュリティインシデントにつながるケースは少なくありません。アーキテクチャ特性は「与えられるものではなく、発見するもの」です。

• 明示的な特性は要件から直接読み取れるが、それだけでは設計として不十分である
• 暗黙的な特性はドメインの性質や利用コンテキストから能動的に導く必要がある
• 特性の過剰な盛り込みは複雑性を増大させるため、優先順位づけと取捨選択が不可欠である
• 要件に記述されていない特性ほど、設計上のリスクになりやすい

良いアーキテクトとは、要件の行間を読み、書かれていない制約を設計に織り込める人です。

まとめ

第5章では、アーキテクチャ特性を「どう見つけるか」という実践的な観点から整理しました。各節のポイントを振り返ります。

5.1 ドメインの関心事から特性を導く
技術やトレンドを起点にするのではなく、ビジネスの関心事や利用状況からアーキテクチャ特性を導くことが出発点です。ドメインの言葉を「〜性（-ility）」に変換する思考プロセスが、設計の根拠を明確にします。

5.2 要件から特性を抽出する
要件に書かれている内容をそのまま受け取るのではなく、背後にある意図を解釈することが求められます。ドメイン知識がなければ読み取れない暗黙の前提を拾い上げる力が、アーキテクトのコアスキルです。

5.3 明示的な特性と暗黙的な特性
要件から直接読み取れる明示的な特性は比較的見つけやすい一方、設計上のリスクになりやすいのは要件に書かれていない暗黙的な特性です。ドメインの性質や利用コンテキストから能動的に導く姿勢が不可欠です。

---

これらに共通する前提として、アーキテクチャ特性は「与えられるもの」ではありません。要件にすべてが明示されるわけではなく、ステークホルダーごとに重要視する特性も異なります。すべての特性を満たすアーキテクチャは存在しない以上、何を優先し何を手放すかを判断すること自体が設計行為です。

ドメインへの深い理解と、ステークホルダーとの対話を通じた合意形成。この2つがなければ、本当に必要な特性は見えてきません。

要件はヒントであり、答えはアーキテクト自身が導き出すものです。

終わりに

第3章では「構造（どう分けるか）」、第4章では「特性（なぜそれを選ぶか）」を扱いました。第5章ではさらに踏み込み、「その特性をどう見つけるか」という設計の出発点を整理しました。

ここで見えてきた本質は、アーキテクチャの質は設計スキルだけでなく、「どれだけ正しく問題を理解できるか」によって決まるという点です。同じ要件であっても、表面的に読むのか背景まで理解するのかによって、導かれるアーキテクチャは大きく変わります。

アーキテクトとは「正しい設計をする人」ではなく、「正しい問いと前提を見抜く人」です。良いアーキテクチャは、良い設計技法からではなく、問題への深い理解から生まれます。

第5章までで、アーキテクチャ設計の基盤となる4つの視点が揃いました。

章	テーマ	問い
第2章	思考	どう考えるか
第3章	構造	どう分けるか
第4章	特性	なぜそれを選ぶか
第5章	抽出	どう見つけるか

第6章「アーキテクチャ特性の計測と統制」では、これらの特性をどのように測定し、維持し、進化させていくかを扱います。視点は「設計」から「運用・継続」へと広がっていきます。