Ruby on Rails によるシステム開発をモデリングで効率的に行う

• 概要編
• 分析・設計編（ユースケース図とユースケース記述）
• 分析・設計編（フィーチャモデリング）
• 分析・設計編（フィーチャと解決領域のマッチング）
• 分析・設計編（ER 図）
• 分析・設計編（ER 図の実践）
• 実装編（モデルを実装に落とし込む）
• まとめ

Ruby on Rails は大変優れたフレームワークです。DB のスキーマさえ作ってしまえば、開発を高速に進めることができます。しかし、Rails は「どんなソフトウェアを作ればいいのか」教えてくれるわけではありません。この問いに答えるために、開発者は自分で分析を行わなくてはなりません。

何を作るのかを考える場合、モデリングはよい道具になります。しかし、一般的な UML 本などに載っている開発プロセスなどは、重厚すぎて Rails を対象とするような小さな開発を行う際に、コストの面で不安があります。本連載では Ruby on Rails 用に使用する図や手順を絞り込んだ実用的なモデリング手法を、実際に Rails アプリケーションを作成しながら紹介します。

Ruby on Rails の一般的な開発モデル

Ruby on Rails を使ったアプリケーションの一般的な作り方は、以下のような図になるかもしれません。つまり、直感から DB スキーマを思いついて、DB を作成したら、scaffold のコード生成を行って画面の作り込む、という感じです。

Rails の一般的な開発の流れ

こうした開発方法が悪いわけではありません。たとえば、他の「単純な」アプリケーションをコピーするような開発であれば、スムーズに開発を進めることができると思います。アプリの動きを見ていれば DB 設計と画面設計が見えてきます。つまり、分析行程が完了している状態ですので、最初からレールに乗って開発を進めることができます。そうした案件も少なくはありません。

しかし、ある程度以上複雑なものになると、分析情報を整理してから開発しないと、手戻りの多い開発になる場合があります。たとえば、ウェブアプリに認証と認可を後付けする場合、ロールを使ったモデルにするか、グループを使ったモデルにするかで微妙に変わってきたりしますが、ビジネスの要求によって何を選択するか変わってきます。このような複雑で影響の多い追加を頭の中で済ませようとすると、さまざまな思考が浮かんできて、最悪手が止まってしまうこともあります。（主に私です。）

このような事態を防ぐために紙に書きだしたりして、明示的に分析・設計を行うわけです。しかし、分析工程は開発者自身が自分のやり方で実施しなくてはならず、Rails が助けてくれるわけでもありません。Rails は「何を作るか決めてからがすごいフレームワーク」です。Rails といえども、何を作るか明確になっていない開発を高速化することはできません。それと同時に、「Rails は試行錯誤の中でよいアプリケーションを開発することができるフレームワーク」でもあります。特にユーザビリティにかかわるような部分は、実際にアプリケーションを作ってから徐々に改善するという手段をとるほうが効率的であることもあります。

ですから、下手にモデリングを入れると、この試行錯誤の部分をやりづらくなり、Rails の良さを殺してしまう重厚な開発になってしまうという懸念もあります。本連載では、Rails の良さを生かした、軽量でありながら Rails を使った開発を十分にサポートしてくれるモデリングプロセスを、実際にアプリケーションを開発しながら紹介したいと思います。