アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント：どう作るか、どう活用するか

アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。

[Diane Hoffman，TechTarget]

　ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書（BRD：Business Requirements Document）を用意すれば、顧客のニーズを満たすことが可能になる。

　アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプロジェクト管理にBRDがどのように適合するか、BRDを実際のコードに変換する方法、ソフトウェアチームがBRDを満たしているかどうかを判断する方法について考える。

BRDによって想定結果を設定する方法

　BRDには、プロジェクトが目指すビジネス目的を記述する。BRDでは、製品の目的、製品の仕組み、クライアントの使用目的など、製品の製造方法を定める。BRDがあれば、コストに影響する可能性のある要因や制限、ソフトウェアプロジェクトの工程やスケジュールを確認できる。また、個々のプロジェクトの想定結果や必要な納品物の概要を示し、量と質の両面でプロジェクトの成否を判断するベンチマークを設定することもある。

　BRDにはさまざまな構成がある。製品開発チームは、BRDをゼロから作成することも、サンプルテンプレートを利用しニーズに合わせて調整することも可能だ。とはいえ、どのように作成するとしても、BRDの効果を高めるには次の10件の標準情報を構成要素として含めるのが一般的だ。

1. エクゼクティブサマリーまたはプロジェクトの概要
2. 成否を判断するベンチマークとプロジェクトのリスト
3. プロジェクトの対象範囲の説明（必ず含めるものと含めないもの）
4. プロジェクトの主要関係者のID
5. 不可欠なビジネス要件とビジネス目標
6. 最終製品または最終サービスが目的とする対象範囲
7. システムの機能要件と非機能要件（省略可）
8. プロジェクトで可能性のある制約と費用便益分析
9. 品質管理手法の参考資料
10. プロジェクトの工程と期限を表すスケジュール

アジャイル開発でのBRDの使用方法

　アジャイル開発では、定義する製品機能をプロジェクトエピックの一部として含めることが多い。プロジェクトエピックとは1つの大きなユーザーストーリーのことで、最終的にはプロジェクトの一連のタスクやサブタスクに分解される。プロジェクトエピックには、BRDの情報の大部分を組み込むのが一般的だ。

　プロジェクトマネジャーと製品担当者が協力して、このエピックをプロジェクトタスクや製品ロードマップに落とし込む。

チームはこの情報を使ってユーザーストーリーを絞り込み、機能のニーズと対象範囲の適切な説明を提供することも可能だ。開発者は、ビジネス要件を満たすのに必要な詳細機能要件をこのユーザーストーリーから取得することになる。

　ユーザーストーリーは、対象となるエンドユーザーや顧客が求める価値を、非常に分かりやすい方法で簡潔に説明する形式にする。BRD内でユーザーストーリーを表現する例を示す。「私は＜ユーザー／役割／顧客の種類を挿入＞で、＜理由／目標／メリットを挿入＞を目的として、＜製品／機能／サービスを挿入＞が必要」

　ユーザーストーリーには、受け入れ条件を含めることができる。受け入れ条件は、プロジェクトが対処する必要のある不可欠な機能や必須機能が適格かどうかを決定する。受け入れ条件を含めることで、成功したとみなされている既存製品のパフォーマンスなど、開発者がそのユーザーストーリーを適切に提供できたかどうかを把握するために使用できるベンチマークを提供することもできる。ユーザーストーリーをさらに細分化し、個別のシステムコンポーネントにフォーカスするサブタスクに分割しているグループもある。例えば、顧客のニーズを満たす要件の一部として、アプリケーションのUIコンポーネント、バックエンドコンポーネント、データベースコンポーネントに対して開発チームが実行しなければならない作業の詳細をユーザーストーリーに記述することもできる。

エピックがどのようにアジャイルタスクになるか

　アジャイル開発のシナリオでは、BRDを使って、大まかな製品機能とバックエンド開発タスクの関係を一連の親子関係で描くエピックを作成できる。プロジェクトマネジャーやプロジェクト担当者は、関連する子開発タスク全てを自身が担当する包括的なユーザーストーリーに結び付け、それを親タスク内のユーザーストーリーに統合する。この種のワークフロー図は、プロジェクトの各段階でプロジェクトマネジャーが進捗状況を正確に追跡するのに役立ち、必要な変更や優先順位の変化に応じてプロジェクトを後戻りさせるのにも役立つ。

ビジネス要件の変化への対応方法

　顧客は、変更要求（RFC：Requests For Change）を行う可能性がある。ベンダーは、RFCに応じて、ビジネス要件を改訂し、その改訂を承認することになる。ただし、RFCを正しく管理しなければ、コストが追加され、開発プロジェクトのスケジュールが遅れる可能性がある。こうした変更の管理は、アジャイル開発のシナリオと非アジャイル開発のシナリオでは異なる。

　例えば、ウオーターフォールモデルを採用している開発チームは、変更管理委員会を任命してBRDを委員会の手に委ねるのが一般的だ。委員会は、変更要求を事前承認する唯一の権限を有し、承認した変更が必要な仕様に従って行われたことを確認する責任も担う。

　一方、アジャイル開発での変更は、RFCの対象範囲に併せて変化するエピックやユーザーストーリーとして追加する形を取る。変更は、次のプロセスを経て行われる。

1. プロジェクト担当者が、開発チームのメンバーを含む監理委員会を編成する
2. クライアント、業務チーム、ソフトウェアチームの各関係者が機能の変更と追加に同意するかどうかの交渉を行う
3. 製品担当者が使用できる一連の新しいユーザーストーリーを開発チームが作成する。このユーザーストーリーは、開発者が新しいプロジェクトタスクとバックログタスク双方の優先順位を再設定するのに役立つ
4. 開発チームはバックロググルーミングセッションでユーザーストーリーを確認し、プロジェクトのスケジュールやワークフローを必要に応じて作り直す

ビジネス要件の完了を判断する方法

　アジャイルチームは、概要計画から最前線のリリースに至るまで、製品開発プロセスの複数のレベルで成否を判断する。ただし、それぞれのレベルでプロジェクトの成否を正確に判断するとしたら、特にBRDを使って成否の判断を行うとしたら、その視点と対象範囲はレベルごとに異なる。アジャイル開発チームが成否を判断する方法を知るのに特に重要なのは次の3つのレベルだ。

リリースレベル

　製品担当者には、製品開発の各段階でコスト、収益、予算に関する情報が次々と手元に届く。この情報を、プロジェクトの対象範囲、スケジュール、予算、品質に対して絶えず比較検討しなければならない。アジャイルチームは、BRDのスケジュール情報に従って期限内に納品され、機能する製品機能の数によって、リリースレベルの成否を判断することになる。

タスクレベル

　製品機能をスケジュール通りに提供するには、アジャイルチームは、スケジュールが定められた開発タスクを複数同時に実行し、ユーザーストーリーを管理し、各機能の継続的な受け入れテストを実行しなければならない。正式コミットに必要な閾値を満たすかどうかを検証するコードの単体テストを実行した数を基に、タスクレベルの成否を判断できる。

ユーザーストーリーレベル

　アジャイルチームでは、機能要件を満たしているかどうかを判断するためのベンチマークとして受け入れ条件を使用するのが一般的だ。開発者は、プロジェクト内の全てのユーザーストーリーの条件を満たしたら、エピックまたは機能について直接ユーザー受け入れテストを実行できる。