ユーザー機能駆動開発（ユーザーきのうくどうかいはつ、英: Feature Driven Development, FDD）は、反復的ソフトウェア開発工程の一種。アジャイルソフトウェア開発手法の1つでもある。FDD は業界におけるいくつかのベストプラクティスを混合したものである。それらは全て、顧客にとっての機能価値（feature）という観点で駆動される。その主な目的は、実際に動作するソフトウェアを繰り返し、適切な間隔で提供することである。
歴史
FDDは、ジェフ デ・ルーカが1997年、シンガポールの大きな銀行向けのソフトウェア開発プロジェクト（50人で15か月）での必要性に応じて生み出したものであった。ジェフ デ・ルーカは、開発をカバーする5つのプロセスを設定した。それらは、全体モデルの開発と、機能のリストアップ、計画、設計、構築である。最初のプロセスは、ピーター・コードのオブジェクトモデル技法に大きな影響を受けている。2番目のプロセスは、機能的要求仕様と開発作業を管理するためのピーター・コード の機能リストの考え方を取り入れている。他のプロセスと全体としてのプロセスの統一性は、ジェフ デ・ルーカの経験に基づいている。シンガポールでのプロジェクトが成功して以来、FDDはいくつかのプロジェクトで使用されている。
FDDが世界的に知られるようになったのは、ピーター・コード、エリック・レイフェイブル、ジェフ デ・ルーカの1999年の著書Java Modeling in Color with UML(日本語訳『Javaエンタープライズ・コンポーネント—カラーUMLによるJavaモデリング』) [1] の第6章で紹介されたのが最初である。スティーブン・パルマーとマック・フェルシングの2002年の著書 A Practical Guide to Feature-Driven Development (日本語訳『アジャイル開発手法FDD—ユーザ機能駆動によるアジャイル開発』) [2] では、さらに詳しく Java とは切り離した手法として FDD が解説されている。
オリジナルと最近のFDDプロセスについては、ジェフ デ・ルーカ のウェブサイト[※ 1]の Article 配下にある。FDD に関するコミュニティ]のウェブサイト[※ 2]もある。
概要
FDD は、5つの基本活動からなるモデル駆動型の短期反復方式の開発工程である。ソフトウェア開発プロジェクトの正確な状態報告と監視のために、各 feature についての進捗を示すマイルストーンが定義されている。以下ではそれら活動について概要を解説する。
活動
FDD では、ソフトウェア開発工程を構成する5つの基本活動が存在する。最初の3つの逐次的な活動によって、全体モデルの形が決まる。その後の2つの活動は feature 毎に反復的に実施される。
全体モデル開発
プロジェクトは、システムの範囲とその内容についての高レベルなウォークスルーから開始される。次に、部門毎の詳細なウォークスルーが、各モデリング分野ごとに行われる。各部門のサポートを受けて、複数のウォークスルーモデルが少人数で制作され、査読と議論のたたき台とされる。提案されたモデルのうちの1つまたは複数をまとめたものが、その特定の分野のモデルとして選択される。分野ごとのモデルが結合されて全体モデルとなり、全体モデルとしてその後調整が行われる。
feature リスト構築
初期のモデリングで収集された知識は機能（feature）のリストアップに使われる。このとき、領域を顧客が重要と考えている点ごとに分類する。この分類された各点にはそれぞれ何らかのビジネス活動が含まれ、各ビジネス活動内のステップ群に feature リストが対応する。この観点での feature とは、顧客にとっての価値を生む小規模な機能単位であり、<action> <result> <object> という形式になっている。例えば、「売り上げの合計を計算する」(Calculate the total of a sale) あるいは「ユーザーのパスワードを検査する」(Validate the password of a user) などである。完成に2週間以上かかると予想される feature は、さらに分割すべきである。
feature 毎の計画
feature リストが完成すると、次はその開発計画を立案する。feature をクラスに割り当て、各クラスに関して責任を持つプログラマ（オーナー）を決め、分担させる。
feature 毎の設計
各 feature ごとの設計パッケージを作る。オーナーは2週間で開発すべき feature 群を選択する。関連するクラスのオーナーと共同で、feature ごとの詳細なシーケンス図を作成し、全体モデルを更新する。次に、クラスとメソッドのプロローグを書き、最後に設計インスペクションを行う。
feature 毎の構築
feature ごとの設計インスペクションが完了したら、feature を実現するコードを書く。単体テストとコードインスペクションが完了したら、その feature はメインのビルド環境に入れられる。
マイルストーン
feature は小さいので、feature を1つ完成させるのは小さな作業である。ソフトウェア開発プロジェクトとしての進捗状況を監視して報告するには、それぞれの feature の進捗状況を全て把握する必要がある。そこで、FDD では feature ごとに6つのマイルストーンを定義し、それらが順次完了していく状況を監視する。最初の3つのマイルストーンはfeature 毎の設計活動のもので、残る3つはfeature 毎の構築活動のものである。進捗を把握する補助として、各マイルストーンに進捗率が設定されている。次の表にそれらマイルストーン（と進捗率）を示す。これによると、コード作成中の feature の進捗率は 44%（ドメイン・ウォークスルーが 1%、設計が 40%、設計インスペクションが 3% で、合計で 44%）である。
表 1: マイルストーン
| ドメイン・ウォークスルー
|
設計
|
設計インスペクション
|
コーディング
|
コードインスペクション
|
ビルド
|
| 1%
|
40%
|
3%
|
45%
|
10%
|
1%
|
ベストプラクティス
ユーザー機能駆動開発は、ソフトウェア工学に基づいたベストプラクティスを中心として構築されている。それらプラクティスは、顧客にとっての機能価値（feature）の観点で駆動される。FDD が注目されるのは、それらプラクティスと技法の結合にある。FDD を構成するベストプラクティスを以下に簡単に列挙する。
- ドメイン・オブジェクト・モデリング - 解決すべき問題の領域を探査し、説明する。結果として、機能を追加していく全体フレームワークが生じる。
- feature 毎の開発 - 2週間以内に実装できない機能はより小さな部分機能に分割され、最終的に feature と呼ばれる小さな機能単位になる。これによりバグの少ない実装が可能となり、システムの拡張や改善も容易になる。
- クラス毎のオーナーシップ - オーナーは、クラスの一貫性、性能、概念的完全性に責任を持つ。
- feature チーム - 小規模で動的に結成されるチーム。個人あるいは固定的なチームで陥り易い独善を防ぐ。
- インスペクション - インスペクションは、主にバグを検出することで設計やコードの品質を保証する。
- 構成管理 - 全 feature のソースコードについて、進捗を管理し、feature チームによる改変の履歴を保守する。
- 定期ビルド - 常に顧客に対してデモンストレーション可能な最新システムを構築しておくと共に、ソースコード結合時のエラーを早期に発見する。
- 目に見える進捗と成果 - プロジェクト内外に頻繁で適切で正確な進捗報告をすることで、マネージャがプロジェクトを適切に運営する補助となる。
ツール
注釈
出典
- ^ Coad, P., Lefebvre, E. & デ・ルーカ, J. (1999). Java Modeling in Color With UML: Enterprise Components and Process. Prentice Hall International. (ISBN 0-13-011510-X)
- ピーター・コード、ジェフ デ・ルーカ、エリック・レイフェイブル、依田光江 (訳) 、依田智夫 (訳) 、今野睦 (訳) 、2000年、『Javaエンタープライズ・コンポーネント—カラーUMLによるJavaモデリング』、ピアソン・エデュケーション、ISBN 978-4894712591
- ^ Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice Hall. (ISBN 0-13-067615-2)
- スティーブン・R. パルマー、ジョン・M. フェルシング、今野睦 (訳) 、長瀬嘉秀 (訳) 、飯塚富雄 (訳) 、デュオシステムズ (訳) 2003年、『アジャイル開発手法FDD—ユーザ機能駆動によるアジャイル開発』、ピアソンエデュケーション、ISBN 978-4894717350
関連項目
外部リンク
