Simple_Easy_Complicated_Software

「簡単さ」という罠 SimpleとEasyをめぐる思考の旅 ソフトウェア設計における、言葉の解像度を高める

すべては善意から始まった： :「驚き最小の法則」 ソフトウェア設計において、誰もが同意する理想的な法則が存在する。「驚き最小の法則 (POLS)」だ。ユーザーがシステムの挙動を直感的に予測できるべきだという、この考えは優れたデザインの基礎に見える。私たちの物語は、この崇高な理念から始まる。

なぜ「驚き最小」は、Rubyコミュニティで禁句になったのか？ この法則は実践で破綻した。開発者たちの「驚き」は、彼らの出身言語に依存していたからだ。Java出身者、Perl出身者、Lisp出身者は、それぞれ異なる挙動を「当然」だと期待した。「驚き最小」は、個人の慣れ親しんだ環境を要求するための武器となり、設計の一貫性を脅かす混沌を生み出した。 Java Perl Ruby Lisp

我々が混同していたもの：客観的な単純さと主観的な親しみやすさ シンプル (Simple) ? イージー (Easy) 破綻の原因は、我々が「Simple (客観的な単純さ)」と「Easy (主観的な親しみやすさ)」を混同していたことにある。「驚き最小」とは、システムの構造的単純さ (Simple) ではなく、個人の慣れ親しんだ知識 (Easy) を求める要求だったのだ。

「Easy」の正体：『手元にある』ということ Rich Hickeyが指摘するように、「Easy」の語源は古フランス語のaisie (手元にある) に由来する。これは、個人の既存の知識やメンタルモデルで対応できる状態を指す。Easyかどうかは、システムではなく、あなた自身のスキルセットとの距離で決まる。 手元の知識 (Current Knowledge)

「Simple」を理解する鍵は、その真の対義語にある 「Simple」の反対は「Hard」ではない。この誤解が、我々の思考を曇らせていた。Simpleの本質を理解するためには、まずその真の対義語を定義する必要がある。 Simple ≠ Hard Simple vs. ???

「Complicated」の正体：『共に編まれた』ということ Simple / Sim-plex 一重の Complicated / Com-plected 共に編まれた 「Complicated」の語源はラテン語のcom-plicare (共に編む) にある。これは「難しい」という意味ではなく、「複数の要素が絡み合い、分離できない」という構造的な状態を指す。 したがって、「Simple」とは「Complicatedではない (絡まっていない)」ことである。

「Simple」をめぐる3つの誤解 「絡まりがないこと」という定義は、Simpleに関する一般的な誤解を正す。 Myth 1: シンプル ≠ ミニマリズム ルールやコード行数が少ないことではない。少ない部品でも複雑な結び目を作れば、それはComplicatedである。 Myth 2: シンプル ≠ 素朴さ 手早く書かれた、抽象化のないコードではない。それは単に実装がEasy (安直) なだけで、構造的にComplicatedな場合が多い。 Myth 3: シンプル = 構造的な独立性 真のSimpleとは、各要素が絡み合っていない状態 (Unentangled) である。

ケーススタディ：Go言語の`for`文はSimpleか？
Go言語の`for`文は、ループ処理のためのキーワードが一つしかない。この「構文上のミニマリズム」から、多くのプログラマはこれを「シンプルだ」と主張する。本当にそうだろうか？
// C-style loop
for i := 0; i < 10; i++ {
// ...
}
// While loop
for sum < 1000 {
// ...
}
// Iterator
for k, v := range m {
// ...
}

結論：MinimalでEasy。しかし、Complicatedである。 カウンター 条件 for 「Range」 「無限」 Hickeyの定義によれば、Goの`for`文はComplicatedである。なぜなら、単一のキーワードに複数の異なる概念を「編み込んで (complect)」しまっているからだ。これは「構文上のミニマリズム」を優先し、「概念的な純粋さ」を犠牲にした設計である。一つのことが一つの役割を持つのがSimpleであり、Goの`for`文は多重定義による「絡まり」を内包している。

UD Shin Go NT: 「Simple Made Easy」の真意 EASY (インターフェース) SIMPLE (コア) First, Make it Simple: まず、絡まりのない独立したコンポーネントで土台を築く。これは初期にはより困難 (Not Easy) かもしれない。 Then, Make it Easy: そのSimpleなコアの上に、親しみやすいインターフェースを薄い層として構築する。 持続可能な「Easy (使いやすさ)」は、「Simple (構造的な美しさ)」という土台の上にしか成り立たない。

では、Easyは悪なのか？ 決して悪ではない。Easy (親しみやすさ、手軽さ) は、ユーザーにとって目指すべき「ゴール」の一つである。しかし、「設計の基準」として用いることが致命的な悪となる。 成果物 (Goal) 設計基準 (Criterion) なぜか？Easyは「私」の問題であり、コードの問題ではない。それは主観的で近視眼的であり、システムの長期的な健全性よりも開発者の目先の快適さを優先させてしまうからだ。

Easyは人気投票であり、Simpleは持続可能性である Easy: GitHubのスター数や初回のデートのようなもの。第一印象やとっつきやすさが全て。それはマーケティングの指標である。 Easy / 人気 (Popularity) Simple: 長期的な保守性や結婚生活のようなもの。時の試練に耐える構造的な健全性が全て。 Simple / 保守性 (Maintainability) 「スターが多いから良い設計だ」とは限らない。人気 (Easy) と品質 (Simple) を区別する眼力が必要だ。

思考のまとめ 1 言葉を区別せよ Easy (主観的な親しみやすさ) ≠ Simple (客観的な非絡まり性)。 2 真の敵を知れ Simpleの対義語はHardではなくComplicated (絡まり) である。 3 順序を守れ Simpleを土台とし、その上にEasyを築け。Easyを得るためにSimpleを売り渡してはならない。

最後の問い ? あなたのコードベースで、Easy (目先の簡単さ) と引き換えに、Complicated (構造的な絡まり) になっている箇所はありませんか？