フレームワーク活用ガイドひとことで言うと#
「このアーキテクチャは狙い通りに機能しているか」を自動テストで定量的に検証し続ける仕組み。コードにユニットテストがあるように、アーキテクチャにもテストを書くという発想。
押さえておきたい用語#
- Fitness Function（フィットネス ファンクション）
- アーキテクチャの特性（パフォーマンス、セキュリティ、結合度など）を数値で評価する関数のこと。合格ラインを設定し、CI/CDで自動実行する。
- Evolutionary Architecture（進化的アーキテクチャ）
- ビジネス要件の変化に追従して段階的に進化できるアーキテクチャ設計。フィットネス関数はこの進化を安全に行うためのガードレールになる。
- Architecture Characteristic（アーキテクチャ特性）
- パフォーマンス、可用性、セキュリティなどシステムの非機能要件を指す。
- Guided（ガイデッド）
- フィットネス関数が「進化の方向」を示してくれる状態。テストがないと自由に劣化できるが、テストがあれば望ましい方向にだけ変更が進む。
アーキテクチャ・フィットネス関数の全体像#
こんな悩みに効く#
- アーキテクチャの品質が徐々に劣化しているのに気づけない
- 「パフォーマンスが大事」と言いつつ定量的な基準がない
- リファクタリングした結果、かえって設計が悪くなったケースがある
基本の使い方#
すべての特性を守ろうとしない。ビジネスにとって最重要な3〜5つに絞る。
- 決済システム → レイテンシ、セキュリティ、可用性
- 社内ツール → 保守性、結合度、テストカバレッジ
- リアルタイム通信 → スループット、レイテンシ、スケーラビリティ
いきなり理想値を設定するのではなく、現状を計測した上で「これ以上劣化させない」ラインを決める。
- 現状のP95レイテンシが180msなら、閾値は200msに設定
- 循環依存が2箇所あるなら、「これ以上増やさない」= 2以下
手動チェックは続かない。PRマージ前やデプロイ前に自動実行し、閾値を超えたらブロックする仕組みにする。
- ArchUnitでパッケージ依存ルールを検証
- Lighthouseでパフォーマンスバジェットを検証
- 負荷テストツール（k6, Gatling）でスループットを検証
具体例#
従業員50名のフィンテック企業。サービス成長に伴いAPIレイテンシが3ヶ月で120ms→350msに悪化。ユーザーからの「遅い」というフィードバックが急増していた。
導入したフィットネス関数
| 特性 | 関数 | 閾値 | 計測方法 |
|---|---|---|---|
| レイテンシ | P95応答時間 | < 200ms | k6負荷テスト |
| スループット | 秒間処理数 | > 300 rps | k6負荷テスト |
| メモリ | 最大ヒープ使用量 | < 512MB | Prometheus |
CI/CDに組み込み、PRマージ前に自動実行。閾値を超えるPRは自動的にブロックされる。
導入から6ヶ月後、P95レイテンシは 350ms → 160ms に改善。それ以降も200msの閾値を一度も超えていない。
エンジニア200名体制の小売EC。マイクロサービス30個の依存関係がスパゲッティ化し、1つのサービスを変更すると平均4つのサービスに影響が波及していた。
ArchUnitを使って以下のフィットネス関数をCI/CDに追加。
- 循環依存 = 0（検出したらビルド失敗）
- 1サービスの外部依存先 <= 3サービス
- 共有ライブラリの変更頻度 <= 月2回
結果、新たな循環依存の混入がゼロになり、サービス変更時の影響範囲が平均 4サービス → 1.2サービス に縮小。デプロイ頻度は週1回から日次に改善された。
患者データを扱う医療SaaS。年1回のセキュリティ監査で毎回指摘を受け、対応に3ヶ月を費やすのが恒例行事になっていた。
監査で指摘される項目をフィットネス関数化して日次で自動実行することにした。
- 既知脆弱性のある依存ライブラリ = 0（Snykで検出）
- HTTPS以外の通信 = 0（ネットワークポリシー検証）
- 暗号化されていないデータストア = 0（Terraformスキャン）
- 認証なしで到達可能なエンドポイント = 0（OWASPスキャン）
監査前の慌ただしい対応がなくなり、直近の監査では指摘事項ゼロを達成。セキュリティ対応のコストは年間で 約40%削減 された。
やりがちな失敗パターン#
- 最初から完璧な閾値を求める — まず現状値を計測し、「これ以上悪化させない」ラインから始める。理想値をいきなり設定するとほとんどのPRがブロックされて形骸化する
- フィットネス関数を増やしすぎる — 関数が多すぎるとメンテナンスコストが跳ね上がる。ビジネスにとって本当に重要な3〜5特性に絞る
- 自動化せずにスプレッドシートで管理する — 手動計測は1〜2回で放置される。CI/CDに組み込んで初めて継続的な品質保証になる
- 閾値を更新しない — ビジネス要件やトラフィック量は変わる。四半期ごとに閾値の妥当性をレビューし、必要に応じて厳しくしたり緩めたりする
まとめ#
アーキテクチャ・フィットネス関数は 「アーキテクチャのユニットテスト」 ともいえる仕組みで、重要な特性を数値化してCI/CDで継続検証する。守りたい特性を3〜5つに絞り、現状値をベースに閾値を設定し、自動化するのが導入の基本。閾値はビジネス変化に合わせて定期的に見直し、フィットネス関数自体も進化させていく必要がある。