知識エリア【要求のライフサイクル・マネジメント】

 

この知識エリアの最大の特徴は全てのタスクのインプットとアウトプットが要求管理ツール/リポジトリとのやり取りをすることです。BABOKではこの知識エリアでもツールの使用を重視しています。ツールの使用を前提とした知識エリアです。

 

【要求をトレースする】タスク：

要求のトレーサビリティには前方トレーサビリティ、後方トレーサビリティ、他の要求との関係の3種類があります。

• 前方トレーサビリティ：ある要求やデザインをソリューション・コンポーネントまで結びつけること
• 後方トレーサビリティ：ある要求やデザインを上位のビジネス要求に結びつけること
• 要求間の関係：　要求同士の関係です。要素の項で詳細を記述します。

次の図はプロセスのトレーサビリティとソフトウェアのトレーサビリティの関係を示しています。

ソフトウェアに関しては、通常のトレーサビリティはソリューション要求から設計、コード、テストにトレースされるのですが、BABOKではさらに上位のステークホルダー要求、ビジネス要求にまで遡ってトレースされることが重要とされています。

どの関係を使ってトレーサビリティを管理するのかは「ビジネスアナリシス情報マネジメントを計画する」タスクで決めておきます。そして、その結果を要求管理ツールに設定しておけば、あとはツールが支援してくれますから、トレーサビリティをマネジメントすることは大変容易になります。逆に、このようなツールを使用しないと複雑な要求間のトレーサビリティを管理することはほとんどできないと言ってよいでしょう。

 

 

 

 

 

 

要求間の影響図です。ある要求を変更するとその影響がどの要求や設計などに影響するのかをグラフィックに表示してくれますから極めて便利です。

【要求を維持する】タスク：

このタスクこそ、要求管理ツールで要求やデザインをマネジメントすることです。

要求を管理するのはツール内のリポジトリーです。これを手動（エクセルなど）で行うことはほとんど不可能と言ってよいでしょう。

要求の属性を管理することも要求管理ツールが自動的に行ってくれます。「ビジネスアナリシス情報マネジメントを計画する」タスクで、このプロジェクトではどの属性を使って管理するのかを決めて、それを要求管理ツールに登録しておけば、あとはツールが支援してくれるので属性の管理も大幅に手が省けます。

要求の再利用も同様です。ただこれは要求管理ツールの仕様（機能）に大きく依存します。あるツールは特定プロジェクト内での要求を管理することだけを支援してくれます。別のツールはエンタープライズ全体で要求をシェアすることまでサポートするものもあります。そのようなツールを使用すれば、他のプロジェクトから当該プロジェクトで作成した要求を再利用することも容易に支援してくれます。また、開発フェーズを越えて、運用フェーズにおいても、開発フェーズで開発された要求をそのまま使用することも可能になります。ですからツールの仕様に大きく依存します。

 

要求の管理、要求属性、再利用、は「ビジネスアナリシス情報マネジメントを計画する」タスクの中で定義しておき、要求管理ツールに設定しておけば、ツールが強力に支援してくれるようになります。

 

【関係タスク：ビジネスアナリシス情報マネジメントを計画する】

「トレーサビリティ」、「再利用」、「要求の属性」はこの計画タスクの中で事前に計画しておきます。以下、簡単に解説します。

要素：トレーサビリティ・アプローチを計画する

• ドメインの複雑さ、
• 要求のビューの数、
• 要求に関するリスク、組織標準、適用される規制要件、
• トレースに関係するコストと便益

上記を過度の費用をかけずに価値を付加できる詳細度で、トレーサビリティのやり方を決めておきます。

要素：要求の再利用を計画する

品質標準、サービス・レベル・アグリーメント、生産しているプロダクトに関する要求などは組織が継続的に満たさなければならない要求です。またユーザー・インターフェイスのように複数のシステム、プロセス、プログラムで共通に使用できる要求も再利用されます。

要素：保存とアクセス

ビジネスアナリシス情報の保存方法には多くの方法がありますが、この計画タスクで決めておきます。保存とアクセスの方法の決定に影響を与える、どのツールを使用するかは、前述の「ビジネスアナリシス・アプローチを計画する」タスクで決めておきます。

要求管理ツール・リポジトリは、保存したあらゆる情報のステータスを示すことができ、また時間の経過と共に情報の修正も可能です。それなりの高度な要求管理ツール（リポジトリ）を使用することが奨励されます。

要素：要求の属性

一般的な要求の属性の例です。

• 絶対参照番号：
• 作成者：
• 複雑さ：
• オーナーシップ：
• 優先順位：
• リスク：
• 情報源：要求の出所です。
• 安定性：要求の成熟度です。
• ステータス：
• 緊急性：

大規模（例えば、ウォーターフォールで1年がかり）なプロジェクトでは、管理するべき属性はそれなりに多く（例えば10種類ぐらい）必要かもしれません。しかし、の小規模（3か月程度）のアジャイル・プロジェクトでは、それほど多くの属性を管理する必要がないかもしれません。ですから、当該プロジェクトにおいて管理するべき属性を前もって決めておく必要があります。そして決めたらその属性を要求管理ツールに設定すればよいのです。あとはツールが属性の管理を支援してくれますので非常に楽になります。逆に、もしツールを使用しないとすると、要求属性の管理は大変です。

【要求に優先順位を付ける】タスク：

要求に優先順位を付けることは極めて重要です。優先順位の高いものから実装されますから、ビジネス価値をベースに決めることが多いです。

BABOKでは、次のような優先順位付けの方法を推奨しています。

• 便益：実装するとビジネス的にメリットが大きいもの
• ペナルティ：契約上、実装しないとペナルティーが発生するもの。
• コスト：
• リスク：ソリューションが実現可能でないリスクがある場合は、最も実装が難しい要求を最優先させる考え方です。失敗しても被害を最小にします。成功すれば便益も大きくなる可能性があります。
• 依存性：ある要求が完了しない限り、別の要求も完了しないという要求間の関係です。
• 時間依存性：その日を過ぎると、実装の価値が下がってしまう、いわゆる「賞味期限」です。競争相手のあるプロダクト、クリスマス商戦が重要な商品も該当します。
• その他。

ここでは、優先順位付けに有効なテクニックを紹介します。

 

• グループ化：優先順位を高、中、低などの区分に従って、要求を分類します。日本でもおなじみです。要求管理ツールは、優先順位の区分を属性としてリスト化する機能をサポートしています。アジャイルでポピュラーなMosCow優先順位付け（Must/Should/Could/Won’tの4種類に分類する方法）もグループ化の一例です。
•  ランク付け：要求を、その重要度に応じて並べます。アジャイルのプロダクト・バックログ・リストがその例です。
•  時間制限／予算制限：固定リソースの割り当てを基に、要求に優先順位を付けます。時間制限はプロジェクト・チームが決められた期間内に提供できる作業量を基に要求に優先順位を付ける際に使用されます。最近のアジャイル開発でよく好まれる方法です。
•  交渉：ステークホルダー間の合意をもとに優先順位を決めます。

 

【要求変更を評価する】タスク：

要求やデザインに対して提案された変更を評価します。
このタスクは、新しいニーズが生じたり、可能性のあるソリューションが新たに明らかになったりしたときに実行します。

予測型アプローチ（ウォーターフォール）では、提案された変更に対してより公式度の高い評価が必要です。個々の変更の影響が極めて大きく、多くの手戻りを引き起こす可能性があるからです。

トレーサビリティは影響評価を行うときの有効なツールです。要求が変化したときに、関連する他の要求やソリューション・コンポーネントにも変更が必要になるかもしれませんので、要求管理ツールがあると、影響分析を支援してくれます。

【要求を承認する】タスク：

このタスクの目的は、ビジネスアナリシス作業を継続したり、ソリューションの構築を進めるために、要求とデザインについて合意と承認を得ることです。
予測型アプローチでは一般に、承認はフェーズの最後か、定期的に行われる変更管理会議の中で行います。適応型アプローチの場合は、要求を満たすソリューションの構築と実装を開始できるようになったときにのみ行います。
このタスクへのインプットは次の通りです。

• 要求（検証された）：後続の精緻化や開発において信頼性のある作業単位として使用できる、十分な品質があることを既に検証された要求一式
• デザイン：後続の精緻化や開発で使用できると判断されたデザイン一式

【重要】このインプットは単なる要求ではなく、要求一式（およびデザイン一式）であることが重要です。承認された要求一式は、ビジネスアナリシスの最終決定のワーク・プロダクトであり、実装されることになります。

ビジネスアナリストは、ステークホルダーの承認を得る責任があり、誰が意思決定の責任を持ち、誰がサインオフの権限を有しているのかを把握しておかなければいけません。また、要求について協議したり報告するべき影響力のあるステークホルダーも考慮しましょう。

要求の承認要請に先立って、ステークホルダーに合意してもらいます。その方法については「ビジネスアナリシス・ガバナンスを計画する」タスクの中の「意思決定」で計画しておきます。

上記3つのタスク、

• 要求に優先順位を付ける
• 変更要求を評価する
• 要求を承認する

を実行するために「ビジネスアナリシス・ガバナンスを計画する」タスクで事前にそのやり方を計画しておきます。

 【関係タスク：BAガバナンスを計画する】

要素：優先順位付けのアプローチを計画する

実装のタイミング、期待される価値、依存関係、リソースの制約条件、方法論などをベースに、要求の優先順位付けの方法を決めます。

• 優先順位付けプロセスの公式度と厳密性
• 優先順位付けに関わる参加者
• 優先順位付けのテクニック、
• 優先順位付けの方法を決定するプロセス
• 優先順位付けに使用する基準。たとえば、コスト、リスク、価値など。

どのステークホルダーが優先順位付けの役割を持つかについても、このアプローチで決めます。

要素：変更管理プロセス

次の変更管理プロセスを定義しておきます。

• 変更を要求するためのプロセスを決定する：
• 変更要求の要素を決定する：

要素：意思決定

• 意思決定の議論への参加者
• 意思決定のプロセスへ経験と知識を提供する当該分野専門家
• 情報のレビュアー
• 決定の承認者

意思決定のプロセスでは、チームが合意に達することができない場合の対処方法を定義します。

左の図は知識エリア「要求のライフサイクル・マネジメント」の各タスクと要求管理ツール、そして2つの計画タスクとの間の関係を図解したものです。