フレームワークは枯れた技術の水平思考なのでは？

　枯れた技術の水平思考をどう説明すればいいのかを考えてたとき、フレームワークを題材にすればいい、と思いました。世に出ているフレームワークを思い出したとき、どれも跳躍したようなアイディアではなく今まであった技術を再解釈された物が多いと考えました。コンポーネント指向も古くから合った。wikipediaだと1960年台には存在していて、かなり古い。オブジェクト指向を初めて実装されたと言われているSmalltalkも1980年台に発表されていてそれよりも古い。

　これらの歴史を見ると、フレームワークとは、新進気鋭のかつてないアルゴリズムの発明ではなく、長い研究を終えた技術を再解釈をされて誕生したと考えられます。もちろん、開発者本人は新しい発明であることには変わりはありません。なぜなら、このように視点を切り替えた発明もれっきとした発明だからです。コンポーネント指向を発明、発見をしたことはすごいことですし、それらを研究した人たちも偉大です。そして、彼らの研究に新しい視点を加えた人たちも等しいくらい偉大です。

　フレームワークの特徴は「誰でも使いやすいように設計されている」点です。RailsもWebの技術を１〜１００まで知らなくともウェブアプリを作ることができます。OSI参照モデルを知っていなくてもウェブアプリを作れるのは「誰でも使いやすいように設計されてる」からです。抽象化をしたり、OSI参照モデルの部分は知らんくてもいいように設計をされているのでRailsは使いやすいのです。

そもそも枯れた技術の水平思考とは？

　枯れた技術の水平思考とは横井軍平さんという任天堂に在籍をしていたエンジニアが設計や発想をするときの考え方です。

　枯れた技術とは、研究しつくされた技術を指します。オブジェクト指向もそこに入って差し支えないでしょう。オブジェクト指向を例に説明をします。オブジェクト指向の良いところは「変更がしやすい」ところです。ポリモーフィズムを利用すれば、使っているオブジェクトのメソッド名が同じあればオブジェクトを置換しても動きます。しかし、悪いところは「オブジェクトの依存が複雑だと変更がしにくい」というところです。先程のポリモーフィズムだと一箇所の型の変更でそれほど変更点が狭い場合です。オブジェクトの依存関係が複雑の場合一箇所を直したら別の箇所も直さないといけなくなります。

　ざっくりとした説明ですが、ネット上でもメリット、デメリットがたくさん出てきます。つまり、オブジェクト指向のようにある程度まで出し尽くされた発明が枯れた技術です。

　横井軍平さんの発明でも「光線銃SP」という商品では、太陽光パネルが光にあたったときに反応することを利用して当たり判定を作っています。太陽光パネルは発電用として使われていますが、視点を変えてゲームの的にしています。ここがすごいんです！

　太陽光パネルを別の用途に転用したり、技術そのものの物の見方をありえない角度で覗いてみることが「枯れた技術の水平思考」と言えます。

枯れた技術の水平思考としてのRails

　Railsは名のしれたWebアプリのフレームワークです。今やソシャゲから業務用までのバックエンドの開発でも使われている優秀なフレームワークです。Railsの良いところは一からすべてを用意せず雛形を渡されてそれを自分用にアレンジするところです。

　Railsでは枯れた技術がふんだんに使われています。もっともわかりやすいのがMVCモデルです。MVCモデルは古い技術でSmalltalkと同じくらいの時期に誕生した技術です。MVCはGUIの考え方で、VIEWという画面に表示して、それに対してコントローラーを使って司令を出してModelがプログラムされた手順を実行するモデルです。

　Railsはこれに「DRY」,「設定より規約が優先される」という考え方を加えて作りやすくしています。この２つの考え方の起源はわかりませんでした。「DRY」は同じような処理を書かないようにする。例えばお金のプログラムを作るとします。Moneyオブジェクトのメソッドで米ドルへ変換してくれるメソッドがあったとしましょう。別の製作者が米ドル変換のメソッドの存在を知らなくて、新しく米ドル変換オブジェクトを作ってしましました。このような２度の実装をやらないようにしようというのが「DRY」の考え方です。

「設定より規約が優先される」は、設定値をいじるよりもフレームワークの決まりを守る方を優先させよう、という考え方です。設定値の変更はひとによってばらつきがあります。NGINXの設定値もかなりばらつきがあります。例えばAサーバーでRailsのアプリを動かしてNGINXの設定値をBサーバーで新しいRailsアプリで動かすと動かない、ということがあります。設定値はある程度まで制限ができますが、動きをはっきりとさせることがまず無理です。ですので、規約を優先させるように設計をすること万が一ユーザー側でまずい設定をしたとしても規約の方でだめなら通さずにデフォルトのままにしておきます。それかエラーを出します。

　このように見ていくと、Rails自身がオープンワールドのような新進気鋭の新しい技術を使われていないことがわかります。少なくとも、基本機能はそのような真新しい機能ないはずです。

　枯れた技術を使うことで、技術面で制御がしやすくなります。オープンワールドのゲームの場合はまずどうしたらメモリを気にせずにオブジェクトを展開させるか、そして〜GBのメモリのデータの置換をどうするのか、そしてユーザにそれを見破られないための方法を考えます。ここでは、技術１つ１つが非常に予測がしづらいです。アルゴリズムはあるけど、それを実装するとなる環境の問題やそれ以外のIOでの処理問題がかかってきます。仮にオープンワールドの技術が枯れていたらそのようなことを考えなくてもいいです。考えるかもしれませんが、枯れていてフレームが揃っていればそれほど意識せずに書けるはずです。

　Railsが作りやすいのは枯れた技術を別の視点でわかりやすく書かれているのだとしたら、フレームワークは本当に観察をする力が求められてくると思います。

　Rubyの作者のmatzさんも言語に対して非常に観察して設計されています。Rubyは楽しくプログラミングができるように設計されていて、真新しさよりも楽しさを優先していると聞いています。ということは、楽しさ、遊びというのは観察に観察を重ねてそこから新しい視点を見つけることかもしれません。