Easy_is_Not_Simple

なぜ、優れた思想は「禁句」になったのか？ 驚き最小の法則 ソフトウェア設計における有名な指針、「驚き最小の法則 (POLS)」。その意図は「ユーザーが最も驚かない挙動を実装すべき」という、直感的で優れたものだった。しかし、Rubyコミュニティでは、この言葉が論争の火種のこととなり、いつしか「使うべきではない言葉」――事実上の禁句となった。 本資料は、この「事件」の真相を解明し、ソフトウェア設計におけるより根源的な原則を探求するものである。

混乱の現場：期待のバベルの塔 「静的型付けないことに驚いた！」 「もっと柔軟に書けないことに驚いた！」 「マクロがないことに驚いた！」 「驚き最小」という言葉は、各プログラマが「自分の慣れ親しんだ言語と同じ挙動にしろ」と要求するための盾として使われた。すべての「驚き」をなくすことは、すべての主観的要求を満たすことを意味し、それは不可能である。問題の根源は、客観的な指標の欠如にあった。

犯人は「Easy」という言葉の誤解だった 「Easy」の語源 ・ラテン語の facilis や古フランス語の aisie に由来する。 ・本来の意味は「近くにある」「手元にある」。 ・すなわち、「自分のすでに知っている知識（手元の知識）で解決できる」状態を指す。 「驚き」の本質 ・「驚き」とは、「自分の手持ちの知識（メンタルモデル）との乖離」によって発生する。 ・Rubyのユーザーは、客観的な「良さ」ではなく、主観的な「親しみやすさ (Easy/Familiar)」を「驚き最小」の名の下に求めていた。 「Easy」は個人のバックグラウンドに依存する相対的な指標であり、設計の普遍的な指針にはなり得ない。

解読の鍵：SimpleとComplicatedという新しいレンズ この混乱を解き明かす鍵は、Rich Hickeyが提唱した「Simple」と「Complicated」の厳密な定義にある。 Easy Simple Complicated 彼は「Easy (簡単/容易)」と「Simple (単純)」を明確に区別した。 重要なるのは、「Simple」の対義語を「Hard (難しい)」ではなく、「Complicated (複雑)」と定義したことだ。 この視点の転換が、すべての謎を解く。

Complicatedの正体：編み込まれ、絡み合った状態 語源：ラテン語 com-plicare 分解：com- (共に) + plicare (折る、編む) 本質：複数の要素が互いに編み込まれ、絡み合っている状態。 「Complicated」とは「難しさ」を指す言葉ではない。それは「構造」を指す言葉である。構成要素が互いに依存し、分離できない状態こそが「Complicated」の本質だ。

Simpleの定義：一本の糸、絡まりのない状態 語源：ラテン語 sim-plex 分解：sim- (一つ) + plex (折り) 本質：一重であること。一つのこと。独立していること。 「Simple is not Complicated.」 シンプルとは、絡まっていないことである。 機能の数や実装の高度さではない。 各要素が独立し、分離しているかどうかが唯一の基準となる。

「Simple」という言葉から、2つの誤解を外科手術のように切り離す 1. 最小性 (Minimalism) との混同 「ルールが少ない」「コード行数が少ない」はSimpleではない。 キーワードが一つでも、それが複数の意味を持つならComplicatedである。 区別：少ないこと (Brevity) ≠ 絡まっていないこと (Simplicity) 2. 素朴さ (Crudeness) との混同 「何も考えずに書いたベタ書きコード」はSimpleではない。 それは単に実装がEasy (安直) だっただけで、結果として密結合 (Complicated) を生む。 区別：原始的であること (Primitiveness) ≠ 絡まっていないこと (Simplicity) 3. 真のSimple (Structural Independence) Hickeyが提唱するエンジニアリング上のSimpleとは、概念が「絡まり合っていない」構造的独立性のことである。 独立性 (Independence) 構造的 (Structural)

事件の解決：Rubyコミュニティが直面した本当の対立 Before: The Mystery 混乱：主観的な「Easy」の衝突 After: The Truth 対立の構造 コミュニティの要求 → Easy (親しみやすさ) 言語設計の一貫性 → Simple (絡まりのなさ) コミュニティが要求したのは、それぞれの出身言語に似せるという「Easy (親しみやすさ)」だった。 しかし、その要求をすべて満たすことは、言語の内部論理を破壊し、様々な概念を無理やり編み込む「Complicated」な設計を強制することを意味した。 対立の正体は「Simple vs Complicated」であり、「驚き最小の法則」という言葉がその構造を見えなくしていた。

理論の証明：第二のケースファイル - Go言語の`for`ループ

// C-style
for i := 0; i < 10; i++ { ... }

// While-style
for x < 100 { ... }

// Range-style
for k, v := range items { ... }

// Infinite
for { ... }

Goの設計思想は「シンプルさ」で知られている。キーワードも少ない。では、この`for`文は、我々の定義において「Simple」だろうか、それとも「Complicated」だろうか？

分析結果：Goの`for`は`Complicated`である

// C-style
for i := 0; i < 10; i++ { ... }

// While-style
for x < 100 { ... }

// Range-style
for k, v := range items { ... }

// Infinite
for { ... }

カウンターによる反復
状態条件による継続
コレクションの走査
無限ループ

・Goの主張：キーワードが`for`しかないため、覚えることが少なくEasyであり、構文要素もMinimalである。
・Hickeyの定義による分析：「反復」と「条件」という本来別々の概念を、一つのキーワードに編み込んで (Complect) しまっている。これは意味的なComplicatedである。

結論：Minimal + Easy ≠ Simple。Goの`for`は、学習しやすさ (Easy) のために、概念の純粋性 (Simple) を犠牲にした設計である。

我々が学ぶべき設計思想：Simple Made Easy この言葉は、持続可能なソフトウェアを築くための指針であり、2つの意味を持つ。 意味A：「シンプルさこそが、真の安楽をもたらす」 ・Easy (手っ取り早い) な方法は、長期的にはComplicatedなシステムを生み、開発を困難にする。 ・最初にSimple (絡まりのない) な構造を選べば、結果として変更や保守がEasy (楽) になる。 意味B：「シンプルなものを、使いやすくする」 ・これがエンジニアリングのあるべき姿。まず、システムの核となる部分は徹底してSimpleに作る。 ・その上で、人間が使いやすいように、薄い皮としてEasyなインターフェースを被せる。 Simplicity (構造) を土台にして初めて、持続可能なEasy (使いやすさ) が作れる。

設計の順序：土台としてのSimple、皮膜としてのEasy Easy Interface (使いやすい皮膜) Simple Core (絡まりのない構造) ・Easy (手軽さ・親しみ)：ユーザー体験としての「成果物」としては善。 ・Simple (単純さ・非絡まり)：エンジニアが常に追求すべき「構造的特性」。 ・致命的な過ちとは、「Easy」を「設計の基準」にすることである。なぜならEasyは主観的で近視眼的だからだ。 ・戒め：Easyを得るためにSimpleを売り渡すな。Simpleな土台の上にEasyを築け。

「Easyとは、GitHubのスター数のようなものだ」 Easy (とっつきやすさ) は、マーケティングにおける最強の武器である。 「5分で動く」「設定不要」といったEasyな技術は、初速が早く、人気 (スター) を集めやすい。 しかし、その裏側で、内部がComplicatedになっているかもしれない。 人気があるからといって、それが設計として正しい (Simpleである) とは限らない。

見せかけの「人気」と、隠された「構造」 Easyはデートのようなものだ。Simpleは結婚のようなものだ。 最初の印象 (Easy) に惑わされず、長く付き合える健全な構造 (Simple) を見抜く眼力こそ、我々エンジニアが持つべき最も重要なスキルである。