Rails 開発者こそモデリングすべきだよなぁって唐突に思いました。Rails は DB スキーマさえ作成すれば、そのあとはレールに乗って高速に開発ができるのですが、当たり前の話 Rails は DB スキーマの設計方法は教えてくれません。ましてや、どんなソフトウェアを作ればいいのか教えてくれるわけでもありません。

Rails は「何を作るか決めてからがすごいフレームワーク」なのです。分析工程は開発者自身が自分のやり方で実施しないといけないのです。

何を作るのかを導き出すのはモデリングが得意です。とはいえ、一般的な UML 本に載っているような開発プロセスはどうにも Rails アプリを記述するには重すぎる気がします。（少なくとも私はそう考えています。）往々にして、図解言語というものは、概要をとらえるには適していますが、詳細に書くと途端に見難くなります。実装レベルのシーケンス図などは、見るだけでも吐き気がします。

そこで、Rails 向けにシンプルな分析工程を考えてみます。

---

■ Rails 向け分析工程

(1) 要求モデルを作成する（ユースケース図もしくはフィーチャモデル）
(2) データモデルを作成する（クラス図もしくは ER 図）

私が考える必須モデリングはこれだけです。一つ一つ見ていきましょう。

(1) 要求モデルを作成する（ユースケース図もしくはフィーチャモデル）

何を作るのか、ユーザサイドから見た場合、ユースケースはわかりやすいです。ユースケースの例をあげると、「ブログ記事を投稿する」とかそんな感じですかね。図だけではなく、ユースケース記述もしっかりと書くようにしたいところです。

フィーチャも認識しましょう。

フィーチャモデルをあえて挙げている理由は、「Rails のコード生成はフィーチャ単位で行われることが多い」からです。フィーチャとは、機能を再利用の観点からまとめたものです。「ブログ記事管理」「認証」などが例になります。フィーチャは、Scaffold や act_as_authenticated（認証機能のコードジェネレータ）などで生成されるコードの単位に近いです。フィーチャの粒度はモデリングのやり方によって変わってきますので、Rails で使いやすい粒度にまとめるのがいいでしょう。

認証、コメント、タギングなどさまざまなフィーチャを認識できると、既存の資産（プラグインなど）の再利用がスムーズに行えます。そういう意味では、Rails とその周辺プラグインは一種のプロダクトラインを形成していて、Web アプリケーション開発に再利用可能なさまざまなフィーチャを提供してくれているという言い方ができるかもしれません。

(2) データモデルを作成する（クラス図もしくは ER 図）

ユースケース記述などを書くと、ある程度データモデルを記述できるはずです。クラス図を使ってもよいですが、私は ER 図をお勧めします。クラス図は仕様が複雑で難しすぎます。クラス図は関連、関連端の誤記・誤読が多く、使いこなすにはそれなりのスキルが要求されます。ER 図は、仕様が単純です。

堅い ER 図を書きたい場合は、オブジェクトの広場のこの記事で触れられている「現場を助けるモデリング」の発表資料を参照してください。ER 図のテストの仕方を紹介しています。

■ 注意したいこと

「Rails は試行錯誤可能なフレームワークであること」です。どこかの工程を完璧に完了することよりも、ある程度で進めて、早めにレールに乗ってください。レールに乗って試行錯誤することが、実は最短になるのです。開発対象範囲内において、要求ならユースケースやフィーチャの漏れがないこと、データモデルはテーブルの漏れがないことあたりが目安です。

来月あたり、このエントリに関係する内容を八角さんのサイトで執筆するつもりです。乞うご期待。