http://www.martinfowler.com/bliki/EnterpriseRails.html

Railsのコミュニティでは「エンタープライズ」という言葉がダーティーワードになりつつある。 多くの人にとってRailsフレームワークとは、貪欲にシンプルさを備えたものであり、複雑になり過ぎた「エンタープライジー」なフレームワークへのアンチテーゼなのだ。

先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。 その中にはエンタープライジーなことも含まれていた。 たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。

これに対するDHHの反応は、この上なく痛烈な拒絶であった。Wired誌(訳注：Linux Journal誌だと思われ。)の表紙になった画像をうまく編集して、DHHは自らをソフトウェア界のネオ（救世主）としてプロジェクタに映し出した。 それは、彼のいる場所が「より良い場所」だということを強烈に宣言するものであり、 エンタープライズ界に対して「こちら側へ来い」と声明するものであった。 これを複合キーの話に当てはめると、返答は「嫌だ」となる。 Railsは為すべきことを為す。 嫌いなものをサポートして複雑になるようなことはしない。

Railsを「”こだわりのある”ソフトウェア（opinionated software）」たらしめている顕著な例がある。 Railsのマインドセットには「テーブルをオブジェクトと同一構造にし、プライマリーキーにはinteger型のサロゲートキーを設定しておけば、かなり楽になる」というものがある。 Rails道を進めば、ライフ・イズ・イージー。 Rails道を進まないのであれば、別のものを使えばいい。

正直、私はこの頑なな姿勢が気に入っている。 多くの異なった事をする一つの複雑なツールよりも、一つの事を上手くこなす沢山のツールを使おうとするUnix文化のバックグラウンドが、私に備わっていることと関係しているのかもしれない。 とある部類のアプリケーションのみを取り上げて、それを巧みに提供する。 このRailsの目の付け所が気に入っている。

その意味で私は、DHHとKent Beckとの間に驚くべき類似点を感じている。 彼らに制約のある世界を見せれば、その制約を調べ、不必要と見なし、その制約のない新しい世界を創造するだろう。 私にはその能力がない。制約のあるなかで、制約を排除しながら、どうにかこうにかやっていくだろう。 だが彼らは、「知的ダイナマイト」を突っ込んで、走り去っていく。 だからこそ、Extreme ProgrammingやRailsを作り出し、業界を震撼させることができるのだ。

PragDaveの講演は、さらに深いものだった。 彼は、私のようにダイナマイトを扱えない普通の人と多くの時間を過ごしてきた。 データ管理グループが運営するデータベースからデータを引き出さなければならないとしたら、しかもそのデータベースが10年間ずっと複合キーで運用されてきたとしたら、ネオのようにクールなサングラスを身に着けることも、制約をダイナマイトで吹き飛ばすこともできないだろう。 これに対するひとつの答えはこうだ。 「組織を変「え」るか、組織を変「わ」るかだ」。 だが、それができない人々は完全に見放されてしまうのだろうか、Rubyに。

先のパラグラフの最後の言葉が、答えの鍵となる。 「Rails」がエンタープライジーな世界を相手にしないのは、私は正しいと思う。 だがこれは、「Ruby」がそうだということではない。 Rubyのようなスクリプト言語の強みは、混沌としたソフトウェアエコシステムの海にダイブできるポストモダンな楽しみである。 Railsの”こだわり”に遅れをとった他のフレームワークにとって、Rubyはその差を埋めるのに相応しい言語である。

同僚のBadriが、まさにこういう話をしていた（残念ながら私は聞くことができなかったのだが）——rBatisについてだ。 rBatisは、JavaのフレームワークであるiBatis（同僚のClinton Begin他によって開発されている）をRubyにポートしたものだ。 ポートは同僚のJon Tirsenによって行われている。 rBatisはまだ開発中の段階だが、iBatisがポピュラーになった機能——SQLをQuery Objectレイヤーの裏に隠すのではなく、恐れずにSQLの強みを包括している——については、すでに実装されている。 大部分をRubyで構築したことにより、さらに強みが増している。 Active Recordからいくつかの機能（バリデーションなど）を拝借し、XMLではなく便利なRubyの構文を使用している（XMLはプログラム言語のせむし男ではないだろうか？）。 rBatisは、Railsと統合しつつも、複雑なデータベース問題に何らかの答えを出すだろう。 ただし、現行のRailsとは異なるトレードオフを提示することになるだろう。 SQLを扱うのが苦ではないなら、rBatisは非常にシンプルだ。 （ところで、シドニーにRubyistはいる？ Jonのサーフボードを取り上げて欲しいんだ。 rBatisの開発が進まないからね。）

そういう意味で言うと、「エンタープライズRails」という言葉は矛盾語法かもしれない。 しかし、「エンタープライズRuby」はそうではない。 エンタープライズ界が動いている様を見ているからこそ、そう言えるのだ。 エンタープライズ界は、メッセージングの利用、アプリケーションデータベースを持つ自律型サービス、ポストモダンな多様性の受容、の方向に動いている。 つまり、型に嵌めないグルー（糊）のようなツールが理想となっている。

以上の話から、David達Rails開発者の登場前後に断層があるのではないかと受け取る人もいた。 だが、会話を続けていくうちに、そういった断層はなく、ただの誤解だということが分かった（断層のメタファは打ち壊された）。 PragDaveが必要だと言ったのは、Railsがサポートする必要があるという意味ではなく、もっと広いコミュニティに対して、何らかの手段を見つけて欲しいというものだった。 同様にDHHの返答も、Railsコアチームに限定したことであった。 rBatisのデモンストレーターのような、コアチーム以外の人の成果まで制限することはできない。 DHHは、PragDaveの要望はコアチームの要望とも一致していると考えていた。 狭いRails（コア）と広いRubyの世界（そこにRailsも含まれる）という考え方は、どちらにもあてはまる。 これは小さなツールを構成する強みである。

しかし、この広いRuby／狭いRailsという見方には問題がある。 私はキーノートのなかでこんなジョークを言った。 「RailsConfはRailsの失敗を示している。なぜなら、本当にRailsが成功していれば、カンファレンスが必要ではないほどシンプルなはずだからだ」。 これは、RubyでWebアプリケーションといえばRailsになったという事実があるからだ。エンタープライズアプリケーションでもRailsかもしれない。 RailsConfにはRubyConfよりも多くのエンタープライジーな人間が参加しているのではないだろうか。 Railsがそれほど注目を集めているからだ。 そのため、Railsのこだわりの特性が、Ruby自体の声明だと受け取られてしまう危険性がある。 これではRubyはエンタープライズのグルーには適していないと受け止められてしまうかもしれない。 それは残念なことだ。