> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.
# ガルの法則
> ガルの法則は、機能するすべての複雑なシステムは機能する単純なシステムから進化してきたと述べています。この原則がテクノロジー、組織、システム設計にどのように適用されるかを学びましょう。
**Category**: 法則
**Type**: システム設計の法則
**Origin**: システム理論、1975年、ジョン・ガル
**Also known as**: Gall's Law、複雑系の進化
**先に答えると** — ガルの法則（Gall's Law）は、機能するすべての複雑なシステムは機能する単純なシステムから進化してきたという原則です。1975年にジョン・ガルによって定式化されたこの法則は、複雑なシステムは究極的には脆弱であり失敗する傾向がある一方、機能することが証明された単純なシステムが開発のためのより信頼できる基盤を提供することを示唆しています。
## ガルの法則（Gall's Law）とは
ガルの法則は、複雑で完全に機能するシステムはゼロから設計・開発することはできず、より単純な動作するシステムから進化しなければならないと提唱しています。中核となる洞察は、成功する複雑なシステムは包括的な計画によってではなく、すでに機能していた基盤の上に各段階が構築される反復的な開発によってそうなるということです。
> 「機能する複雑なシステムは、常に機能する単純なシステムから進化していることがわかります」
この原則は、完璧なシステムを最初に設計しようとするアプローチに異議を唱えます。代わりに、複雑で効果的なシステムへの道は実証された単純さを通ると示唆しています。成功するすべての複雑なシステムは、中核的な問題をすでに解決しているより単純な祖先の子孫です。
### ガルの法則を3つの深さで理解する
* **初心者**: 新しいものを構築する際、中核的な問題を解決する可能な限り最も単純なバージョンから始めましょう。完全なソリューションをすぐに構築しようとするのではなく、まず基本的な概念が機能することを証明しましょう。
* **実践者**: 提案されたソリューションを評価する際、それが機能するより単純なバージョンから進化したかどうかを評価しましょう。ゼロから「設計された」複雑なシステムは、予期しない方法で失敗することが多いです。
* **上級者**: 進化には選択圧力が必要であることを理解しましょう。単純なシステムは、仮説的な計画ではなく、実世界の条件下での反復によって複雑なシステムになります。
## 起源
ガルの法則は、システム理論家および著者である**ジョン・ガル**に帰属し、1975年の著書「Systemantics: How Systems Really Work and How They Fail」で発表されました。ガルは大規模なシステム——技術的にも組織的にも——がなぜそれほど頻繁に失敗するのかを分析し、成功する複雑なシステムは常にその背後に機能する単純さの歴史を持っていることを観察しました。
この法則は、軍事、政府、企業組織など、様々なドメインにおけるシステム失敗のガルの研究から生まれました。彼の重要な洞察は、建築家や設計者はすべての偶然を計画できると信じることが多いが、現実世界の複雑さは最終的にそのような包括的な設計を打ち負かすということでした。生き残る唯一のシステムは、実際の使用を通じてテストされ、改良され、拡張されたシステムです。
## 要点
概念から複雑な実装に直接飛び込むことはできません。複雑さの各層は、すでに機能している層の上に構築されなければなりません。この基盤がなければ、砂の上に構築していることになります。
多くの相互依存変数を持つシステムでは、進化的開発が事前設計を上回ります。実際の使用の選択圧力は、計画では予測できない問題を明らかにします。
単純なバージョンは単なるプロトタイプではありません——それは機能しなければならない中核です。追加の複雑さはすべて、この実証された基盤に奉仕し、それを損なわないものでなければなりません。
複雑なシステムが失敗したとき、問題は複雑さ自体ではなく、適切にテストされた機能する単純な前身の欠如にあることが多いです。
## 応用場面
成功するプロダクトは通常、1つの問題をうまく解決する最小実行可能プロダクト（MVP）から始まります。中核を証明する前に機能を追加すると、負荷の下で失敗する脆弱なプロダクトになります。
ソフトウェアシステムを設計する際、現在のニーズを満たす最も単純なアーキテクチャから始めましょう。実際の使用パターンによって必要性が証明された場合にのみ複雑さを追加しましょう。
組織は、すでに機能する構造の上に構築することでより成功裏に進化します。大規模な再編成は、テスト済みのパターンを未テストの設計と引き換えに破棄するため、多くの場合失敗します。
スタートアップは、まず単純で実証済みのビジネスモデルを見つけてから複雑さをスケールアップすることで成功します。プロダクトマーケットフィットの前に複雑なシステムを構築するために多額の資金を調達するスタートアップは、多くの場合失敗します。
## 事例
### ワールドワイドウェブの進化
ワールドワイドウェブは、ガルの法則が実際に機能する説得力のある例を提供しています。1989年のティム・バーナーズ＝リーの元の設計は驚くほど単純でした。ハイパーリンクで接続されたドキュメントのシステムで、基本的なブラウザーを通じてアクセスできるものでした。
この単純さ——ドキュメントとリンク——が「機能する単純なシステム」でした。これはCERNの異なるコンピューター間で情報を共有するという特定の問題を解決しました。システムは非常に単純だったため、1つの研究機関内で実装、テスト、証明することができました。
この単純な基盤から、ウェブは進化しました。追加の層が追加されました。画像、JavaScriptを通じたインタラクティビティ、サーバーサイドプログラミングによる動的コンテンツ、ユーザー認証、eコマース、ソーシャル機能、モバイルアクセスです。各層は機能する基盤の上に構築されました。
重要なことに、元のウェブが最初からこれらの機能をすべて組み込もうとしていた場合、失敗していたでしょう。複雑さは管理不可能であり、設計決定は実世界のフィードバックなしに行われ、システムは自身の重みで崩壊したでしょう。代わりに、ウェブは層ごとに進化し、次の層を試みる前に各追加機能が証明されました。
今日、ウェブはバーナーズ＝リーの元のビジョンよりも想像できないほど複雑になっています——しかし、その複雑さは最初に設計されたのではなく、進化によって獲得されたものです。
## 限界と失敗パターン
ガルの法則には重要な制限があります。
1. **すべてのドメインに適用されるわけではない**: 一部のシステムはゼロから成功裏に設計できます——特に要件がよく理解されており、ドメインが制約されている場合。
2. **進化には適切な条件が必要**: 進化を駆動する「選択圧力」は現実的で有益でなければなりません。急速に変化する環境では、条件が変化する前に進化が機能する時間がない場合があります。
3. **単純さが不十分な場合がある**: 一部の問題は、最初から複雑なソリューションを本当に必要とします。重要なのは、時期尚早な複雑さと必要な複雑さを区別することです。
4. **パス依存性が重要**: システムが特定の方向に進化すると、その方向を変更することはますます困難になります。初期の決定が将来の選択肢を制約します。
## よくある誤解
ガルの法則は単純が優れていると言っているのではありません——単純が最初に来なければならないと言っているのです。目標は最終的に有用な複雑さに到達することですが、基盤を証明した後に限ります。
進化には時間がかかりますが、デジタルシステムは反復を通じて急速に進化できます。重要なのはカレンダーの時間ではなく、実世界のフィードバックです。
ガルの法則は計画を拒否するのではありません——計画は包括的な設計ではなく進化の条件を作り出すことに焦点を当てるべきだと示唆しています。基盤を計画するのであって、大聖堂を計画するのではありません。
## 関連概念
仮説をテストできる最も単純なバージョンを構築するという概念——ガルの法則をプロダクト開発に直接適用しています。
前のものの上に構築する繰り返しのサイクルを通じてプロダクトを構築する——ガルが記述する進化的アプローチを体現しています。
[コンウェイの法則](/ja/laws/conways-law) — システム設計が組織のコミュニケーション構造を反映するという洞察——進化が特定の経路をたどる理由を説明することでガルの法則を補完します。
## 一言で言うと
まず機能する単純なシステムを構築し、それから進化させましょう。成功する複雑なシステムは、実証された基盤の上に層ごとに構築されます。