"Simple Made Easy" Made Easy
lagenorhynque 氏（以下、lagenorhynque）：それではよろしくお願いします。
（会場拍手）
今日は見たところScalaの人とかOCamlの人とかHaskellの人とか静的関数型言語勢の人が多くて、LISPの人や、とくにClojureの人とかほぼいなくて……Clojureの人！
（会場挙手）
1人、2人。Clojureの人、もしくはElixirの人も仲間意識があるんですが、Elixirの人なんかは少数ですよね。だと思いますが、Clojureはすごくて、もっと言うと「Rich Hickeyはすごいぞ」という話をしたいと思います。なのでタイトルは「"Simple Made Easy" Made Easy」です。「Simple Made Easy」というのはRich HickeyというClojureの作者が何年か前に発表した有名なもので、Clojure界隈では当然超有名な発表ですし、Clojure以外のコミュニティにも断片的に伝わっているかと思います。
その真意はどういうことなのか、Clojureの使いとして解説を試みたいと思います。それを通して本当のSimpleとは何なのか。先ほどOCamlの話題で「シンプル」とカタカナで出てきましたが、あれは本当のsimpleなのか。もしかすると話を聞くとわかるようになるかもしれないです。
（会場笑）
というわけでよろしくお願いします。
一応自己紹介をすると、よくカマイルカと呼ばれるんですけど、このフランス語のID（@lagenorhynque）でやっています。イルカと『ラブライブ！』の海未ちゃんでお馴染みのカマイルカです。ClojureとHaskell、その他関数型言語が好きなので、このイベントを主催しています。あとはヨーロッパ言語が好きで、フランス語とか英語とかが好きです。
ちょっとだけ宣伝をすると、9月の技術書典7でClojureの本を出すので、よければお立ち寄りください。
また、電子版も出すと思います。中級者向けの本になるかもしれないです。
今日話したいことは7点ぐらいあります。
そもそもよく話題になる、先ほども触れていた「simpleとeasyという言葉は本来どういう意味なのか」ということを掘り下げていきたいと思います。その過程でRich HickeyのSimple Made Easyで重要な部分について、元は全体で1時間以上あるような発表なので、10分とか15分ではとてもじゃないけど話せません。
Clojureの人はこの話題が好きなので2、3時間は平気で語れるんですけど、この場ではダイジェストでお送りするので、まわりのClojureの人を探して聞くか、もしくは自分がClojureの人になりましょう。
というわけで、このような話題でお送りします。
"simple"と"easy"という言葉
まず、simpleとeasyという言葉はよく出てくるんですが、自然言語的に交換可能(interchangeable)な単語だとよく思われています。とくに英語圏の人だと「それってsimpleだね」と「それってeasyだよね」というのはだいたい同じような意味というか、日本語訳にしてもなかなか定まらないところがあると思います。簡素や簡潔、もう片方は容易とか簡易とかありますが、それをソフトウェアの文脈に当てはめて、とくにClojureコミュニティだとこういう意味だよという話です。
つまり、他のコミュニティではどうかは知りませんが、Clojureコミュニティではsimpleは明確な意味を持って定義されています。なので、Clojureの人はその意味で話していると思ったほうがいいです。なので、Clojureの人の前でsimpleという言葉を軽々しく言わないほうがいいですね。
（会場笑）
刺されます。……刺しはしないです。
とくにeasyとは区別が必要ですし、easyとはぜんぜん次元が違う言葉です。Clojureの人が誇りを持っているのは、正にClojureという言語は、この意味でのsimpleを追及しています。なので少しでもClojureに触れてみると「こういう意味でsimpleなんだ」というのがわかるかもしれません。
実際、コミュニティ内ではこの概念がとても重視されていて、言語や設計もそうですし、ライブラリ、もしくはアプリケーションの作り方にも表れます。なので、このsimple、もしくはこの対義語としてcomplexという言葉があるのですが、それが重要な評価軸になっています。
Simple Made Easyとは何か？
ここで先に「Simple Made Easyって何なの？」という話をしておきます。
Rich HickeyがStrange Loop 2011というところで発表した話で、すごく有名ですね。このClojureコミュニティにsimpleという言葉の概念が普及するきっかけになったのも、恐らくこれです。
日本語の発表資料や記事で、この2つの言葉の対比やRich Hickeyの話を引用した話題がよくネット上でもありますが、だいたい何か趣旨からずれているように感じています。なので、それを多少でも正したい気持ちがあります。
関連するものとして、翌年のRails Conf 2012で「Simplicity Matters」という、Simple Made Easyとかなり似た発表がありました。こちら日本語版もあるので、読まれると理解が捗るかもしれません。
ここでまず第1点目、タイトルの意味です。
誤解が多いんですが、英語の本で『Word Power Made Easy』という書名があります。Made Easyというのは後置修飾で「簡単に解説」みたいなものです。なので、たぶん「simple簡単解説」みたいなのが素直な直訳ですよね。
つまり、simpleがeasyを成すという解釈も可能かもしれませんが、本来はそういう意味ではありません。言葉遊びとしてはそうかもしれない、みたいに把握しておくといいかもしれないです。なので、主題はあくまでsimpleで、easyは本題ではない。区別の対象ですね。
"simple"と"easy"の意味
というわけでようやく意味に入ります。Rich Hickeyの発表を聞くとわかりますが、語源を重視しています。僕は個人的に自然言語が好きなので語源の話だけで1時間ぐらい使えそうなんですが、簡単に説明します。
まず、simpleというのはラテン語でsimplexという言葉から来ています。simplexの"sim-"というのは「1」(single)と同じ語源みたいです。"plex"はreplyとかで英語の単語に出てきますが、「折る」(fold)ことです。なので1回折る、一折り、もしくは1回編む、もしくは1回捻るみたいな意味を持っています。
それをソフトウェアの文脈に当てはめると、いわゆる単一責務とか単一の役割、単一の概念、単一の次元のように、1つのことに専念すると考えておくといいです。注意が必要なのはモノとして1個であるとか、操作として1つであるというのはあまり関係ありません。なので、simpleに対して「構成要素が少ない」という理解がありますが、それは違います。ここでのsimpleではありません。
むしろ役割が1個1個特化したものだと、たくさんないと全体としてやりたいことができません。なので構成要素が減るわけがないんです。これは外せない重要なポイントです。かつ、1つの役割というのは、もちろんある程度相対性はあるかもしれませんが、抽象的に分析する観点においてはある程度の客観性がある概念です。
これは語源的にちょうど対応するのですが、対義語はcomplexです。これもまた"plex"という語幹が付いています。これは絡まっているとか折り重なっているという意味です。もつれているとか毛玉のようなイメージがわかりやすいです。逆に言うとsimpleというのはそういう意味がなく1本の線が通っている。複数本でもいいんですが、絡まりがない状態と絡まっている状態のイメージがとても重要です。
それに対してeasyとは何かというと、これはどうやら語源が諸説あるみたいですが、フランス語を経由して、大元はラテン語のadjacensという言葉であると言われています。
これは英語でadjacentと書いていますが、「近くにある」という意味です。これをどうソフトウェアの文脈で理解するかというと、1つは「物理的に近い」です。自分のPCの中にあるとか、もしくは気軽にインストールできるみたいな、近くにあるというのが1点目。
もしくは感覚的に、理解において近い。親しみがある、familiarみたいに英語では使われます。3点目は、能力的に近い。そういう意味で日本語の「簡単」に近いと思いますが、簡単、手軽、身近みたいな言葉です。
そういう言葉からわかるようにきわめて相対的ですし、主観的です。「誰にとって」というのが重要です。入門者にとっては難しいかもしれませんが、熟練者にとっては簡単とか、もしくはこの言語を知っていれば簡単、という話になります。なので、そもそもこの次元で比べるのは難しいかもしれません。もちろんやさしいに越したことはない。
対義語は英語の語源的には無関係ですが、hardとか、もしくはdifficultかもしれません。ということで、simpleとeasyはこういう意味で使うとRich Hickeyは言っています。
"simple"と"easy"の関係
では、この2つの概念がどう関係あるのかというと、直接関係はないと思っていいでしょう。つまりsimpleに対しての対義語はcomplexで、絡まっているかどうか。それに対して親近感が湧くか、理解が近いかといったことは別軸です。なので、少なくともトレードオフではありません。もちろん多少の関係はあり得ます。
なのでSimple Made Easyで、今日1番伝えたいのは3行目です。「easyよりもsimpleを選ぼう」と、いろいろな資料に書いてありますが、これは完全に間違いです。そういう意味ではありません。easyに越したことはないですが、easyのことはひとまず置いておき、simpleを重視しましょう。逆に言うと、easyで見た目が簡単そうだけどcomplexなものを下手に使うのは避けよう、simpleを追及しようという話です。
実際にこの考え方はClojureという言語に表れていますが、Clojureに限らず役に立つ考え方だと思います。つまり比較対象はsimple or complexであってsimple or easyではない。別軸なので、比較できないという話ですね。
とはいえ、軸は違うけれど、極端な例を考えるとeasyだけどcomplexなもの、逆にsimpleだけどhardなものってあり得ますよね。
わかりやすい例を挙げると、Railsで開発するのであれば、例えばとてもeasyでcomplexかもしれない、裏の仕組みがごちゃごちゃしているかもしれません。僕は実際のところは知りませんが。
それに対して、例えばいわゆるsimpleと言われている言語、Clojureを使ってsimpleなライブラリを組み合わせて開発する。これは知識がないと難しいという点では恐らくhardでしょうね。simpleだけどhard。Clojure開発とRails開発の例を比較してみると、恐らくこう言えるのではないかと思います。
Rich HickeyはClojureとRubyのことは言っていませんが、概念的にこういう対応関係であると言っています。つまり、easyだけどsimpleさを考えていないものはどうなるかと言うと、とりあえず簡単なので初期の生産性は高いだろうし、多少は裏がもつれているかもしれないけど、とりあえず進んでいけるので立ち上がりの生産性は高い。
ただ、中長期的にやっていくほど複雑さにやられるわけです。逆に、難しいかもしれないけどsimpleなものはどうなる傾向があるかと言うと、難しいから学習コストはあるだろうし、そもそもsimpleにものごとを捉えるというのは分析にもそれなりのコストが掛かるので、初期はきっと時間が掛かります。
でも、それを乗り越えると継続的に生産性が上がっていき、ずっと生産性が高い水準になる可能性があるということです。というわけなので、easyかhardかは置いておいて、少なくともsimpleは大事にしようという話です。
