Ruby on Rails

David Heinemeier Hansson(DHH)が 2004 年 7 月に公開した、ruby で書かれたフルスタック Web アプリケーションフレームワーク。Basecamp(37signals)の社内コードから抽出された。convention-over-configuration と DRY を核に据え、当時の Web 開発の生産性基準を一段階押し上げた。設計哲学は後に the-rails-doctrine として 9 原則に体系化されている。

Rails が Rails たりえた理由(テーゼ)

Rails の本質的な勝因は 機能の多寡ではなく時代との噛み合わせ にある。同等の機能だけなら J2EE のほうが豊富だったし、PHP のほうが配布は容易だった。「2004 年というタイミングで」「Ruby というプログラマに気持ちのいい言語の上で」「当時の標準を大きく超える利便性を提供できた」 という三つが揃ったことで Rails は Rails になった。これらが一つでも欠けていれば、Rails は単なる「もう一つの MVC フレームワーク」で終わっていた可能性が高い。

つまり Rails の歴史は、フレームワーク単独の歴史ではなく、Ruby というランタイム選択・Web 2.0 という時代潮流・37signals という思想集団の三層が重なった現象 として読むべきもの。

2004 年に Rails が入った地形

Rails が登場した時、Web アプリ開発の主要選択肢は以下のような状況だった。

環境当時の体感Rails が突きつけた問い
Java + Struts / J2EEXML 設定の山、EJB の重さ、IDE 必須、エンタープライズ志向「なぜ Hello World に 5 ファイル必要なのか」
PHP 4/5配布は楽だが、構造を強制する仕組みが薄い。スパゲッティ化しやすい「規約と構造はもっと安く手に入るはず」
Perl + Mason / CGI古参の現場では現役。だが新規採用は減少「もう Perl で新規プロジェクトを始める時代ではない」
ASP.NET 1.xMicrosoft 専用、Windows サーバ前提、ライセンス費用「OSS のプラットフォームでも同水準のものが作れる」
Python + Zope / TurboGears構成が複雑、または立ち上がり期(Ruby 陣営から見た)哲学の対比相手

Rails 以前の主流は「設定ファイルで挙動を記述し、IDE がそれを解釈して支援する」モデルだった。Rails はその前提を反転させた。

Rails が持ち込んだ具体的な利便性

Rails が登場時点で提供したのは以下のような体験。個々の機能ではなく、それらが「一つの一貫した規約の下で同梱されていた」 ことが核心。

これらは個別には他言語にもあった。だが「プロジェクト生成 5 秒・データベース付きの動く Web アプリが 15 分」という体験は、当時の他のスタックにはほぼ存在しなかった。

「15 分でブログを作る」スクリーンキャスト

DHH が 2005 年に公開した Creating a weblog in 15 minutes スクリーンキャストは、Rails の伝播における最大の触媒。

なぜ Ruby が「いけてる」言語だったか

Rails の勝因に時代背景があるとして、では「なぜ DHH は Ruby を選んだのか」「なぜそれが多くのプログラマに受けたのか」が問題になる。詳細は ruby 側に書くが、当時の文脈で重要だったのは次の点。

つまり Ruby は当時、「他の主流言語に飽きた、書き味を重視する開発者」の受け皿 として既に文化的なポジションを獲得していた。Rails はその受け皿の上に立った。

時代の追い風(critical timing)

Rails が広まった 2004–2007 年は、Web 開発の地殻変動期だった。

特に Y Combinator 系のスタートアップで Rails が標準採用された影響は大きい。Twitter(初期)、Shopify、Hulu、Airbnb(初期)、GitHub、Square、Basecamp 自身、Heroku — 2005–2010 年に立ち上がったメジャー Web プロダクトの相当部分が Rails で書かれた。

中心人物 / 組織

DHH(David Heinemeier Hansson)

37signals(現 Basecamp)

The Pragmatic Programmers(Pragmatic Bookshelf)

Apple

何を変えたか(影響)

Rails が変えたのは Ruby の世界だけではない。

テーゼの再確認

「Rails が Rails たりえたのは、機能性というよりあの時代にいけてる言語で基準を大きく超えて利便性を提供できたから」

この命題は概ね支持できる。ただし精度を上げるなら:

つまり Rails の成功は 言語選択 × 思想設計 × 時代潮流の三項の積 であって、どれか一つで説明できるものではない。

押さえどころ(カード化候補)

Graph