進化的アーキテクチャ

月間注文5万件のECサイト。PHPモノリスで運用していたが、新機能の追加に平均3週間かかり、デプロイのたびに全機能のリグレッションテストに8時間を要していた。

フィットネス関数の設定:

増分変更の実施:

1. まず商品カタログサービスをモノリスから分離（Strangler Fig）
2. フィットネス関数を全てパスすることを確認
3. 次に注文サービスを分離
4. 4か月間で5つのサービスを順次分離

各ステップでフィットネス関数が品質を担保した。2つ目のサービス分離時にレスポンスタイムが420msに劣化し関数が失敗。原因はサービス間通信のN+1問題で、バッチAPIを追加して解決した。

最終的に新機能の追加は3週間→5日に短縮。デプロイ頻度は週1回→週8回に向上。フィットネス関数がなければ「パフォーマンス劣化に気づかないまま移行を進めていた」とテックリードは振り返った。

ヘルスケアSaaS。HIPAA準拠が必要で、年1回のセキュリティ監査に毎回2か月の準備期間を要していた。監査のたびに「暗号化漏れ」「アクセスログの欠落」が発見され、緊急修正に追われていた。

導入したフィットネス関数:

• 暗号化関数: DBの全カラムのうち個人情報カラムが暗号化されていることを検証
• ログ関数: 全APIエンドポイントにアクセスログが記録されていることを検証
• 依存関数: CVSSスコア7以上の脆弱性を持つライブラリがゼロであることを検証
• 認証関数: 認証なしでアクセスできるエンドポイントがホワイトリスト以外にないことを検証

これらをCIパイプラインに組み込み、PR単位で自動実行。新しいエンドポイントを追加したPRで「ログ関数」が失敗し、開発者がログ記録を追加してから再提出する、という流れが日常化した。

導入1年後の監査では、準備期間が2か月→2週間に短縮。指摘事項はゼロになり、監査法人から「継続的にセキュリティを管理している模範的なケース」と評価された。

官公庁向け業務システム（Java 8 + Struts）。ユーザー数3,000名で、年度末のピーク時にレスポンスが5秒以上になる画面が12個あった。全面リプレースは予算的に不可能で、段階的な改善が求められた。

フィットネス関数:

増分変更の計画:

• Phase 1: 最も遅い3画面のSQLチューニング（2週間）
• Phase 2: セッション管理をインメモリからRedisに移行（3週間）
• Phase 3: 重い集計処理を非同期バッチに切り出し（4週間）

各Phase完了時にGatlingで負荷テストを実行し、フィットネス関数を通した。Phase 2でメモリ使用率が**85%**に上昇しフィットネス関数が失敗。Redisクライアントの接続プール設定を修正して解決。

3か月後、5秒超の画面は12個→0個に。年度末ピーク時でも95%ileが2.1秒に収まった。全面リプレースなしに、段階的改善で品質を回復した。