14年前の講演が、いま必要になる理由。生成AIがコードを量産できてしまう2025年、圧倒されてしまっていないでしょうか。コードレビューや品質確保に追われているかもしれません。
この"複雑性の増大"に対して鋭い洞察を与えるのが、Rich Hickey（リッチ・ヒッキー）による Simple Made Easy (2011) です。ソフトウェア設計の本質を突く名講演でありながら、最近はあまり話題に登らないようです。
この記事では、原義に沿って Simple Made Easy を整理しつつ、後半は AI 時代にどのように読み替えられるのかを紹介していきます。今あらためて心に刻みたい内容です。
1. Rich Hickey —— 稀有な思想家が見ていたもの
Simple Made Easy を理解するためには、Rich Hickey（リッチ・ヒッキー）という人物にも触れておく価値があります。彼は Clojure の作者として有名ですが、「複雑性」を深く洞察する思想家に近い存在でもあります。
若い頃は音楽活動をしており、時間・構造・制約といった概念を作品にまとめる感覚が、ソフトウェアにも共通していると語っています。その後、現場のコンサルタントとして多数の複雑なシステムを見てきたことで、彼は確信を得ます。
"We are all very limited compared to the complexity we create."
私たちは、自分たちが作り出す複雑性に比べて、非常に限られた存在だ。
― Simple Made Easy (2011)
このテーマは以下の講演にも共通して現れます。
- Are We There Yet?（状態とアイデンティティ）
- Hammock-Driven Development（深い思考の必要性）
- The Language of the System（システム設計と抽象化）
彼の主張は言語仕様よりも"ものの見方"に重心があります。Simple Made Easy はその集大成ともいえる講演です。
2. Simple Made Easy の要点
前半では、Rich Hickey が講演で語った内容を、まず解釈を挟まず、そのままの構造で整理していきます。Simple Made Easy というタイトルのとおり、彼は "Simple" と "Easy" の違いを丁寧に切り分けることから話を始めます。この区別が本質であり、以降のメッセージすべてがここに紐づいています。
動画はこちら:
(InfoQはスライドが見やすく、YouTubeは字幕が便利)
スライドはこちら:
Simple と Easy はまったく別概念
Hickey がまず強調するのは、2つの言葉の意味がまったく別軸にあるという点です。
| 言葉 | 意味 |
|---|---|
| Simple | 構造的に「絡んでいない」(Complect しない)状態。分離され、一方向で、境界がはっきりしている。要素同士が独立している。 |
| Easy | 人間の主観による「近さ」。慣れている、すぐ理解できる、すぐ使える、といった心理的・技能的な距離。 |
Hickey は、ソフトウェアにおいてこの2つが混同されることが、複雑性の主な原因だと指摘します。人間は「簡単だから」「使いやすいから」という理由で Easy を選択してしまいがちですが、それは構造が Simple であることとは一切関係がありません。
"Simple is objective... Easy is relative."
Simple は客観的であり、Easy は相対的である。
― Simple Made Easy (2011)
つまり、Simple は「構造の状態」であり、Easy は「人間の経験」である と言い換えられます。この対比を理解した瞬間、私たちが普段「簡単だと思って採用しているもの」が、構造面でどれほど複雑なものを招いているかが見えてきます。
複雑性の正体は Entanglement（絡み合い）
Hickey がいう "Complexity" は、多機能であることや難易度が高いことではありません。もっと具体的で、もっと構造的です。
"Complect: To interleave, entwine, braid."
Complect（コンプレクト）: 織り交ぜること、絡み合わせること、編み込むこと。
― Simple Made Easy (2011)
Hickey は "complect" という古語を復活させ、複雑性の正体は entanglement（絡み合い）である と定義しました。具体例は次のとおりです。
- 本来分離されるべき責務が混ざる
- データとロジックが密につながる
- 依存が循環し、片方を変えるともう片方が壊れる
Hickey は、この entanglement が恐ろしいのは "指数関数的に増える" ところにあると強調します。最初の数本の糸の絡まりは問題にならないが、気づいた頃には解けなくなっている。この構造的な死を避けるために、Simple を基準に考える必要があります。
Simple を優先し、Easy を後から足す
講演の核心はここにあります。
"...we can make the same exact software that we make today with dramatically simpler stuff... there's no inherent complexity."
私たちは今作っているのとまったく同じソフトウェアを、劇的にシンプルなもので作ることができる。本質的な複雑性など存在しない。
― Simple Made Easy (2011)
つまり、"Simple first, then easy."（Simple を優先し、Easy を後から足す）という姿勢です。Easy を先に選ぶと、短期的には早いのですが、構造的なコストが蓄積していきます。後からほぐそうとすると莫大な時間がかかり、本来やりたかった開発が進まなくなります。
一方、Simple を優先する設計は一見回り道に見えますが、変化が来ても壊れにくく、長期的な速度を維持できます。Hickey は、Simple を基準にしておけば、Easy のツールやフレームワークを後から安全に乗せられる、と語ります。
私は以下のようなイメージを持っています。
Simple Made Easy が目指す世界
Hickey が語る "Simple" は、一般的な「イージー」「簡単」とは別物です。むしろ、現場の便利ツールへの過度な依存をいったん疑い、構造的な純度を保とうという姿勢に近いものです。
- 分離されていること
- 依存が単純であること
- 一方向であること
- 解釈の余地が少ないこと
こうした "構造の簡潔さ" は、AI 時代の現在でも、そのまま通用するどころか重要度が増していそうです。
3. 事例で理解する Simple と Easy
抽象概念としての Simple / Easy の違いを説明してきました。更にこの章では、具体的な例を通して両者の違いを立体的に理解していきます。
例1: レゴブロック —— Simple の象徴
レゴは、Simple の本質を驚くほどよく表しています。
- ピースは小さく、明確に分離されている
- 接続のルールは単純で、例外がほとんどない
- 小さな部品を組み合わせるだけで複雑な構造がつくれる
自動化やフレームワークの"便利さ"とは無関係に、構造そのものが Simple であるからこそ、全体が壊れにくく、後から変更しやすいのです。Simple な部品は、複雑な組み合わせを許しながら、複雑性そのものは増やさない。 ソフトウェアのコンポーネント設計とも非常に相性が良い考え方です（ただ、娘の遊ぶ最近のレゴを見ていると、固有のパーツが増え、 Easy に寄って来た印象もありますね。時代は変わりました）。
例2: UNIX —— 小さな道具の合成で世界をつくる
UNIX の哲学もまた Simple の好例です。
cat server.log | grep "Exception" | head -5
1つひとつのコマンドは単機能で小さく、責務が非常に明確です。役割を絞ったツールをパイプでつなぐだけで、柔軟な処理をつくることができます。
- 小さい
- 副作用が少ない
- 結合が一方向
- 組み合わせに強い
UNIX は「Simple を積み上げると、生産性が高い」という事実を体現しています。
例3: Spring Boot の"魔法" —— Easy だが Simple ではない
Spring Boot は、現代 Java のプロダクトで広く採用されている一方、Simple というより Easy 寄りの特性を持っています。
- アノテーションで暗黙的に依存が増える
- 自動設定（AutoConfiguration）が巨大で見通しにくい
- 内部の Bean ロード順序や振る舞いが把握しづらい
導入直後は「起動が速くて便利」ですが、Easy が強いがゆえに構造が把握しづらくなり、entanglement を招きやすい と言えます。
例4: GraphQL の巨大クエリ依存 —— Easy が強いと境界が曖昧になる
GraphQL は柔軟で、必要なデータを一度に取得できるという点で Easy が非常に強い技術 です。フロント実装は進めやすく、初期の開発速度は大きく向上します。
ただし、便利さが強いほど、次のような構造的な絡まりが発生しやすくなります：
- 巨大クエリが複数のドメインを横断する
- スキーマの結合関係がフロント都合で増えていく
- 「1項目追加」がサーバー内部の複数箇所の変更を誘発する
- 型や責務の境界が曖昧になりやすい
ここでのポイントは、GraphQL の柔軟さが構造を Simple から遠ざけることがある、ということです。便利さはそのまま、複雑性だけがじわじわ溜まりやすい領域、つまり、Easy が強い技術ほど、Simple を意識しないと絡まりが増える と言えます。
例5: AI コード生成 —— "Easyの暴走" が招く entanglement
AI が生成するコードは、初速が圧倒的に速く、"動くもの"を短時間で得られます。これは** Easy が無限に拡張された状態** といえます。便利さは飛躍的に向上しましたが、同時に次のような AI 特有の構造的リスクが生まれます：
- 局所的に賢い抽象化を入れ、責務境界を曖昧にしてしまう
- 一見汎用的なユーティリティや層を"よかれと思って"自動生成する
- 仕様の曖昧さを埋めるために、余計な意味付けや判断を勝手に追加する
- 関数単位では正しいが、モジュール全体では依存が絡みやすくなる
AI は「動くコード」を優先し、構造の純度（Simple）よりも即時性（Easy）を強化する 傾向があります。これは人間が陥る構造的問題と似ていますが、速度が桁違いです。"Easyの暴走" を止める役割は、依然として人間が担う必要があります。
先程の四象限で位置づけるとこうです。
4. AI 時代に Simple Made Easy を読み直す
3章で見たように、AI は Easy を極端に強化しました。動くコードが一瞬で手に入る時代です。しかしその裏で、entanglement も同じ速度で増殖しています。ここで思い出したいのが、Hickey のメッセージです。
"Simplicity is a choice... It requires vigilance."
シンプルさは選択である。それには注意深さが必要だ。
― Simple Made Easy (2011)
Easy の前に Simple のステップを挟む
AI 時代においても、この順番は変わりません。むしろ、Easy が強力になったからこそ、Simple のステップを意識的に挟む 必要があります。従来の開発では、Easy を選んでも複雑性の増加は人間の作業速度に比例していました。しかし AI は、その増加速度を桁違いに加速させます。だからこそ、AI に任せる前に「構造を決める」フェーズを設けることが重要になります。
- まず境界を決める
- 責務を分離する
- 依存の方向を整える
- その上で AI に実装を任せる
この順番を守れば、AI の出力が構造を破壊するリスクは大幅に下がります。
Simple を組み上げる作業も AI は得意
興味深いことに、AI は「Simple に書く」作業自体も得意です。1つの関数を責務を絞って書く、既存のパターンに沿ったコードを生成する、指示された境界の中だけで実装を完結させる。つまり、人間が Simple の基準を示せば、AI はそれに従って Simple なコードを量産できる のです。問題は、基準を示さなければ Easy に流れるという点にあります。
AI は自発的に Simple を選びません。しかし、Simple を選ぶよう指示すれば、その通りに動きます。ここに AI 時代の開発者の役割があります。
Simple を選ぶ能力が価値になる
AI はコードを書く能力において、すでに多くの人間を超えています。しかし AI は以下の判断ができません。何をどこで分けるべきか、境界をどこに置くべきか、結合をどこまで許容するか、どうすれば絡まりを避けられるか。これはすべて「Simple を選ぶ能力」です。そしてこの能力は、AI の性能が上がれば上がるほど、人間にしかできない領域として価値を増し続けます。
AI が Easy を高速化するほど、Simple を軸にできる開発者・チームが強くなります。Simple はただの美学ではなく、プロダクトの持続性を決定する基盤そのものです。
では具体的に日常にどう活かせるか。次章で少し考えてみましょう。
5. Simple を守るための9つの問い
Simple Made Easy の概念を、AI との協働の中で活かすにはどうすればよいか。ここでは「自分に問う質問」として整理します。Hickey の概念をそのまま判断基準として使える、思考の道具です。
Complect を見抜く
「この2つは、本当に一緒にすべきか？」
— AI は「関連しそうなもの」をまとめたがる。しかし関連と結合は違う。一緒にしなくても動くなら、分けたままにする。Complect の芽を摘む最初の問い。
「この変更の影響範囲を、即答できるか？」
— 即答できないなら、どこかで絡まっている。AI が生成した構造でも、変更時に「どこまで影響するかわからない」状態は entanglement の兆候。見通しの悪さを検出する問い。
「片方を変えたら、もう片方は壊れるか？」
— 壊れるなら絡んでいる。壊れないなら分離されている。この問いに Yes と答えるたびに、将来の変更コストが積み上がっている。
Easy の誘惑に気づく
「これは"慣れているから"選んでいないか？」
— Easy は相対的。自分にとって Easy なものが、構造的に Simple とは限らない。慣れや経験で選んでいるなら、一度立ち止まって構造を見る。
「1週間後の自分は、これを理解できるか？」
— Easy は「今の自分」にとっての近さ。しかしコードは未来の自分やチームメンバーも読む。今だけの Easy に最適化していないか。
「短期の速さと長期の速さ、どちらを取っているか？」
— Easy は短期で速い。Simple は長期で速い。AI の速さに引きずられて短期を選び続けると、entanglement が指数関数的に増える。どちらの速さを選んでいるか、意識する。
Simple に立ち返る
「これを分けたら、何が楽になるか？」
— 分割の目的を言語化する。「なんとなく分ける」は Simple ではない。分けることで得られる独立性・変更容易性を説明できないなら、分けない方がいい。
「この抽象化がなくても、動くか？」
— AI は「賢く見える」抽象化を作りたがる。しかし、なくても動くなら、それは今は不要。3箇所以上で使うまで抽象化を遅らせる勇気を持つ。
「この"賢さ"は、本当に必要か？」
— AI は賢く見えるコードを書きたがる。しかし賢さと Simple は別。愚直でも読める方が、長期的には強い。賢いコードほど、将来の自分を苦しめる。
これらの問いに共通するのは、構造を見る習慣 です。生成されたコードが動くかどうかではなく、絡んでいないか、一方向か、説明できるか。Simple Made Easy をいつも頭の片隅において AI と協働できるとよさそうです。
おわりに —— Simple を選ぶことは、未来を選ぶこと
Simple Made Easy が登場した 2011 年当時、Hickey が語っていたのは「便利さに流されると複雑性に飲まれる」という警告でした。現在、その警告は現実となり、AI によって Easy が無限に拡張される時代に突入しています。だからこそ、私たちが選ぶべきは Simple です。
"Simplicity is the ultimate sophistication."
シンプルさは究極の洗練である。
― レオナルド・ダ・ヴィンチ（Hickey が講演で引用）
Simple first, then easy. この順番を守ることが、AI 時代のソフトウェア開発における"もっとも古くて、もっとも新しい戦略"になっていきます。「早く行きたいなら Easy に行け、遠くまで行きたいなら Simple に行け」かもしれないですね！
参考: Rich Hickey の思想をさらに深く知りたい方へ
Rich Hickey Fanclub
2007年から2023年までの50以上の講演、インタビュー、著述物を網羅した包括的なコレクション。「毎回彼の講演を見るたびに、誰かが脳を整理してくれたような感覚になる」という引用が象徴的です。
Rich Hickey 講演トランスクリプト集
上記すべての講演を含む、Rich Hickey の講演トランスクリプト集。例外に漏れず、この記事の執筆も AI にサポートしてもらっていますが、このようなスクリプト集が完全に残っているからこそ、原文のニュアンスを正確に伝えることができました。
Discussion