ユーザー機能駆動開発について
ユーザー機能駆動開発（FDD: Feature Driven Development）の概要
ユーザー機能駆動開発とは
ユーザー機能駆動開発（以下FDD）とは、アジャイル開発手法の一つであり、ユーザー目線で価値のある機能を中心に開発を進める手法です。
この手法は、1997年にジェフ・デ・ルーカ（Jeff De Luca）がシンガポールの銀行プロジェクトのために考案したといわれています。
FDDは、「5つの基本活動」と呼ばれる開発工程と、「ベストプラクティス」という実績のある事例を用いて、稼働するソフトウェアを短い間隔で繰り返しリリースしながら開発していきます。
Featureとは
FDDは、はじめに「全体モデル」を作成して開発の全体像を明らかにした上で、「Feature」毎に切り分けて計画や設計・構築を行うという特徴があります。
Featureとは、顧客にとって価値のある機能の単位のことです。
FDDでは、Feature単位での開発サイクルを繰り返すことで、プロジェクト全体を完成させていきます。
FDDの注意点
FDDでは、ユーザーのビジネスを「見える化」して、必要な機能を洗い出しやドメインモデリングなどのプロセスを実施します。
そのため、ユーザーの要望・要求を明確化するために、コミュニケーションなどで大きなコストが掛かります。
しかし、その分、規模の大きなプロジェクトでも適用できるメリットがあります。
ユーザー機能駆動開発の「5つの基本活動」とは
FDD は 5 段階の開発プロセスに従うように設計されています。
モデル全体の形状は最初の2つのステップで形成され、残り3つのステップがフィーチャごとに繰り返されます。
１．Develop an overall model（全体モデル開発）
プロジェクトは、はじめにモデルリングチームを作成し、システム領域のドメイン知識を持つ専門家によるウォークスルーを実施します。
ウォークスルーとは、仕様や構成の問題点を探し出し、解決策を討論する作業のことです。
モデリングチームは、ドメインを分析して問題点を小さく分割していき、「小さなドメインモデル」を作成します。
ドメインモデル（Domain model）とは、システムに関わる様々な実体とそれらの関係を説明するシステムの概念モデルです。
概念と用語を文書化するために、システムの主要な実体とそれらの関係を明らかにし、重要なメソッドと属性も洗い出します。
ドメインモデルを分野別に結合していき、最終的にはドメイン全体のオブジェクトモデルである「全体モデル」を作成します。
この「全体モデル」が、全体モデル開発の最終的な成果物となります。
２．Build a features list（フィーチャーリストの構築）
リストの構築では、全体モデルを基にして、顧客の考える重要度ごとに分類されたフィーチャーリストを作成します。
（フィーチャーリストはアジャイル開発においてバックログと呼ばれるリストに相当します。）
フィーチャーリスト作成チームを結成して、全体モデルからフィーチャーを切り出していきます。
各フィーチャーは、例えば「パスワードを入力する」「指定金額を送金する」などの単純な機能として、2週間以内で開発できるものとします。
それ以上開発工数が必要になるフィーチャーは、2週間以内の開発になるように分割します。
フィーチャーを小さな粒度にすることで、顧客がプロジェクトの規模や進捗を容易に測定できるようになります。
また、短い期間でフィーチャーが実装されていくことで、顧客が素早いフィードバックを出すことを可能にします。
３．Plan by feature（フィーチャー毎の計画）
各フィーチャーを分析して、チームメンバーが実行するタスクの開発計画を立案します。
開発の順番や割り当ては、フィーチャーの依存関係や開発チームの負荷状況、フィーチャーの複雑さなどを考慮して決定します｡
この段階で、フィーチャーをクラスに割り当て、各クラスに責任を持つオーナー（プログラマ）を決めます。
（ここでいうクラスとは、オブジェクト指向におけるクラス概念と同義です。）
開発者はクラスの概念的原則に責任を負い、クラス図を作成できるくらいに詳細化します。
４．Design by feature（フィーチャー毎の設計）
各フィーチャー毎に、チーフプログラマーが設計および構築する機能を決定します。
まず、チーフプログラマーは、フィーチャーごとの詳細なシーケンス図を作成し、全体モデルを更新します。
次に、開発者がクラスとメソッドの概要を書き、設計のインスペクションを実施します｡
その後、「設計インスペクション」と呼ばれる第三者による設計の不具合や問題の確認・レビューを行います。
ここでは、機能の優先順位を定義しながら、関与するクラスの所有者と機能チームを決定します。
設計段階の終わりまでに、チーム全体による設計レビューが完了してから次に進みます。
５．Build by feature（フィーチャー毎の構築）
フィーチャー毎の設計が完了したら、フィーチャーを実装するためのコーディングを行います。
クラスのオーナー（フィーチャーの実装を割り当てられた開発者）は、プログラムコードを記述します。
そして、コーディングが終わったら単体テストを行い、コードインスペクションと呼ばれる第三者によるコードの確認を行います。
機能のプロトタイプが実装されると、ドメインの専門家からフィードバックを収集して、機能が意図した通りに動作することを確認します。
そして、機能がテストに合格して承認されると、完成したバージョンがメインビルドに追加されます。
顧客は、この時点の稼働するソフトウェアをが利用できるようになります。
ユーザー機能駆動開発の「ベストプラクティス」とは
ベストプラクティスとは、ある結果を得るのに最善の手法、プロセス、もしくは最良の事例、活動などのことです。
FDDでは、以下のような実績のある方法論を用いて開発を実施します。
| プラクティス名 | 内容 |
|---|---|
| Domain Object Modeling（ドメイン・オブジェクト・モデリング） | ドメイン内のオブジェクトとオブジェクト間の関係を記述するクラス図を作成します。 このプロセスは、どのような機能を追加するかを明らかにします。 |
| Developing by Feature（フィーチャー毎の開発） |
必要とされる機能を分割していき、「Feature」という小さな機能単位にし、これを開発の単位とします。 その機能が2週間以内に実装できない場合は、より小さく管理しやすい機能に分割する必要があります。 |
| Individual Class (Code) Ownership.（クラス毎のオーナーシップ） |
コードの各クラスまたはグループは、単一の所有者に割り当てられます。 そして、そのオーナーは、クラスの一貫性、性能、概念的完全性に責任を負います。 |
| Feature Teams（フィーチャーチーム） |
フィーチャーチームとは、機能チームとも呼ばれ、小規模で動的に結成されるチームです。 1 つの機能には複数のクラスが関与する場合があるため、フィーチャーチームの全員が設計と実装の決定に貢献します。 動的にチームを結成することで、個人や固定的なチームで陥りやすい独善的な開発が防げます。 |
| Inspections（インスペクション：検査） |
インスペクションとは、第三者による検証によって不具合や問題を見つけることです。 FDD チームはインスペクションを実行することで不具合を検出し、設計やコードの品質を保証します。 |
| Configuration Management（構成管理） |
全フィーチャーのソースコードについて、進捗を管理し、改変の履歴を保守します。 この実践には、すべての機能のソース コードを特定し、変更を文書化することが含まれます。 |
| Regular Builds（定期ビルド） | 定期的にビルドを行うことで、顧客に対してデモンストレーション可能な最新システムを提供することができます。 また、ソースコード結合時のビルドエラーを早期に発見します |
| Reporting/Visibility of Results（進捗と成果の可視化） |
FDDでは、プロジェクトマネージャーは、完了した作業の進捗レポートを定期的に提供する必要があります。 プロジェクト内外に対して「頻繁に」正確な進捗報告をすることは、プロジェクト自体を適切に運営する補助となります。 |