エンジニアリング哲学：Rich Hickey、シンプルはイージーではない

要点

• シンプルはイージーではない。 シンプルとは「絡まっていない」——一つの物事に一つの関心——という意味で、客観的なものです。一方イージーとは慣れ親しんで手元にあるという意味で、主観的なものです。私たちは絶えずイージーを選びながら、それをシンプルと取り違えています。
• 複雑さの根源は「絡める（complecting）」ことにあります。 複雑さとは部品の数ではなく、それらがどれだけ絡み合っているかです。状態を時間に、同一性を振る舞いに、方針を仕組みに絡めること——それが、ただ祈ることしかできないシステムを生み出すのです。
• 執拗に「ほどく（decomplect）」こと。 絡み合った関心を、意図的に組み合わせられる独立した部品へと引き離していきましょう。シンプルさは「一つの選択」であり、「絶え間ない警戒」を必要とします——慣れ親しんだツールに手を伸ばしているだけでは、決してたどり着けません。
• 場所より値を、オブジェクトよりデータを選ぶこと。 不変性をデフォルトとし、その場で状態を上書きするのではなく、過去を不変の事実として積み重ねていきましょう——ClojureとDatomicの両方を支える規律です。

原則

「この言葉の語源は『sim』と『plex』で、『一つの折り目、一つの撚り（より）』を意味します［…］そのすぐ隣に、あるいは対極にあるのが『complex』で、こちらは『一緒に撚り合わされた』『一緒に折り重ねられた』という意味です。」——Rich Hickey, Simple Made Easy¹

ソフトウェアの品質をめぐるほぼすべての議論は、実は一つの言葉をまとった二つの議論であり、Rich Hickeyの貢献はその二つを引き剥がしたことにあります。シンプルとイージーは同義語ではありません。そもそも同じ軸の上にすらないのです。一方は物事そのものを測り、もう一方はあなたとその物事との距離を測ります。シンプルはラテン語のsimplex——一つの折り目、一つの撚り、一つのねじれ——に由来します。これは物事そのものを表すもので、そこにどれだけの関心が織り込まれているかを示します。客観的なものであり、その対義語が複雑（complex）——一緒に撚り合わされ、自らの上に折り重なったもの——です。対照的に、イージーは「近くに横たわる」を意味する語根に由来し、これはadjacent（隣接）と同じ語根です。² イージーとは、その物事とのあなたの関係を表します。どれだけ手近にあるか、どれだけ慣れ親しんでいるか、始めるのにどれだけ労力がかからないか。主観的なものであり、その対義語がハードです。¹²

この区別が一度見えてしまうと、もう見ないことはできません。npm installひとつで手に入るからという理由で手を伸ばすツールはイージーです。それがシンプルかどうか——永続化をバリデーションに、それをUIに、それをビジネスルールに絡めてしまわないかどうか——は、まったく別の問いであり、その答えはたいてい「ノー」です。私たちは絶えずイージーを選び、それをシンプルと呼び、そして自ら招き入れた複雑さの中で溺れていきます。絡める行為を表すHickeyの言葉がcomplect——「織り交ぜる、絡ませる、撚り合わせる」——です。³ 絡めることこそが原罪なのです。それは、本来なら筋道を立てて考えられたはずのシステムを、ただ祈ることしかできないものへと変えてしまいます。なぜなら、いったん二つの関心が撚り合わされてしまえば、もう一方を理解し、そのリスクを負うことなしには、片方に触れることすらできなくなるからです。

だからこそ規律とは、ほどく（decomplect）こと——絡み合った関心を執拗に独立した部品へと引き離していくこと——であり、Hickeyはその代償について率直です。「シンプルさは選択です」と彼は言います。「シンプルなシステムを持てないのは、あなたのせいなのです」⁴ それは慣れ親しんだツールに手を伸ばすことで自然に手に入るものではありません。「絶え間ない警戒」と、意図的な配慮を通じてこそ得られるのです。⁴ 原則のすべてが、たった一言に集約されます——シンプルはイージーではない。 シンプルさとは、より困難で、選び取られた、絡まっていない道であり、複利のように積み上がっていく唯一の道なのです。品質こそが唯一の変数であるという主張の根底にも、同じ信念が横たわっています——その都度便利な一歩を踏むことで、きれいなシステムに後ずさりしてたどり着くことはできません。勾配に逆らって、毎回それを選び取るのです。

背景

Rich Hickeyは独立系のプログラマーで、彼を有名にしたものを作り上げるまでに、およそ20年にわたってC++、Java、C#のシステムを生業として書いてきました。⁵ それらの言語で大規模システムを作る方法を熟知していた彼が、20年を経てたどり着いた結論は、それらの言語に機能が足りないということではありませんでした。それらが「絡める機械」だということ——関心を撚り合わせることをいとも簡単にし、それをほどくための助けをほとんど与えてくれないということでした。

そこで彼は、たった一人で、その代替を自ら作り上げました。2005年ごろから、Hickeyはおよそ2年半をかけてClojureを開発しました——その多くを自己資金で、給与なしで働きながら、Java仮想マシン上で動くLispを作ったのです。それは、不変性とシンプルさを英雄的行為ではなく最小抵抗の道とするための言語でした。⁵ 彼は2007年にそれを公開しました。背後に企業はなく、委員会もなく、助成金もありませんでした。病をその目で間近に見てきた一人のプログラマーが、その治療法を作るために自らの蓄えから何年もを費やすと決めた——ただそれだけのことでした。彼はのちに不変データベースであるDatomicを生み出し、⁵ 一連のカンファレンス講演——Simple Made Easy、The Value of Values、Hammock-Driven Development、Are We There Yet?——を行いました。それらは総体として、現代の関数型プログラミングにおいて最も影響力のある設計哲学の集大成となっています。⁶

仕事

Simple Made Easy：シンプル対イージー、そして絡めること

2011年9月にStrange Loopで行われたSimple Made Easyは、ある世代のプログラマーが複雑さについて語る言葉を再編成した講演です。¹ その力のすべては、シンプルとイージーを同じ意味にさせまいと拒むところから生まれています。シンプルとは構築物についてのこと——一つの折り目か、それとも幾重にも撚り合わされているのか。イージーとはあなたについてのこと——手近にあるか、慣れ親しんでいるか、今の自分の能力の範囲内にあるか。シンプルだが不慣れなもの（学ぶのは難しいが、付き合っていくのは楽なもの）もあれば、イージーだが複雑なもの（慣れ親しみ、心地よく、そして静かに破滅をもたらすもの）もあります。業界が生産性として売り込むものの大半は、この後者です。¹

その中心にある動詞がcomplect——撚り合わせる、織り交ぜる、絡ませる——です。³ 絡めることこそが、システムを複雑にするものなのです——部品の数ではなく、それらがどれだけ絡み合っているか。状態は値と時間を絡めます。オブジェクトは状態と同一性と振る舞いを絡めます。継承、ORM、メソッド全体に散らばった条件分岐——そのどれもが、本来は別々に立っていられたはずの関心を撚り合わせています。そして撚りの代償は一度きりでは済みません。それは将来のあらゆる変更のたびに支払われます。なぜなら、もう一本の糸すべてを乱すことなく、一本の糸に触れることはできなくなるからです。

その治療法がほどく（decomplect）こと——糸を、あとから自分の条件で組み合わせられる独立したものへと引き離すこと——です。Hickeyの主張は、そしてそれは強い主張ですが、ほどくことは力の喪失ではない、というものです。「劇的にシンプルなツールで、同じだけ洗練されたシステムを書くことができます」と彼は言います——同じプログラムでありながら、実際に筋道を立てて考え、変更し、信頼できるものを、です。⁴ シンプルさとは、初心者向けに削ぎ落とされた能力の部分集合ではありません。それは、絡めることを拒むという、熟練者の規律なのです。

Clojure：JVM上のLisp、オブジェクトよりデータ

Clojureとは、原則を実行可能にしたものです。JVM上で動く動的な関数型Lisp方言であり、Hickeyによって「並行性のために設計された確立されたプラットフォームと共生する、関数型プログラミングのためのLisp」として設計されました。⁷ 二つの決定が、その哲学を体現しています。第一に、不変性はオプションではなく、デフォルトである——Clojureのコアデータ構造は不変かつ永続的であり、最も自然に書けるものが、遠く離れた場所での変更によって壊されることのないものでもあるのです。⁷ 第二に、オブジェクトよりデータ——それぞれが私的な状態と振る舞いを絡めて抱えた、無数のあつらえのクラスが乱立するのではなく、Clojureは「少数の主要なデータ構造の上に定義された多くの関数」——シーケンス、マップ、ベクター、セット——を好みます。⁷ ただマップを使う。ただデータを使う。

この分離は、言語の文法のレベルでの「ほどき」です。オブジェクトは状態、同一性、振る舞いを、密封された一つのものへと撚り合わせます。Clojureはそれらを引き離します——物事が何であるかを表す不変の値、それに対して何をするかを表す素朴な関数、時間をまたいで管理される変化を表す明示的な参照型へと。JVMと戦うのではなくプラットフォームとすることで、Hickeyは言語をランタイムからもほどきました。ClojureはJVMの成熟度、ライブラリ、性能をただで手に入れ、その新規性の予算のすべてを、状態と時間のモデルだけに費やしたのです。⁷

The Value of Values：不変性とDatomic

The Value of Valuesは、不変性の議論をもう一段上——データベースそのものへと引き上げます。Hickeyの標的は、彼が場所指向プログラミング（place-oriented programming、PLOP）と呼ぶものです。「新しい情報が古い情報を置き換えるたびに、あなたは場所指向プログラミングをしているのです。」⁸ 私たちはレコードをその場で更新し、古い値は消え、それとともに履歴も消えます。彼は、これがメモリが希少だった時代の名残であり、ビジネスが思考するためにまさに必要とするもの——過去——を捨て去っていると論じます。対照的に、値は定義からして不変です。事実とは「起こったこと、起こったと知られていること」であり、事実は更新できず、ただより新しい事実によって取って代わられるだけなのです。⁸ 新しい大統領は古い大統領を上書きするのではなく、追記するのです。

Datomicは、その考えをデータベースとして築いたものです。それは根本的に不変です。「Datomicのデータベースとは、datomと呼ばれる不変の原子的事実の集合である」、そして「Datomicのトランザクションはdatomを追加するだけで、決して更新も削除もしない。だから完全な監査証跡が残る」のです。⁹ 何ひとつ上書きされることがないため、データベースはある時点における値として扱うことができます——過去の任意の瞬間を、現在に対して実行するのと同じクエリで、何の変更もなく「as-of（〜時点）」で問い合わせられるのです。⁹ データベースは単一の可変な場所であることをやめ、時間をまたいだ一連の値となります。状態、同一性、そして時間——それらが本番のデータストアの中でほどかれているのです。

Hammock-Driven Development：まず考える

これらすべてに寄り添うのが、本当の仕事がいつ起こるのかについての講演であり、Hickeyの答えはこうです——キーボードに触れる前に、と。Hammock-Driven Developmentの中で彼は、「バグを直すのに最も費用がかからない場所は、ソフトウェアを設計しているときだ」と論じ、深刻なソフトウェアの失敗の大半は思い違いの失敗である——解き始める前に、私たちは問題を理解していなかった——と述べます。¹⁰ その処方箋は、問題を明示的に述べ、事実と制約を集め、そして考えること——問題を「背景の心」に手渡すことも含めて、です。背景の心は、分析的な「目覚めた心」が無理やり作ることのできないつながりを作り出します。¹⁰ ハンモックとは、邪魔されることなく、ただ考えるだけのための、文字通りの家具なのです。

ハンモック駆動開発は、そもそもシンプルさを可能にする実践です。まだ理解していないシステムをほどくことはできませんし、コンパイルへと急ぎながらそれを理解することもできません。ハンモック駆動開発は、シンプルはイージーではないの、華やかさのない前半部分なのです——絡まっていない設計が現れる前に起こらねばならない、意図的で、ゆっくりとした、警戒を怠らない思考のことです。

方法

その方法とは、たった一つの区別——シンプルはイージーではない——を、言語、データベース、そして仕事のやり方を貫いて、並外れた頑固さで適用することです。

あらゆる決定の前に、「シンプル」を「イージー」から切り離す。 どんなツールや設計についても問いましょう——これは絡まっていない（シンプル）のか、それとも単に慣れ親しんで手近にある（イージー）だけなのか。両者は別々の軸であり、それらを混同することこそが、複雑さが生産性を装って忍び込む経路なのです。¹²

絡まりを狩り、それをほどく。 複雑さとは部品の数ではなく、それらがどれだけ絡み合っているかです。状態が時間に、同一性が振る舞いに、方針が仕組みに撚り合わされている箇所を見つけ——その糸を引き離し、意図的に組み合わせられる独立した部品にしましょう。³

場所やオブジェクトより、値やデータを選ぶ。 不変性をデフォルトにしましょう。情報を素朴なデータ——マップ、ベクター——として表現し、状態と振る舞いをオブジェクトの中に密封してしまうのではなく、関数でそれを操作するのです。⁷⁸

過去を、上書きされる状態としてではなく、値として扱う。 新しい情報は、破壊するのではなく追記すべきです。時間をまたいで不変の事実を積み重ねていくシステムは、筋道を立てて考え、監査し、任意の瞬間を「as-of」で問い合わせることができます——その場で上書きされる場所には、決してできないことです。⁸⁹

打つ前に考える。 欠陥を直すのに最も安上がりな場所は、設計の中です。問題を述べ、それを背景の心に与え、まず問題を理解することで、シンプルな設計を勝ち取りましょう。¹⁰

シンプルさは困難であり、選び取るものだと受け入れる。 それはイージーなものに手を伸ばすことでは手に入りません。「シンプルさは選択」であり、「絶え間ない警戒」を必要とします。便利な道とシンプルな道は、めったに同じ道ではないのです。⁴

影響の連鎖

彼を形作った人々

LispとJohn McCarthy。 Clojureは、Hickey自身の言葉で言えば「後方互換性に縛られないLisp」です——コードをデータとして扱う同図像性（homoiconicity）とマクロの力は、McCarthyの系譜からまっすぐに受け継がれ、それがリストだけでなくマップやベクターへと拡張されています。⁷（直接的影響）

John Backusと関数型プログラミングの伝統。 Backusの1977年のチューリング賞受賞講演Can Programming Be Liberated from the von Neumann Style?は、代入駆動の、場所指向の計算に反対する正典的な論証です。Hickeyの場所指向プログラミングと可変状態に対する戦いは、その論証を本番へと持ち込んだものなのです。（形成的影響）

Java仮想マシン。 ランタイムを抽象化して遠ざけるべき敵として扱うのではなく、HickeyはJVMをプラットフォームとし、その上に言語を築きました——「言語」を「ランタイム」から意図的にほどくことで、Clojureは初日から成熟度と到達範囲を手に入れたのです。（直接的影響）

リレーショナルで値指向の思考。 データを、時間をまたいで積み重ねられ、任意の時点を「as-of」で問い合わせられる不変の事実とみなすDatomicの見方は、事実をその保管場所から切り離すリレーショナルの伝統——情報は、今それを保持している場所とは独立に存在する、という考え——から受け継がれたものです。⁸⁹（形成的影響）

彼が形作った人々

関数型プログラミングのルネサンス。 Clojureは、JVM上のScalaなどと並んで、関数型プログラミングを学術的な好奇の対象から主流の本番へと押し上げる手助けをしました。そしてHickeyの講演は、働くプログラマーが今や設計を論じるのに使う共通の語彙——「シンプル」「イージー」「complect」——となったのです。

主流となった不変性。 不変をデフォルトとするデータこそが、風変わりな制約ではなく正気のデフォルトである、という考えは、Clojureをはるかに超えて広まりました。それは今や、業界全体の言語やライブラリの設計における、当然の前提となっています。

React、Redux、そしてフロントエンドの世界。 値指向のモデル——不変の状態、データに対する純粋な変換、引き離された同一性と状態——は、Reactの、とりわけReduxの概念的な背骨です。一世代分のフロントエンドエンジニアが、それが誰のものかを必ずしも知らないまま、Hickeyの値の思考を吸収していったのです。

貫く一本の線

John Carmackはレンダラーを高速でシンプルな核へと削ぎ落とし、内側のループに遅さを絡めてしまうようなあらゆる機能を拒みます。Hickeyはシステムを絡まっていない関心へと削ぎ落とし、それらを絡めてしまうようなあらゆる抽象を拒みます。両者ともに、シンプルさをデフォルトではなく、困難で選び取られたものとして扱っています。そしてLinus Torvaldsが、特殊ケースを一般ケースの中へと消し去る「良いセンス」を重んじるのに対し、Hickeyは、二つの絡み合った関心を一つずつ別々に立たせる「ほどき」を重んじます——同じ直感を、対極の端から見たものなのです。正しい構造とは問題に施す装飾ではなく、その実体へと正しく切り分けられた問題そのものである、と。Yukihiro MatsumotoはRubyを、書く感触——Hickeyの語彙で言えばイージー——のために最適化しました。一方Hickeyは、物事が何であるか——シンプル——のために最適化しました。二人合わせて、Hickeyが講演まるまる一本を費やして「混同するのをやめよう」と訴え続けた、その二つの軸を描き出しているのです。（シリーズの架け橋）

ここから私が受け取るもの

私が抱き続けている教訓は、イージーとは美徳を装った罠だ、ということです。コードベースにおけるほぼすべての後悔は、手近なものへ手を伸ばすという、もっともらしい行為から始まりました——便利なライブラリ、手っ取り早い変更、すでに存在するクラスに折り込まれた、もう一つだけの責務。そのどれもが間違いだとは感じられませんでした。なぜなら、イージーは決してそう感じさせないからです。Hickeyが与えてくれたのは、それをその場で捕まえるための語彙です——立ち止まってこれはシンプルなのか、それともただイージーなだけなのか？と問い、そして正直な答えはたいてい不都合なほうだと知ること。それは品質こそが唯一の変数であるというのと同じ基準です——問いは決して「何に最も速くたどり着けるか？」ではなく、「ここで実際に絡まっていないものは何か？」なのです。

私が今ものを作っている世界——エージェント、ツールのループ、状態、プロンプト、リトライ、副作用が、統治しようのない一つの塊へと自らを撚り合わせたがる、ハーネスのコード——では、誘惑は最大限にイージーです。フレームワークを積み重ね、状態をループ全体に塗り広げ、判断のロジックをI/Oと、それをロギングと絡めていき、ついには誰も全体のリスクを負わずに一部分を変えることすらできなくなる。Hickey流の一手は、ほどくことです——方針を仕組みから引き出し、できるところでは状態を不変にし、上書きする場所としてではなく、一回の実行を値として扱う。その信念——センスとは技術的なシステムである、手近なものに手を伸ばして受け継ぐ「雰囲気」ではなく、警戒をもって選び取るものだという信念——こそが、2007年の自己資金のLispから、2026年のエージェントのハーネスへと貫く一本の線なのです。シンプルはイージーではない。それでも、それを選びましょう。

FAQ

シンプルとイージーの違いは何ですか？

Rich HickeyのSimple Made Easyにおける捉え方では、シンプルとイージーはまったく別々の軸です。シンプルはラテン語のsimplex——「一つの折り目、一つの撚り」——に由来し、物事そのものを表します。そこにどれだけ少ない関心が織り込まれているか、ということです。客観的なものであり、その対義語が複雑（「一緒に撚り合わされた」）です。¹ イージーは「近くに横たわる」を意味する語根に由来し、これはadjacentと同じ語根です。それは、その物事とのあなたの関係——どれだけ慣れ親しみ、手近にあるか——を表します。² 主観的なものであり、その対義語がハードです。何かはシンプルだが不慣れであることもあれば、イージーだが深く複雑であることもあります。Hickeyが言いたいのは、私たちは絶えずイージーを選びながらそれをシンプルと取り違え、その複雑さの代償を後で支払っている、ということです。¹

「complect」とはどういう意味ですか？

complectは、関心を撚り合わせる行為を表すために、HickeyがSimple Made Easyでよみがえらせた動詞です。彼はそれを直接こう定義します——「織り交ぜる、絡ませる、撚り合わせるという意味だ」と。³ 絡めることこそが、システムを複雑にするもの——部品の数ではなく、それらがどれだけ絡み合っているか——です。二つの関心が絡め合わされてしまうと（たとえば状態と時間、あるいは同一性と振る舞い）、もう一方を理解し、そのリスクを負うことなしには、片方を変えることができなくなります。その処方箋がほどく（decomplect）ことです——糸を、意図的に組み合わせられる独立した部品へと引き離すのです。Hickeyは、ほどくことをシンプルなシステムを築くための核心的な規律として扱っています。³

Rich Hickeyは何を作ったのですか？

Rich Hickeyは独立系のプログラマーで、Java仮想マシン上で動く動的な関数型Lisp方言Clojureを生み出しました。彼はおよそ2年半をかけて、その多くを給与なしの自己資金で、ほぼ一人でそれを開発し、2007年に公開しました。⁵⁷ 彼はのちに不変データベースDatomicを生み出しました。これはデータを決して上書きせず、時間をまたいで不変の事実（「datom」）を積み重ねていくため、データベースを過去の任意の時点における値として「as-of」で問い合わせることができます。⁹ 彼はまた、一連のカンファレンス講演——Simple Made Easy、The Value of Values、Hammock-Driven Development、Are We There Yet?——でも広く知られており、それらは業界が複雑さ、不変性、設計について語る語り方を形作りました。⁵⁶

Rich Hickeyは「プログラマーはあらゆるものの利点を知っているが、何のトレードオフも知らない」と言ったのですか？

この一言は非常に広くHickeyに帰せられ、彼の考えをまさに言い当てていますが、彼の主要な講演の書き起こしには一字一句そのままの形では現れません。それは書籍やカンファレンス講演を通じて広まった、結晶化された言い換えです。¹¹ 一字一句に最も近い一次資料はDesign, Composition, and Performanceにあり、そこで彼は、解決策を分解して「利点だけでなく——そう、利点はたいてい一目瞭然ですよね。そうではなく、トレードオフも見るのです。これのどの部分がうまくいかないのか、を」見るよう促しています。¹² その趣旨が紛れもなく彼のもの——エンジニアはツールが何を与えてくれるかに過度に注目し、それが何を犠牲にするかをほとんど検討しない、という趣旨——であることは間違いありませんが、あの切れ味のいい警句は、直接の引用ではなく言い換えとして扱うのが最善です。

出典