テスト駆動でもデータ駆動でもない 「機能駆動開発」とは何か：「ユーザーが価値を感じる機能」に注力する手法

TechTargetは「機能駆動型開発」に関する記事を公開した。機能駆動型開発は、アプリケーションの機能を中心にプロジェクトを構成することでアジャイルの原則を開発プラクティスに持ち込む。

[Chris Tozzi，TechTarget]

　TechTargetは2024年4月17日（米国時間）、「機能駆動開発」に関する記事を公開した。

機能駆動開発のフェーズを学ぶ（提供：TechTarget）

　人気の開発手法であるアジャイル型開発は開発作業を複数のフェーズに分割することを奨励している。だが、アジャイルは「分割する各フェーズに何を含めるべきか」といった詳細なガイダンスはほとんど提供していない。それは、アジャイルが“開発哲学”といったもので、具体的な手順を説明するものではないからだ。

　こうしたギャップを埋めるのに役立つのが、「機能駆動型開発」（Feature-Driven Development、以下、FDD）などのフレームワークだ。FDDは本質的にはアジャイルを実現する手法の一つで、「機能」を軸にしている。“開発作業を5つのフェーズに分割する”という具体的で構造化されたアプローチを採用している。

FDDとは何か

　繰り返しにはなるが、FDDはアプリケーションの“機能”を軸にした開発手法だ。FDDを採用する開発者は、実装または改善する機能を特定してから新たな機能セットの開発に取り掛かる。同じアプリケーションや同じプロジェクトを担当する開発者を十分確保できる場合は、開発者を小さなグループ（通常は「機能チーム」と呼ぶ）に分け、特定の機能セットや機能の更新に専念させることができる。

　FDDは、アジャイルが推奨する「管理しやすい小さな開発作業に分割する」という作業を、現実的なステップに落とし込むのに役立つ。別の言い方をすれば、FDDは、開発作業の単位を“機能”で区切ることで「アジャイルを実践するための実用的な方法を提供している」ということだ。

FDDで重点を置く機能とは

　FDDで“機能”という用語はそれほど厳密には定義されていない。ユーザーがオンラインショッピングカートに商品を入れる機能や決済の機能など「アプリケーション機能」を指すこともあれば、それ以上の意味を持つこともある。

　例えば、オンラインショッピングカートのページ読み込み速度を改善する、ユーザーの使いやすさを高めるためにアプリケーション内のテキストサイズや色を変更するといったことも“機能”に含まれる。この場合、新たなアプリケーションの機能が追加されるわけではなく、あくまでも既存のアプリケーション機能が改善される形だ。だが、FDDの目的から考えれば、それらは「仕事の整理に役立つ機能が追加された」と捉えられる。

FDDのメリット

　FDDを適切に実装すれば、幾つかのメリットが得られる。

作業範囲が明確になる

　FDDは作業単位を具体的な機能や機能の改善に関連付けられるため、開発者が各作業にかける正確な時間と作業量を見積もりやすくなる。

反復的に作業を進められる

　プロジェクトを小さな作業単位に分割することで、チームは効率的かつ反復的に作業できる。一度に大きな変更を加えると調整が大変だが、FDDであれば少しずつステップとして進めることができるため、継続的にアプリケーションを改善できるようになる。

ユーザー中心のアプローチを取ることができる

　FDDは機能を中心とする手法だ。そのため、ユーザーが必要とする機能（もしくは評価する機能）に開発者の作業を集中させられる。

開発者間のコミュニケーションとコンセンサス（同意）の効率が高まる

　開発作業と機能を対応させると、開発作業の定義（どのように開発を進めるかを決めること）が比較的簡単になる。そのため、FDDは開発者間の議論を最小限に抑えられる。開発チームとしても一連の作業を迅速に決定できるため、すぐに実装作業に着手できるようになる。

FDDの課題

　一方、課題もある。最も大きな課題は、複数の機能もしくはアプリケーション全体に影響するようなケースには向いていないということだ。

　例えば、「モノリシックなアプリケーションをマイクロサービス化する（マイクロサービスアプリケーションにリファクタリングする）」というタスクがあるとする。この場合、特定の機能ではなく、アプリケーションの広い範囲に変更を加えなければならないため、FDDはうまく働かない。

　「アプリケーションのセキュリティを強化したい」というタスクがあるとする。この場合、ユーザーがログインする、アプリケーションによってデータを処理する、ネットワークでやりとりするなど、多種多様な機能に影響するため、FDDのアプローチでは作業が難しくなる可能性がある。これらの処理は個別の機能には集約できないからだ。

　ユーザーが重視する機能を開発者が明確に把握できていない場合や、相反する関心を持つ複数のユーザーグループをサポートする必要がある場合も、FDDでの対応が難しくなる。このような場合、平均的なユーザーにとって最も価値のある機能が分からないため、どの機能に取り組むかを決めるのに時間がかかる可能性がある。

　また、開発者の数が少ない（もしくは1人しかいない）場合も、FDDは適切に働かない。FDDのアプローチではプログラマーが並列に作業することができない。開発者が潤沢で、異なる作業を複数のチームに同時に割り当てられないのであれば、FDDで得られるメリットは少ない。

FDD実践に必要な5つのステップ

　FDDを実践するには、5つのステップ（フェーズ）を進める必要がある。

フェーズ1．全体モデルの作成

　対象となるアプリケーションがどのように動くか、どのようなカテゴリーの機能が付いているのか、といった方向性（ビジョン）を確立する必要がある。このフェーズでは、どういったタイプの機能にユーザーが価値を感じるかについて仮説を立て、技術的な視点で、主要な要件を最も効果的に実装する方法を決めることになる。

　例えば、Eコマース用のアプリケーションを設計するとしたら、アカウントの作成、商品の検索、購入などの機能が必要になるが、その中で、主にサポートする機能をどれにするかを決める、といったイメージだ。

フェーズ2．機能リストの作成

　フェーズ1で立てた仮説を実現する（ユーザーが価値を感じる機能を持ったアプリケーションを構築する）ために、実装する必要がある機能の詳細を記載した「機能リスト」を作成する。

　例えば、アカウントを作成する機能がアプリケーションモデルの一部になっている場合、アカウントに関連したその他の機能（新規アカウントの登録、ユーザーの認証、ユーザーによる自身のアカウントの情報更新など）も実装する必要がある。

フェーズ3．機能別の計画

　開発チームが機能リストの内容に合意できたら、次はその機能を実装する方法についての計画を立てる。

　このフェーズでは、各機能の実装に必要な時間と作業量を見積もる。その後、各機能チームに作業を振り分ける方法を決める。

　機能別に計画を立てる場合、開発者や開発チームが保有するスキルの種類も考慮する。作業に適したスキルを持っている開発者に委託するのが理想的だ。

フェーズ4．機能別の設計

　機能別の設計のフェーズでは、各機能をどのように実装するかについて具体的な計画を立てる。通常、その作業の監督は主任の開発者が担うことになる。各機能チームと連携して、使用する言語やフレームワークなどを決め、必要に応じて、その機能がユーザーとやりとりする方法（インタフェースなど）も決める。

フェーズ5．機能別の構築

　フェーズ4で確立した設計に基づいて、機能を実装する。機能の完成に想定よりも時間がかかりそうな場合は、設計を見直すか、作業をさらに小さな機能セットに分割することを検討する。

　このフェーズは、各チームが計画した機能を全て構築し、テストを終えるまで続ける。このフェーズが終了したころ、開発者は、FDDによる反復作業の経験を基に、新たな機能セットの計画と実装に取り組めるようになっているだろう。