第4回：【要求事項の引き出しと分析】（後半）
後半では、「引き出し」が終了し要求を分析することになります。
まずは、BABOK V2の知識エリア「要求アナリシス」をご覧ください。
BABOK V2 知識エリア「要求アナリシス」
この知識エリアには次の6つのタスクがあります。
- 6.1 要求に優先順位を付ける
- 6.2 要求を体系化する
- 6.3 要求の仕様化とモデリングを行う
- 6.4 前提条件と制約条件を定義する
- 6.5 要求を検証する
- 6.6 要求を妥当性確認する
「6.2 要求を体系化する」タスク
次のようにモデルのコンセプトでカテゴリー化してあります。
- ユーザークラス、プロファイル、ロール（Who/Where）
- コンセプトと関連（What）
- イベント（When）
- プロセス（How）
- ルール（Why）
上記カッコ内の5W1Hは筆者が追加したものですが、BABOKでは明示的ではありませんが5W1Hがいたるところに出てきます。
そして、そのモデルの例は上の表のとおりです。
このようにモデルをカテゴリー分けすることを勧めています。
「6.3 要求の仕様化とモデリングする」タスク
多くのモデリング・テクニックを紹介しています。
- 受け入れ基準と評価基準の定義（9.1節）
- ビジネスルール分析（9.4節）
- データディクショナリと用語集（9.5節）
- データフロー図（DFD）（9.6節）
- データモデリング（9.7節）
- 機能分解（9.12節）
- インターフェース分析（9.13節）
- メトリクスとKPI（9.16節）
- 非機能要求の分析（9.17節）
- 組織モデリング（9.19節）
- プロセスモデリング（9.21節）
- プロトタイピング（9.22節）
- シナリオとユースケース（9.26節）
- シーケンス図（9.28節）
- 状態遷移図（9.29節）
- ユーザーストーリー（9.33節）
「6.5 要求を検証する」タスク
と「6.6 要求を妥当性確認する」タスクが続きます。
この2つのタスクはBABOKの強点です。他の知識体系、CMMIやSWBOK（ソフトウェア知識体系）などにはなく、BABOK で初めて導入された概念としてよく知られています。
「要求検証」は次のような形式的な品質をチェックします。
- 正確性、
- 完全性（漏れがない）、
- 実現可能性、
- テスト可能性、
- あいまいでない、
- …
ただし、その要求がビジネスに役に立つかどうかは何も問いません。あくまで形式的にい漏れや、あいまいでなく、実現できるものなのかを問います。
「要求を妥当性確認する」タスク
このタスクは要求がビジネスに役に立つものなのかを問うのです。
ステークホルダー要求、ソリューション要求のすべてがビジネス要求と整合することを確実にします。「要求の検証」と「要求の妥当性確認」を独立してチェックすることができるのはビジネスアナリストが自らビジネス要求を定義しているからこそなせる業と言えます。ビジネス要求を明確に定義していない他の知識体系では、こうはならないようです。
それでは、PMIの実務ガイドを見ましょう。
PMI 実務ガイド： 要求事項の引き出しと分析（2）
- 4.9 要求事項を分析する
- 4.10 要求事項をモデル化し精緻化する
- 4.11 ソリューション要求事項を文書化する
- 4.12 要求事項の妥当性を確認する
- 4.13 要求事項を検証する
- 4.14 承認セッション
- 4.15 要求事項関連のコンフリクトを解消する
「優先順位付け」は次のドメインにあります。BABOKのタスクの分類と少し異なりますので注意してください。
「4.10 要求事項をモデル化し精緻化する」タスクでは、次のようなモデルのカテゴリーがあります。
- スコープモデル
- プロセス・モデル（How）
- ルール・モデル（Why）
- データ・モデル（What/When）
- インターフェイス・モデル
この章は「要求を分析する」部分なのですが、そこで使用されるモデルだけでなく、「ニーズ評価」や「BA計画」で使用するモデルもリストに含まれていますので注意が必要です。
上記表のモデルの例（26種類）が全て解説されています。ただ、すべてのモデルを使用するわけではないので、よけいに感じる読者もいるかもしれません。一つ一つのモデルは通り一辺倒のうわべの説明のようです。BABOKでは第9章のテクニックの中から必要なものを選んで読めばよいのですが、どちらが分かりやすいかは意見が分かれるところです。
ちなみにBABOK v3はPDF版（IIBA日本支部会員限定版）が供給されていて、テクニックは全てハイパーリンクが貼られていますので、ページをめくらなくてもワン・クリックで見たいテクニックのページに切り替わり、大変便利です。
「4.11 ソリューション要求事項を文書化する」は要求事項を文書化することの重要性を説いています。いかにもウォーターフォールの色彩が強いですが。
ビジネス要求事項文書（BRD）について親切に解説されています。また、ソリューションの文書化は「ビジネス要求事項およびステークホルダー要求事項に適合するために開発されるプロダクトやサービスのフィーチャー、機能、および特性を文書化することである。」すなわち、ソリューションの要件定義を文書化することです。
「4.12 要求事項の妥当性を確認する」と「4.13 要求事項を検証する」の2つのタスクがあるのは良いですね。BABOK V2の良さを踏襲していると思います。ただし、順番がBABOK V2と異なるのは少し気になります。
プロジェクト内での要求事項を分析することは主にビジネスアナリストの責任なので、プロジェクト・マネジャーとの協働ポイントは多くありませんが、次のものがあります。
[協働ポイント]
- プロダクトの要求事項は、ビジネスアナリストに責任がある。プロジェクトの要求事項は、プロジェクト・マネジャーに責任がある。
当たり前のことのようですが、日本では当たり前ではありません。残念ながら、ビジネスアナリスト不在のプロジェクトがあまりにも多いからです。北米ではプロジェクト内にビジネスアナリストがいることが当たり前（常識）になっているのですが、日本ではそうではありません。PMBOKではそれを前提として知識体系ができているのですが、常識なのでどこにも解説されていません。日本のPMBOKを教える人もほとんど知らないようです。
プロジェクトで作成するプロダクトの要求事項の責任者のいないプロジェクトが成功するでしょうか。
最後に、BABOK v3を見てみましょう。
BABOK v3 知識エリア「要求アナリシスとデザイン定義」
次の6つのタスクがあります。
- 7.1 要求を精緻化しモデル化する
- 7.2 要求を検証する
- 7.3 要求の妥当性を確認する
- 7.4 要求アーキテクチャと定義する
- 7.5 デザイン案を定義する
- 7.6 潜在価値を分析しソリューションを推奨する
BABOK v3でのモデルのカテゴリーは次の通りです。
- 人と役割（Who/Where）
- 根拠（Why）
- アクティビティ・フロー（How）
- 能力（How）
- データと情報（What/When）
分類の仕方は異なりますが、似たような方法でカテゴリー分けしています。PMIの実務ガイドと違い、このリストに含まれるモデルは要求アナリシスで有効なモデルのみとなっています。
「7.2 要求を検証する」タスク、続いて「7.3 要求の妥当性を確認する」タスクとなります。
「7.4 要求アーキテクチャを定義する」タスクはツールが不可欠です。「要求アーキテクチャ管理ソフトウェア」です。
上記3つのタスクに関しては別ページで詳しく解説してありますのでご覧ください。
http://kbmanagement.biz/?p=3168
「7.5 デザイン案を定義する」タスクと「7.6 潜在価値を分析しソリューションを推奨する」タスクの詳細は別途解説ページをご覧ください。
http://kbmanagement.biz/?p=3244