Ruby on Rails とは

Ruby on Rails の普及段階は？

Web エンジニアの間で、Ruby on Rails (ルビー・オン・レイルズ) あるいは省略形の Rails (レイルズ)という言葉が知られるようになったのは、2006年のことです。

この年、かなりの数の解説書が日本で出版され、ちょっとしたブームのようになりました。

その後、一時の熱狂は去り、Rails への関心も落ち着きを取り戻したようです。

ハイプサイクル (hype cicle)という言葉をご存じでしょうか。新技術が現れて普及するまでに、世の中の期待あるいは関心が変化する様子を示す図のことです。

@ITの情報マネジメント用語辞典「ハイプサイクル」によれば、それは5つの段階を経て変化します。

1. 黎明期: 技術の引き金
2. 流行期: 過剰期待の頂(いただき)
3. 反動期: 幻滅のくぼ地
4. 回復期: 啓蒙の坂
5. 安定期: 生産性の台地

要するに、新技術が現れると過度の期待が高まり、世の中は幻滅する。しかし、その後、新技術の正しい使い方が知られるようになって、本格的な導入・採用が行われるようになる、ということです。

また、新技術の普及に関してはキャズム (chasm)という概念もあります。

「深い溝」という意味の英単語ですが、同じく@ITの情報マネジメント用語辞典「キャズム」によれば、それは「初期市場からメインストリーム市場への移行を阻害する深い溝」を指します。

キャズム理論では、新技術の顧客(採用者)は、5つの類型に分類されます。

1. イノベーター: とにかく新しい技術が大好きな人
2. アーリーアダプター: 新技術で競争相手を出し抜きたい人
3. アーリーマジョリティ: 新技術が役に立つなら進んで使う人
4. レイトマジョリティ: みんなが使っているなら仕方なく新しい技術を使う人
5. ラガード: 新しい技術を嫌う人

新技術は 1 から 5 の順に受容されていくが、実は 2 と 3 の間に深い溝が存在し、新技術の多くはそれを越えられない、とキャズム理論は主張しています。

アーリーアダプター(2)は、新技術に関する試行錯誤を厭いません。他方、アーリーマジョリティ(3)は、未熟な技術によって振り回されるのを嫌います。

どちらも新技術導入による生産性向上には貪欲ですが、その違いはとても大きいのです。

キャズムを越えられなかった新技術は、ハイプサイクルの「反動期」を経て、そのまま消えていきます。

さて、2008年末現在、Ruby on Rails はどの段階にあるのでしょうか。果たして、Rails はキャズムを越えたのでしょうか？

Ruby on Rails 専門のコンサルティング会社である当社としては、越えたと信じたいところですが、正直なところを言えば、「越えつつある」という控えめな表現がふさわしいと考えています。

Rails は企業が内部で利用するものですから、どのくらい採用が進んでいるのか、その情報はなかなか表に出てきません。

オープンソースソフトウェアですので、売り上げの統計もありません。

コンサルティングやセミナーを通じて聞き取った限りでは、アーリーマジョリティに属すると思われる企業が少しずつ使い始めた、という印象を私自身は持っています。

Ruby と Ruby on Rails の違い

エンジニアでない方とお話ししていると、Ruby と Ruby on Rails を混同している場合があります。

まずは、この点から始めましょう。

Ruby (ルビー) は、プログラミング言語です。Fortran, COBOL, BASIC, C, Perl, Java, PHP 等の仲間です。

「言語」ですから、それ自体はソフトウェアではありません。日本語や英語と同じように、文法と語彙があるだけです。

Ruby で書いたプログラム（ソースコード）を、「Ruby インタープリタ」と呼ばれるソフトウェアで読み込むと、アプリケーションとして実行できます。

Ruby on Rails は、フレームワーク(framework)です。

直訳すれば「枠組み」となりますが、ソフトウェアの世界では特別な意味を持ちます。

それは、ある分野のソフトウェアを効率的に開発するために揃えられたライブラリとツールの一揃い、を指します。

ライブラリは「部品」と言い換えてもいいでしょう。

ツールは、その部品を変形したり、組み立てたりするためのプログラムです。

Ruby on Rails は、Web アプリケーションという種類のソフトウェアを作るための基本的な部品と道具をまとめたものなのです。

Ruby on Rails は単なるソフトウェア開発キットではない

フレームワークに類似した言葉としては「ソフトウェア開発キット（SDK）」もあります。

実は、フレームワークの構成要件は、もう一つあります。

それが、アーキテクチャです。

建築用語では「建築様式」や「構造」を表しますが、コンピュータ用語では「基本設計概念」を意味します。

ソフトウェアの開発方法には常に改良が加えられています。

時々、革新的な開発方法を思いつく人がいて、その人の考えはアーキテクチャとしてまとめられます。

新しいアーキテクチャに従ってソフトウェアを作るには、新しい部品や道具が必要になります。

それらをまとめると、フレームワークになります。

単なる部品と道具の集合ではありません。その背後には、アーキテクチャという名前の新しい思想が存在するのです。

アーキテクチャというと何だか難しいようですが、「工法」と言い換えることも可能です。

建築の世界でも、「ツーバイフォー」とか「鉄骨プレハブ」とか様々な工法がありますね。

Ruby on Rails は、21世紀になって生まれた新しい工法で Web アプリケーションを作るためのフレームワークなのです。

制約による大胆な単純化

では、Ruby on Rails の何が新しいのでしょうか。

Ruby on Rails の考案者は、Web 開発にいくつかの制約を設けると物事が非常に単純化されることに気付きました。

たとえば、データベースのテーブル（表）の名前には英単語の複数形（例えば、companies）を使う、という約束事を設けました。

そして、/companies という URL で会社の一覧を表示し、/companies/99 という URL で ID が 99 番である会社の情報を表示することにしました。

何でもないことのようですが、重要な発想の転換でした。

従来は、テーブルの命名法も URL の形式も自由放任でしたので、エンジニアが何から何まで決定しなくてはなりませんでした。 また、その決定事項はアプリケーションの設定ファイルに記述する必要がありました。

しかし、Web アプリケーション開発の大部分は決まり切ったやり方で行われるものです。

テーブルの名前も URL の形式も、ほとんどの場合、機械的に決めることができます。

それは定型業務なのです。

問題は、そのやり方が開発業者ごとに異なることです。

フレームワークがルールを決めてしまうと、エンジニアはそれまでの習慣を捨てなければなりません。

エンジニアたちの心理的に反発を招きそうなところです。

しかし、現実には、多くのエンジニアたちが Ruby on Rails を歓迎したのです。

なぜエンジニアに受けが良かったのかは大変興味深いテーマですが、本稿の趣旨からは外れます。

重要なことは、制約を設けることは、必ずしもエンジニアを束縛することにはならない、ということです。

Ruby on Rails には、エンジニアが Rails のルールから逸脱したい場合の設定手段も用意されています。

しかし、エンジニアがその種の設定をしたくなる状況はそんなにありません。

エンジニアは Rails のルールに従うことで、様々な報酬を得ます。

第一に、設定ファイルを書かなくていいので、自分自身が楽になります。

また、他のエンジニアとのコミュニケーションも円滑になります。

Ruby on Rails の訓練を受けたエンジニアは、ある文脈において companies という英単語を見れば、それがテーブル名であることを直ちに理解します。そして、そのテーブルの情報を表示するための URL を推測することができます。

そして、多分、設計文書も短く簡潔になります。

以上のことを別の言葉で言い換えた標語が「設定より規約 (Convention over Configuration)」です。

ここで「規約」とは、Rails のルールを指します。

それは、従っても従わなくてもいい緩いルールですが、従うと良いことがあります。

Ruby on Rails は、規約の導入によって Web アプリケーション開発を大胆に単純化しました。

この単純化こそが、Ruby on Rails の本質的な新しさなのです。

直感的にデータベースを操作できる

Ruby on Rails の具体的な技術的特徴を見ていくことにしましょう。

第1に挙げたいのは、直感的にデータベースを操作できる、ということです。

従来、データベースを操作するには、SQL と呼ばれる特別な言語を使用していました。

例えば、companies テーブルから ID が 99 番であるレコードを検索するには、SQL で次のように書きます。

SELECT * FROM companies WHERE id = 99;

これが、Ruby on Rails では次のようなコードになります。

Company.find(99)

次は、複数のテーブルを結合して検索する SQL 文の例です。

SELECT * FROM employees
  INNER JOIN companies ON employees.company_id = companies.id;

Rails バージョンはこんなに短くなります。

Employee.includes(:company)

Web アプリケーションの開発で最も時間を取られるのは、おそらくデータベース関連のプログラミングです。 また、不具合やセキュリティホールが発生しやすいのもここです。

ソースコードが短くなるのは、単にキーボードの打鍵数が減る以上の意味があります。

全体の見通しが良くなり、考えがまとまりやすくなります。

ミスが減り、ミスを発見しやすくなります。

また、システムの仕様変更にも強くなります。変更箇所が減るからです。

なお、誤解なきように付け加えますと、Ruby on Rails は SQL を廃止したわけではありません。

内部的に SQL を使っていますし、プログラマー自身が SQL 文を書いてデータベースにアクセスする手段も残してあります。

ただし、Rails を使い込んでいくと、直接 SQL を利用する機会はどんどん減っていきます。

Rails が用意するデータベースアクセスライブラリ ActiveRecord は非常に強力で、おおよそ何でもできるからです。

テストの自動化で品質を上げる

次に重要な Rails の技術的特徴は、自動テストです。

アプリケーションを作ったらテストするのは当たり前ですが、伝統的なやり方は人力に頼るものでした。

試験用の Web サイトに Web ブラウザを使って実際にアクセスして、様々なリンクをクリックしたり、様々な値をフォームに記入してみて、エラーが発生しないこと、想定される結果になることを確認するという方法です。

Rails では、このプロセスを自動化できます。

本物の Web ブラウザの代わりに、テストプログラムがアプリケーションに対してあらかじめ決められた手順でアクセスし、その結果をチェックしてくれます。品質向上を図る最も確実な方法です。

この自動テストが最も威力を発揮するのは、仕様変更の時です。

Web アプリケーションに仕様変更は付きものですが、小さな仕様変更が思いがけない部分に影響を与えることがあります。

自動テストはアプリケーション全体を細かくチェックしてくれますので、修正漏れによるバグの混入を防いでくれます。

ただし、過剰な期待を抱かないでください。

自動テストを行うプログラムは、プログラマー自身が作る必要があります。

ですから、テストプログラム自体が不完全であれば、バグは見落とされてしまいます。

リソース中心主義は Web アプリケーションの寿命を延ばす

Rails 第3の技術的特徴は、URL の取り扱いです。

前述のように、データベース上に companies テーブルが存在したとき、ID が 99 であるレコードの情報を表示する URL は /companies/99 となります。

この /companies/99 という URL が指している対象をリソースと呼びます。

Ruby on Rails の世界では、Web アプリケーションを「リソースを操作する手段を提供するシステム」と捉えます。

Web アプリケーションは、ユーザーに対して様々な情報を様々な見え方で提供します。

また、情報を見せるだけでなく、入力フォーム等を通じて情報を追加したり、更新したり、削除したりする手段も提供します。

Web ブラウザで情報を表示・追加・更新・削除することを「操作」と呼びます。

そして、この操作の対象物を特に「リソース」と呼ぶのです。

話が少し抽象的になりすぎたかもしれません。

Rails のこのリソース中心主義にはどのような効用があるのでしょうか。

それは、Web アプリケーションの設計が人間にとって把握しやすいものになる、ということです。

Web アプリケーションに限らず、ソフトウェアは時間の経過とともに機能追加によって次第に複雑になっていくものです。

そして、いつの間にかエンジニアが全体を把握できなくなって、もはやメンテナンスできない状態に至ります。

リソース概念を中心に据えた設計は、そのような事態の到来を防ぐ効果があります。

要するに、Web アプリケーションの寿命を延ばしてくれるのです。

Ruby on Rails は本当に生産性を向上させるか

さて、Ruby on Rails の存在理由はずばり、高い生産性です。

同じ機能を持つ Web アプリケーションを作る場合、他の言語やフレームワークを採用するよりも少人数・短期間で完成する、ということです。

もっと分かりやすい表現で言いましょう。

Ruby on Rails でコストダウンできる、ということです。

これは本当でしょうか。

ソフトウェアの生産性は実に複雑なテーマです。

工業製品の製造過程と異なり、ソフトウェアの開発は同じ条件で繰り返し観察することができません。

例えば、同一仕様のソフトウェアを同時に2組のチームがそれぞれのフレームワークで開発して、生産性の優劣を論ずることが可能でしょうか。

可能かもしれませんが、結果の判定は微妙です。

それぞれのエンジニアの能力差が結果を大きく左右しますし、仮に能力が同程度であるとしても、エンジニアとしての経験（慣れている言語やツール）が生産性に大きな影響を与えるはずです。

ですから、ソフトウェアの生産性に関する言説は、どうしても感覚的にならざるを得ません。

ソフトウェアの生産性をめぐる果てしない戦い

とはいえ、あなたが職業としてソフトウェア産業に関わっているなら、生産性の向上というテーマから目を背けることはできません。

基本的に、ソフトウェア産業はサービスを売ることで成立しています。

エンジニアが単位時間で顧客の要求にどれだけこたえられるか、が企業競争力の源泉です。

ソフトウェアを早く完成させること、ソフトウェアの仕様変更に早く対応できることがとても大事です。

品質がよいことは大前提。

その上で早く仕上げられなければ、今の時代を生き抜くことはできないのです。

しかし、残念ながら、あなたの会社が競合他社に対して持つ生産性の優位は長く続きません。

言語やフレームワークに関する知識は瞬く間に業界に広まりますし、新しい言語やフレームワークも次々と誕生します。

同じところで足踏みしていれば、競合他社に追いつかれ、追い越されてしまいます。

生産性の向上に向かって常に努力する必要があります。

何も、新しいものにすぐに飛びつけと言っている訳ではありません。

新しいものの採用にはコストとリスクがあります。

しかし、「レイトマジョリティ」では競争に勝てないのです。

→ Ruby on Rails コンサルティング