Ruby on Rails によるシステム開発をモデリングで効率的に行う（3） - 分析・設計編（フィーチャモデリング）
どうも、あかさたです。前回は「何を作るのか明確にする」観点でユースケースモデリングの紹介をしました。今回と次回は「どうすれば少ないコストでシステムを作れるか」という点について触れます。今回は、効率的な開発をする前準備として、フィーチャモデリングについて説明します。
開発効率を上げるとはどういうことか
Ruby on Rails を使った開発に限った話ではありませんが、素晴らしい生産性を発揮する人がいます。優秀なフレームワークを使っていても、そこそこの生産性しか発揮できない人もいます。プログラミング能力や設計能力（内部・外部問わず）の差かもしれません。しかし、私はその差は次の二つの理由も外せないと考えています。
一つは、「何を作るのかイメージできない」ことです。この問題に対しては、前回の記事にて、ユースケースモデリングを通して対処する方法を説明しました。もう一つの理由は、「どうすれば少ないコストで作れるか検討するステップがない」ことです。
Rails にはプラグインなどの多数の既存資産があります。Rails にも数多くの機能があります。優れた開発者は、こうした既存資産を使って効率よく開発を進めています。いくら既存資産がたくさんあったとしても活用しなければ、生産性を上げることはできません。そこで、明示的に既存資産の活用を検討する工程を含めることで、「意識して効率的に開発する」ことができるようになります。
既存資産の活用を手順化すると以下のようになります。
- 要求を「既存資産の再利用の検討」をしやすい形式にまとめる（フィーチャ・モデリング）
- 既存資産・フレームワークの機能などを整理する（解決領域の分析）
- 要求と既存資産のマッチングを行う
今回は、(1) と (2) について、次回は (3) について説明します。
フィーチャ・モデリングを行う
フィーチャとは、要求をシステムの視点から表現したものです。ユースケースが、「ユーザーに提供するサービス」を表現するためのものであるのに対し、フィーチャは「そのシステムが持つ機能」を表現することに主眼を置いています。
要求をシステム的にとらえることになるので、再利用性やソリューション技術の選択などの検討が行いやすいという特徴を持っています。実際、上手く認識されたフィーチャは、Rails のプラグインと一対一に近い形で対応します。
まずは、本事例（事例については前回の記事を参照してください。）のフィーチャを抜き出してみましょう。フィーチャはユースケース記述やビジネス要求に関するドキュメントに登場するので、それらのドキュメントから拾っていきます。
対象となるユースケースは「ブログ記事を投稿する」「ブログ記事を公開する」「ブログ記事を閲覧する」ですから、「記事管理（記事の CRUD）」、「認証」、「管理（Admin 画面）」がフィーチャとして読み取れます。以下にフィーチャモデルの図を起こします。
今回の事例では要求から省きましたが、「コメント」「トラックバック」「タギング」「RSS」「国際化」などもフィーチャになり得ます。また、見てのとおりフィーチャモデルはツリー構造になっているので、ブレークダウンすればいくらでも細かいフィーチャを認識することができます。しかし、プラグインより小さな粒度にはしない方がいいでしょう。再利用も細かくなりすぎると、管理する手間が増えてかえってコストを上げてしまう場合があります。
上記で挙げたようなフィーチャを、「問題領域のフィーチャ」と呼びます。次に、「解決領域の分析」について紹介します。
解決領域の分析
解決領域の分析は、使用する予定のテクノロジー（言語、フレームワーク、付随するプラグインなど）がどのような特性を持っているのか分析する作業です。Rails が対象とするようなシステムであれば、フレームワークの機能やプラグインなどの情報をカタログ化（もしくは頭の中に入れておく）する作業となります。勉強会に顔を出すのも一つ手です。勉強会では、プラグインの適用範囲や完成度に関する情報を得ることができます。
また、解決領域の分析結果は、一つのアプリケーションの開発ではなく、解決領域が同じである限りどの開発でも活用することができます。そういう意味では、「エンジニアの心得として、良く使用する技術分野は常日頃からよく調べておく」行為を解決領域の分析と呼んでも差し支えありません。（もちろん、分析というからには形式的な手法も存在します。興味のある人は前述のマルチパラダイムデザインを参照してください。）
まとめ
今回は、「どうすれば少ないコストでシステムを作れるか」検討する前段階として、「フィーチャ・モデリング」と「解決領域の分析」の紹介をしました。次回は「フィーチャと解決領域に存在する技術要素とのマッチング」について説明します。それでは！
コラム － 「問題領域」と「解決領域」
「問題領域」と「解決領域」の話をします。問題領域（アプリケーションドメイン）と解決領域（ソリューションドメイン）はマルチパラダイムデザインによってメジャーになった用語です。
問題領域はアプリケーションやその上位となるビジネス、解決領域は C++ や Ruby のような言語、Rails のようなフレームワーク、DBMS などを指します。マルチパラダイムデザインでは、問題領域と解決領域の分析を両方行うことで、より適切なソフトウェア開発を行うことができることを説明しています。（本記事もまた、この考え方をベースにしています。）
問題領域の分析は大変難しい作業です。しかし、ビジネスモデリングやユースケースモデリングのような優れた手法があったり、画面設計を丹念に行うことで、ある程度こなすことはできます。それに、必ず行う作業でもあります。
解決領域の分析を行うということは、問題領域の解決を行うための「引き出し」を整える作業であり、とても大切なことです。しかし、解決領域の分析はメジャーな方法が存在しておらず、意識的に行われることはそれほど多くありません。
Rails における開発では、活用すべき資産（プラグインなど）が解決領域に多数存在しています。それらを活用するために、解決領域も含めた分析を行うことは非常に有効です。少し難しい（しかも少し古い）本ですが、マルチパラダイムデザインを一読することをお勧めします。（こちらの記事も参考になります。）
このサイトについて
執筆者紹介
TrackBack URL :
技術記事のRSSフィード
News&TopicsのRSSフィード
製品紹介のRSSフィード
この執筆者のRSSフィード