連載 次世代開発基盤技術“Software Factories”詳解 第3回 長期的な要求を定義するフィーチャ・モデル ―― ソフトウェア・プロダクトラインの分析、設計、実装法（前編） ―― マイクロソフト株式会社　萩原 正義 2005/05/28

Page1 Page2

Back Issue

1 ソフトウェア工業化を目指して 2 開発手法「ソフトウェア・プロダクトライン」とは？

　前回の「開発手法『ソフトウェア・プロダクトライン』とは？」では、長期的視点と短期的視点を分離し、変化を管理する重要性を説明した。ソフトウェア・プロダクトラインにおけるプロダクトライン分析では、ドメイン工学を前提とし、フィーチャ・モデルを利用してアーキテクチャ要求（フィーチャ）の定義を進めていく。フィーチャ・モデルは本連載でも何度か登場したが、今回はそのフィーチャ・モデルの内容について深く掘り下げて解説する。

◆ユースケースとフィーチャの違い

　Software Factoriesでソフトウェア・プロダクトラインとしてアーキテクチャを構築するには、まずユースケースとフィーチャの違いを理解しておかなければならない。

　そこで、書籍購入サイトの開発におけるユースケースとフィーチャの関係を例に、両者の違いを見ていこう。この例の場合では、ユースケースとフィーチャの関係は次の表のようになる。

ユースケース（アクターに対する機能）	フィーチャ（アーキテクチャの要求と再利用可能な機能）
	ユースケース優先度	カタログ管理	注文処理	課金処理	認証	メタデータ	データ分析	……
カタログ検索	1	○
カタログ保守	1	○
カタログ分類	3	○				○
カタログ在庫	2	○					○
注文	1		○
注文状況	2		○				○
決済	1			○	○
： ： ：
表1 書籍購入サイトにおけるユースケースとフィーチャの関係
フィーチャは非機能要求を含むアーキテクチャの要求と再利用可能な機能を提供し、ユースケースはアクター（＝エンドユーザー）に対する機能を提供する。Software Factoriesでは、プロダクトライン・アーキテクチャの提供するフィーチャを取捨選択することで、アクターの要求に応じたユースケースの追加、更新に対応する（例えば、「カタログ検索」のユースケースでは、「カタログ管理」のフィーチャを選択することで、その機能が追加される）。要するに、フィーチャはアーキテクチャとして提供される長期的要求に対する機能を、ユースケースは一度限りの開発プロジェクトの短期的要求に対する機能を提供するのである。

●書籍購入サイトにおけるフィーチャとは？

　例に取り上げた書籍購入サイトでは、表の横軸にあるような「カタログ管理」「注文処理」「課金処理」「認証」、さらには「データ分析」「出版会社や卸との取引管理」「営業支援」「Webサイト管理」などのフィーチャ（アーキテクチャの再利用可能な機能）を持つ。これらの機能は、業務内容に基づく問題領域におけるドメインを定義する*1。

　また、「メタデータ」などの解決領域におけるIT実現技術による機能分類も一部ここには含まれている。これらのIT実現技術は、フィーチャとして書籍購入サイトが長期的視点で持つべき機能分類といえる。

*1 問題領域と解決領域におけるドメインの説明は本連載第2回を参照のこと。

●ユースケースとは？ フィーチャとの違いは何か？

　一方で、顧客、システム管理者、営業担当者などのアクター（＝エンドユーザー）に対するユースケースが定義される。例えば、表の縦軸にある、「カタログ検索」「カタログ分類」「注文」「注文状況」「決済」などがそれである。

　フィーチャは非機能要求を含むアーキテクチャの再利用可能な機能を提供し、ユースケースはアクターに対する機能を提供する。フィーチャは必ずしもアクターに直接提供する機能でなくてもよく、ソフトウェアが利用する間接的な機能である。

●ユースケースの実現に合わせた優先度の決定

　さて、フィーチャとユースケースの違いをもう少し詳しく見ていこう。書籍購入サイトの開発では、エンドユーザー（＝システム利用者）の要求に応じたバージョン・アップによってユースケースを追加、更新していく。ここでは、ユースケースの実現に合わせてフィーチャを取捨選択し開発をしていこう。

　例えば「カタログ分類」のユースケースとしての書籍のジャンルやキーワードによる分類と検索、また「注文状況」のユースケースとしての注文状況の確認などの機能追加要求が考えられる。もちろんこれらの機能は書籍購入サイトとしてあった方が便利であるが、実際にそれを実装するかどうかは開発コスト、開発期間、採用するWebサイト構築技術によって決定される。そのため、現バージョンでの開発は見合わせてユースケースの優先度を下げた（表1で、「カタログ分類」の「ユースケース優先度」が「3」となっているのを確認されたい）。

　このように、「ユースケース優先度」の決定は、エンドユーザーの要求と開発者の技術的課題や開発コストとの間で調整し決定する。

●フィーチャの視点から見たユースケースの優先度の見直し

　次に、「カタログ在庫」と「注文状況」のユースケースを考えてほしい。これらのユースケースは、エンドユーザーの要求からは優先度が低いと考えられるので、先の「カタログ分類」のユースケースと同程度の「ユースケース優先度」を適用すべきである。

　しかし、この2つのユースケースは、横軸の「データ分析」のフィーチャを利用する。もし、この書籍購入サイトを導入する企業システムにおいて、ほかのアプリケーションを含めた長期的な共通機能として、データ分析、すなわち、リアルタイムな経営の可視化の構築が重要であるのなら、そのためのアーキテクチャの構築を優先しなければならない。

　つまり、当の書籍購入サイトを開発するためのユースケースの要求定義で決まる短期的な優先度ではなく、アーキテクチャ構築のための長期的な優先度から、「データ分析」のフィーチャの実現を優先的に選択する必要があるのだ。

　「データ分析」のフィーチャの実現を優先するのであれば、このフィーチャを利用した現行の開発プロジェクトでのユースケースの優先度を上げて、短期的要求の実現で長期的要求の実現を考えるべきだ（そこで、表1の「カタログ在庫」と「注文状況」の「ユースケース優先度」では、このような考えから、優先度を1つ上げて「2」としているわけである）。

　結果として、「カタログ在庫」「注文状況」のユースケースの実現を通じて、データ分析のフィーチャの実現が早期に行える。これがフィーチャの視点から見たユースケースの優先度の見直しの例である。

●Software Factoriesにおけるユースケースとフィーチャの特長

　Software Factoriesでは、フィーチャはソフトウェア・プロダクトライン開発プロセスで、ユースケースはプロダクト開発プロセスで考慮する。将来発生するであろう開発プロジェクトのユースケース要求を予見し、フィーチャとして再定義して長期的に安定するアーキテクチャの要求を考える。

　UP（Unified Process）など既存の開発プロセスでは、プロジェクトの個別要求も、ほかのプロジェクトと共通に利用するアーキテクチャの要求（そのプロジェクトで必要とされる要求と将来発生するプロジェクトの要求を含む）も同じユースケースで定義するため、短期と長期の要求の分離が明確化できなかった。

　しかしSoftware Factoriesでは、短期はユースケース、長期はフィーチャとして要求を定義し、開発プロセスを分離するという特長がある。

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第3回 長期的な要求を定義するフィーチャ・モデル
	1．ユースケースとフィーチャの違い
	2．フィーチャ・モデル

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）