- #1: 統計を調べる
- #2: Railsの長所と向いている用途
- #3: Railsの短所と不向きな用途、他の選択肢など（本記事）
Railsの短所
不運にもRuby on Railsの人気に陰りが生じつつありますが、人気の下落にはそれなりに深刻な理由がいくつかあります。理由が致命的なものとは限りませんが、ものによってはプロジェクトで厄介な問題を引き起こす可能性もありえます。
1. パフォーマンス
これについては触れないわけにはいきません。Railsはスピードにおいて強者ではありません。処理速度が極端に高く、サーバーのメモリ消費も少ないものが必要な場合、Ruby on Railsは明らかに不向きです。もちろん、これはあくまで極端な場合であることを忘れてはなりません。数百万ユーザーをさばくことを期待しているのでもない限り、ほとんどのプロジェクト（特にスタートアップやMVP）ではそんなスピードを必要としません。ユーザーは、便利なアプリを安全かつ直感的に使えているうちは、パフォーマンスのことなど気にしないものです。
2. スケーリング
Twitter vs Railsは忘れがたいドラマでした。当時「Railsはスケールできない」といった議論が噴出したものです。ただしRailsは実際にはスケール可能です。サーバーのRailsをアップグレードすることも、複数のサーバーやツールで処理を手分けすることも可能です。しかしそうする価値はあるのでしょうか？こればかりはアプリ次第です。
前述のとおり、Railsのテクノロジーはバックエンドとしてそこまで高性能ではないと考えられています。他のフレームワークやバックエンドソリューション並のパフォーマンスをRailsで得ようとすれば、もっと性能の高い本格的なサーバーインフラに莫大な資金を注ぎ込まなければならなくなるでしょう。Node.jsやPhoenixといった高性能なテクノロジーを選択すれば、月に数千ドルは節約できることもあります。
3. 柔軟とまではいかない（個人の感想です）
Ruby on Railsフレームワークを使い慣れている方からすれば、これはものすごく偏った意見に見えるかもしれません。ここでいう「柔軟とまではいかない」とは、「Rails様は、Rails wayに乗ったアプリしか’お望み’にならない」ということです。この方針は多くの場合非常にうまくいっていますが、ひとたびRails wayから外れたありきたりでないアプリを開発しようとすると、たちまちつらくなることもあります。Railsにはデフォルト値やオブジェクトの詰め合わせセットなどがずらりと揃っているので、開発者が独自の創意を発揮する余地があまり残されていないように見えるかもしれません。もちろん開発者が「オレのやりたいようにやらせろ」と心ゆくまでオリジナリティを発揮しようと思えばできますが、その分開発期間も圧迫されるので、開発期間とオリジナリティを天秤にかけなければならなくなります。
4. 用途によっては「オーバーキル」
ここで大事なことを指摘しておきます。RailsがなくてもWebアプリは作れるのです。私たちは、プロジェクトの種類に合わせて最適なテクノロジーをお客様におすすめしています。お客様の要件によっては、Railsだと少々トゥーマッチなこともあれば、別の既存ツールならどんぴしゃりとはまることもあります。
5. Ruby言語と機械学習
AI（人工知能）やML（機械学習）はここ4年ほどホットな話題に顔を出しています。今どきのアプリの大半は、何らかの形で機械学習と統合されており、退屈な仕事を手伝ったり、主に既存の業務や人員をコードで置き換えることで業務を自動化したりしています。
この分野は、一言で言うと残念ながら今のRuby言語には荷が勝ちすぎます。ALやMLとくれば、Pythonが最適なテクノロジーです。言うまでもなく、Pythonは世界中で使われている人気上位のプログラミング言語であり、Rubyよりずっと高速です。Javaですら、AI/MLに適しているテクノロジーとみなされています。惜しいことに、愛しのRubyは主に必要なライブラリの不足が原因で、MLというもうひとつの大きなトレンドをフォローできていません。もちろん、言語というものはどんな用途にも使える万能性までは想定されていないことを忘れてはなりません。したがって、これはさほど大きな問題ではありません。
Railsを使うべきでない用途
1. 自社紹介に毛の生えたようなサイト
わざわざ不要な複雑さを持ち込まないようにしましょう。Ruby on Railsは、シンプルな静的サイトを作るには少々トゥーマッチです。そうした特定の用途であれば、コーディングをほとんど必要とせずにやれる選択肢がいくらでもあります。
2. ブログ中心のサイト
その気になればRailsでブログWebサイトを15分で作れることは、皆さんもデモでとっくにご存知かと思いますが、その後Webの世界ではさまざまなものが登場しました。今なら使いやすいツールの揃った本格的なブログを無料で構築できますし、そのためにRuby on Railsという戦車をわざわざ繰り出す必要もありません。
3. 開発者がRailsに不慣れな場合
開発者が好きでもないテクノロジーや、開発者が不慣れなテクノロジーを強要してはいけません。開発者がGo言語やNode.jsなどのバックエンドフレームワークに通じているのであれば、それを使ってアプリを開発してもらいましょう。
4. 納期がなく、プロトタイプも不要な案件
ここは重要です。既に何度も申し上げたとおり、Ruby on Railsは開発者の生産性を最大限に高めることができるがゆえに、開発期間を大きく短縮できます。残念ながら、Railsはその過程でパフォーマンスの一部を犠牲にしています。納期が明確に定まっておらず、MVPアプリも不要であれば、他のバックエンドソリューションを検討すべきです。もちろん、アプリの要件やその他の要素によって変わってきますが。
Rails以外のRubyバックエンドの選択肢
1. Sinatra
Sinatraは、Ruby on Railsに代わるミニマムな選択肢です。Sinatraの作者は、Railsとは少しばかり異なるアプローチを採用しており、アプリのセットアップに必要なコンポーネントを絞り込んでいるので、読み込みが比較的高速です。
2. Hanami
何らかの理由でRuby on Railsを使うわけにいかなくなった場合は、Hanamiをお試しください。HanamiはRuby製の新しいフレームワークであり、Ruby on Railsの短所のいくつかを修正することを保証します。Hanamiのメモリ消費量はRailsの60%に抑えられており、セキュアかつ応答も高速で、かなりの程度の軽量化を保証します。私たちが調べた範囲では、Hanamiは、Ruby on Rails以外では初めてと言える「本物の」Rubyフレームワークの選択肢です。詳しくはHanamiRBをどうぞ。
3. サーバーレスRuby
本記事を書いている間に、何やら面白いことが起きました。「サーバーレスで使える」Rubyをぜひチェックしましょう。AWSはつい先ごろ、AWS LambdaでRubyをサポートすると公式にアナウンスしました。これはRubyコミュニティにとって一大ニュースです！Java、Node.js、Go言語、C#などと同じくAmazonのクラウドにRubyも参入しました。
「サーバーレスRuby」にはどんな意義があるのでしょうか？開発者はサーバーインフラのことを気にしなくてよくなりますし、コードを正しく書きさえすれば、アプリの特定の機能をAmazonのクラウドの計算機パワーの一部として実行できるようになります。支払いが計算時間ベースだけで済むのもクールです。
AWS Lambdaやその他のサーバーレステクノロジーの登場が比較的新しいので、サーバーレスのコンセプトに精通した開発者や、サーバーレス経験のある開発者を見つけるのは今の段階では一苦労です。
AWS Lambdaについて詳しくはこちらをどうぞ。
GitLabもRubyを使っている
少し前の話ですが、GitLabは同社のRuby on Rails開発についての打ち明け話を記事で公開しました。GitLabは、リポジトリのストレージとしては世界2位の人気を得ており（異論はあるかと思いますが）、そのバックエンドではRuby on Railsが使われています。同社CEOのSid Sijbrandijは、自分たちが最初にRuby on Railsを選択したのはまさしく先見の明であり、そのおかげでさまざまな高品質の機能を苦もなく実現できていると述べています。
それだけではありません。GitLabの開発チームはさらなる課題への挑戦を続けています。コードの一部をGo言語で書き換えたり、Vue.jsフレームワークを採用したりすることで、パフォーマンスの問題を克服しました。
Ruby言語の未来とは
Link: Ruby is alive and well and thinking about the next 25 years | TechRadar: https://t.co/ywNBrVjabC
— Yukihiro Matsumoto (@yukihiro_matz) March 27, 2018
遡ること数年前、Rubyプログラミング言語のクリエイターであるMatzことまつもとゆきひろ氏は、「Ruby 3×3」と銘打った新しいバージョンのRubyを手がけていると発表しました。このプロジェクトではRuby 2.0の3倍の高速化を目指しています。リリース予定日は残念ながら未定ですが、2020年終わりまでのリリースとしてスケジューリングされるであろうと期待されています。
Ruby世界は1つのWebフレームワークで終わる。RailsはRubyを活かすと同時に苦しめてもいる。
Grzegorz Wilczyński（Lunaremのソフトウェアエンジニア）
Rubyファンは、Ruby 2.6のプレビュー版でRuby 3×3の一部が既に導入されていることに気づいています。JITコンパイラの導入によってパフォーマンスが著しく向上したことがさまざまなベンチマークで示されました。もちろん、変わるのはスピードだけではありません。Matzのインタビューによれば、Ruby 2.6はクリスマスのリリースが予定されており、ある種のコンカレンシー抽象化もリリースに含まれます（訳注: 2.6は予定どおりリリースされました）。
Matzは他にも、過去のRubyアプリケーションではRubyのバージョンが変わると互換性が失われていたと述べています。かつてMatzはさまざまな変更を導入して「巨大なギャップ」が生じ、それによってRubyコミュニティが分裂したことがありました。Matzは今後そうした間違いが起きないようにするとのことです。Matzは大胆にも、Ruby 2のプログラムはすべてRuby 3で動くようにすると述べています。
StackOverflow Developer Surveyでは、Rubyを愛する開発者が減少しつつあるという残念な結果が出ていました。実際、トップ10にも入っていません。Matzは、現状のRubyは既に「ホットな言語」ではないとみなされているが、その分安定しているとも述べており、3×3がリリースされたときに再び「ホットな言語」として愛用されることを願っています。
成熟と停滞
Rubyは成熟のときを迎えています。自らを「成熟した」と言い切れるプログラミング言語はそう多くはありません。現状のRubyは、人気の高い言語の中では今も古株であり、実績も信頼もあるテクノロジーとして世界中で使われています。Rubyのコミュニティは絶え間なくRubyを支援しています。コードで何か困ったことがあれば、そして運良く同じ問題を数千人が踏んでいれば、かなり楽に解決方法を見つけられるでしょう。
残念ながら、成熟と停滞は表裏一体です。前述の通り、ここ数年はRubyを「ホットな言語」にする変更や新機能はそれほどありませんでした。Rubyもコミュニティももうお終いだという意見もあったりします。私個人は、Rubyのテクノロジーは停滞期を迎えていると考えています。率直に言うと、Rubyは極めてゆっくりとですが、レガシー言語になりつつあります。
少なくともここ数年、Rubyからときめきが失われていた。ただし、ときめきがないとだめということではない。長い目で見れば、プログラミング言語にとってときめきが必要だとも私は思わない。私としては、プログラミング言語には成熟と安定性と信頼性を求めたい。私は2019年のRubyについてそう考えている。私がRuby以外の言語に乗り換える必要のある分野は年々減り続けている。Rubyがこれまで「エンタープライズ向け」テクノロジーであったことはないし、今後そうなるかどうかも疑問ではあるが、高速かつ柔軟にやりたいことがあれば、Rubyは今後もよい選択のひとつである。
Filip Tepper（Castle Intelligenceの上級エンジニア）より
まとめ
皆さんが本記事を最後まで読んだとしても、Ruby on Railsを使うことで生産性が向上するとも思えず、アイデアとして非常に優れているとも思えないかもしれませんが、Rubyのエコシステムはまだまだやることをたくさん抱えています。Ruby on Railsのパワーを余すことなく活用すれば、洗練されたアプリをすぐにでも開発できるようになります。この機能については、他の多くのフレームワークでそこまで自信たっぷりに言い切ることはできません。なぜなら（はい、皆さんご一緒に）「欲しいgemは必ずある」からです。
ここ最近、そして近い将来のRuby on Railsのリリースはとても有望に思えます。開発者から寄せられた不満の多くが修正され、新バージョンが出るたびに素晴らしい新機能が追加されています。Ruby、そしてRailsが近い将来再び勢いを盛り返すことを願っています。
- #1: 統計を調べる
- #2: Railsの長所と向いている用途
- #3: Railsの短所と不向きな用途、他の選択肢など（本記事）
おたより発掘
僕の場合「楽しく書けるか？」「エレガントに（＝シンプルかつ美しく）書けるか？」が最重要事項なので、いまだにRuby以上に「おっ」と思える言語はないんだよな〜。なので短所を挙げられてもRailsから乗り換える気が起きない。
Railsは2019年も「あり」か？#3 短所と不向… https://t.co/4jo5hmYQ0A— Junichi Ito (伊藤淳一) (@jnchito) January 31, 2019
Railsが成熟し、停滞しつつあることにしっかり触れて、向いていないケースの解説も丁寧だった。非常にいい記事。
Railsは2019年も「あり」か？ https://t.co/Nc1IA6OVXE— ngmt (@ngmt83) January 31, 2019