プログラミング言語サバイバル
まつもとゆきひろ氏（以下、まつもと）：どうもこんにちは、まつもとと申します。今日は「プログラミング言語サバイバル」というタイトルでお話をしようと思います。
今年は、2月にイベントをやりましたが、Rubyの開発を始めてからちょうど25年ということで「思えば遠くに来たもんだ」という感じです。もう人生の半分くらいはRubyを作ってる（笑）。
これで興味があるところは「プログラミング言語の寿命って、いったいどのぐらいあるんだろう？」ということを考えるわけです。だいたい、ソフトウェアの寿命ってそんなに長くないんですね。だんだんバージョンが上がっていって、5年とか10年で使えなくなるのが一般的だと思います。考えてみたら、10年前にはなかったソフトウェアが、すごくたくさんある。
プログラミング言語は、そういう一般的なソフトウェアに比べると、ソフトウェアとしての寿命は比較的長いほうではないかなと思います。
例えば、FORTRANという、一応世界で最初のプログラミング言語と言われているものが1954年に生まれているので、もう今年で64年経つわけです。あるいは、COBOLは1959年ぐらいなので、もうすぐ60年ぐらい。
最近はFORTRANとかCOBOLとかの記事をあまり読まなくなりましたけど、世の中からFORTRANやCOBOLが消えてなくなったかというとそうではなくて、ジャンルによっては今も使われて生き残っている。
フィルターバブルっていうんですか。自分の知ってる世界と違う世界のことが、だんだん見えなくなってきてるんですよね。Twitterみたいなネットメディアでお話ししてると、そこに参加してる人から届くものだけが見えるので、そこから外れたものが世の中からなくなったような気がするんです。
今言ったようなFORTRANとかCOBOLは、そういう（ものを扱っている）コミュニティに近づくと「あっ、実はあるんだ!?」みたいな話になります。
私が所属してる会社で、松江（市）にネットワーク応用通信研究所という会社があるんですけど、そこのエンジニアも何分の1かがCOBOL技術者です。
レセプトのソフトを作ってるんですが、医療関係で元オフコンみたいなシステムではわりとCOBOLが生き残っておりまして、保険の点数の計算のロジックなんかは、まだCOBOLでやってる人たちがいる。そういうふうにいうと、みなさんの知らない世界でCOBOLはまだ元気に動き続けているわけです。
例えば金融機関とか、あるいは大企業の中のシステムとかには、メインフレーム＋COBOLみたいなものが意外と残っていたりする。知らないだけなんです。
とはいうものの、死んだように見えるという点では、何十年か前に一世を風靡した「プログラミング言語といえばFORTRAN」みたいな雰囲気とか、あるいは大学でプログラミング実習といえばFORTRANという時代もあったわけですけど、そういう空気はもうなくなっている。
大学生が「プログラミングを勉強します」というときに出てくる言語がFORTRANであることはもうなくて、JavaだったりCだったり、あるいはRubyとかPythonを使うところも増えてますね。そういう、ファーストチョイスにならないという意味では、旧世代の言語というか、しばらく前の言語の凋落は明らかです。FORTRANとかCOBOLの絶頂は30年とか40年前で、今やだんだん凋落している言語であると。
Rubyは死んだのか？
「Rubyはどうか？」という話ですけど、Rubyはよく「死んだ」って言われる言語です（笑）。まぁ、いろんなことがあったわけです。例えばTwitterは、もともと、2007年に始まったときはRuby on Railsのアプリケーションだったんですが、何年か経って、彼らの増え続けるユーザーやトラフィックを扱うときにRubyでは難しいということで、Java Technology……具体的にいうとScalaという言語で、コアの部分を書き直したんですね。
Twitterみたいな規模のものがRubyから移行したということで「Rubyは死んだ」みたいに言われることが増えたり。
あるいは、オランダの会社で、 TIOBEという会社が毎月プログラミング言語の人気ランキングみたいなものを公開してるんですね。インターネットでどのぐらいその言語が検索されたかとか、そういう指標から出しているらしいんですが。
これも上がったり下がったりするのですが、Ruby on Railsが非常に話題になっていた頃には、8位とか7位とか、それぐらいまでRubyは上がってたんですけど、最近ちょっと下がり気味なんですね。つい一昨日だかに今月分、2018年12月分が発表されたんですが、確か17位だったかな、だいぶ下がっているという話です。
これをもってして「Rubyは死んだ」みたいなことを言う人がいて「またかよ？」という感じなんですけど、そういう意味でいうと「Rubyは凋落している」と見られているところもあると思うんです。
あるいは、静的なプログラミング言語と動的なプログラミング言語の間で、トレンドが振り子のように変わったりするわけですが、2010年代のプログラミング言語は静的な言語が多いんですね。
最近出てきた言語は、昔と違って、けっこう静的型のついたプログラミング言語が多い。例えばGo。これ、出たのは2009年ですが、静的型の言語です。Swiftにしても、Rustにしても。それから、JavaScriptに対して型をつけたTypeScriptみたいな言語があったり。
式、変数、引数、戻り値といったものに静的に型を宣言することによって、コンパイル時により多くの型をチェックする、より多くのエラーを見つけるというようなことが流行っている時代ですね。
そういう意味だと、2010年代もだいぶ終わりが近づいてきましたが「2010年代のプログラミング言語は静的に傾いている」と言ってもいいんじゃないかと思います。
静的型付け言語が支持される理由
これはなぜかという理由を考えると、現代のプログラミング言語が「スケール」という問題に直面しているというところがかなり大きいんじゃないかと思います。
スケール問題とは、つまり、昔は牧歌的だったので、例えば「Web作ります」「Webサービスを作ります」「Webアプリケーションを作ります」といったときに、集まるところのユーザーがすごく少なかった。例えば、Windows 95が出た1995年はインターネットを使っている人なんてすごく珍しかったので、サービスを作っても、集まるユーザーは数百人とか、毎秒アクセス2とかで、パフォーマンスについて問題が起きることは特になかったわけです。動くかどうかだけが問題だった。
ところが現代は、すごい数の人たちがインターネットにアクセスするためのデバイスを持つようになったんですね。具体的にいうとスマートフォンです。そうすると、なにかがバズると数百万、数千万アクセス集まることがぜんぜん珍しくないようになってきたわけです。
そういう人たちがてんでバラバラにアクセスすると、例えば毎秒アクセス数千とか、かなりのトラフィックの、昔だったらハイトラフィックな、日本を代表するWebサイトじゃないとありえなかった状況が、ごく普通のサービスでも起きることがあった。そういった「データが集まる」「トラフィックが集まる」という意味でのスケーラビリティが問題になりはじめました。
さらに、いろんなものがWebで実装されるようになったので、Webアプリケーションに求められる機能がどんどん増えていくわけです。「あんな機能も提供しよう」「こんな機能も提供しよう」となると、Webアプリケーションがどんどん複雑化する。
そうすると、スケールといってもいろんな意味のスケールがあって、トラフィックあるいはデータ量という意味だったり、それからコードの複雑さ、あるいはチームのメンバーの数という意味でのスケーラビリティもあるわけです。
そういう問題に対処する手段の1つとして「プログラミング言語に静的な型をつける」ことが最近ホットになっているというわけです。
現代のソフトウェア開発はトライアンドエラー
ソフトウェアを開発するということは、そういった概念を（実際に）動くソフトウェアに持っていくということでもあります。「こんなことをするソフトが欲しい」と頭の中でぼんやり思ってるだけではソフトウェアは動かないので、「欲しいものがいったいどういうことか」をこと細かに定義して、それをだんだん動くソフトウェア、そしてその背景になるロジックを記述してコンピュータにわかるように教えてやるという過程がソフトウェア開発なわけです。
そうすると、頭の中にあるぼんやりとしたイメージをどんどん段階的に具体化していって、コードに書いていく必要があるんですね。「このソフトウェアはいったいなにをするのか？」ということが初めから詳細にわかっているなら、まず仕様を書いて、その仕様のとおりソフトウェアを開発すればいいんですけど、現代におけるソフトウェア開発では、そういうことはむしろ少ない。
頭の中にぼんやりイメージがあっても、ぼんやりとあるだけなので、細部が定義されていないんですね。その細部を定義していって、やってみて、動かしてみて「あれ？ イメージと違う」って軌道修正していくという開発手段がほとんどになってきています。具体化してロジックしてコードに直したときに、頭の中にある「こうあるべきだ」というイメージとのズレを途中で軌道修正してやらないと、いいものができない。
そうすると、俊敏な開発というんですか、途中で軌道修正するときに、俊敏あるいは柔軟に開発できることがけっこう重要になってくる。
他のテクノロジーが気になるのはエンジニアの本能
一方、そうやってソフトウェアを開発していくと、どんどん機能が増えていきますし、ビジネスが成功していくにつれてチームメンバーもどんどん増えて、コードも複雑化するので、それらとソフトウェア開発におけるソフトウェアの成長段階とどのように戦っていくかが大きなチャレンジになってくるわけです。
ソフトウェア開発者は、そういうさまざまな問題を解決するためにどんどん出てくる新しいテクノロジーを、学んでいくことが必要なんですね。本当に、日々勉強を続けないといけない職業です。だから、自分の抱えている問題を解決する新しいテクノロジーを探し求めること自体が、ある程度趣味みたいな人がけっこうたくさんいます。
そうすると、例えば、PythonとDjango、あるいはPythonとFlaskみたいに、Pythonという言語とWebアプリケーションフレームワークを組み合わせましょうとか。あるいはElixirという言語とPhoenixというWebアプリケーションフレームワークを組み合わせましょうとか。あるいはCrystalという言語と、AmberやAmethystやLuckyを組み合わせたり。Crystalはまだ定番のWebアプリケーションフレームワークがないので、いろいろありますけど。
これらの言語にはRubyとは違う特質があるので、それを使って自分たちの生産性をより高めたいと思う方はたくさんいらっしゃるわけです。さっきは挙げませんでしたけど、例えばRust、あるいはGoを使って、「自分のプログラミングの性能を改善しよう」「生産性を高めよう」という人たちもたくさんいらっしゃいます。
そういうふうに、新しいテクノロジーをどんどん求めている人がいる。というのは、RubyもRuby on Railsも定番の技術になっていて、出てからもう10年以上経つので、いろんな道具は揃っているにしても、劇的に新しいことはあんまり起きないわけです。
そうすると、ブレークスルーを求めて、極端に生産性を上げる方法はないだろうかとほかのテクノロジーを見にいきたくなるのは、人間の……人間というと主語が大きいですけど、技術者の本能みたいなものだと思うんです。
Ruby on Railsのビジネス上の価値はそれほど下がっていない
じゃあ、その「自分のアプリケーションを新しい技術・言語・新しいフレームワークでやってみよう」という人に話を聞いてみると「プロトタイプはそれでやってみました」「いくつか試してみたけど、結局Rubyに戻ってきました」という人が、けっこういるんです。
新しい言語、新しいやり方はすごくおもしろいけど、例えば「〇〇するライブラリがなくて自分で作らなくちゃいけなかった」「情報が少なくて、Webを探し回ってもあまり見つからない」「ソースコードを読まないといけなくてつらかった」と。
安定性とか安心感、あるいはビジネス上の価値。結局（今まで）問題だと思ってた部分は新しい技術によって対応されたけど、それ以外の問題がどんどん発生して、トータルのビジネス上の価値としてはどうなの？ ということが起きがちなんです。そうすると、場合によっては信頼と実績のRubyとRuby on Railsに戻ってくるということが、よくあるわけです。
RubyとかRuby on Railsだと、簡単なWebアプリケーションをすぐ作ったり、あるいは、さまざまなジャンルで実際の適用例があるので、なにか困ったとき同じ問題に直面した人を探せたり、あるいはその問題を解決するRubyGemsを見つけられる。そういう点でいうと、トータルの生産性はかなり高いことがあるんですね。
なので、テクノロジーとしては、2010年代にどんどん新しく出てきた言語が持ってるあの機能がないとかこの機能がないとか、そういうカタログスペック上の欠点があるように思えても、トータルの生産性あるいは効率のよさを考えると、Ruby on Railsのビジネス上の価値は、実はそんなに下がっていないと思うんです。
先ほどのTIOBE Indexみたいなランキングは、技術者が新しいことを学ぶときに探すところで順位がついているので、ホットなトピックというんですか、新しく出てきて話題になっているものが上に来がちなんですよね。
だから、実際に仕事として、あるいは自分のプロダクトを作るときに、どんな言語を選択してどういうふうに開発したらいいのかを考えると、Rubyの持っているビジネス上の価値はそんなに下がっていないと思います。たとえ順位が下がって、表面上Rubyの人気が凋落したように見えても、ある意味「まだまだ大丈夫」が1つの見識だと思います。
Ruby開発者としての危機感
ただ、全員がこうやって安心してても、それはそれで困るわけで。「それ、ホントかな？」と。
実際に明日、ソフトウェア開発者として、自分たちのチームがWebアプリケーションを作るとします。言語を選択するとき、さっきの「まだまだ大丈夫」は真実ではありますが、非常に長期的に見たとき「いつまでもこれで本当に大丈夫か？」と考えると、ちょっと危機感を持ったほうがいいと思う。
人間には「恒常性バイアス」というものがあって「今日が大丈夫だったから明日も大丈夫」と思いがちなんですね。本当は危ないのに、なんとなく「明日も大丈夫だろう」って思い込む、そういう心理的・認知的な癖がある。なので、先んじて不満をキャッチすることが必要なんです。
実際、例えば東日本大震災のとき「津波が来ます」と言われているのに「この間来た津波は大したことなかったから、今回もきっと大丈夫だろう」と言って逃げなくて、巻き込まれた人がすごくたくさんいるんですね。恒常性バイアスが悪いほうに出たわけです。
なので、Rubyが凋落したと言われたとき、論理的に考えてもまだだいぶ大丈夫なんだけど、いつまでも本当に大丈夫と思ってていいかどうかは、また別に考えないといけない。とくに、Rubyそのものを作っている人は。
Rubyの話をしているときに、未来に対しての不満や課題で一番出てくる話題は、やっぱりパフォーマンスと、それからエラー検出なんですね。結局はスケーラビリティにつながるわけですが。
つまり「トラフィックが増えました」、あるいは「ユーザーが増えました」「データ量が増えました」といったときに、パフォーマンスの問題がある。
もしRubyのパフォーマンスがもっと高ければ、データセンターから借りているマシンの数が3分の2で済むかもしれない。そうすると、サービスを提供するときの固定費が30パーセント削減できるわけです。サービスが大きくなればなるほど、その30パーセントの金額は大きくなる。ですから実は、パフォーマンスは、お金に直結するかなり重要な問題でもあります。
それから、ソフトウェアの規模が大きくなったときに、より早く、よりたくさん、より網羅的にバグ・間違い・エラーを見つけられれば、ソフトウェア開発のスピードをさらに高められるわけです。そうすれば、より大きなソフトウェア、より複雑なソフトウェアをハンドルできて、よりたくさんの機能を提供できる。それもまた、求められていることではあるんですね。
Rubyを使っていると、エコシステムは揃っているし、いろんなライブラリを自分で開発しなくても済むけど、自分のロジックにおいてエラーの発見が遅れてちょっと不安なところがあるとか、あるいはデータセンターのマシンをよりたくさん用意しなくちゃいけないのでコストの面で不安があるとか、そういう話はたまに聞くんです。
Rubyそのものを提供している側としては、そういうユーザーの持っている不満に対するアンテナを高く掲げなければいけません。そこでなにをしようかという話ですが、パフォーマンスもさらに改善しないといけないと思っています。
