技術選定の審美眼。時代を超えて生き続ける技術と、破壊的な変化をもたらす技術を見極める（前編）。デブサミ2018

IT分野の技術はつねに速いスピードで変化し続けています。そうしたなかで登場する新しい技術には、スルーしてもかまわないものと、スルーすべきでない重要な技術があります。

めまぐるしい変化の中で、どこに着目することで重要な技術を見極めるのか。一方で、長年にわたって変わらず現役で使われ続けている技術にはどのような特徴があるのでしょうか。

2月15日と16日の2日間、都内で開催されたイベント「Developers Summit 2018」では、こうした変化する技術、変化しない技術をテーマにした、和田卓人氏の講演「技術選定の審美眼」が行われました。

本記事では、その講演の内容をダイジェストで紹介します。

技術選定の審美眼

和田卓人といいます。

最近の立ち位置としてはライオンと一緒にされていまして、テストを書いていないプルリクエストとかに対して、却下の代わりにこの画像が張られるみたいな形で、一種の恫喝の代わりに使われています。

が、本人はきわめてジェントルな人で、いましゃべってるところを見て、このライオンとはキャラが違うなとお感じになっていただければ嬉しいです。

ついて行くべき変化とスルーしていい変化

昨今の技術の現場でよくあるのは、フロントエンド疲れ。JavaScriptの新しいフレームワークや、開発方法論とか、そういうのがどんどん登場して、また新しいものが出てきたと。

2年前に標準とされていたものがすっかり過去のものになってしまっていて、Gruntはどこに行ってしまったんだとか、Backbone.jsはどこに行ってしまったんだとか。

そうした変化に追いつけずに、疲れてしまうわけです。

かと思えば、一種の限界集落。よく言えば安定し、悪く言えば停滞し、若者がやってこない、というプロジェクトもあったりしますよね。

そういった2つの極端なコントラストは、なぜ出てくるのか。

技術の世界はどんどん変化していくわけですが、そこには重みがあって、つまり「ついて行くべき変化」と「スルーしていい変化」がある。その見分けがつかないと、日々キャッチアップに疲れてしまう。

変化の速さは、本質ではない変化を強いられる頻度でもあります。

例えば、とあるフレームワークの変化が激しいとすると、自社のビジネスニーズやシステムの変化とは関係なくフレームワークをアップグレードせざるを得なくなる。もちろんアップグレードには機能やセキュリティ面でのメリットもあるでしょうが、それがあまりに多いと自分たちの望む変化のサイクルとは関係なくアップグレードを強いられて、それで疲れてしまったり、変化すべきところでついていけなくなったりします。

すると、はてブに愚痴るようになる。フロントエンドの技術はいつになったら落ち着くんですか、みたいな。

今回のデブサミのテーマは「変わるもの、変わらないもの」なので、今日のテーマはこのデブサミのテーマそのものです。

変わるもの、変わらないものがあるとして、それはどう変化しているのか、あるいはなぜ安定しているのか、といったことを僕なりに考えてみた内容です。

技術の変化は振り子ではなく螺旋

技術の変化は、よく振り子に例えられます。でも振り子ではなく、どちらかというと螺旋（らせん）のようなものだと思っています。同じところに戻ってきているように見えて、前回の周期からは差分がある。

差分と、その差分を可能にした技術。以前と同じところに戻ってきているように見えて、実は進化している部分のキーファクターが重要なんですね。そこが見えないと「それは20年前に通った道だ」みたいな、老害発言かもしれないことを言ってしまいます。

一方で、螺旋に乗っていないような安定した技術もあって、それはなぜなんだろう、ということも考えたいと思います。

変わらないもの。UNIX、REST/Web、RDBMS/SQL

まずは変わらないものからお話をしたいと思います。

変わらず、長生きをして、使われ続けてる現役の技術で思い浮かぶものを3つ持ってきました。

OSとしてのUNIXと、Webの仕組み、RESTのアーキテクチャスタイルやそのうえで動いているWorld Wide Webの仕組み。

そしてリレーショナルデータベースとSQL。これも実に強固で長生きしています。

UNIXの何がその長生きを支えているか。1つは、その背後にある思想、哲学だと考えています。

それはUNIX哲学と言われていることで、Small is Beautiful。大きなソフトウェアを書くのではなく、ひとつのことをうまくやる小さなプログラムを書き、それを組み合わせることで複雑さに対処しましょう、という考えです。

そのため、UNIXではすべてがファイルとして示されていて、それに標準入力と標準出力という単純なインターフェイスを組み合わせることで、プログラムはそのあいだでフィルタとして扱える。

この単純かつ一貫した思想が背後にあることで、UNIXがいまだに生き残っているわけです。

RESTやWebを考えると、RESTやWebはすべてがURLで示されるリソースであり、それに対して少なく統一された振る舞いが用意されています。

メソッド自体は正確には8つくらいありますが、基本的にはGET、POST、PUT、DELETEの4つくらいです。

バリエーションはURLで表現し、振る舞い自体は少ないセットにキープして、しかも状態を持たない。それらのあいだの状態遷移はハイパーリンクで示す。分散コンピューティングとして非常に強固でよくできているわけです。

リレーショナルデータベースやSQL。なぜこれが生き残っているかというと、数学的な背景があって、これが強固で理論的な支えになっています。

先ほどのRESTに似ていますが、操作が少ない。SELECTやINSERTなど、いくつかに絞られていて、その代わりすべてをリレーションで示せるようになっています。

またSELECT文とテーブルを同一視できる。テーブルが書けるところにはSQLのクエリも書けるため、系が閉じているわけで、これも強みになっています。

長生きする技術に共通するのは「制約の大きさ」

UNIX、REST/Web、RDBMS/SQL、この3つに共通するものとして思い浮かぶのは、制約が大きいこと。

制約の大きいルールを共有することで、その上での相互作用、フィルタとしてのプログラムをつないだり、Webサイトをつなげたり、テーブルをつなげたり、ということができます。

インターフェイスが限定的で振る舞いの種類が少なく、かつそれぞれが実装依存ではなく抽象的な層のインターフェイスで再利用できる。

例えば、lsコマンドの出力をRubyで書いたフィルタにかませて、それをSedにわたして、最後にPythonで書いたコマンドにわたすと、だいたい40年の時を超えてプログラム同士がつながっていきます。

UNIXはあっさり、そういったことを成し遂げているのです。

これら生き残っている技術の強さに共通するものは、強い抽象であると考えました。

UNIXはすべてがファイルとフィルタであると考えるからつながる。REST/Webはすべてはリソースであり、そのリソースに対する操作は狭い範囲で閉じているので、新しいメソッドを覚える必要はなくて、URLと望む操作に閉じています。

RDBMS/SQLは、すべては集合であるとしているので、系が閉じており、それがさらに系を強固にしています。

螺旋のように変わる技術

次に、螺旋のように変わる技術について考えていきます。

ここでまっさきに思い浮かぶのは、集中と分散の螺旋ですね。

僕のキャリアは最初は大規模システムをやっていましたが、そのあとはWebシステムが多くて、それが僕のバイアスなので、その話が多くなります。

まず、Good Old Webの時代、PHP3やJava Servletなどがあり、これからは動的なWebサイトが作れて、ECサイトなどもできるんだ、という時代がありました。

基幹システムにJavaなどが使われ始めると、企業は既存の資産を生かしつつ分散コンピューティングを実現するようになってきて、そのための技術がEJBやSOAP、XML、SOAなどでした。

そのあと、Ruby on Railsが現れます。

Ruby on Railsの登場によって、例えばEJBやXMLなどを用いた場合と比べて生産性が10倍、つまり10分の1の時間で開発ができるようになりました。ものによってはそうでないこともありますが、Ruby on RailsはWebシステムの開発において非常に強力で、Webシステムを作るフレームワークは、Ruby on Railsの登場前と後では大きく違うくらい影響を与えました。

Ruby on Railsは、こういうルールに則るのなら設定を書かなくてもよくて、コードも書かなくてよい、となれば生産性がマックスになる、という世界を見せました。

でも、規模的に大きくなって、例えばRuby on Railsを使って作ったサービス企業が上場を目指すようになると、サービスで攻めたい事業部と、守りたい事業部でデプロイのやり方に温度差が生まれたりして。

そこで事業部ごとに必要なアーキテクチャを引っ張れる方がいいのではないかとmicroservices（マイクロサービス）が登場して、コンウェイの法則やGraphQLなどがWebに適用される時代が来たわけです。

なので、microservicesを用いた分散の世界にやや戻ってきているのがいまの時代です。

EJB時代とmicroservices時代の差分は？

じゃあ、EJB時代の分散からmicroservices時代の分散に戻ってきたとき、その差分のキーファクタはなんだろうかと考えると、あきらかにクラウドコンピューティングです。

クラウドコンピューティングの登場前後で、コスト構造が完全に変わってしまいました。

いまでは考えられない若者もいるかもしれませんが、クラウド以前はまずサイズの見積もりをしてハードウェアを購入し、データセンターで設定しないとちゃんとWebシステムが動かなかったのです。

もう1つ、EJB時代の分散とmicroservices時代の分散システムの考え方の違いは、EJB時代の分散システムがCORBAやRPCを用いていたのに対し、その後Ruby on RailsがRESTful Web Servicesの考え方や設計に道筋を付けた結果、実はWorld Wide Webがとてもよくできた分散システムの事例であることにみんな気づきました。

XMLじゃなくてJSONで十分だ、ということにも気づいたわけです。

そしてムーアの法則による限界が来ると言われていて、それを打破するのがマルチコアプロセッサだと言われていましたが、実は打破したのはクラウドでシェアドナッシングでサーバを横に並べてなんとかするという単純な分散コンピューティングでした。

その要素技術としてDockerなどのコンテナ技術が登場し、またJSONでRESTfulだけだと型の定義がふわっとしているので、SwaggerやGraphQLなどがでてきましたと。

≫後編に続く。後編ではネイティブアプリとWebアプリの螺旋、オープンソースの個人と組織の螺旋、Game Changerな技術とは、などの解説へと展開していきます。