Railsは2019年も「あり」か?#1(翻訳)

概要

原著者の許諾を得て翻訳・公開いたします。

原文が長いため3分割してあります。
日本語タイトルは原文タイトルではなく内容に即したものにしました。
画像は元記事からの引用です。

Railsは2019年も「あり」か?(翻訳)

Post image

もう認めようではありませんか、Ruby on Railsが年を取ったことを。いや本当に長生きしたものです。しかしtech業界の移り変わりを見渡してみれば、Railsのテクノロジーは驚くほど成熟していると考えられるので、Railsを特定用途に用いることに何の不思議もありません。

今さらこんな話題を蒸し返す意味はあるのでしょうか。RubyのコミュニティとRuby on Railsのコミュニティにとって、ここ数年は企業や開発者の関心が失なわれつつあるというエビデンスによって、厳しい試練にさらされていました。RubyとRailsが今日の標準に照らし合わせて著しいデメリットを多数抱えているという理由で、他のテクノロジーを選ぶスタートアップ企業や開発チームが増えています。

「Rubyは死んだ」「Railsは死んだ」と主張する人もいるでしょうし、その理由には的を射た部分もあるでしょう。決して根も葉もない噂ではありません。

2011年から開発にRubyを用いてビジネスを継続してきた当Rebased社は、さまざまなサーバーサイドWebアプリケーション開発のオルタナティブを評価してきました。その結果、Ruby on Railsは2018年末の時点においても、ほとんどのユースケースにおいて、セキュアかつ高品質のWebアプリを短期間で開発するのに最もふさわしいと私は確信いたします。リッチなJavaScriptアプリの登場によってビジネスロジックの一部がフロントエンドに移行しましたし、バックエンドの責務は「サーバーレス」ツールの勃興によって縮小され、単にSQL->JSON変換と認証をこなすだけのものに成り下がりつつあります。しかし、構築するバックエンドの規模が数個のリモート関数呼び出しより大きくなるのであれば、私たちにとってRuby on Railsは今も変わらず選択肢のひとつに含まれています。ただし「Railsにしておけば万事OK」ということではありません。用途によっては、他のテクノロジーを使う方がずっと適切な場合もあるからです。しかし総合的に見れば、2019年も私たちにとって「ほぼほぼRailsを使う」年となる見通しです。
Tomasz Stachewicz(RebasedのCEO)

かつて、RailsがあのWeb 2.0の申し子扱いされていた時代がありました。それまでPHP開発者たちはスパゲッティコードを長年量産しながら苦しみ続けたというのに、ブログアプリをわずか15分で、しかもまともそうなコードで構築できるようになったのですから、当時は目を見張ったものです。

Rails登場後の数年間は、マーケットプレイスやeコマースサイトからSNSに至るさまざまな製品にうってつけの構築ツールとしてもてはやされました。その状況が一変したのは、スマホの人気上昇とともにアプリへの要求が著しく複雑化したときでした。

Ruby on Railsのテクノロジーは完全無欠でも何でもないことがわかってきました。機械学習やブロックチェーン(2019年はどうなることやら)といった特定の問題を扱うには明らかに不向きです。TwitterはRuby on RailsからScala言語に移行し、他のプラットフォームもGo言語やRust言語を選ぶようになったことは、Ruby on Railsコミュニティにとって痛恨の一撃でした。Ruby on Railsは世界中にいる数百万人のユーザーをさばくには力不足であることに誰もが気づきました。Railsをマルチサーバー上でスケールアップすれば別ですが、それはまた別の話であり、かつ高くつきます。

それから数年経った今、私たちは1つの問いかけを自分たちに投げました。「Ruby on Railsは本当に死んだのか?」「今後もRuby on Railsで自分たちの製品を構築するのはありなのか?」。私たちと一緒に答えを探ることにしましょう。

統計をチェック

StackOverflow

ruby-on-rails-stackoverflow-trends

StackOverflowのデータをちょっと見てみましょう。Rubyコミュニティ、そしてRuby on Railsコミュニティのエンゲージメント率は、Node.jsとは逆に明らかに大きく減少しています。Node.jsのコミュニティは絶え間なく成長し続け、人気も上昇の一途ですが、Ruby on RailsフレームワークとRuby言語は、かつてないほど0%に接近しています。

StackOverflow Developer Survey

ruby-on-rails-stackoverflow-survey-2018

StacOverflowは、特定のプログラミング言語それ自体や、その言語の業界での一般的な位置づけについて開発者にアンケートを取るのが毎年の恒例です。その質問の中に「業務で使うプログラミング言語」という項目があり、結果は上のグラフのとおりです。

同じ調査の中で、Ruby開発者のグローバルなサラリーが64,000ドルという結果が出ています。これはClosureClojure(72,000ドル)やRust(69,000ドル)はおろか、Go言語(64,000ドル)をも下回っていますが、JavaScriptの55,000ドルと比べれば大幅に上回っています。

事実はどうなのか

同じ結果を米国に絞り込んで見ていくと、少々趣が異なっています。

ruby-on-rails-salary-indeed-com

ご覧のとおり、Ruby開発者はこのカテゴリ内で明らかに収入の高い仕事にランクインしていますが、その役職の枠は減少しつつあり、Node.jsの開発者が就ける役職の枠は、Ruby on Rails開発者の2倍近くあります。

Rails開発者の収入はNode.jsよりも上

このデータを元に判断すると、Node.jsをやってきたプログラマーのサラリーは、明らかにRuby on Railsプログラマーのそれを大きく下回っています。この要素は、Web製品を開発するときの総合的な開発コストに大きく影響を与える可能性がありますので、頭に置いておきましょう。

仮に、あなたが製品をスクラッチから開発するためにチームメンバーを招集することになったとします。私たちの経験から申し上げると、スキルの高いプログラマーをこのマーケットで集められるかどうかについては大した問題とならないはずです。胸の躍るような新規プロジェクトを求める腕の良いRails開発者は今も数千人はいますが、今そうした開発者の数は減少しつつあります。もちろん、この辺の事情は地域によって変わってきますので、まずは皆さんの地元の事情を調査することをおすすめします。でなければ、単に開発をアウトソースするかコソーシング(co-sourcing)しましょう。

RedMonkのデータ

Rubyは、2018年6月の時点で6位につけています。

redmonk-ruby

RedMonkは、GitHubやStackOverflowから言語への関心のデータを取り出し、それを他の主要な言語すべてと比較しています。悲観論者の言うこととはうらはらに、Rubyは死んでいるどころかその逆であることがはっきりわかります。Rubyが上位につけていることを考えれば、Rubyは今も開発ツールやアプリで用いられる言語として人気を保っていると結論付けられます。でも「喜ぶのはまだ早い」のです。

GitHub Statsのデータ

github-osctoverse-ruby-on-rails

上のグラフは、GitHubコントリビュータたちの間で人気の高い言語を比較しています。具体的には、あるテクノロジーを用いて開発されたリポジトリの数を比較しています。不動の勝利を収めている言語についてはだいたい見てのとおりです。グラフからわかるように、Rubyを選ぶプロジェクトは減少の一途を辿っており、今も人気トップ10にランクインしているものの、利用数は年を追うごとに減っています。

Ruby Gem

この流れで、今度はGemのダウンロード数をチェックしてみましょう。InfinumはGemのダウンロード数についてまとめた良記事を公開しています(訳注: 記事では2017年を対象としています)。Infinumはダウンロード数を頻繁にトラッキングして自分たちのデータベースに保存しています。この結果からRuby on Railsの現状についてさらに情報を得ることができます。結果はあまり芳しくありません。

Infinumが集めたデータによれば、新しく作成されるGemの数は年々減っており、リリース数も同じく減少しています。一方、Ruby on Railsのダウンロード数は前年度に比べて非常に増えているようです。

2019年: Rubyにとって2018年はかつてないほどよい状態でしたが、2019年にはさらに大きな可能性を秘めています。Rubyは、自らが支配するWeb開発やバックエンドAPIのニッチな分野で急速に成長しています。私は2004年からRubyのマーケットをウォッチしていますが、今ほど胸が高まったことはありません。私は、他の言語からRubyに移った開発者を何人も目にしています(我がArkencyだけでもC#言語出身のプログラマーが2人います)。Rubyは開発者を今も幸せにし続けており、同時にエコシステムの成熟も大きく進んでいます。私がRubyコミュニティで特に興奮を覚えるのは、DDD(ドメイン駆動設計)CQRS(コマンドクエリ責任分離)イベントソーシングの技法やミューテーション解析の採用が増加していることです。
Andrzej Krzywda(Arkency


関連記事

Railsは2018年も現役か?: 前編(翻訳)

Railsドメイン設計: イベントソーシングでCQRS Read Modelが基本的に必要な理由(翻訳)

デザインも頼めるシステム開発会社をお探しならBPS株式会社までどうぞ 開発エンジニア積極採用中です! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

ActiveSupport探訪シリーズ

BPSアドベントカレンダー