進化的アーキテクチャとは：定義・誕生背景・3原則

なぜ「設計は完成しない」のか

ソフトウェアは竣工した建物ではなく生き物に近い。ビジネス要件は変わり、技術スタックは陳腐化し、チーム構成も変わる。「完璧な設計を最初に決めて、あとは実装するだけ」という前提は、変化の前に崩れる。

問いを逆にする。「変化に耐えるアーキテクチャではなく、変化を前提として設計するにはどうすればよいか？」

これが進化的アーキテクチャの出発点だ。

定義

適応度関数（Fitness Functions）によってアーキテクチャ特性を継続的に保護しながら、多次元的な変化をサポートするアーキテクチャ

適応度関数: パフォーマンス・セキュリティ・結合度などのアーキテクチャ特性を自動検証する仕組み
多次元的な変化: 機能・インフラ・スケール・セキュリティなど複数の軸での変化を同時にサポートする

3原則

1. Incremental Change（段階的変更）

変化を小さな単位に分割し、リスクを局所化する。大きなリリースは変更範囲が広く、失敗時の影響も大きい。小さく変えることで、失敗を早く検知して素早く修正できる。

2. Fitness Functions（適応度関数）

アーキテクチャが守るべき特性を自動検証する。テストが「機能の正しさ」を守るのに対し、Fitness Function は「アーキテクチャの特性」を守る。CI/CD に組み込むことで、変更のたびに特性の劣化を検知できる。

3. Appropriate Coupling（適切な結合）

疎結合が常に正しいわけではない。モジュール間の結合には適切なレベルがあり、それを意識的に設計する。過度な疎結合は分散モノリスを生み出す。

         変化を前提とする設計
         ┌──────────────────────────────────────────┐
         │                                          │
  変化 ──→  Incremental Change  小さく・安全に変える │
  特性守護 ─→  Fitness Functions  自動検証で品質守護 │
  構造設計 ─→  Appropriate Coupling 結合を意識設計  │
         │                                          │
         └──────────────────────────────────────────┘

「進化的」と「アジャイル」の違い

どちらも「変化への対応」を重視するが、扱う対象が異なる。

観点	アジャイル	進化的アーキテクチャ
対象	開発プロセス・チーム文化	アーキテクチャ構造そのもの
変化への対応	反復的なサイクルで要件に追従	アーキテクチャ特性の継続的検証
主なツール	スプリント・バックログ・レトロ	Fitness Functions・CI/CD・段階的デプロイ
主な問い	何を・いつ届けるか	どう変化に耐える構造を作るか

アジャイルは「いつ・何を届けるか」のプロセスを扱い、進化的アーキテクチャは「どう変化に耐える構造を維持するか」を扱う。両者は補完的だ。

伝統的アーキテクチャとの比較

観点	伝統的アーキテクチャ	進化的アーキテクチャ
前提	要件は事前に固まる	要件は変わり続ける
設計タイミング	最初に完成させる（Big Design Up Front）	継続的に進化させる
変化の扱い	コスト・リスク・例外	前提・設計の対象
特性の検証	手動レビュー・ドキュメント	自動化された Fitness Function
結合の考え方	疎結合を目指す	適切な結合を設計する
失敗の単位	大きなリリース単位	小さな変更単位

出典・参考文献

Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures, O’Reilly (2017, 2nd ed. 2022)
→ 適応度関数の詳細分類と実装
→ 適切な結合とConnascence
→ 段階的変更の戦略パターン