■ 1. Rich Hickeyとその思想的背景
- Clojureの作者でありソフトウェアの複雑性を深く洞察する思想家
- 音楽活動の経験から時間・構造・制約の概念をソフトウェアに応用
- コンサルタントとして多数の複雑なシステムを観察し「人間は自分が作る複雑性に対して非常に限られた存在だ」という確信を得た
- 主張の重心は言語仕様よりも「ものの見方」にある
- Simple Made Easy (2011)はその集大成であり他の講演(Are We There Yet? / Hammock-Driven Development / The Language of the System)にも共通テーマが現れる
■ 2. SimpleとEasyの違い
- SimpleとEasyは全く別の軸にある概念:
- Simple: 構造的に「絡んでいない」状態であり分離・一方向・明確な境界・独立した要素を持つ客観的な概念
- Easy: 慣れている・すぐ理解できる・すぐ使えるといった人間の主観による心理的・技能的な距離の概念
- ソフトウェアでこの2つが混同されることが複雑性の主な原因
- Simpleは「構造の状態」でありEasyは「人間の経験」である
■ 3. 複雑性の正体：Entanglement（絡み合い）
- Complexityは多機能や難易度ではなく構造的なEntanglement（絡み合い）を指す
- Hickeyは"complect"という古語を復活させ複雑性の正体を定義:
- 本来分離されるべき責務が混ざる
- データとロジックが密につながる
- 依存が循環し片方を変えるともう片方が壊れる
- Entanglementは指数関数的に増大し気づいた頃には解けなくなる
■ 4. Simple優先の設計原則
- 核心は「Simple first then easy」（Simpleを優先しEasyを後から足す）
- Easyを先に選ぶと短期的には速いが構造的コストが蓄積する
- Simple優先の設計は変化に強く長期的な開発速度を維持できる
- Simpleを基準にしておけばEasyのツールやフレームワークを後から安全に追加できる
- Simpleの条件:
- 分離されていること
- 依存が単純であること
- 一方向であること
- 解釈の余地が少ないこと
■ 5. 事例によるSimpleとEasyの比較
- レゴブロック（Simpleの象徴）:
- ピースが明確に分離されている
- 接続ルールが単純で例外がほとんどない
- 構造そのものがSimpleであるため壊れにくく変更しやすい
- UNIX（Simpleの好例）:
- 各コマンドが単機能で責務が明確
- 小さく副作用が少なく結合が一方向で組み合わせに強い
- Simpleを積み上げることで高い生産性を実現
- Spring Boot（EasyだがSimpleではない例）:
- アノテーションで暗黙的に依存が増える
- 自動設定が巨大で見通しにくい
- Easyが強いがゆえに構造が把握しづらくEntanglementを招きやすい
- GraphQL（Easyが強いと境界が曖昧になる例）:
- 巨大クエリが複数のドメインを横断する
- スキーマの結合関係がフロント都合で増えていく
- 型や責務の境界が曖昧になりやすくSimpleから遠ざかる
- AIコード生成（「Easyの暴走」の例）:
- 局所的に賢い抽象化を入れ責務境界を曖昧にする
- 仕様の曖昧さを埋めるために余計な意味付けや判断を自動追加する
- 動くコードを優先し構造の純度（Simple）より即時性（Easy）を強化する傾向がある
- Easyの暴走を止める役割は依然として人間が担う必要がある
■ 6. AI時代におけるSimple Made Easyの読み直し
- AIはEasyを極端に強化したがEntanglementも同じ速度で増殖させる
- AI時代においてもSimpleのステップを意識的に先に挟む順番は変わらない:
- まず境界を決める
- 責務を分離する
- 依存の方向を整える
- その上でAIに実装を任せる
- AIはSimpleに書く作業自体も得意であり人間がSimpleの基準を示せばそれに従って実装できる
- AIは自発的にSimpleを選ばないが指示すればその通りに動く
- AI時代に人間の価値となる「Simpleを選ぶ能力」:
- 何をどこで分けるべきか
- 境界をどこに置くべきか
- 結合をどこまで許容するか
- どうすれば絡まりを避けられるか
- AIの性能が上がるほどSimpleを軸にできる開発者・チームが強くなる
- Simpleはただの美学ではなくプロダクトの持続性を決定する基盤そのもの
■ 7. Simpleを守るための9つの問い
- Complectを見抜く問い:
- 「この2つは本当に一緒にすべきか」（関連と結合は違い一緒にしなくても動くなら分けたままにする）
- 「この変更の影響範囲を即答できるか」（即答できないならどこかで絡まっているEntanglementの兆候）
- 「片方を変えたらもう片方は壊れるか」（壊れるなら絡んでおり将来の変更コストが積み上がっている）
- Easyの誘惑に気づく問い:
- 「これは慣れているから選んでいないか」（慣れや経験で選んでいるなら一度立ち止まって構造を見る）
- 「1週間後の自分はこれを理解できるか」（今だけのEasyに最適化していないかを問う）
- 「短期の速さと長期の速さどちらを取っているか」（Easyは短期で速くSimpleは長期で速い）
- Simpleに立ち返る問い:
- 「これを分けたら何が楽になるか」（分割の目的を言語化できないなら分けない）
- 「この抽象化がなくても動くか」（なくても動くなら今は不要であり3箇所以上で使うまで抽象化を遅らせる）
- 「この賢さは本当に必要か」（愚直でも読める方が長期的には強くAIが生成する賢いコードほど将来の自分を苦しめる）