書籍転載：Ruby on Rails 4アプリケーションプログラミング
Railsというフレームワーク
一般的なフレームワークについて触れた後、Railsの特徴、具体的な機能について概説。書籍転載の1本目（「第1章 イントロダクション」より）。
書籍転載について
ご注意
本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどはBuild Insiderのそれとは一致しません。あらかじめご了承ください。
本書のテーマであるRuby on Railsは、Ruby言語で記述された、そして、Ruby環境で動作するWebアプリケーションフレームワークの一種です。
本章では、まず手始めに一般的なフレームワークについて触れた後、Railsの特徴、具体的な機能について概説します。また、後半ではRailsの学習を進めるにあたって、最低限必要となる環境の構築手順について解説します。
1.1 Railsというフレームワーク
なにかしら困難な課題に遭遇した時、みなさんであればどうするでしょうか。問題を整理し、解決に向けて一から取り組む？ そのようなアプローチも、もちろんあるでしょう。しかし、それはあまり効率的な方法とは言えません。
というのも、ほとんどの問題にはなにかしらよく似た先例と、先人による解決策があるからです。そして、それら先人の知恵を利用することで、（問題のすべてを解決できるわけではないにせよ）問題はよりスムーズに、かつ、取りこぼしなく解決できます。
このような先人の知恵は、最初は「事例」などと呼ばれることもありますが、より類型化し、整理＆蓄積されることでフレームワークと呼ばれるようになります。フレームワークとは、問題をより一般化し、解決のための定石をまとめた枠組み（Framework）であると言っても良いでしょう。
たとえば、経営のためのフレームワークと言ったら、自社の現状分析や進むべき方向性の分析、業界における収益構造の解析に対する指針、方法論を意味します。
業界の構造を5つの競争要因に分けて分析するファイブフォース分析や、内的要因／外的要因から企業の現状分析を試みるSWOT分析などが有名です*1。
- *1 詳しくは『不況を生き抜く「戦略立案」の基礎』のような記事が参考になります。
フレームワークとは、数学で言うところの公式のようなものなのです。ただし、数学と異なるところは解答が常にひとつであるとは限らないという点です。利用するフレームワークによっては得られる解答（結論）も異なる可能性がありますし、そもそも状況や周辺環境によって、フレームワークは使い分けるべきものです。
1.1.1 アプリケーションフレームワークとは
アプリケーションフレームワークもまた、そうしたフレームワークの一種です。アプリケーションを開発するにも、当然、こうあるべきという設計面での思想（方法論）があります。アプリケーションフレームワークでは、そうした方法論を「再利用可能なクラス」という形で提供しているのが一般的です。
アプリケーション開発者は、アプリケーションフレームワークが提供する基盤に沿って独自のコードを加えていくことで、自然と一定の品質を持ったアプリケーションを作り上げることができます。アプリケーションフレームワークとは、アプリケーションのコードを相互につなげるベース――パソコン部品で言うならば、マザーボードの部分に相当するものなのです（図1-1）。
もっとも、「再利用可能なクラス」というと、定型的な機能を集めたライブラリと何が違うのか、混同してしまいそうです。実際、両者はよく似ており、広義にはライブラリも含めてアプリケーションフレームワークなどと呼んでしまうこともあるため、ますますわかりにくいのですが、厳密には両者は異なるものです。
その違いは、プログラマが記述したコード（ユーザコード）との関係を比較してみると明らかです（図1-2）。
まず、ライブラリはユーザコードから呼び出されるべきものです。ライブラリが自発的になにかをすることはありません。文字列操作のライブラリ、メール送信のライブラリ、ロギングのためのライブラリ…いずれにしても、ユーザコードからの指示を受けて初めて、ライブラリはなんらかの処理を行います。
一方、アプリケーションフレームワークの世界では、ユーザコードがアプリケーションフレームワークによって呼び出されます。アプリケーションフレームワークがアプリケーションのライフサイクル――初期化から実処理、終了までの流れを管理していますので、その要所要所で「なにをすべきか」をユーザコードに問い合わせるわけです。そこでは、ユーザコードはもはやアプリケーションの管理者ではなく、アプリケーションフレームワークの要求に従うだけの歯車にすぎません。
このように、プログラム実行の主体が逆転する性質のことを制御の反転（IoC：Inversion of Control）と言います。制御の反転こそが、フレームワークの本質であると言っても良いでしょう。
Railsは、こうしたアプリケーションフレームワークの中でも、特にWebアプリケーションを開発するためのWebアプリケーションフレームワーク（WAF）です*2。本書でも以降、単に「フレームワーク」と言った場合にはWAFのことを指すものとします。
- *2 アプリケーションフレームワークも用途に応じてさまざまなものがあります。デスクトップアプリケーションを開発するならばデスクトップGUIフレームワーク、Webサービスを開発するならばWebサービスフレームワーク、というように、フレームワークはそれぞれに専門領域を持っています。
1.1.2 フレームワーク導入の利点
フレームワークを導入することには、以下のような利点があります。
1 開発生産性の向上
アプリケーションの根幹となる設計方針や基盤部分のコードをフレームワークに委ねられるので、開発生産性は大幅に向上します。また、すべての開発者が同じ枠組み（ルール）の中で作業することを強制されるので、コードの一貫性を維持しやすく、その結果として品質を均質化できるというメリットもあります。
ユーザコード（固有のロジック）は相互に独立しているので、機能単位に役割分担をしやすく、たくさんの人間が関わるプロジェクト開発にも適しているでしょう。
2 メンテナンス性に優れる
コードに一貫性があるということは、アプリケーションの可読性が向上するということでもあり、これは問題が生じた場合や仕様に変更があった場合に該当箇所を特定しやすいという利点にもつながります。
もっと広い視点で考えれば、同一のアーキテクチャが採用されていれば、後々のアプリケーション統合も容易になる、開発ノウハウを後の開発／保守にも援用できる、というメリットも考えられるでしょう。
3 先端の技術
トレンドにも対応しやすい言うまでもなく、昨今の技術変動は敏速であり、一般的な開発者にとって日々キャッチアップしていくのは難しいものです。しかし、フレームワークはそうした技術トレンドを日夜取り入れており、フレームワークの活用によって先端技術にも即応しやすいというメリットがあります。
たとえば、昨今ではセキュリティ維持に対する要求はより一層高まっていますが、多くのフレームワークは積極的にその対応にも取り組んでおり、開発者の負担を軽減してくれます。
4 一定以上の品質が期待できる
これはフレームワークに限った話ではありませんが、一般に公開されているフレームワークが自作のアプリケーションよりも優れるもうひとつのポイントとして、「信頼性が高い」という点が挙げられます。オープンソースで公開されているフレームワークは、さまざまなアプリケーションでの利用実績もさることながら、内部的なソースコードも含めて多くの人間の目に晒され、テストされています。自分や限られた一部の人間の目しか通していないコードに較べれば、相対的に高い信頼性を期待できます*3。
- *3 もちろん、すべてのオープンソースソフトウェアが、というわけではありません。きちんと保守されているものであるのかどうかという点は、自分自身で見極めなければなりません。
フレームワークを導入するということは、現在のベストプラクティスを導入するということでもあるのです。今日のアプリケーション開発では、もはやフレームワークなしの開発は考えにくいものとなっています。
【NOTE】フレームワーク導入のデメリット
もっとも、フレームワーク導入は良いことばかりではありません。フレームワークとは、言うなればルール（制約）の集合です。ルールを理解するにはそれなりの学習時間が必要となります。特に、慣れない最初のうちはフレームワークの制約がむしろ窮屈に感じることもあるでしょう。デメリットがメリットを上回るような「使い捨て」のアプリケーションや、小規模なその場限りの開発では、必ずしもフレームワーク導入に拘るべきではありません。
1.1.3 Rubyで利用可能なフレームワーク
さて、本書で扱うRuby on Rails（以降Rails）は、Ruby環境*4で利用できる代表的なフレームワークです。
- *4 Rubyは、まつもとゆきひろ氏が開発した国産のオブジェクト指向言語です。
しかし、Ruby環境で利用できる唯一のフレームワークというわけではありません。Rubyでは、実にさまざまなフレームワークが提供されています（表1-1）。
| 名称 | 概要 |
|---|---|
| Ruby on Rails | 本書で解説 |
| Sinatra | DSL（ドメイン固有言語*5）を利用して、簡潔にアプリケーションを記述することを目的としたフレームワーク |
| Ramaze | シンプルさとモジュール化を旨とし、ライブラリ選択の自由度の高さが特長 |
| Padrino | Sinatraをベースに、ヘルパーやジェネレータ、国際化対応などの機能を加えたフレームワーク |
| Pakyow | ビューファーストで、シンプルさを旨としたフレームワーク |
| Halcyon | SOA（サービス指向アーキテクチャ）アプリケーションの作成を主目的とした、JSONベースのフレームワーク |
- *5 特定用途のために設計された言語のことを言います。たとえばデータベース問い合わせ言語であるSQLもDSLの一種です。
本書では、これらさまざまなフレームワークの中で、もっとも知名度が高く、機能性や資料の充実度、実績といった面でも申し分ないRailsを採用しています。
Railsの特徴としては、以下のような点が挙げられます。
1 Model-View-Controllerパターンを採用
Railsは、MVCパターン（Model - View - Controllerパターン）と呼ばれるアーキテクチャを採用しています。MVCパターンとは、一言で言うならば、アプリケーションをModel（ビジネスロジック）、View（ユーザインターフェイス）、Controller（ModelとViewの制御）という役割で明確に分離しよう、という設計モデルです。図1-3はMVCパターンの典型的な処理の流れであると共に、Railsの基本的な挙動を表すものでもありますので、まずは大まかな流れを理解しておきましょう。
それぞれの構成要素が明確に分かれていることから、MVCパターンには以下のようなメリットがあります。
- プログラマとデザイナとで並行作業を行いやすい
- デザインとロジックのそれぞれの修正が相互に影響しない（保守が容易）
- 機能単位のテストを独立して実施できる（テストを自動化しやすい）
もっとも、MVCパターンはなにもRails固有の概念というわけではありません。むしろWebの世界ではMVCパターンを前提とした開発がごく一般的です。おそらくJavaやPHP、Perl、Pythonなどでフレームワークを使って開発したことがある方ならば、MVCパターンはごく親しみやすいものであるはずです。逆に言えば、Railsを学んでおけば、その知識はそのまま他のフレームワークの理解にも役立つということでもあります。
2 Railsはアプリケーション開発のレールを提供する
Railsというフレームワークを語る際に、よく言及されるのがRailsの初期バージョンから継続して貫かれている以下の設計哲学です。
- DRY（Don't Repeat Yourself）＝同じ記述を繰り返さない
- CoC（Convention over Configuration）＝設定よりも規約
Railsはソースコードの中で同じような処理や定義を繰り返し記述するのを極度に嫌います。たとえば、Railsではデータベースのスキーマ定義を設定ファイルとして記述する必要はありません。データベースにテーブルを作成するだけで、あとはRailsが自動的に認識してくれるのです。DRY原則の典型的な例と言えるでしょう。
そして、DRY原則を支えるのがCoC原則です。Convention（規約）とは、もっと具体的に言えば、Railsがあらかじめ用意している名前付けのルールです。たとえば、usersテーブルを読み込むためにはUserという名前のクラスを利用します。互いに関連付けの設定が必要ないのは、users（複数形）とUser（単数形）がRailsの規約によって結び付けられているためです。
RailsではDRYとCoCの原則が隅々まで行きわたっていることで、開発者が余計な手間暇をかけることなく、保守しやすいアプリケーションを手軽に開発できます。
もっと言えば、Railsとはこうした設計理念でもって利用者をあるべき姿に導くフレームワークでもあるのです（それこそがレールと命名された所以でしょう）。
Railsの基本哲学は、その後登場した多くのフレームワークにも強く影響を与えており*6、Railsの名を一層世に知らしめるものとなっています。
- *6 Rubyの世界だけではありません。PerlのCatalyst、PHPのSymfonyやCakePHP、.NETのASP.NET MVCなどなど、環境を問わず、さまざまなフレームワークにRailsの影響が見て取れます。
3 フルスタックのフレームワークである
Railsは、アプリケーション開発のためのライブラリはもちろん、コード生成のためのツールや動作確認のためのサーバなどをひとまとめにしたフルスタック（全部入り）なフレームワークです。つまり、Railsひとつをインストールするだけでアプリケーション開発に必要な環境はすべて揃いますので、環境の準備に手間暇がかかりません。また、ライブラリ同士の相性やバージョン間の不整合などを意識することなく、開発を進めることができます。
図1-4に、Railsに含まれるコンポーネント（ライブラリ）をまとめておきます。
| Rails | |
|---|---|
| ├─ Action Pack | …… Action Controller ／ Action Dispatch ／ Action Viewの総称（MVCのVC） |
| │ ├Action Controller | …… Controllerの管理。リクエスト処理、状態管理、レスポンスの生成などを司る（第6章） |
| │ ├Action View | …… HTMLやXML、JSONなど各種フォーマットでのレスポンスを生成。View開発に役立つヘルパーやレイアウト機能を提供（第4章）。Ajaxにも対応（9.5節＝※転載対象外） |
| │ └Action Dispatch | …… リクエストをどのクラスで処理するかを決定するルーティング機能を提供（第7章） |
| ├─ Active Model | …… 命名規則、検証機能など、Modelの基本的な規約を定義（第5章） |
| ├─ Active Record | …… データベースアクセスのための基本機能を提供（第5章） |
| ├─ Action Mailer | …… メールの送受信を管理するライブラリ（10.1節＝※転載対象外） |
| ├─ Active Support | …… Ruby標準ライブラリの拡張（本書では割愛） |
| └─ Railties | …… Railsの各種コンポーネントやプラグインを繋ぎ合わせるRailsのコア |
※上記の第4／5／6／7章の該当箇所は、今回の転載対象外です
Rails 2まではこれらのコンポーネントが密結合しており、いわゆる「一枚岩」のフレームワークでした。つまり、Rails本来のコンポーネント以外を組み込もうとした場合には、相当の労力が必要でした。
しかし、Rails 3以降ではModularity（モジュール志向）を強く意識しています。つまり、標準コンポーネントは依然として提供されますが、必要に応じて、より目的に合ったコンポーネントへの差し替えを簡単に行えます。
バージョン3以降のRailsはRails 2のレールを引き継ぎながらも、より柔軟に多様なレールの存在を許容するフレームワークへと進化しているのです。
4 最新の技術トレンドにいち早く対応
Rails 4は、昨今のさまざまな技術トレンドに対応しています。代表的なものは以下の3つです。
- HTML5対応
- 控えめなJavaScript
- RESTfulなインターフェイス
HTML5は、言わずと知れたHTMLの次期バージョンです。本書執筆時点では正式勧告には至っていませんが、既に多くのブラウザが先行して主要な機能を実装していることからも、期待の高さが窺い知れます。Rails 4でもScaffolding機能*7がHTML5対応のマークアップを出力したり、ビューヘルパー*8がHTML5のタグにも対応していたりするなど、来るべきHTML5時代の開発への対応が進んでいます。
- *7 自動的にアプリケーションの基本コードを生成する機能。第3章（※転載対象外）で詳述します。
- *8 Action Viewが提供しているタグ生成のためのユーティリティメソッド。第4章（※転載対象外）で詳述します。
控えめなJavaScript（Unobtrusive JavaScript）とは、昨今のJavaScriptのトレンドで、HTMLの中にJavaScriptのコードを混在させるべきでない（＝ JavaScriptが出しゃばるべきでない）という思想のことです。HTMLの中に混在したJavaScriptはコードの可読性や保守性を落としますし、なにより潜在的なバグの原因にもなりますので、できるだけ明確に分離しようというのです。Rails 2までは、特にAjax*9周りの機能で自動生成されるコードが複雑なJavaScriptを含んでいましたが、Rails 3以降ではJavaScriptが外部ライブラリに分離され、HTML側には最低限のパラメータ情報のみを残すという措置が取られています。
- *9 JavaScriptを利用してリッチなユーザインターフェイスを構築する技術の総称です。9.5節（※転載対象外です）で後述します。
そして、RESTfulなインターフェイス、これはネットワーク上のコンテンツ（リソース）をすべて一意なURLで表現し、リソースに対するCRUD操作*10はすべてHTTPメソッドで表現する考え方のことを言います（詳しくは第7章（※転載対象外）で解説します）。RESTfulインターフェイスを利用することで、より統一感のある、かつ、意味がつかみやすいURLを設計できます。RESTfulインターフェイスのサポートはRails 2からの路線ですが、Rails 4ではそれがより一層推し進められています。
- *10 Create（作成）、Read（取得）、Update（更新）、Delete（削除）の意味です。
■
次回は「1.2 Railsを利用するための環境設定」を説明します。
※以下では、本稿の前後を合わせて5回分（第1回～第5回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
1. 【現在、表示中】≫ Railsというフレームワーク
一般的なフレームワークについて触れた後、Railsの特徴、具体的な機能について概説。書籍転載の1本目（「第1章 イントロダクション」より）。
2. Railsを利用するための環境設定
Railsプログラミングに必要なソフトウェアを紹介。WindowsおよびLinuxにおける環境設定の手順や、SQLite／DevKit／Node.js／Railsのインストール方法を説明する。書籍転載の2本目（「第1章 イントロダクション」より）。
3. Ruby on Rails 4アプリケーションの作成
環境が整ったら、いよいよアプリ作成を始めよう。スケルトンコードの生成から、Webサーバー上で実際にRailsアプリを動かすところまでを説明。
