RoRでプロトタイピングするのはアリだと思う
こちらの記事を見つつ考え。
迅速なプロトタイピング(アジャイルプロトタイピングと意味が同じかもしれない)は、とりあえず作ってみることで不明点を洗い出し、顧客とイメージを共有するためのツールだ。言い換えると、プロジェクトのリスクを軽減するための手法だと思う。
作成されたプロトタイプはその半分以下のコードしか本番コードに流用できないことが多いようだ。しかし、重要なのは流用性ではなく、不明点を出し、とりあえず動きそうなモデルを作るという態度の問題だろう。この態度は「リスクを回避するためにコストを投下する」というものだと言える。
リーンソフトウェア開発中での「オプション志向」、「決定を遅らせる」、もしくは熊とワルツを、におけるリスクの軽減策、いずれにも共通して登場するのは「決定をギリギリまで遅らせる」「しかしギリギリではマズいものは事前に検証する」ということで、この両者のバランスが重要。プロトタイピングに時間をかけすぎるのは、リスクヘッジにコストを投下し過ぎることになる。しかしまったく作らない場合はリスクヘッジを行なわず、情報が少ないまま(やってみたことがないのだから開発チームは想像と机上の範疇でしか物事を判断できない)突き進むことになる。
ここでいうコストはもちろん「効果」との兼ね合い、つまりコストパフォーマンスということになる。かなりカネはかかるが、流用性が高いとか、カネはかからないが、せいぜい技術検証で顧客との擦り合わせには使えない、とかいろいろとサイズがある。個人的には、RoR(Ruby on Rails)でプロトタイピングする、というのがバランスがいい投資(コストも割とかかるがいろいろなことが明らかになる選択)のような気がする。
RoRを使ってプロトタイピングする場合、画面デザインに一定の自由度が与えられる。ほとんどモックのようなページコントローラをさくさくと作り、かつ楽をしようと思えば、テーブル定義もすることになる。ActiveRecordパターンになるものの、このパターンはドメインモデルを反映したものになるのでロジックも含めて再利用性は充分に高い(本番構築フェーズでJava/C++などの実装を行なうことを想定しての考え)。そう考えると、論理データモデル、コントローラの責務、画面のフローとデザイン、という要素をそこそこに押さえておけるのだ。前者２つは開発上の問題点/リスクポイントの発見に役立つし、画面まわりは顧客との擦り合わせに効果を発揮する。
独特のフレームワーク、というか学習曲線がいびつ(入り口は緩いが、途中から随分ハードルが高くなると思う)な気がするが、プロトタイピング用のツールとして勉強する価値はあるような気がする。
…って全部Webアプリケーションの場合の話やねー。
