トップ > ビジネスアナリシス > （３）要求ライフサイクルのマネジメント

（３）要求ライフサイクルのマネジメント

ビジネスアナリシス ビジネスアナリシス-BABOK

本章全体の解説

要求とデザインの発生から廃棄までのマネジメント（ライフサイクル）を扱います。要求のライフサイクルは、ビジネスニーズを要求という形にするところから始まり、ソリューション開発期間中はライフサイクルは継続します。ソリューションが実装されても管理対象となりえます。要求が廃棄されればライフサイクルは終了となります。

 

また、要求はライフサイクルの中で洗練されていきます。序論の中でも掲載した図をもう一度載せておきます。

本章内のタスクを整理すると以下の通りです。

基本的に要求とデザインがタスクによって洗練されるだけです（トレースするタスクを行うとトレースされた要求になる）。ただ、要求変更の評価はインプットアウトプットが他のものと異なるので注意してください。

1.要求をトレースする

要求をトレースするとは要求の系統を文書化することです。

要求やデザインが詳細化されると管理している表現が異なります。詳細化によりレベルが変わった要求やデザインを同じ系統のものとして管理しておく必要があります。この関係性が追えないと当初の要求が本当に実行されたのか（前方トレーサビリティ）がわからなくなったり、デザインを見直したい場合にそもそもなぜそのソリューションを必要としたのか（後方トレーサビリティ）が判断できなくなります。要求管理ツールが大きな力を発揮します。

また、トレーサビリティは有益ではありますが、公式度が高くなるほど一般的にコストがかかります。そのため、便益とコストのバランスをとるという観点も重要な要素です。

トレーサビリティの関係には以下の種類があります。

  • 派生：要求が別の要求から派生した場合
  • 依存：要求に依存関係がある場合
    • 必然性：別の要求と同時に実装されないと意味のないもの
    • 作業効率：関係する要求が実装されれば効率的に実装できるもの
  • 充足：要求を満たした実装の要素となっているか
  • 妥当性確認：実装の要素は要求を満たしているか

このタスクにより、表明された（トレースされた）要求とデザインに変わります。

 

2.要求を維持する

ここでは、要求のライフサイクルを通し、要求の精度と一貫性を維持することが目的です。これによりアクセスしやすくなり、要求の再利用もしやすくなります。要求の中には長期的に使用する要求もあります。それらは要求の一部しか実装されなかったり、長期的に改良する場合があります。業務領域の専門家にニーズが反映されているか定期的に確認することも有効です。

要求を適切に管理するには、正確性と最新性の確保が重要です。また、コンテキストと要求本来の意図が失われないようにする必要があります。

要求の属性も重要な要素です。情報源や優先順位があると管理がしやすくなります。

適切な抽象度で保管しておくと要求を長期で利用する際に再利用しやすくなります。

 

このタスクにより、精緻化・モデル化された（維持された）要求とデザインに変わります。

 

3.要求に優先順位をつける

要求の相対的価値を決め、価値の最大化を目指します。

評価方法の代表としては、MoSCoW 分析があります。

優先順位付けに影響する要因には以下のものがあります。

1.便益

2.ペナルティ

3.コスト

4.リスク

5.依存性：要求間の依存性

6.時間依存性：時間によって要求の価値が変わる

7.安定性：要求が変わる可能性

8.規制やポリシー順守

他に優先順位に関してのトピックは、立場により優先順位は異なるという点と、時間の経過とともに優先順位は変化するという点です。

 

このタスクにより、優先順位付けされた要求とデザインに変わります。

 

4.要求変更を評価する

要求/デザインの変更プロセスと捉えています。アプローチにより評価の公式度は異なります。（予測型は公式度が高い。適応型は公式度が低い）

変更を評価する際に影響分析をする要素は以下の5つです。

  • 便益
  • コスト
  • 影響：影響が及ぶ顧客、影響が及ぶビジネスプロセス
  • スケジュール
  • 緊急性：重要度のレベル。規制、安全性

影響分析の結果、明らかになった影響と解決策は文書化し、すべてのステークホルダへ伝達します。

5.要求を承認する

インプットは、検証された要求とデザインです。承認に関してはビジネスアナリストに責任が求められるところです。

ステークホルダーの承認を得る

ビジネスアナリストにはステークホルダの承認を得る責任があります。サインオフの権限を誰が持っているか理解しておく必要があります。ただし、意思決定に影響を及ぼすステークホルダが多数いることにも注意が必要です。

衝突と課題の管理

承認を得る前にステークホルダ間で意見が衝突することは多々あります。衝突が発生した場合はステークホルダで調整するよう促します。これは実務でもすごく役立つ視点です。私も内心ではどちらかの肩を持ちたいような場合でも、議論を整理するような話の持っていき方で当事者同士で意見を言ってもらうようにしています。

合意を獲得する

承認は投資を正当化できることをステークホルダ全体で認識した証です。ステークホルダに理解してもらう責任があります。

承認を追跡し伝達する

承認の決定は責任をもって記録します。承認を得た後も、要求のステータスを把握できるようにしておく必要があります。（承認済み/実装済み）

 

このタスクにより、承認された要求とデザインに変わります。

 

以上が、要求ライフサイクルのマネジメントのまとめです。