新しいサービスを作るとき、最初からあらゆる機能を備えた完璧なシステムを描きたくなる瞬間があります。会員管理、決済、レコメンド、統計まで一度に設計して一度に完成させれば、はるかに効率的に思えるからです。ところが、大きく始めたプロジェクトほど、結局うまく動かないことが多いのです。この現象を一文でまとめた経験則が「ガルの法則（Gall's Law）」です。
ガルの法則とは、簡単に言えば「うまく動く複雑なシステムは、必ずうまく動いていた単純なシステムから育ったものだ」という原則を意味します。アメリカの小児科医で作家のジョン・ガル（John Gall）が、システムが失敗する仕組みを研究する中で残した言葉で、今日ではソフトウェア設計や製品開発でよく引用されます。
本資料では、ガルの法則が生まれた背景から、法則の三つの文に込められた意味、実際の事例、そして現場でこの法則を守る方法まで、順に見ていきます。
単純さから複雑さへと育つシステムの原理
小児科医が書いたシステムの話
ジョン・ガルは、アメリカ・ミシガン州アナーバーで40年以上子どもたちを診てきた小児科医で、ミシガン大学で小児科の臨床准教授も務めました。本業は子どもの発達や行動の問題でしたが、彼は別に時間を割いて、大小さまざまなシステムがなぜ期待どおりに動かないのか、その事例を集めました。
- 最初の本（General Systemantics）：1975年、彼はそれまで集めた失敗事例と教訓を『一般システム学』という本にまとめて出版しました。
- 再出版（Systemantics）：2年後の1977年、『システム学：システムはどう動き、特にどう失敗するのか』という題で改めて出版され、広く読まれました。
- 改訂版（The Systems Bible）：1986年に2倍近くに増えた第2版が出て、2002年には第3版が『システム・バイブル』という題で出版されました。
この本は、マーフィーの法則やピーターの法則のように、短く機知に富んだ文でシステムの性質を解き明かしました。その中で最も有名になった一文が、のちに人々の間で「ガルの法則」と呼ばれるようになりました。ただ、本の中ではそのような名前は付いていませんでした。
法則を成す三つの文
ガルの法則は普通ひとまとめにして語られますが、原文は三つの文が続く構造になっています。
(1) 成功した複雑系には単純な出発点がある
うまく動く複雑なシステムをさかのぼると、必ずうまく動いていた単純なシステムに行き着きます。複雑さは最初から設計されたものではなく、動く状態を保ちながら少しずつ積み重なった結果だという意味です。
(2) 最初から複雑に作ったシステムは直して使うこともできない
白紙から一度に設計した複雑なシステムは動かず、継ぎはぎをしても生き返らせることはできないとガルは断言しました。部分同士がどう絡み合って動くのかを、前もってすべて知ることはできないからです。紙の上では完璧に見えた設計も、実際にかみ合って動き始めると、予想もしなかった衝突があちこちで一斉に噴き出します。
(3) もう一度単純なものから始めなければならない
それなら解決策は一つです。動く単純なシステムを新たに立ち上げ、そこから改めて育てていくことです。すでにかけた労力が惜しくても、動かない巨大な設計にしがみつくより、小さく始め直すほうが結局は早いという意味です。
ただし、ガルはこれらの文の前に、単純なシステムも動くことがあれば動かないこともある、という但し書きを付けました。単純だからといって成功が保証されるわけではなく、成功した複雑系の出発点が単純だったという点を述べたものです。
法則を示す事例
ガルの法則は、システム設計者たちが引用することで情報技術の分野に広まりました。1981年にシステム設計者のケン・オア（Ken Orr）が早くからこの文を紹介し、1991年からはオブジェクト指向設計の大家グラディ・ブーチ（Grady Booch）が複数の著書で繰り返し引用しました。
小さく始めて育ったワールド・ワイド・ウェブ
ワールド・ワイド・ウェブは、文書と文書をリンクでつなぐごく単純な構造から出発しました。最初は研究者が資料を共有するための道具でしたが、動く骨組みの上に画像、検索、ショッピング、動画が次々と加わり、今の巨大なシステムになりました。最初からすべての用途を決めておかなかったからこそ、新しい機能が自然に根づくことができたのです。
最初から巨大に設計された標準
反対に、最初からあらゆるケースを盛り込もうとした複雑な技術仕様は、現場に定着できなかった例が多くあります。異なるプログラムをつなぐ分散オブジェクト標準のCORBAは、膨大な仕様で始まりながら広く使われなかった例としてよく挙げられます。
現場でガルの法則を守る方法
ガルの法則は、短く作って頻繁に直すアジャイル開発（Agile Software Development）とよく合います。特にエクストリーム・プログラミング（Extreme Programming）は、最も単純なものから先に作り、機能は後から加えるよう勧めています。
(1) 最も小さな完成品から作る
機能が少なくても、最初から最後まで実際に動く最小限の製品をまず出します。ユーザーの反応を見ながら必要なものだけを加えていけば、無駄な設計にかける労力を減らせます。
(2) 常に動く状態を守る
機能を加えるたびに、システムが変わらずきちんと動くかを確かめます。一度に大きく変えるより、小さく変えてすぐに試すほうが、問題の原因も見つけやすくなります。
(3) 急いで作った巨大さを警戒する
今は人工知能のコーディングツールで大きなシステムを一瞬で作れるようになりましたが、速く組み立てたからといって、ガルが言った失敗を避けられるわけではありません。スピードが上がるほど、小さく始める原則はいっそう重要になります。
ガルの法則は、複雑なシステムを作るなという話ではなく、複雑さに至る道は別にあるという助言です。大きく立派な設計図よりも、今日きちんと動く小さなシステム一つのほうが、より遠くまで連れて行ってくれます。
小さく作ってきちんと動かし、一歩ずつ育てていくこと、それが丈夫なシステムへの第一歩です。
