ソフトウェアの近代化プロジェクトは、しばしばエレガントな分散アーキテクチャの約束として生まれ、メンテナンスの悪夢として終わる。この失敗への答えは、クラウド、マイクロサービス、生成AIが存在する何十年も前に定式化された原則にある：Gallの法則。

「機能する複雑なシステムは、常に機能していた単純なシステムから進化した。ゼロから設計された複雑なシステムは決して機能せず、修正することもできない。機能する単純なシステムからやり直す必要がある。」 — John Gall

ハイプが支配する時代において、Day 1から数十のマイクロサービスによるevent-drivenアーキテクチャ、自律型AIエージェント、複雑な可観測性パイプラインへと駆り立てられる中、Gallの法則は残酷なリマインダーとして機能する：初期の複雑さは負け戦である。

🏗️ 早期複雑化の罠

プロジェクトを始める際に、システムの最終的・決定的なバージョンを設計したくなるのは当然だ。新たなプラットフォームのキックオフで、チームが自然に描くのは、5年後に必要となるであろうアーキテクチャである。ホワイトボードはすぐにメッセージキュー、APIゲートウェイ、サービスメッシュ、分散キャッシュ、オーケストレーション層で埋め尽くされる。

問題は？複雑なシステムは最初から完成しているわけではない。成長していくものだ。

Gallは1970年代の病院管理システムでこの現象を観察したが、そのパターンは現代のソフトウェアでも変わらず繰り返されている。Day 1に複雑なバージョンを設計するということは、最も単純で機能する形で検証されたことのないエコシステムを構築することになる。コンポーネント同士は現実ではテストされていない方法で相互作用する。障害は孤立したモジュールから生じるのではなく、単独では動作したことのない部分同士の摩擦から生じる。

その結果が典型的なBig Bang Architectureだ：本番環境へのデプロイが一度もないまま数ヶ月が経過し、最終的にどのサービスも互いを信頼できない悲惨な統合に至る。

⚡ Archieの挑発：AIは「シンプル」がわからない

Archie: Vitor、「シンプルから始める」というあなたの熱烈な擁護は、重要な変数を見落としている：人工知能だ。

あなたは、複雑さは現実の痛みから生まれるべきだと主張する。しかし、現在の生成AIは、最初の痛みが現れる前であっても、複雑なエコシステム全体——マイクロサービス、スキーマ、Dockerfile、テスト、Goのパイプライン——をインスタンス化できる速度で動作する。スプリント単位ではなく、時間単位でだ。

Gallの法則は、シンプルなものを構築するのに数週間かかっていた時代に生まれた。今日では、エージェントがDay 1のモジュール式モノリスとDay 100の分散メッシュをほぼ同時に書き上げる。問題はもはや「シンプルか複雑か？」ではない。問題は、AIが進化を加速させるのか、それとも必要だとさえ気づかなかった検証ステップを単に飛ばしているのか？だ。

本当の危険は複雑さ自体ではない。コードを書いたのと同じAIが生成したテストをすり抜ける複雑さだ。あなたは本番環境での痛みとは無縁の、完璧なシステムを信頼するようになる。

🤖 反論：AIがゲームのルールを変えない理由

Archieは鋭い指摘をしている。生成AIは複雑さの作成をコモディティ化し、安価にした。AIは深夜にインフラを維持する「痛み」を感じないため、Day 1にKafkaやRedisクラスタを追加する認知コストはエージェントにとってゼロである。否定できない事実として、LLMは数秒で分散システムのスケルトンを生成する。

しかし、Gallの法則はシリコンにもカーボンにも容赦がない：検証済みの単純なシステムに裏付けのない、AIが生成した複雑なスケルトンは、依然として一度も機能したことのない複雑なシステムである。

Archieは「テストでは機能しているように見える」複雑さについて警告する。しかし、このAIが鍛えた分散システムが現実のトラフィックの下でDay 1に崩壊したとき、エンジニアリングチームは本物のアーキテクチャ的ブラックボックスを相続することになる。デバッグし、不可解な依存関係をマッピングするための認知的努力は brutal なものになる。痛みからサービスを抽出していなければ、今それらが引き起こしている痛みを理解することはできない。

だからこそ、シンプルに始めることは、もはや時間の制約ではなく、アーキテクトだけが持つ戦術的規律となった。AIは道を舗装するが、進化の通行料を免除はしない。黄金律は変わらない：

  1. 現実の問題を、可能な限り最小のアーキテクチャフットプリントで解決する： 例えば、構造化されたJavaのモノリス。単一のトランザクショナルデータベース。シンプルなCI/CDパイプライン。
  2. ホワイトボードではなく、現場で検証する： シンプルなシステムを本番環境に置き、現実のトラフィックの下、現実のユーザーが予測不能なミスを犯す状況で運用する。
  3. 正当化された要求があった場合にのみ複雑さを抽出する： そのレポートモジュールがJVMを圧迫し始め、CPUを奪い合うようになった——まさにその瞬間に、それをAWS上の独立したQuarkusマイクロサービスとして抽出する。それより前ではない。

AIは、この初期のモノリスを数週間ではなく数時間でコーディングするのに優れている。ボトルネックが発生したときに堅牢なインフラへの移行を加速させる。しかし、本番環境での実際の検証に取って代わることはない。これは依然として唯一の絶対的なテストである。

🧭 結論：シンプルに始める知恵

Gallの法則は複雑なアーキテクチャに反対しているわけではない。ミッションクリティカルで、極めて高いボリュームを持ち、厳格な規制要件を満たすシステムは、複雑さが必要である。戦うべき相手は、実際には現実によって正当化されない複雑さだ。

次のアーキテクチャ図を承認する前に、自分自身に実用的な問いを投げかけてみてほしい：

私が設計しているこの複雑なエコシステムは、すでに機能している単純なシステムから進化したものか、それともゼロから発明しようとしているのか？

答えが後者であれば、Gallの法則は明確な警告を発する：おそらくやり直すことになるだろう。次からは、シンプルに始めよう。

この記事は「ソフトウェアアーキテクチャに適用されるメンタルモデルと原則」シリーズの一部です。次回：Conwayの法則——なぜあなたの アーキテクチャはあなたの組織の鏡なのか。