Railsの未来についての一考察

概要

前置き

この記事はRails Advent Calendar 2020の15日目の記事です。昨日はnegito6さんの忙しい人のための Rails デバッグ方法まとめでした。

動機

うなすけさんのRailsを主戦場としている自分が今後学ぶべき技術について(随筆)という記事と、それに対するmizchiさんのアンサーブログ、Re: Rails を主戦場としている自分が今後学ぶべき技術についてに触発されて書いています。

お断り

この記事ではRailsの技術的な側面を意図的に重視していません。というのは、私がRails以外の技術についてそこまで詳しくないため比較するのが困難だからです。

また、ふわっとした話題を扱うということもあり、どうしても書き方が推測多めになってしまっています。これは私の知見と経験の少なさによるものです。

本編

アプリケーション開発のマトリックス

いきなりですが、アプリケーションを開発するときに、チームのサイズ感と将来的なスケール感とをそれぞれ横軸と縦軸にすると以下のようなマトリックスが描けるかと思います（テキスト失礼！余談ながら、Webでいい感じにマトリックスみたいな図が描けるツールあったら教えてください）。

チームサイズ	将来的なスケール感
スモールチーム	スケールしない
ビッグチーム	スケールしない
スモールチーム	スケールさせたい
ビッグチーム	スケールさせたい

このうち、「ビッグチーム・スケールしない」というアプリケーション開発は例が他と比較して極端に少なさそう（スケールしないならビッグチームを支えられない可能性が高い）なので、実際に考えるべきはそれを除いた3つになります。

Railsはスモールチームでスケールしないアプリケーションを開発するのに最適

上記のマトリックスのうち、Railsが最も力を発揮するのは「スモールチーム・スケールしない」のケースです。これはRubyが動的型付け言語であるということと、Railsのそもそもの設計思想によるというが私の考えです。

Rubyが動的型付け言語であるということは、Rubyでの開発はチーム規模が大きくなるほど生産性が（その他の言語と比較して）急激に低下しやすいことを示唆しています。これにより、Railsはスモールチームに最適化されていると考えられます（異論はあると思います）。

Railsの設計思想についてはやさいちさんのRuby on Railsの正体と向き合い方に詳しいのですが、要するに「少人数チームによる速くてキレイな開発を実現するためにコンポーネントを密結合させている」という話で、これがRailsではスケールが困難という事実につながってきます。もちろん、Ruby言語自体のスケーラビリティが低いということも場合によっては意味を持つでしょう。

チーム規模の拡大とスケールを前提としたアプリケーションをRailsで作るのは理にかなっているとは言えない

ということは、なんにせよスケール前提のアプリケーションであれば、それをRailsで構築するのは最適ではないのかもしれません。少なくとも、何らかの工夫なしにRailsアプリケーションがスケールしていくと辛くなってくる、という事例は複数あるようです。また、チーム規模が大きくなることでRailsでの開発が最善ではなくなってくるケースもあるでしょう。

何より、世の中にはRails以外の選択肢も豊富にあります。静的型付けやスケーラビリティを求めるのであればそれらを採用することが最適である場合が多いと考えられます（現状のチームが持つ技術的な強みなど他の考慮点もあるので常にとは言えない）。

スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワークがRails

RailsのオリジナルアプリケーションはBasecampですが、このアプリケーションを開発しているBasecamp社は創業当初から社員数を増やさないことを徹底しているらしく、チームページによれば、創業から21年経った今でも60人ほどしかいないようです。

また、Basecampというアプリケーションはフリーミアムモデルを適用しておらず、価格ページによると現在は月99ドルの固定価格のようです。これはBasecampが大規模にスケールしなくてもビジネスとしては成立するということを意味しています。

このように、Railsの開発を最も強く推進しているBasecamp社の現状を考えると、Railsが「スケールが不要なアプリケーションをスモールチームで開発する」ことに特化しているとしてもさほど不思議ではないでしょう。

興味深い話として、Basecamp社は自社のスマートフォンアプリをWeb技術中心で開発し、そのために自社開発のライブラリであるTurbolinksを活用して、わずか数名のチームでiOSとAndroid向けのスマートフォンアプリを開発できたということです（リンクを探したのですが見つかりませんでした…）。このように、Basecamp社のアプローチは少なくとも彼らの環境では機能しているようです。

また重要な点として、Railsはこの「スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワーク」としては最も成熟したフレームワークです。近年ではLaravelとの差が急激に縮まっている、またはすでに追い抜かれているとの言説もあるようですが、その文脈においてすらRailsの成熟度と利便性は否定されません。

Railsが強みを発揮できるケースはどれくらいあるのか

この「スケーラビリティが不要なアプリケーションをスモールチームで開発する」というシチュエーションですが、Webアプリケーション開発の全体に占める割合はどのくらい大きいのでしょうか。意外と大きいのでは、というのが私の見解です。

まず、スタートアップ企業が開発するアプリケーションはすべからく少人数での開発となる場合が多いです。これは単純に資金が少ないまたは貴重であることからチーム規模を大きくできないケースが多いでしょう。スモールビジネス（スタートアップと違って大きく成長する前提ではない）も定義上スモールチームでの開発をするしかありません。これらのケースではRailsを採用することは、以下のスケーラビリティの問題をクリアできるのであれば、合理的な選択肢の一つと考えて間違いないでしょう。

アプリケーションのスケーラビリティについてですが、いわゆるSaaSの場合はスケールメリットが相対的に小さいとは考えられます。一方、UGC（User Generated Contents）のサービスであれば、スケーラビリティは必須になってくるでしょう。それ以外にもECサイトなど、急激なスケーラビリティを必ずしも必要としないサービスはそれなりにあると思われます。

個人開発の友

Railsは「フルスタックフレームワーク」であり、それが逆にフロントエンドの最適化の妨げになっているという話がmizchiさんの記事の一つの論点であると私は理解しています。私はフロントエンドに詳しくないので深く議論することはできないのですが、Rails（あるいは他のフルスタックフレームワーク）がフロントエンドの最適化をある意味で犠牲にして提供しているものがスモールチームでの生産性です。その究極の形は個人開発でしょう。

個人開発は笑い飛ばせるような存在ではもはやなく、実際にいくつものサービスが個人開発から育っていっています。そこでは「フロントエンドの最適化」よりも「いかに仮説を検証するか」が重要であり、Railsが提供する高速な開発が重要な意味を持ちます。Railsのエコシステムにより各種実装を省略できることもまた重要です。

これらの点で他のフレームワークがRailsを超えるまでは、Railsはある程度安泰と言っていいかもしれません。

Railsの改善点：段階的なスケーラビリティ

もちろん、ここまでの話はRailsに問題がないことを意味しません。私の考えでは事実は逆で、Railsには改善すべき点が多くあります。ここではいくつかの考えを紹介します。

Railsに欠けているものは詰まるところ「段階的なスケーラビリティ」に尽きるのではないかと私は考えています。これは、現実の世界では「スケールするアプリケーション」と「スケールしないアプリケーション」にハッキリと分かれるわけではないという、これまであえて触れて来なかった事実に由来します。最初は個人開発またはスモールチームで作ったものが予想以上に成功してしまい、スケーラビリティを考慮する必要が出てきた―こんなシチュエーションはRailsの最も顕著な弱点です。

Railsはomakaseであるというのが、Railsドクトリンに掲げられたRailsの思想ですが、これに照らし合わせれば、Railsはいわば「スケーラビリティを標準で備える」べきです。具体的には、多くのケースでモデル層が肥大化することがスケーラビリティを下げているという点を踏まえ、モデル層を段階的に分割するような機構を導入することなどが考えられます。例えばコマンドオブジェクトやフォームオブジェクト、シリアライザなどです（大雑把にはそれぞれCRUDのD, CU, Rに相当します）。

もちろん、Railsのエコシステムにはこれらが含まれているのですが（それぞれinteractor-rails、yaaf、active_model_serializersなどが代表例）、これらは結局コアと統合されておらずメンテナンスなどの面で不安があります（実際、AMSのメンテナンスは滞っています）。

Railsに「段階的なスケーラビリティ」が組み込まれることで、開発の初速を担保しつつ開発をスケールさせられるようなフレームワークに進化すると良いなと思っています。

まとめ

というわけで、Railsの未来について考えてみました。この記事ではいくつかの点に触れることができず（例えばShopifyやCookpad, GitHubのような大規模Railsアプリケーションの実例など）、悔しい気持ちも少しあります。もしかしたら、また別の機会に似たテーマで書くかもしれません。