Rubyでアジャイルプロトタイピング（3）
アジャイルプロトタイピングとRuby on Rails

永和システムマネジメント鍜治舍浩
永和システムマネジメント西川仁
アークピア林秀一
2006/1/18

1｜2｜次のページ

　本記事はRuby on Rails（以下RoR）を使ってプロトタイプを作成し、アジャイルかつ正確にクライアントからの機能要件を取りまとめることを提案する連載「Rubyでアジャイルプロトタイピング」の第3回です。今回は、アジャイルプロトタイピングを可能とするWebアプリケーションフレームワークであるRoRについて解説します。RoRは、洗練された習得が容易なフレームワークですが、本記事の分量だけでは、RoRを用いた実装ができるようになるほど詳細な解説は行えません。代わりに、RoRの基本的な紹介と、アジャイルプロトタイピングに寄与する特徴にポイントを絞って解説します。

◆ アジャイルプロトタイピングの性質

　アジャイルプロトタイピングでは、顧客からのフィードバックを頻繁に受けるために、詳細な内容のデモを何度も行い、プロトタイプに対する試行錯誤的な変更を繰り返します。この際、プロトタイプに対して次にどのような変更を行うかは、顧客や開発者が持つ知識や経験を基に発想され、決定されます。つまり仕様策定や、設計に関する知見を獲得するためのアジャイルプロトタイピングは、本質的にクリエイティブな活動なのです。そして、顧客と開発者のクリエイティビティをどこまで引き出せるかが、アジャイルプロトタイピングを成功させるための鍵となります。

◆ 既存のアプローチでの実現は難しい

　アジャイルプロトタイピングを、Javaなどの既存のアプローチで行おうとした場合を考えてみます。

図1 既存アプローチでのPDSサイクル

　アプリケーションを開発するとき、開発者は上図のようなサイクルを繰り返します。矢印の上に書かれた作業は、開発において本質的な作業ではありません。しかしながら、特にDoからSeeに向かう過程では、コードを1行修正するだけでも、かなりの手間が必要になります。テストで発見されたバグの修正結果を確認するために、1回に10分以上かかるデプロイを1日に何度も繰り返すような経験を持っている方も、筆者だけではないのではないでしょうか。

　これらの付帯的な作業は、採用している開発言語、開発環境、アプリケーションサーバ、フレームワーク、ライブラリなどからもたらされています（以下では便宜上、これらを総称して「ツール」と呼ぶことにします）。これらの作業が必要な背景には、それぞれのツールが下表のような問題を解決することにフォーカスしていることが挙げられます。

既存のツール	フォーカスしている問題	新たな問題
アプリケーションサーバ	スケーラビリティ 可用性 各種機能の抽象化	煩雑な設定ファイルの記述 デプロイの必要性
DIコンテナ XMLベースのO-Rマッパー	テスタビリティ 再利用性 変更容易性	煩雑な設定ファイルの記述
コンパイラ	実行速度（*インタプリタと比較する観点から考えています）	ビルド、デプロイの必要性
表 ツールがフォーカスしている問題

◆ 最も重要な問題は何か

　 多くの開発者が、質の高いソフトウェアを生み出すためには、上の表にまとめたような問題解決手段を持つ、優れたプロダクトやプロセスを採用することが重要だと考えています。しかし同時に、人間1人1人と、人間同士で組織される顧客も含めたチームの能力を最大限に引き出すことこそが、さらに根本的な重要事項であるということにも気付き始めています。この観点に立つと、既存のツールからもたらされる問題は、軽視すべきものではないことが分かってきます。ビジネス界の著名な思想家である故P. F. ドラッカー氏は、知識労働者の生産性を高めるのは、スキル、プロダクト、固定化されたプロセスといった生産手段ではないと述べています。同氏は、いかに賢く働くことができるかが、生産性を高める唯一の手段であると提言しています［注1］。

［注1］「プロフェッショナルの条件」

　また、リーンソフトウェア開発の著者であるポッペンディーク夫妻は、開発者の思考停止時間や、コンテキストスイッチ時間（頭の切り替え時間）といったムダを排除することが重要［注2］であると述べています。これらのムダを排除し、より賢く働くことを可能として、開発者とチームのクリエイティビティを最大化するアジャイルプロトタイピングツール、これこそがRoRです。RoRは、後述する2つの哲学を自身の各機能で徹底することによって、ムダを排除しています。

［注2］「リーンソフトウェア開発」（メアリー・ポッペンディーク、トム・ポッペンディーク）

◆ RoRとは

　ここで、RoRに関する一般的な情報を少しお伝えしておきます。RoRのWebページに記述された紹介文を筆者なりに翻訳してみます。

　RoRは、プログラマの幸福と継続的な生産性のために最適化された、オープンソースのWebフレームワークです。Convention over Configuration（訳注：後述します）の恩恵により、ムダのない美しいコードを書くことが可能となります。

　RoRはMVC型のフレームワークです。MVCアーキテクチャに慣れた開発者であれば、容易に理解できるでしょう。

・百聞は一見にしかず

　RoRの生産性の高さは、目を見張るものがあります。わずか15分間でブログエンジンを作るデモが公開されています。

・注目度

　RoRの開発者であるDavid Heinemeire Hansson氏（通称DHH）は、RoRを開発した功績が評価され、Google、O’Reillyの両社が主催するオープンソース・アワードで、 2005年のベストハッカー・オブ・ジ・イヤーを受賞しています［注3］。また、ソフトウェア業界における、多数の著名人がRoRについて肯定的な（もしくは絶賛する）コメントを出しています。例えば、書籍「達人プログラマー」で有名なDavid Thomas氏のコメント［注4］が紹介されています［注5］。RoRについてのコメントに共通することは、RoRの生産性、哲学の有効性、洗練度がこれまでのWebフレームワークになかったほど高い、ということです。RoRは、Webシステム開発における、次のメインストリームの1つとなるでしょう。

［注3］WikipediaのDavid Heinemeire Hansson氏の解説

［注4］ 高橋征義（日本Rubyの会）、Lightweight Language Day & Night2005 フレームワーク対決資料

［注5］「達人プログラマー」（David Thomas、Andrew Hunt）

◆ RoRの根底にある哲学

　RoRの一般的な情報については、ご理解いただけたと思います。次に、ムダを排除し、生産性とクリエイティビティを向上させることを可能とする、RoRの哲学を説明します。

・DRY

　DRYは、David Thomas、Andrew Hunt両氏によって紹介された［注4］原則です。Don’t Repeat Yourself、つまり「重複を排除する」「同じ作業を繰り返さない」という意味です。従来のWebアプリケーションフレームワークでは、毎回お決まりのコードを書かなければならない場合が数多くあります。特にプロジェクトの初期までは、一度は行ったことがあるようなアプリケーションのひな型作りを繰り返してしまいがちです。また、前回「Ruby超入門」の記事で解説した、クラス名を修正した際に、設定ファイルまで修正しなければならない、というような状況もそれに当たります。RoRは、このような重複のムダを極力排除しています。ある情報に対するコードが1カ所にあれば、開発スピードは上がり、変更にも強くなることは明白です

・Convention over Configuration

　先にも述べたように、 最近のフレームワークは、XML形式の設定ファイルを大量に作成することを強いる傾向があります。これらのプロダクトが提供するメリットは確かにありますが、アプリケーションの大部分を占める、いわゆる「一般的な作り」の部分1つ1つについても、いちいち設定を書かなければなりません。

　RoRは、開発者によって設定を指示されなかった場合のデフォルトの挙動を、Convention over Configuration、「設定に勝る規約」として定めています。これらの規約には、先人の知恵であるベストプラクティスやパターンが適用され、アプリケーションの多くの局面で有効なように吟味、洗練されています。この規約のおかげで不要な設定ファイルの準備や、重複したコードの記述が自然に、かつ大幅に抑制されます。

1/2

INDEX
Rubyでアジャイルプロトタイピング（3） アジャイルプロトタイピングとRuby on Rails
	Page1 ◆ アジャイルプロトタイピングの性質
	Page2 ◆ アジャイルプロトタイピングを実現するRoR

IT Architect 連載記事一覧