Rich Hickey と Clojure：簡潔性・不変性・より良いデフォルト

なぜ現実のプロジェクトでは複雑さが勝ち続けるのか

ソフトウェアがいきなり複雑になることは稀です。締め切りを守るための簡易キャッシュ、コピーを避けるための共有ミュータブルなオブジェクト、「これは特別だから」の例外処理──それらは一つひとつは合理的に見える決定ですが、積み重なると変更が怖くなり、バグが再現しにくくなり、新機能の追加に以前より時間がかかるようになります。

複雑さが勝つのは短期的な快適さを提供するからです。既存のものを簡素化するより新しい依存関係を組み込む方が速いことがあり、状態をパッチする方が状態が五つのサービスに散らばっている理由を問うより簡単です。システムがドキュメントより速く成長するとき、慣習や部族的知識に頼りたくなる誘惑も強くなります。

この記事が目指すもの（と目指さないもの）

これはClojureのチュートリアルではありませんし、Clojureを知らなくても十分に価値が得られるように書いています。目的は、Rich Hickeyの議論にしばしば結びつく実践的な考え方を借りて、言語に依らず日常のエンジニアリング判断に適用できるヒントを提供することです。

デフォルトが思ったより重要な理由

ほとんどの複雑さはあなたが意図的に書いたコードではなく、ツールがデフォルトで何を簡単にしてしまうかから生まれます。デフォルトが「どこでもミュータブルなオブジェクト」なら、隠れた結合が生まれます。デフォルトが「状態はメモリにある」なら、デバッグや追跡が難しくなります。デフォルトは習慣を形作り、習慣がシステムを形作ります。

ここでは三つのテーマに焦点を当てます。

• 簡潔性（Simplicity）：機能を減らすことではなく、可動部分や特別扱いを減らすこと。
• 不変性（Immutability）：データを変更しない値として扱い、推論しやすくすること。
• より良いデフォルト（Better defaults）：安全で予測可能な選択が最も簡単になるようにすること。

これらはドメインから複雑さを取り除くわけではありませんが、ソフトウェアがそれを増幅するのを止める手助けになります。

Rich Hickey と Clojure が直そうとしたこと

Rich Hickey はClojureの作成者として知られる長年のソフトウェア開発者で、一般的なプログラミング習慣に挑む数々の講演でも知られます。彼の焦点は流行を追うことではなく、システムが変えにくく、推論しにくく、成長したときに信頼しにくくなる繰り返し起きる原因を見極めることです。

Clojureとは（高レベル、専門用語は控えめに）

ClojureはJVM（Javaのランタイム）やJavaScriptといった既存プラットフォーム上で動くモダン言語です。既存のエコシステムと協調しつつ、情報をプレーンなデータとして表現し、不変な値を好み、「何が起きたか」を「画面に表示するもの」と分けるスタイルを促します。

隠れた副作用から遠ざかるようにあなたをそっと導く言語、と考えてよいでしょう。

それが減らそうとした問題

Clojureは短いスクリプトを短くするために作られたわけではなく、繰り返し起きるプロジェクトの痛みに焦点を当てています：

• 共有状態から生まれる増大する複雑さ：多くの部分が同じデータを書き換えられると、バグはタイミング依存になり再現が難しくなる。\n- データと振る舞いの密結合：情報がオブジェクトやクラスの内部に閉じ込められると再利用が難しくなり、変更の波及が大きくなる。\n- 並行性の頭痛：バックグラウンドジョブ、キュー、並列処理が増えると「誰がいつ何を変更したか？」が日常問題になる。

Clojureのデフォルトは可変部品を減らす方向に働きます：安定したデータ構造、明示的な更新、安全に協調するツール群。

Clojureを採用しなくても有用な理由

価値は言語を乗り換えることに限定されません。Hickeyの核となる考え――不要な相互依存を取り除いて簡素化する、データを永続的な事実として扱う、可変状態を最小化する――はJava、Python、JavaScriptなどどの言語でもシステム改善に役立ちます。

簡潔性：「楽」ではなく、可動部分を減らすこと

Rich Hickeyは**simple（簡潔）とeasy（簡単）**を鋭く区別します──そして多くのプロジェクトは気づかないうちにこの線を越えています。

Simple と easy の違い（日常的な例）

Easyは今どう感じるかに関するものです。Simpleは部品の数とそれらの絡み合いの強さに関するものです。

• インスタントヌードルは簡単です。シンプルなシチューはシンプル：材料が少なく一鍋で済む、隠し事がない。
• ボタンが60個あるリモコンは一つの機能を“簡単”にするかもしれませんがシンプルではありません。6つの明確なボタンのリモコンの方がシンプルです。

ソフトウェアでは「簡単」はしばしば「今日タイプするのが速い」を意味し、「シンプル」は「来月壊れにくい」を意味します。

「今簡単」が将来の複雑さを作る仕方

チームはしばしば当面の摩擦を減らす近道を選びますが、それは目に見えない構造の増加という負債を生みます：

• 「フラグを追加しよう」→ 今やすべての機能がそのフラグを考慮する必要が出る。\n- 「計算済み値を保存して時間を節約しよう」→ 今度は複数経路で整合性を保たねばならない。\n- 「UIでパッチしよう」→ 同じビジネスルールが複数箇所に出現する。

各選択は一見スピードの向上に見えますが、可動部品、特別ケース、相互依存を増やし、どんどん脆くしていきます。

速さは簡潔さと同義ではない

迅速なデリバリーは素晴らしいことですが、簡潔化せずに速さだけ追うと将来への借金をしていることが多いです。その利息は再現しにくいバグ、オンボーディングの遅さ、変更に「慎重な調整」が必要になる形で現れます。

偶発的な複雑さを見つける簡単なチェックリスト

設計やPRをレビューするときに次を問いかけてください：

• 新しいモード、フラグ、設定の枝葉を導入していないか？
• 一貫させる必要があるデータをキャッシュ／重複していないか？
• ある振る舞いのために複数モジュールを同時に変更する必要があるか？
• ルールが複数箇所に実装されていないか？
• 新しいチームメンバーが追加説明なしに動作を予測できるか？

状態（State）：複雑さを静かに増幅するもの

「状態」とはシステム内で変化し得るもののことです：ユーザーのカート、口座残高、現在の設定、ワークフローの進行状況など。厄介なのは変化そのものではなく、変化は常に事が食い違う機会を生むということです。

同じ情報が時間や場所によって異なり得るとき、コードは常に「今どのバージョンが本物か？」という問いに応え続けなければならず、その答えを間違えるとランダムに感じるエラーが生まれます。

ミュータビリティ（可変性）：見過ごせない変化

ミュータビリティはオブジェクトをその場で編集することを意味します。「同じ」ものが時間とともに違うものになるということです。効率的に思えますが、推論を難しくします。なぜなら先ほど見たものを信頼できなくなるからです。

身近な例は共有スプレッドシートです。複数人が同じセルを編集できると、合計が変わったり数式が壊れたり、行が整理されて見えなくなったりします。誰かが悪意を持っているわけでなくても、共有可能で編集可能であるという性質自体が混乱を生みます。

ソフトウェアの状態も同様です。二つの部分が同じミュータブルな値を読むと、片方が静かにそれを変更している間にもう片方は古い仮定で処理を続けてしまい得ます。

なぜデバッグが苦痛になるのか

ミュータブルな状態はデバッグを考古学に変えます。バグ報告が「データが10:14:03に誤って変更された」と教えてくれることは稀です。見えるのは結果だけ：間違った数値、予想外のステータス、たまに失敗するリクエスト。

状態が時間とともに変わるため、最重要の問いは「ここに至るまでにどのような編集の順序があったのか？」になります。それを再構築できなければ振る舞いは予測不可能になります：

• 同じ操作がタイミングによって違う結果を出す。\n- 修正は「自分の環境では動く」が本番では動かない。\n- ロギングを追加するとタイミングが変わりバグが消える。\n これがHickeyが状態を複雑さの乗数と呼ぶ理由です：データが共有されかつ可変であると、可能な相互作用の数はあなたが整理できる能力より速く増えます。

コンピュータサイエンス用語を使わずに不変性を説明する

不変性とは単純に「作成後に変わらないデータ」です。既存の情報をその場で編集する代わりに、更新を反映した新しい情報を作ります。

レシートを思い浮かべてください：印刷されたレシートを消して項目を書き直したりはしません。何かが変われば訂正レシートを出します。古いレシートは残り、新しいものは明確に“最新版”です。

なぜ不意の驚きを減らすのか

データが静的であれば、陰で行われる編集を心配する必要がなくなります。これにより日常の推論がずっと楽になります：

• 値を保持していれば、それがそのままであると信頼できる。\n- バグの再現が容易になる（同じ入力は同じまま）。\n- システムの部分間でデータを共有するのが安全になる（誰も他人のためにうっかり壊せない）。

これがHickeyが簡潔性を語る大きな理由の一つです：隠れた副作用が少なければ追うべき精神的分岐も少なくなります。

「新しいバージョン」を作ることと「その場で編集する」こと

新しいバージョンを作ることは無駄に見えるかもしれませんが、その代替を比較してみてください。その場で編集すると「誰がこれを変えたのか？いつ？以前はどうだったのか？」と問わねばならなくなります。不変データなら変更は明示的です：新しいバージョンが存在し、古いものもデバッグ、監査、ロールバックのために残ります。

Clojureは更新を古いもののミューテーションではなく新しい値を生成することとして扱うことを自然にします。

正直に言うトレードオフ

不変性は無料ではありません。オブジェクトを多く割り当てる可能性があり、「これをただ更新すればいい」という習慣があるチームでは慣れるまで時間が必要です。良い点は、現代の実装は下層で構造を共有してメモリコストを減らすことが多く、見返りは典型的に落ち着いた、説明のつかない事故の少ないシステムです。

データが変わらないと並行処理は楽になる

並行処理とは単に「多くのことが同時に起きること」です。多数のリクエストをさばくウェブアプリ、レシートを生成しつつ残高を更新する決済システム、バックグラウンドで同期するモバイルアプリ──これらはすべて並行的です。

問題は多くのことが同時に起きること自体ではなく、それらが同じデータに触れることです。

共有され変更可能なデータが競合条件を生む理由

二つのワーカーが同じ値を読み取り後に修正し得ると、最終結果はタイミングに依存します。これが**競合条件（race condition）**です：忙しいときに現れるが再現が難しいバグです。

例：二つのリクエストが注文合計を更新しようとする。

1. リクエストAが total = 100 を読む\n2. リクエストBが total = 100 を読む\n3. Aが20を足して120を書き込む\n4. Bが10を足して110を書き込む

何も“クラッシュ”はしていませんが、更新が失われました。負荷が高くなるとこうしたタイミング窓はより一般的になります。

従来の解決策――ロック、同期ブロック、注意深い順序付け――は機能しますが、協調を全員に強います。協調は高コストです：スループットを遅らせ、コードベースが成長すると脆くなります。

不変性が協調を最小限にする仕組み

不変データでは値はその場で編集されません。代わりに、変更を表す新しい値が生成されます。

この単純な転換が多くの問題カテゴリを排除します：

• 読み手は読み中に対象が変わる心配をしなくてよい。\n- 書き手は同じメモリを奪い合うことなく新しいバージョンを生成する。\n- システムは最新版を公開する安全な手段を単純で検証済みのプリミティブで選べる。

結果：負荷下でも予測可能な振る舞い

不変性が並行処理を無償にするわけではありません—どのバージョンを現在と見なすかのルールは依然として必要です。しかしデータ自体が“動く標的”でなくなるため、負荷やジョブの滞留があってもタイミング依存の謎めいた障害が起きにくくなります。

実務での「より良いデフォルト」が意味するもの

「より良いデフォルト」とは、安全な選択が自動的に起きることで、余計なリスクを負うのは明示的にオプトアウトしたときだけ、という状態を指します。

これは小さなことに見えますが、デフォルトは月曜の朝に人が書くもの、金曜の夕方にレビュアーが受け入れるもの、新しいチームメンバーが最初に触れるコードから学ぶワーキングスタイルを静かに教えます。

リスクを減らすデフォルトの例

「より良いデフォルト」はすべての決定を代替するわけではありません。一般的な経路を誤りにくくすることを目指します。

例えば：

• 境界では不変データをデフォルトにする："ものを変更する"のではなく新しいバージョンを作る。これにより他の部分に誤って影響を与えるのが難しくなる。\n- 純粋関数を通常のスタイルにする：関数は入力を取り出力を返し、隠れた共有データを突如変更しない。これにより振る舞いが予測・テストしやすくなる。\n- 状態変更を明示的にする：何かが変わる必要があるときは、どこでも誰でも変更できるのではなく明瞭で定義された仕組みを通す。

これらですべての複雑さが消えるわけではありませんが、それが広がるのを防ぎます。

デフォルトはチームとコードレビューを形作る

チームはドキュメントだけでなく、コードが「やりたがる」ことに従います。

共有状態のミューテーションが簡単だとそれが常套手段になり、レビュアーは意図を議論することになります：「ここで安全なのか？」。逆に不変性や純関数がデフォルトだとレビュアーはロジックと正当性に集中でき、リスクの高い操作が目立ちます。

言い換えれば、より良いデフォルトは健全なベースラインを作ります：ほとんどの変更が一貫して見え、例外的なパターンは質問されやすくなります。

メンテナンスとオンボーディング

長期的な保守は既存コードを安全に読み替え・変更することが大半です。

より良いデフォルトは新しいメンバーのランプアップを助けます（「注意して、この関数は裏であのグローバルマップを更新する」などの隠れたルールが少ない）。システムが推論しやすくなり、将来の機能や修正、リファクタのコストが下がります。

事実（facts）とビュー（views）を分ける：時間、履歴、追跡可能性

Hickeyの講演で有用な思考の一つは、**事実（起きたこと）とビュー（現在私たちが信じていること）**を分離することです。多くのシステムは最新値だけを保存して過去を上書きしてしまい、時間の概念を失わせます。

事実は追記専用、ビューは派生される

事実は不変の記録です：「注文#4821が10:14に行われた」「支払いが成功した」「住所が変更された」。これらは編集されず、現実が変わるたびに新しい事実を追加します。

ビューはアプリが今必要とするものです：「現在の配送先は？」や「顧客の残高は？」。ビューは事実から再計算され、キャッシュやインデックス、マテリアライズドビューにして高速化できます。

履歴を保持する利点

事実を保持すると次が得られます：

• 監査可能性：現在の値がなぜそうなっているかを説明できる。\n- デバッグ：順序を再生してどの時点で乖離が起きたかを見つけられる。\n- 追跡可能性：「誰がいつ何を変更したか、以前はどうだったか？」がデータの問いになる。

分かりやすい例：上書き vs 追記

レコードを上書きするのはスプレッドシートのセルを更新するようなもの：最新の数値しか見えません。

追記専用ログは記帳のようなもの：各エントリが事実であり、「現在残高」はエントリから計算されたビューです。

すべてのシステムがフルイベントソーシングを必要とするわけではない

フルなイベントソーシングに移行する必要はありません。多くのチームは小さく始めます：重要な変更のための追記専用の監査テーブル、一部の高リスクワークフローの不変な変更イベント、スナップショット＋短期間の履歴ウィンドウなど。肝心なのは習慣：事実を耐久的に扱い、現在の状態を便宜的な射影と見ることです。

データを第一に：情報を耐久的かつ柔軟にする

Hickeyの実践的なアイデアの一つはデータファーストです：システムの情報をプレーンな値（事実）として扱い、振る舞いはその値に対して実行するものとする。

データは耐久的です。明確で自己完結した情報を保存すれば、後で再解釈したり、サービス間で移動したり、再インデックスしたり、監査したり、新機能に流し込んだりできます。振る舞いは耐久性が低い—コードは変わる、仮定は変わる、依存は変わる。

値（values）とアクション（actions）

• データ（値）：何が真か？ 顧客のメール、注文合計、タイムスタンプ、ステータス。\n- 振る舞い（アクション）：何をするか？ 検証、割引計算、通知送信、ステータスの意味づけ。

これらを混ぜるとシステムは粘着性を持ちます：データを再利用するために振る舞いも引きずらねばならなくなります。

結合を減らし再利用性を高める

事実とアクションを分離すると結合度が下がり、コンポーネントはデータ形状に合意するだけでよく、共有の実行経路に依存しなくてよくなります。

レポーティング、サポートツール、請求サービスは同じ注文データを消費し、それぞれ独自のロジックを適用できます。ストレージにロジックを埋め込むと、すべての消費者がそのロジックに依存し、変更が危険になります。

例：クリーンなデータ vs ストレージ内の小さなプログラム

クリーンなデータ（進化しやすい）：

{
  "type": "discount",
  "code": "WELCOME10",
  "percent": 10,
  "valid_until": "2026-01-31"
}

ストレージ内にミニプログラムを埋め込む（進化しにくい）：

{
  "type": "discount",
  "rule": "if (customer.orders == 0) return total * 0.9; else return total;"
}

後者は柔軟に見えますが、データ層に複雑さを押し付けます：安全な評価器、バージョニングルール、セキュリティ境界、デバッグツール、ルール言語が変わる際の移行計画が必要になります。

なぜこれがシステムの拡張性を高めるのか

保存された情報がシンプルで明示的なら、時間とともに振る舞いを変えても過去の記録を読み続けられます。新しいサービスは古い実行ルールを“理解する”必要がなく、異なる解釈を導入するのは新しいコードを書くことで済み、履歴を書き換える必要がありません。

既存システム（全面書き換えなし）での適用

大抵のエンタープライズシステムは一つのモジュールのせいで壊れるのではなく、すべてが互いに結びつきすぎることで失敗します。

気をつけるべき失敗モード

密結合は「小さな」変更が何週間もの再テストを引き起こす形で表れます。あるサービスにフィールドを追加したら下流の3つを壊す。共有データベーススキーマが調整のボトルネックになる。単一のミュータブルキャッシュやシングルトンの設定オブジェクトがコードベースの半分の依存になっている。

多くの部分が同じ変わるものを共有すると、連鎖的な変更が自然に発生します。チームはより多くのプロセス、より多くのルール、より多くのハンドオフで対応し、しばしばデリバリをさらに遅くします。

よりシンプルな境界で影響範囲を減らす

言語を変えたり全書き換えをせずにHickeyの考えを適用できます：

• 境界で不変データを優先する。 メッセージ、イベント、API入力を編集不可の「事実」として扱う。変化があるなら新しいバージョンを作る。\n- 状態をエッジに移す。 コアロジックは入力データ→出力データの純粋変換にし、データベースやキャッシュ、UIに「現在の状態」を任せる。\n- 共有ミュータブルな構造をやめる。 二つのモジュールが同じオブジェクトを書き換えるなら結合されている。参照を渡すのではなく値を渡す。

データが足元で変わらなければ「どうしてこの状態になった？」と悩む時間が減り、コードの振る舞いについて考える時間が増えます。

チーム間での「より良いデフォルト」

デフォルトが不一致の温床になります：各チームが独自のタイムスタンプ形式、エラー形状、リトライ方針、並行性アプローチを発明します。

より良いデフォルトはバージョン管理されたイベントスキーマ、標準の不変DTO、明確な書き込みの所有権、シリアライズ／検証／トレーシング用の承認済み少数ライブラリのようなものです。その結果は驚きの少ない連携とワンオフ修正の減少です。

既存コードベースでの漸進的導入

変化が既に起きているところから始めます：

1. 既存モジュールを、受け取り/返すデータが不変であるAPIでラップする。\n2. 高変化率のワークフローの一つをイベントスタイルの「追記専用」レコードに変える。\n3. 共有ミュータブルキャッシュを耐久的な事実から再計算されるビューに置き換える。

このアプローチはシステムを動かし続けながら信頼性とチームの調整を改善し、スコープを小さくして終わらせることができます。

プラットフォームとツールが「より良いデフォルト」を強化する場所

これらの考えを適用しやすくするのは、ワークフローが迅速で低リスクな反復をサポートする場合です。例えば、チャットベースのvibe-codingプラットフォームであるKoder.aiで新機能を作ると、二つの機能が直接「より良いデフォルト」マインドセットに合います：

• Planning mode は実装前に境界とデータ形状を明示にすることを促し、シンプルなデータフローと偶発的結合の違いを生みます。\n- Snapshots and rollback は変更を安全にデプロイできるようにし、「簡単な」近道が複雑さのスパイクになるリスクをすばやく元に戻せます。

スタックがReact + Go + PostgreSQL（あるいはモバイルはFlutter）であってもコアの指摘は同じです：日々使うツールは静かに作業のデフォルトを教えます。トレーサビリティ、ロールバック、明示的な計画を日常にするツールを選べば、その場しのぎのパッチに頼る圧力を減らせます。

トレードオフ、限界、そしてイデオロギーを避けること

簡潔性と不変性は強力なデフォルトであって、道徳的な掟ではありません。システムが成長する際の予期せぬ変更を減らすのに役立ちますが、実際のプロジェクトには予算や締め切り、制約があり、時にはミュータビリティが適切な道具です。

ミュータビリティが許される場面

パフォーマンスが重要なホットスポット（緊密なループ、高スループットの解析、グラフィックス、数値処理）ではミュータビリティが実用的です。また範囲が管理されている場合も許容されます：関数内のローカル変数、狭いインターフェースの後ろに隠されたプライベートキャッシュ、単一スレッドコンポーネントなど。

重要なのは「封じ込め」です。ミュータブルなものが外に漏れない限り、複雑さがコードベース全体に広がることはありません。

所有権とインターフェースで複雑さを縛る

ほとんど関数型スタイルでもチームは明確な所有権を必要とします：

• 一つのモジュールが状態を所有し小さなAPIで公開する。\n- データは境界を越える際にプレーンな値として渡す（秘密の振る舞いを持つライブオブジェクトではない）。\n- 副作用は端に押しやる（I/O、DB、時刻）。

ここでClojureのデータ指向と明示的境界へのバイアスは助けになりますが、この規律は言語固有ではなくアーキテクチャ的です。

Clojureが解決しないこと

どの言語も、悪い要件、曖昧なドメインモデル、あるいは「完了」の定義に合意できないチームを直せるわけではありません。不変性は混乱したワークフローを理解しやすくはしませんし、「関数型」のコードでも間違ったビジネスルールをよりきれいに表現しているだけということは起こり得ます。

教条主義を避ける：リスクを下げる最小の変更から始める

システムが既に本番で動いているなら、これらの考えを全面的な書き換えと扱わないでください。リスクを下げる最小限の動きを探しましょう：

• モジュール境界で共有ミュータブル構造を不変データに置き換える。\n- 監査性が重要なところにイベントログや追記専用の履歴を追加する。\n- レガシーな状態を狭いインターフェースの背後にラップし、そこから広がらないようにする。

目標は純度ではなく、変更ごとの驚きの数を減らすことです。

よりシンプルなソフトウェアに向かうための実践的チェックリスト

これは言語やフレームワーク、チーム構成を変えずに適用できるスプリントサイズのチェックリストです。

次のスプリントで試す3〜5のこと

1. 境界のデータ形状をデフォルトで不変にする。 リクエスト／レスポンス、イベント、メッセージは一度作って変更しない値として扱う。変更が必要なら新しいバージョンを作る。\n2. ワークフローの中心では純粋関数を優先する。 あるワークフロー（価格計算、権限、チェックアウトなど）を取り上げ、I/Oや隠れた読み書きを排した入力→出力の関数にリファクタする。\n3. 状態をより少なく、より明確な場所にまとめる。 概念ごとに1つだけのソースオブトゥルースを選ぶ。複数モジュールがそれぞれコピーを持つなら同期戦略を明示する。\n4. 重要な事実のために追記専用ログを追加する。 1つのドメイン領域で「何が起きたか」を耐久的なイベントとして記録する（現行状態は別に保持してもよい）。\n5. APIで安全なデフォルトを定義する。 デフォルトは驚きを最小化すべき：明示的なタイムゾーン、明示的なヌル処理、明示的なリトライ、明示的な順序保証。

設計レビューでの質問（そのまま使う）

• ここでのミュータブルな部分は何か、誰がそれを変更する権限を持つか？\n- フィールドを上書きする代わりに「事実＋派生ビュー」としてモデルできないか？\n- 2つのリクエストが同時に走ったら何が壊れるか？\n- 依存しているデフォルト（時間、順序、リトライ、キャッシュ）は何で、文書化されているか？\n- 3ヶ月後にこれをデバッグするには何が必要か？

Hickeyの講演から再検討すべきトピック

簡潔さと簡単さの違い、状態管理、値指向設計、不変性、時間に基づく履歴がデバッグや運用にどう役立つかに関する資料を探してください。

簡潔さは後付けの機能ではなく、小さく繰り返せる選択の中で実践する戦略です。