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

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

どうも、あかさたです。前回までで Rails を適用した開発におけるモデリング手法を紹介しました。本連載は今回で終了ですので、Rails とモデリングに関するに関するまとめを行います。

モデリングプロセスのおさらい

本連載では、Rails によるアプリ開発で「なぜモデリングをすると有効なのか」を説明してから（第一回）、以下の点に注意しながら Rails の特性に合わせて軽量なモデリングプロセスを組み立てて紹介しました。

• 何を開発するのかを明らかにする
• 既存の資産（プラグイン）を活用しやすくする
• DB の設計をしっかりと行う

本連載におけるプロセス

「何を開発するのかを明らかにする」ためにユースケースモデリング（第二回）を、「既存の資産（プラグイン）を活用しやすくする」ためにフィーチャモデリング（第三回、第四回）を、「DB の設計をしっかりと行う」ために ER 図の作成方法（第五回、第六回）を紹介しました。

また、作成したモデルを実装につなぐためにどのようなことをすればよいのか、以下の流れに沿って紹介しました（第七回）。

モデルを実装に落とす流れ

実装とモデルの同期に関するポイント

保守開発時の実装とモデルの同期は難しい問題です。モデリングに限らず仕様書に類するものに対して、「実装と仕様が乖離してしまって役に立たない」という話はよく聞きます。ましてや、軽量が信条の Rails を使った開発では、頻繁に変更される仕様にドキュメントを追いつかせる作業が、もどかしいものに感じられるかもしれません。

モデルの運用についていくつかのアイディアを紹介します。以下の運用に関するアイディアは、開発時のモデルの詳細度を決める基準にもなるので、開発時に意識して選択するとよいでしょう。

最初のアイディアは、「モデルを運用しない」です。乱暴な意見に聞こえますが、小規模かつ単純なアプリケーションであれば、フレームワークのルールさえ知っていれば保守開発は進められます。この場合、「モデリングは開発時の思考ツール」と割り切って、モデルを中間成果物として取り扱います。捨てはしないがメンテナンスもしないという方針を採用します。（あるいは捨てても構いません。）小規模かつ寿命の短いアプリケーションであれば、軽量さを最大限に発揮できる本アイディアにはメリットがあります。

次のアイディアは、「実装で頻繁に変化する部分のみ運用しない」です。たとえば、ER 図では、Entity とあまり変化しない基本的な Attribute と Relationship のみを書き込み、それ以外の詳細は実装を参照してもらうというようなやり方です。
モデルの役割は、ポインタに徹することになりますが、モデルの参照者は複雑なアプリケーションであっても保守に必要な情報にたどりつく方法をモデルからあらかた得ることができます。おそらく、Rails で開発するアプリケーションの多くはこのアイディアに適した規模・複雑度を持っていることでしょう。

最後のアイディアは、「すべてを運用する」です。ある程度の規模、複雑さ、品質を求められる場合に有効です。
本モデリングプロセスでは使用しませんでしたが、クラス図やシーケンス図を使っていて、このアイディアが適している場合、個人的な意見になりますが、Rails で開発するアプリケーションとしては少々複雑かつ大きすぎるかもしれません。Java の代わりに単純に Rails を使用する案件があるかどうかは知りませんが、あるとすれば、このアイディアが必要になるかもしれません。
その場合、モデリング以前に Rails を大規模案件に適するような改造もしくは開発ガイドラインの整備などが必要になるかもしれません。

今紹介した三つの考え方は、アプリケーションの規模・複雑度・寿命の長さに応じてそれぞれメリット・デメリットがありますので、必要に応じて選択してください。モデルごと（図ごと）に運用の詳細度を定めても良いので、無批判にモデルの運用を行う（もしくは行わない）ようなことはせず、状況に合ったやり方を選択してください。

本連載がカバーしていない範囲

まとめに書くのもどうかと思いますが、本連載でカバーできなかった範囲を紹介します。

ソフトウェア開発において、ほとんどの工数は分析・設計とデバッグやテストで消費されます。少なくとも、本連載では Rails のテストと相性のいいテストを支援するモデリング手法の紹介はできませんでした。おそらく、UML であればステートマシン図（UML なければ状態遷移表も検討対象）などを使ってアプリケーションの状態を分析するようなモデルになると思われますが、私は今のところ検討していません。

また、本連載で紹介したモデリングプロセスは一般的なウェブアプリケーションを開発する際には有効でしょうが、Ajax、AIR、Silverlight などを駆使した複雑な UI を持ったアプリケーションの開発時にはあまり助けにならないでしょう。本モデリングプロセスはサーバーサイドによりすぎていることに注意してください。

言うまでもなく、大規模な案件はカバーしていません。RUP のような重厚なプロセス（RUP もやり方によっては軽量に運用できますが）を採用する方がいいでしょう。Rails がそれに適しているかどうかはわかりませんが。

django、Merb などの他の軽量なフレームワークであれば、本モデリングプロセスを使用することができるかもしれません。検討する価値はあるでしょう。

まとめ

Rails によってウェブアプリの開発障壁が下がり、Ruby 界隈の VB 化を招くという意見もあるようです。そうした情勢下でもある程度安定した品質で開発するにはモデリングのような手法は役に立つでしょう。もちろん、エッジで戦う Ruby 使いの指向ツールとしてもモデリングがもっと活用されるようになれば良いですね。ただ、そうなるためには今のモデリング言語はまだまだ改善の余地があるように感じますが。

以上で、連載「Ruby on Rails によるシステム開発をモデリングで効率的に行う」はおしまいです。今回の連載は比較的硬い内容だったので、次回からは少し遊べるような内容にしたいと思います。それでは！