Laravelでの開発を例に考える、SimpleとEasyの違い - Part1

SimpleとEasyは違う

廣瀬健氏（以下、廣瀬）：株式会社クラシコムの廣瀬と申します。よろしくお願いします。

（会場拍手）

ありがとうございます。入社が一昨年の12月なので、ちょうど1年経ったくらいですね。前職まではRailsをやってて、クラシコムに入ってからLaravelを触るようになりました。

会社のエンジニアのブログでRailsとLaravelの比較記事を書いたり、あとさっきオープニングセッションで紹介があったLaravel Meetup TokyoでLaravelを使ってDDDやってみたという発表をやったりしました。

クラシコムという会社、今回スポンサーを務めさせていただいていますが、みなさんご存知でしょうか？　知ってる人？　

（会場挙手）

ありがとうございます！　じゃあ「北欧、暮らしの道具店」というECサイトを知ってる方、いらっしゃいますか？

（会場挙手）

ありがとうございます。

僕たちクラシコムは「北欧、暮らしの道具店」という、EC兼メディアのようなサイトを運営しています。このサイトを、Laravelだったり、最近だとVue.jsを使って開発・運用しています。

Laravel Mixについて

今日はまず、僕に最近あったことからお話ししたいと思います。最近あったこと1つ目。

Laravel Mixって、ご存知ですよね。（僕は）最近使い始めたんですけど、Laravelに標準で入っている、いわゆるWebpackのラッパーです。アセットのコンパイル設定とかがすごく簡単に書けるやつ。

Webpackをちゃんと理解してなくてもすぐに使えるよっていうライブラリなんですけど、これを使っていて、ある日、Babelのコンパイル、トランスパイルの設定で、presetsの部分を変更したいなと思ったんです。

いろいろLaravel Mixを調べてみると、babelConfigっていうメソッドがある。これを使えばいいのかなと思ったけど、なんかうまくいかない。

結局Laravel Mixのソースをだいたい読んでみて、（やっと）presetsは上書きできないことがわかった。Babelの設定を変えたかっただけなのに、webpackConfigを使ってようやく解決した、ということが最近ありました。簡単だっていうから使い始めたのに、結局簡単じゃなかった。

あと、Webpackをそこまで理解してなくても使えるよというものだと思ってたのに、おかげで（逆に）けっこうWebpack自体の勉強になった（笑）。なんだかなっていう、これが1個目です。

Vue.jsとVuexを使いはじめる

最近あったことの2つ目。

Vue.jsとVuexを使い始めました。

Reactは触ったことあるんですけど、Vueは初めて使ったので、ひととおりドキュメントを読んで、（Reactとの）大きな違いとしてv-modelっていうディレクティブがすごく便利そうだから、これを使う方向で作っていけばいいかなと思ったんです。

それから、Vueの公式ライブラリですし、ステート管理にはVuexを導入しようと思って、ドキュメントを読んでみたんです。そしたら、v-modelを使う方法はちょっとトリッキーというか、そのままでは使えませんって書いてあったんですね。あれ？　となった。これが2つ目です。

「DockerでMySQLのコンテナが動かなくなった」

最近あったことの3つ目。後輩から「DockerでMySQLのコンテナが動かなくなった」と質問されました。彼はまだエンジニアとしての経験が浅いんですが、Dockerの勉強を始めたのかな、それはいいことだなと思って。

「とりあえずボリューム削除してもう1回やり直してみようか」って言ったら「ボリュームって何ですか？」って聞いてくるんですね。「あれ？」と思うわけです。

「そもそもどうやってDocker動かしたの？」

「これ（./vessel start）です」。

見たことないコマンドを教えられて、何じゃこれ!?　と（笑）。結局（彼は）Dockerを勉強し始めたわけではなくて、これ（Vessel）、ベッセルって読むんですかね？　このとき初めて知ったんですけど、LaravelをDockerで動かす便利なツールがあるらしくて、それを使ってたんです。うーんって思った。

はい、何の話かと申しますと、（スライドを指して）もちろんこれです（笑）。

SimpleとEasyは違うっていう話を今日はしたいと思います。このスクリーンショットを撮ったときハートが8で、なんか少ないなと思って今朝自分で押してたんですけど（笑）。押してくれた方ありがとうございます。

SimpleとEasyは違うという話。よくあります。

すごく少ない記述でこういうことができる、コマンド一発でこれができる、それを「簡単だね」と言うのはわかります。

「シンプルだね」という表現もよく使われますが、確かに簡単かもしれないけど、シンプルって言っていいのか？　と、さっきお話しした、最近あった3つの出来事を通して思ったんです。

Laravel Mixであれば、セットアップは確かにすごく簡単で、すぐに始められました。でも、ちょっといじろうとすると、むしろWebpackより難しいんじゃないかと思うくらい大変だった。ほかのことに関しても、似たような体験がありました。

だから、簡単に使えるものがそれ即ちシンプルとは言えないんじゃないかと思って、いろいろネットで調べて、Rich Hickeyさんという、Clojureの作者さんの言葉を見つけました。

「シンプルさとは使いやすいことだと思っているのならそれは違う」「EasyとSimpleはぜんぜん別のものです」ということを、Simple Made Easyというプレゼンテーションの中で明確に言っていました。

「Easy」は相対的、主観的。要は、僕にとっての「簡単」とあなたにとっての「簡単」は違うよね。対義語はhard、難しい。対して「Simple」は客観的な概念。感じ方という意味で、Simpleにも人によって多少違いはあるかもしれないけれど、計測できるものだったり、比較できるものだと思います。対義語はcomplex、複雑。

となれば、さっきの「簡単に動かせるよ」も、簡単とは言えるかもしれないけど、シンプルとは違うのかもしれない。EasyとSimpleを明確に分けて考えると、さっきの3つの話は、SimpleよりEasyを目的としていた（からな）のかなと思えてきます。

とくにLaravel Mixは、リポジトリのディスクリプションのところで明確に「80パーセントのユースケースのためのラッパーだよ」って書いてあって。じゃあ今回の場合は80パーセントじゃなくなったってことなのかなと思ったんです。

こんなことが最近あったり、考えたり、さっきのプレゼンテーションを見たりして。思い浮かべたことがあります。

「創味のつゆ」で考えるSimpleとEasy

簡単といえば……みなさんご存知でしょうか？　料理したことない人でも知ってるかもしれない。創味のつゆというすごく便利な調味料があるんですよ。ちょっとその紹介をしたいと思うんですけど。

創味 つゆ 1L

（会場笑）

すごく簡単です。

パッケージに書いてある水もしくはお湯の分量で薄めるだけで、湯豆腐も作れるし、ざるそばのつゆも作れるし、かけそば、寄せ鍋、和風煮物も作れる。創味のつゆのホームページにいくと、もっとこんな料理がいっぱい作れるよって案内があるんですね。すごい調味料です。ぜひ家に1本入れておくといいと思います。うちも常備してあります。

創味のつゆはすごくEasy。かつ、これってすごく複雑なんです。

これ1本でなんでもできるということは、普通だったらいろんなものを入れなくちゃいけないところに、全部最初から入っている。ホームページには「いつものメニューもプロの味」って出てます。すごいです。

ちょっと整理して考えてみましょう。いいところとしては、計量が簡単だし、醤油が大さじ何杯とかも考えなくていい。いろんなものが作れます。でも、だいたい似たような味になるという欠点があります。

（ホームページの）いろんなものが作れるよっていうレシピも、作ったことあるんですが、すごくおいしいけどまあ似たような味。とくに煮物系はだいたい同じになります。ああ、創味のつゆかな、みたいな。

（会場笑）

それに、結局、醤油やお酒を組み合わせるほどなんでも無限に作れるというわけではない。

つまり、導入コストはすごく低いです。でも汎用性、拡張性という言葉が調味料に使う言葉なのかわからないですけど、そういうところは低い。

対して、創味のつゆを使わずに料理しようと思うと、出汁とか醤油が必要になってきますけど、これもデメリットがあります。最初にいろいろ揃えないといけない。1人暮らしだと使い切れなかったりしますし、かなり辛いですね。僕も1人暮らしをしていたので分かります。やっぱり、手間がかかる。

でも最近というか、ここ何年か、週末に料理するようになって、最初は（自分で味を調えることに）すごくハードルがあったんですけど、だんだん慣れてくるとそこまで難しくはない。レシピどおりに分量を計れば、まあまあできる。

つまりどういうことかというと、導入コストはちょっと高かった。最初はけっこう難しかったです。でも汎用性、拡張性は高い。

整理すると、創味のつゆはEasyで、だけどComplex、複雑です。導入コストはすごく低く抑えられるけど、それを使ってこれやろう、あれやろうという部分に対しては弱い。

対して、醤油やみりんはSimple、でもHard。導入コストは確かに高いかもしれないけれど、やりたいことに応えてくれるという面では、創味のつゆに比べて汎用性、拡張性がすごく高いといえます。

Easyばかりを求めているとHardになる

つまり、Easyを選ぶのであれば、いくらかトレードオフがある。もちろんSimpleもそうなんですが、そういうことが言えると思います。

別にEasyというか、創味のつゆをディスりたいわけではなくて、どうしても（Easyが）優先されるときもあります。

とにかくリリースする速度が優先される場合や、難しいことができる人を確保できなかったり、理由によってはありです。創味のつゆも、休みの日のお昼ごはんとかにはすごくありです。

（会場笑）

うどんを茹でてお湯を沸かして創味のつゆとお湯でめんつゆを作ったら、すぐうどんができます。それくらい便利。それが求められるときもあるのは事実だと思います。

でも、Easyなものばかり求めていると、簡単なものを求めていたはずなのにすごく大変になるということは、みなさん経験があると思います。

最初はこれ一発でなんでもやってくれるということを（期待して）用意したけど、ソフトウェアもアプリケーションも（作っていく中で）どうしたって変わってくるので「ここを変えなきゃ」「あそこを変えなきゃ」というときに、一緒くたになってしまっているものに対して「僕はどうすればいいんだ？」って状況に陥ったりする。

Rich Hickeyのプレゼンテーションからまた引用させてもらいますが、彼は「シンプルであるということは選択だ。もしあなたのシステムがシンプルでないならば、それはあなたのせいだ」と言ってます。

つまり、なにかが自動的にシンプルになることって、ないんですよ。シンプルにしようって思ってがんばらないと、シンプルさは保てない。

SRE本にもありました。「単純性という品質は、いったん失われてしまうと取り戻すことがきわめて難しい」。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

であるならば、状況が許す限りはなるべくEasyよりもSimpleを選択したいよね。かつ、EasyとSimpleが別の概念であるなら、例え過去にEasyを選んでいたとしても、できるところからSimpleにしていきたい。

そんなことを考えて、最近僕らがやっていたことを紹介しようと思います。