概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Is Rails still relevant in 2018 ?
- 原文公開日: 2018/08/16
- 著者: equivalent
記事は3分割しました。画像は元記事からの引用です。
Railsは2018年も現役か？（翻訳）
Rubyから別の何かに乗り換えることを検討中のWeb開発者から、数日前にこんなメールを受け取りました。
まったく新規から始めるとしたら、バックエンドにRubyかElixirかJSのどれを選ぶ？
このメールで他に重要と思われる部分は、現在の彼はもっぱら自分のサイドプロジェクトに関心を寄せていることと、主な懸念点は開発速度と開発のしやすさであるということです。
メールに返信を書き始めたのですが随分と長くなってしまったので、この際記事にすることにしました。
ご興味をお持ちいただいた方に趣旨を簡単にまとめます。
本記事では最初に、Web開発の哲学や仕事と人生についてざっと眺め、それらの意義をよりよく説明できる技術的側面に光を当てます。
忙しい人向けのまとめ
長すぎて読んでいられないという方向けに記事の冒頭に結論を置きました。ここから先は読まなくてもOKです。
これまでを振り返って考えた結果、私なら2018年の今でもRuby on Railsを主要な技術として選択するでしょう。
私はこれまで自分とよく似たタイプの人々にたくさん出会ってきましたが、Railsの技術はそうした人々（主にスタートアップ）を魅了し続けているという点で、私はRailsというプロジェクトが好きです。私は自分の好みとしてRailsを選びますが、皆さんはまた違うことでしょう。
Railsは時代遅れではありませんし、Rubyも死にかけてなどいません。むしろこれまでにないほどよくなっていますし、この技術のマーケットも実に好調です（💰💰💰）。
反論がおありの方は記事に全部目を通していただいてからお願いします。くれぐれもよろしく。
私は自分の主要なツール（つまりRails）に注力すると同時に、素のRubyやElixir、PhoenixやJavaScriptについても学習を継続するつもりです（1日20分の学習時間ぐらい誰だって確保できますよね？）。
そして上に挙げていないプログラミング言語の学習には時間を使いすぎないようにするつもりです。もちろん自分のツールボックスのツールを増やしておく必要があるからですが、かといってツールボックスにツールをぎっしり押し込めてもスキルが伴わなければろくに使いこなせずに終わってしまいます。それよりも低レイヤの技術、つまりデータベース、キャッシュ、コーディングの実践、DevOps、チーム運営、テスティングを学びましょう。
開発経験の長い人なら、新しい言語を学ぶというのもありです。
「ただのツールじゃないか」
プログラミング言語も、ライブラリも、フレームワークも、データベースも、コーディング規則も、所詮ツールに過ぎません。
壁に釘を打つときはハンマーが欲しくなりますし、レンガ塀を解体するときにはもっと大きなハンマーが欲しくなるものです。しかし自動車の修理にハンマーを使うのは普通おかしいでしょう。
画像:「Web開発者ってのは職種じゃないんだ、生き方なんだよ！」
職歴を重ねる中で、さまざまな技術や製品開発アプローチを試したり学んだりということから逃れる道はありません。「Web開発者ってのは職種じゃないんだ、生き方なんだよ！」。自己鍛錬のサイクルに終わりはないのです。
「生き方」について: ここで言う生き方とは、「仕事と生活のバランス」のことではなく、「仕事と生活のマインドセット」の話です。開発者は言ってみれば総合格闘技の選手のようなもので、異種格闘技戦の習得と実戦は生涯に渡って続きます。
ですから、プログラミング言語だけが重要なのではなく、プログラミング言語と組み合わせられる技術（データベース、クラウドソリューション、キャッシュ、ライブラリ）も重要であることに気づく必要があります。もちろんアーキテクチャ（モノリスvsマイクロサービス）や実践的チーム編成（アジャイル、スクラム、カンバン、XP、github-flowなどなど）、コーディングの実践やコーディングスタイル（SOLID、DCI、OODDなどなど）。プログラミング言語は、それらをつなぎ合わせるニカワのようなものでしかありません。
そこで最速のプログラミング言語を使ってもよいのですが、たとえばMySQLデータベースのクエリを効率よく書く方法を知らなければ、アプリは耐え難いほど遅くなってしまいます。
開発者にとっての幸せとは
プログラミング言語を使う仕事は1日に8〜10時間（下手をすると16時間）にのぼります。「開発者としての幸せ」の重要性を見過ごしてはなりません。
自分が使っているツールや、自分が携わっているプロジェクトで幸せになれないのであれば、それはプログラミング言語のせいではなく、自分のせいなのです。
私は今の仕事を愛しています。それというのも、正しい技術セットを正しいチームと一緒に使える、正しい価値観に基づいた正しいプロジェクトで働ける仕事を選んできたからです。
新米開発者は、経験したくもないような業務に耐えなければならなくなることがよくあるようですが、正直に申し上げると、今この2018年の世界で、一人前のシニアWeb開発者が業務で悲惨な目に遭う理由が私にはよくわかりません。もちろんストレスや不満だらけの日々も間違いなくありますが、それもしばらくの間だけです。しかしそれを超えて悲惨なのであれば、プロジェクトや業務を変えるか、違う技術に乗り換えるか、働き方を変えましょう（在宅勤務にシフトするとか）。どれも無理ということであれば、おそらくWeb開発者としてまだ一人前ではないので、もっと精進して腕を磨きましょう（数か月後にこのパラグラフをもう一度読み返してみましょう）。
Web開発10年というのは経験が10年？、それとも毎年同じことを10回やってるってこと？
勝ち組などいない
「悪い」プログラミング言語というものはありません。あるとすれば、プロジェクトでのプログラミング言語の選択が悪かったのです。
ソフトウェア開発者がプログラミング言語をたとえば「Ruby遅すぎ」などとdisるとき、言語の長所は決してスピードではないという点を見落としています。時間をかけてそうした批判の背景を調べてみれば、たとえばろくにロードバランシングしていないサーバーで数千リクエストをさばこうとしているとか、キャッシュをまったく理解していないといったことに気づくでしょう。
開発者は、newrelicなどのツールでアプリの総合的なパフォーマンスを最適化することに注力する必要があります。その言語が扱えるループサイクル数がいくつかなどという点ではありません。今構築しているのは、現実の人間が使う現実のアプリなのですから。
開発者たちが、やれJavaは複雑すぎるだの現実のアプリには向いてないだのと不満を垂れるのをよく目にします。そうした言語は、大規模なチームによって開発され、何十年にも渡って運用されるエンタープライズ向けに設計されています。銀行であれば、即座にRubyではなくJavaを選ぶでしょう。その主な理由は、Javaが機能を廃止することがほぼないからです（どんなにクソなアイデアであっても、一度導入されれば半永久的にサポートされます）。Rubyはそうしたエンタープライズの巨人たちから受ける圧力が少ない分、大胆な変更を頻繁に取り入れる余地が大きく、コードの互換性と引き換えに優れた機能を導入できます。
Googleのように数十億ユーザーを扱うプロジェクトであれば、Rubyを使おうとは思わないでしょう。そしてこれほどの規模になるとモノリスアプリでさばくのはほぼ不可能なので、ほとんどの場合マイクロサービスアーキテクチャの形でさばいて、個別のサーバーで動く小さなアプリの中に言語の制約を隠蔽するでしょう。
詳しくは別記事『モノリスvsマイクロサービス』をどうぞ。
現在の言語がシナリオにそぐわないというだけの理由で、一部の大企業が言語を切り替えることはよくあります。Twitterが何年か後にRubyから乗り換えたのも、TwitterがSNS界の巨人となったからです。GitHubもアプリをリファクタリングしていくつかの技術に分割する必要に迫られました。これは最初の言語の選択が間違っていたのではなく、企業がそのときの姿に合わせて、自らの成長に役立つ最適な言語を選んだまでのことです。
こうした切り替えはプログラミング言語だけではなく、データベース（SQL vs NoSQL）やストレージソリューション（DropboxがAWS S3から乗り換えた）などあちこちで普通に見られます。何か事あらば騒ぎ立てる傾向はプログラミング言語関係者独特のものです。
画像: 「一部の会社が使わなくなったくらいでプログラミング言語が死ぬわけねーだろ」
言語の乗り換えは、普通によくあることです。
並外れた成功を収めるとモノリスアプリをマイクロサービスに分割するというパターンもよく見かけます。
あなたがまだ数千ドルしかファンディングを調達できていないスタートアップ関係者で、アプリをスクラッチから開発して成功させたければ、JavaやElixir Phoenixのような無駄に複雑な言語を選んでいては、リリースを迎えないうちにあっという間に資金は底をついてしまうでしょう。
もちろんElixirもPhoenixも本当にいいものです。生産性も高いし。しかし正直なところ、製品開発速度においてはRailsの方がずっと上です。
Web開発経験すらないホヤホヤのスタートアップ企業が自分たちの「画期的な」プロジェクトに欲しいものといえば、ほぼ間違いなく「プロジェクトを支持してくれる数百万人のユーザー」がそのひとつでしょう。そんなユーザーがいれば成功間違いなしですから。たいていのスタートアップ企業は、そういう手前勝手な期待を当てにして没落します。サービスを立ち上げて半年経っても、ユーザー数はせいぜい数千人がいいところでしょう。大成功してトラフィックが押し寄せるときに備えるのも結構ですが、取らぬ狸の皮算用より現実を先に見ましょう。
成功への期待が大きすぎれば、それをサポートする投資側が期待する完成時の見返りも相応に膨れ上がります。同じ機能であっても、ユーザートラフィックが数百の場合、数千の場合、数十万の場合に応じて開発期間は数日であったり、数週間、数か月と変動します。
競争の激しい市場で生き残るのは、要件に応じた既存機能の改修や新機能の導入をすばやく行えるスタートアップ企業であり、そうしたフットワークがなければたちまち消えるのが定めです。顧客や投資家にしてみれば、箸にも棒にもかからないエクスペリエンスでユーザーがせいぜい数百人程度のアプリが、将来2百万ユーザーをさばける潜在能力を秘めていようが知ったことではありません。
このように、成り行きはプロジェクトによって千差万別です。今構築中のチャットアプリはRubyで作ると初期段階から苦労が絶えず、やがてその分野はElixirに支配される可能性がもしかするとあるかもしれません。そのプロジェクトのボトルネックがどこにあるのかを真剣に分析する必要があります。
私がRubyに（そして概ねRailsにも）こだわり続ける理由は単純そのものです。私が愛しているのは面白い機能を続々開発できるプロジェクトであって、ひとつの機能を何か月もかけて辛抱強く最適化することではありません。私がプロジェクトを選ぶときは、大きすぎるプロジェクトや小さすぎるプロジェクトをあえて避けています。私にとって楽しく難易度も手頃なのはいつも中くらいのプロジェクトです。
そういうわけで、皆さんも自分たちが選んだ技術に合わせて、これから数年どんなプロジェクトで働きたいかを真剣に自問自答すべきです。
コミュニティ
コミュニティの規模や特性も見逃すわけにはいきません。言語のコミュニティ規模が小さすぎると、ライブラリやバグを修正してくれるベテラン開発者が不足します。
かといってプログラミング言語のコミュニティがあまりに大きくなると、コミュニティの劣化が加速する可能性があります。ささいなことに思われるかもしれませんが、とある言語の周辺コミュニティは、小規模だった頃にはクールかつオープンマインドを保っていたのが、市場で支配的な地位を占めるようになって人気が高まるに連れて、ポリティカルコレクトネスグループとしての性格が強まりました。手短に言うと、一部の優秀かつ人当たりもよい開発者たちがSNSで他愛もないジョークをかました途端、非難轟々の嵐にさらされたのです。
どの言語なのかは言わないでおきます。書いたら最後、コミュニティの矛先がこちらに向かって爆発炎上するでしょう。それはそれで私の言説の裏付けにはなるでしょうが、そんな自殺行為は趣味ではありませんので。