---
title: "Simple Made Easy" Made Easier: Clojureに学ぶsimplicity
tags:  #simple made easy #clojure #関数型プログラミング #関数型言語 #lisp #設計  
author: [Kent OHASHI](https://docswell.com/user/lagenorhynque)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LELMN2M37R.jpg?width=480
description: Rich Hickeyの有名なプレゼン"Simple Made Easy"をより踏み込んで解説します。 cf. 2019年版: https://www.docswell.com/s/lagenorhynque/57VRMG-simple-made-easy-made-easy
published: May 28, 26
canonical: https://docswell.com/s/lagenorhynque/K7NJ12-simple-made-easy-made-easier
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LELMN2M37R.jpg)

"Simple Made Easy"
Made Easier
に学ぶsimplicity
Clojure
#lispmeetup
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4JMYX8YMJW.jpg)

🐬カマイルカ
lagénorhynque
関数型プログラミング(言語)の愛好者/実践者
特にClojure, Haskell, Flixがエレガントで好き
関数型まつり2026の運営スタッフ(座長のひとり)
主に(CfPを含む)メインコンテンツの準備を担当
株式会社スマートラウンドのシニアエンジニア
スタートアップと投資家のやり取りを効率化する
データ管理プラットフォームを開発
ソフトウェア設計/開発とともに会計/財務/法務
について探求するのも好き
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/PJR9N59L79.jpg)

年 月の関数型まつり2026で登壇予定🐬
[PR] 2026 7
速習FP in Scala with Flix: Flix言語で親しむ純粋関数型のコード設計
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PEXQNK36JX.jpg)

視点でのFlixの紹介記事を書きました🐬
[PR] Clojurian
が出会ったsimple志向なJVM関数型言語Flix ——ファーストインプレッション
Clojurian
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3EK9N5YGED.jpg)

関数型言語
年 月 での発表
Fun Fun Functional (2)
Lightning Talks!! (2019 7 )
の設計思想を理解しよう
[書き起こし記事] "simple"と"easy"はどう違う？ Simple Made Easyを解説 Part1
"Simple Made Easy" Made Easy: Clojure
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/L73WVK9575.jpg)

今回のテーマ
(-> (simple-made-easy-made-easy)
revisit ;
"Simple Made Easy" Made Easy
deepen
;
Clojure
/
extend) ; Clojure
「
近年の
」をおさらい
エコシステム コミュニティの進化を深掘り
の範囲に留まらないより一般的な示唆へと展開
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/87DK83GYJG.jpg)

と
という言葉
とは
と の意味
と の関係
なぜ
を重視するのか
どのように
にするのか
に見る
と の区別のより抽象的(メタ)な示唆
1. simple easy
2. "Simple Made Easy"
3. simple easy
4. simple easy
5.
simplicity
6.
simple
7. Clojure
simplicity
8. simple easy
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/VJPK8432E8.jpg)

1. simple
と easy という言葉
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2EVVNX4XEQ.jpg)

コミュニティにおける simple
明確に定義された特別な意味がある
easy と混同されやすいが概念的にまったく違う
Clojureとは simple さ(simplicity)を追求した言語
あらゆる場面で非常に重視されている概念
設計の良し悪しを図る指標のひとつ
Clojure
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/57GLKV1REL.jpg)

とは
2. "Simple Made Easy"
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4EQYN6DYJP.jpg)

Simple Made Easy (at Strange Loop 2011)
作者Rich Hickeyによる極めて有名な発表
コミュニティで simple の概念が浸透するきっかけ
日本ではタイトルも趣旨も(特にClojurian以外から)
わりと誤解されているかも
Clojure
cf. Simplicity Matters (at RailsConf 2012)
· eed3si9n
シンプルさの必要性
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/KJ4WG4ZZ71.jpg)

タイトル"Simple Made Easy"の意味
敢えて訳せば「simple簡単解説」
例えば Word Power Made Easy という本がある
英語の文法的には:
X makes Y easy.
→ Y is made easy [by X].
→ Y made easy [by X] (
simple easy
simple
easy
?
簡単になったY)
本題の
と を掛けた言葉遊びでもある
を追求すると にもなる
英語的にも内容的にもちょっと苦しい解釈
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LE1YD4RD7G.jpg)

3. simple
と easy の意味
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GEWGYX18J2.jpg)

simple
の意味
simple < simplex (= sim- + plex)
ラテン語 simplex
原義: 「一折り」「一編み」「一捻り」
「単一の役割」「単一の責務」「単一の概念」「単
一の次元」 ※「単一の実体/操作」 ではない
客観的な概念: 設計対象の構造の単純さ
対義語: complex (= com- + plex)
原義: 「絡まり合った」「折り重なった」「もつれ
た」
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/47ZLX6P9J3.jpg)

easy
の意味
easy (= ease + -y) < aise/eise < adjacens
ラテン語 adjacens (cf. 🇬🇧 adjacent)
原義: 「近くにある」「隣接した」
「身近な」(物理的に近い)「親しみがある」(自分
の理解に近い)「易しい」(できることに近い)
主観的/相対的な概念: 利用者からの(広義の)近さ
対義語: hard
原義: 「強い」「手ごわい」 ※ easy とは無関係
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/YJ6W42MDJV.jpg)

4. simple
と easy の関係
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GJ5MQ2Z8J4.jpg)

と easy の二者択一ではない
simple/complex, easy/hard の直交した2つの評価軸
単純なトレードオフの関係にはない
simple AND easy も complex AND hard もある
「 easy よりも simple を選ぼう」 ではない
complex になりうるものを避けて simple を追求
しようというのがRich Hickeyの主張
選択するのは simple OR complex であって
simple OR easy ではない
simple AND easy は十分に実現可能
simple
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/9E29P4RV7R.jpg)

構図例: "easy but complex" vs "simple but hard"
ease を優先し complexity (↔ simplicity)を甘受する
短期: easy なため生産性が高く、 complex である
ことも直ちに支障をきたさない
中長期: complex ゆえに生産性が急速に低下
構造的な限界により徐々に手に負えなくなる
⭐️ simplicity を優先し hardness (↔ ease)を甘受する
短期: hard ゆえに生産性が低く、 simple なもの
を課題に適用するにはいくらか時間が掛かる
中長期: simple なため生産性が高い水準を維持
hard から easy へと習熟/環境整備も進む
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/D7Y45MDQEM.jpg)

よくある誤解/派生解釈と🐬の見解(1)
"Simple Made Easy"というRich Hickey
による標語がある
「 simple 簡単解説」というのが文字通りの解釈
simple と easy の峻別という本題に関わる最重要の
キーワードが見事に組み込まれた表現
しかし、タイトル自体に何かを促すメッセージ性が
あるとは読み取りがたい
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VENYNW62J8.jpg)

よくある誤解/派生解釈と🐬の見解(2)
simple: 覚えることの少なさ重視
easy: 手数の少なさ重視
simplicity と ease がもたらしうる実用的メリットを
分かりやすく伝えようという試みに感じられる
しかし、 simplicity が客観的な構造の問題から主観
的な体験の問題に変質してしまう危うさがある
「覚えることが少ない」という体験はむしろ
easy であることの例と位置付けるのが素直そう
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/Y79PRXLDE3.jpg)

よくある誤解/派生解釈と🐬の見解(3)
simple と easy はトレードオフなので
simple を選ぼう
simple にすると ease が損なわれ、 easy にすると
simplicity が損なわれるだろうか?
確かに、 simple but hard なもの、 easy but
complex なものは両極端で分かりやすい対比
しかし、「設計対象の構造の単純さ」と「利用者
からの(広義の)近さ」というまったく異なる性質
の間に不可避的な連動関係があるとは考えがたい
21


# Page. 22

![Page Image](https://bcdn.docswell.com/page/G78DW2X57D.jpg)

誤解/派生解釈例に共通する傾向(🐬のメタ読み)
simplicity を分かりやすく(easy に)理解しようとす
るあまり、 simplicity が何かと complect している
例1: (例えば) simple にすると easy になるという
論理関係が加わっている
例2: simplicity に主観的な要素が加わっている
例3: simple/complex, easy/hard という独立した
評価軸が単一軸の二項対立にまとまっている
22


# Page. 23

![Page Image](https://bcdn.docswell.com/page/L7LMN283JR.jpg)

5.
なぜ simplicity を重視するのか
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4EMYX86MEW.jpg)

人間には限界がある
理解することなく信頼できるものは作れない
一度にごくわずかな数のことしかできない
絡まったものは一緒に考えるしかない
複雑さ(complexity)は理解を損なわせる
⇒ いわゆる認知負荷(cognitive load)による制約
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PER9N5PLJ9.jpg)

にするメリット
構造的に(必然的に) — simplicity の内在的性質
組み合わせやすい(composable)
独立性が高い(modular)
人間的に(結果的に) — 派生的な ease への好影響
理解しやすい
変更しやすい
デバッグしやすい
柔軟
あとから方針/決定を見直すことも容易
置き換えられる
simple
25


# Page. 26

![Page Image](https://bcdn.docswell.com/page/P7XQNKN6EX.jpg)

6.
どのように simple にするのか
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/37K9N5NG7D.jpg)

なものを見極める
をもたらす(complect している)もの
を避ける
もともと simple なものを利用する
抽象化する(abstract)
abstractの原義は「引き離す」(draw away)
詳細を覆い隠すことではない
who, what, when, where, why, howをそれぞれ
検討することがヒントになるかも
あらかじめ問題を simple にする(simplify)
simple
complexity
27


# Page. 28

![Page Image](https://bcdn.docswell.com/page/LJ3WVKV5J5.jpg)

に見る simplicity
7. Clojure
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/8JDK838YEG.jpg)

すべて丸括弧ではなく複数の括弧を使い分ける
以前からある
の例
;; Common Lisp: Clojure
Lisp
(defun fizzbuzz (n)
(let ((fizzp (zerop (mod n 3)))
(buzzp (zerop (mod n 5))))
(cond ((and fizzp buzzp) "Fizz Buzz")
(buzzp "Buzz")
(fizzp "Fizz")
(t n))))
丸括弧が複数の役割を担って complect している
as code:
オペレーター呼び出し
束縛フォーム
cond の節など、特殊形式/マクロの要素
as data: コンスセル(によるリスト/alist/plistなど)
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VEPK848278.jpg)

;; Clojure
(defn fizzbuzz [n]
(let [fizz? (zero? (mod n 3))
buzz? (zero? (mod n 5))]
(cond
(and fizz? buzz?) "Fizz Buzz"
buzz? "Buzz"
fizz? "Fizz"
:else n)))
括弧を役割ごとに使い分けたほうが simple
( ): オペレーター呼び出し(as code)、リスト(as
data)
[ ]: 束縛フォーム(as code)、ベクター(as data)
{ }: メタデータ(as code)、マップ(as data)
ℹ️ Common Lispでもリーダーマクロによって括弧
の意味付けの変更は可能
30


# Page. 31

![Page Image](https://bcdn.docswell.com/page/27VVNXNX7Q.jpg)

オブジェクトよりも値
オブジェクト指向言語の例
// Scala:
case class Coffee(price: Double):
def applyTax(rate: Double): Coffee =
copy(price = price * (1 + rate))
オブジェクト(クラス)に以下が complect している
値(value): それ自体としては不変のデータ
[ミュータブルな場合] 状態(state): アイデンティ
ティに紐付く値が時とともに変化するもの
[メソッドを持つ場合] 関数: オブジェクトの文脈
でのクロージャー
名前空間/モジュール: 定義を束ねるもの
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/5JGLKVKR7L.jpg)

;; Clojure
;; (require '[lagenorhynque.cafe.coffee :as-alias coffee])
(defn make-coffee [price]
#::coffee{:price price})
(defn apply-tax [coffee rate]
(update coffee ::coffee/price * (+ 1 rate)))
では構造的に分離されていて simple
値
ただの不変のデータ
状態 を扱いたい場合] 次節で紹介 💁‍♂️
関数 ただのトップレベル関数
名前空間 モジュール: ns として独立
ℹ️ の拡張メソッドにより(メソッドとしての)
関数の分離は部分的に可能
Clojure
(value):
[
(state)
:
/
Scala
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/47QYN6NYEP.jpg)

変数よりも管理された参照型
可変の 変数を持つ言語の例
変数を宣言 初期化
変数に再代入
変数を参照
// Scala: (
)
def heavyCalculation(xs: List[Int]): Int =
var result = 0
//
/
for x <- xs do
result += x * x //
result
//
可変の)変数に以下が complect している
アイデンティティ: 値が変化しても変わらない同
一の実体
値: 変数に紐付いているデータ
時間: 再代入のたびに生じるアイデンティティと
値の紐付き関係の遷移
(
33


# Page. 34

![Page Image](https://bcdn.docswell.com/page/KE4WG4GZJ1.jpg)

;; Clojure
(defn heavy-calculation [xs]
(let [result (volatile! 0)]
(doseq [x xs]
(vswap! result + (* x x)))
@result))
初期値を指定して参照型を導入
; 参照型の値を更新(差し替え)
; 参照型の値を参照
;
参照型では構造的に分離されていて simple
アイデンティティ: 参照型そのもの
値: 参照型が保持するデータ
時間: 更新操作のたびに生じるアイデンティティ
と値の関係の遷移
⚠️ 並行処理向けには atom (CAS), ref (STM), etc.
ℹ️ Scalaのサードパーティライブラリには Ref など
参照型を提供するものがある
34


# Page. 35

![Page Image](https://bcdn.docswell.com/page/L71YD4DDJG.jpg)

継承よりもアドホック多相的な仕組み
継承を備えている オブジェクト指向言語の例
インターフェースの定義
// Scala: (
)
//
trait Shape:
def area: Double
//
( )
class Rectangle(width: Double, height: Double) extends Shape:
def area = width * height
class Circle(radius: Double) extends Shape:
def area = scala.math.Pi * radius * radius
クラス 型 の定義とともにインターフェースの実装
サブタイピング(サブタイプ多相)により、継承関係
にある複数の型/クラス同士が complect している
35


# Page. 36

![Page Image](https://bcdn.docswell.com/page/G7WGYXY8E2.jpg)

;; Clojure
;;
(defprotocol Shape
(area [this]))
;;
(defrecord Rectangle [width height])
(defrecord Circle [radius])
;;
(extend-protocol Shape
Rectangle
(area [{:keys [width height]}] (* width height))
Circle
(area [{:keys [radius]}] (* Math/PI radius radius)))
インターフェースの定義
データ型の定義
インターフェースの実装
のプロトコルではデータ型定義とインター
フェース実装が分離可能で simple
Expression Problemへの解答例でもある
ℹ️ Scalaにも型クラスというアドホック多相機構が
ある
Clojure
36


# Page. 37

![Page Image](https://bcdn.docswell.com/page/4JZLX6X9E3.jpg)

パターンマッチングよりもアドホック多相的な仕組み
パターンマッチングを多用する言語の例
関数定義とともに引数でパターンマッチ
# Elixir:
defmodule Geometry do
#
def area(%{type: :rectangle, width: w, height: h}),
do: w * h
def area(%{type: :circle, radius: r}),
do: :math.pi() * r * r
end
パターンマッチングではパターン(who)と対応する
振る舞い(what)のペアが複数 complect している
37


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YE6W424DEV.jpg)

;; Clojure
;;
(defmulti area :type)
;;
(defmethod area :rectangle [{:keys [width height]}]
(* width height))
(defmethod area :circle [{:keys [radius]}]
(* Math/PI radius radius))
ディスパッチ関数
ディスパッチする値ごとのメソッド実装
のマルチメソッドではディスパッチ関数
とメソッド実装(what)が分かれていて simple
ℹ️ にもClojure類似のプロトコルがある
Clojure
(who)
Elixir
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GE5MQ2Q8E4.jpg)

アクターよりもキュー
並行処理機構にアクターモデルを採用する言語の例
メッセージを受信するプロセス
# Elixir:
#
pid = spawn(fn ->
receive do
msg -> IO.puts(msg)
end
end)
プロセスへメッセージを送信
#
send(pid, "hello")
アクターではメッセージに対する振る舞い(what)と
メッセージを送受信するプロセス(who)が complect
している
39


# Page. 40

![Page Image](https://bcdn.docswell.com/page/9729P4PVJR.jpg)

;; Clojure
(require '[clojure.core.async :refer [<! >! chan go]])
チャネル ブロッキングキュー
;;
/
(def ch (chan))
軽量スレッドでチャネルへ値を送信
軽量スレッドでチャネルから値を受信
;;
(go (>! ch "hello"))
;;
(go (println (<! ch)))
では軽量スレッドでの振る舞い(what)と
値を送受信するチャネル(who)が分かれていて
core.async
simple
40


# Page. 41

![Page Image](https://bcdn.docswell.com/page/DJY45M5Q7M.jpg)

型システムではなくデータ仕様記述ライブラリの追加
clojure.spec: データ仕様を述語で記述する一種の
コントラクトシステム
metosin/malli: データ駆動のスキーマライブラリ
cf. Typed Clojure: Clojureに型システムを追加する
ライブラリ
🐬< データとスキーマを分けて扱うアプローチが
simple
41


# Page. 42

![Page Image](https://bcdn.docswell.com/page/V7NYNWN2E8.jpg)

プラグインではなくデータ主体のCLI/ビルドツール
Clojure CLI: deps.edn の中身はただのデータ
tools.build: build.clj の中身はただの関数
cf. Leiningen:
の中身は(マクロを含む)コード
JavaのMavenの系譜のビルドツール
プラグイン拡張モデル
🐬< 設定(データ)とビルドロジック(関数)が分かれて
いて simple
project.clj
42


# Page. 43

![Page Image](https://bcdn.docswell.com/page/YJ9PRXRD73.jpg)

破壊的変更を避けた積み重ねによる進化
Clojureエコシステム:
言語本体: 2009年(v1.0)から2026年(v1.12)現在に
至るまで破壊的変更のない積み重ね
標準/サードパーティライブラリ: 同様の安定進化
cf. Scalaエコシステム: 破壊を伴うイノベーション
🐬< simple な構造を吟味しながら組み合わせて破壊
なく進化させていく文化
43


# Page. 44

![Page Image](https://bcdn.docswell.com/page/GJ8DW2W5JD.jpg)

と
のコードベースの変遷
Clojure Scala
で示される、
と のコードベースの進化の違い
🐬
も述べるように良し悪しは一概に
言えないが、コミュニティの価値観が表れている
A History of Clojure (HOPL IV, 2020)
Clojure Scala
< Rich Hickey
44


# Page. 45

![Page Image](https://bcdn.docswell.com/page/LJLMN2N3ER.jpg)

と easy の区別の
より抽象的(メタ)な示唆
8. simple
45


# Page. 46

![Page Image](https://bcdn.docswell.com/page/47MYX8XM7W.jpg)

改めて simple と easy の根本的な違いとは
"Simple Made Easy"の核心: simple ≠ easy
simple である(simplicity)
設計対象の構造の単純さ
客観的な概念
easy である(ease)
利用者からの(広義の)近さ
主観的/相対的な概念
⇒ Clojureエコシステム/コミュニティは simplicity を
追求して長期にわたり安定進化してきた
46


# Page. 47

![Page Image](https://bcdn.docswell.com/page/P7R9N5NLE9.jpg)

と ease の対比をさらに抽象化してみると
simplicity → 対象/客体(object)・モノの構造
ease → 主体(subject)・ヒトの対象との関わり方
学習/経験や環境など、個人/社会の対象との向き
合い方
simplicity と ease を区別し simplicity を優先する →
モノへの投資とヒトへの投資を区別する
ヒトが移り変わっても残るモノには最初に意識的
に投資する
simplicity
47


# Page. 48

![Page Image](https://bcdn.docswell.com/page/PJXQNK867X.jpg)

長く残るモノと移り変わるヒトから連想する古い格言
ars longa, vita brevis
🇬🇧: Art is long, life is short/brief.
🇯🇵: 技芸は長く、人生は短い。
古希語(原典): ὁ βίος βραχύς, ἡ δὲ τέχνη μακρή
原文での趣旨: 人生は短いのに対して(医療)技術の
道は長い(だから時間を無駄にせず学ばなければ)。
後世の意味の変化: (芸術家の)人生は短く儚いが、
芸術は長く残る。
48


# Page. 49

![Page Image](https://bcdn.docswell.com/page/3JK9N5KGJD.jpg)

技芸(ars)を磨きながら人生(vita)を高める多様な道
言語/エコシステムとコミュニティの選択
Clojure: simplicity を追求しながら ease を高める
他のLisp (e.g. Common Lisp)
他のJVM言語(e.g. Scala)
他の関数型言語(e.g. Scala, Elixir)
ソフトウェア開発者として、さらには人として
いかなる技芸を学び磨き上げ、何を残せるだろう
自分と社会のより良い体験/人生に向けて、何が
できるだろう
49


# Page. 50

![Page Image](https://bcdn.docswell.com/page/LE3WVKZ5E5.jpg)

simplicity
とは何かを知るために
を一通り観てみる
の背景を探ってみる: A History of Clojure
エコシステム コミュニティに触れてみる
"Simple Made Easy"
Clojure
Clojure
/
50


# Page. 51

![Page Image](https://bcdn.docswell.com/page/8EDK83RY7G.jpg)

user> (-> (simple-made-easy-made-easy)
revisit
deepen
extend)
"Simple Made Easy" Made Easier
;; simplicity
という長く続く価値を、皆さんにとってより身近に
51


# Page. 52

![Page Image](https://bcdn.docswell.com/page/V7PK84W2J8.jpg)

Further Reading
Simple Made Easy
matthiasn/talk-transcripts >
Hickey_Rich/SimpleMadeEasy.md
Clojure
Simple Made Easy Simplicity Matters
· eed3si9n
A History of Clojure
Rich Already Answered That!
Clojurian
simple
JVM
Flix ——
と「
シンプルさの必要性
」 紙箱
が出会った
志向な 関数型言語
ファーストインプレッション
52