知識エリア【アナリシス】
主要概念
「アナリシス」は、情報（要望や要求など）をより深く理解し、完全なものとし、洗練させるために、それら（要望や要求）を調査し、詳細化し、統合し、明確にするプロセスです。プロジェクトで実行される主要な活動のひとつであり、通常は相当な工数を確保する必要があります。 この知識エリアにはプロダクト情報（要望や要求）を分析し、モデル化し、そして文書化するだけでなく、その情報が正しい情報であり、標準に準拠し、ゴールにつながっていることを追跡し、固有のリスクを特定し、プロダクト・デザインに変換できる、といったことを確実にします。
知識エリア「アナリシス」の全体像をプロセスマップで表示します。
[画像クリックで拡大]
ご覧の通り、この知識エリアはプロセスが9つあります。
最もプロセスの多い知識エリアです。それだけビジネスアナリシスにとって重要な知識エリアと言えます。
7.1 アナリシス・アプローチの決定
- 定義
アナリシスの実行方法について事前に考えるプロセスです。分析対象、作成すると最も有益となりそうなモデル、要求事項や他のプロダクト情報の検証、妥当性確認、優先順位付け方法などが含まれます。PMBOKと異なり、計画書とは言わずにアナリシス・アプローチと言います。 - ベネフィット
ソリューションを開発するために実行すべきビジネスアナリシス作業についての共通の理解を支援することです
インプット
- 引出しのアプローチ
- プロダクトスコープ
- 状況記述書
- トレーサビリティと監視のアプローチ
ツールと技法
- ブレーンストーミング
- 文書分析
- レトロスペクティブと教訓
アウトプット
- アナリシス・アプローチ
7.2 モデルの作成・分析
インプット
- アナリシス・アプローチ
- 確認済み引出し結果
- 要求事項と他のプロダクト情報
ツールと技法
モデル・カテゴリーの図を参照してください。
[画像クリックで拡大]
重要なことは5つのカテゴリーすべてを網羅するように複数のモデリング・テクニックを選択することです。そうすることにより要求のモレをなくすことが可能になります。ひとつだけのモデリングですべての要求をカバーすることはできません。スコープモデルはビジネス要求事項を明確にする場合に使用することがあります。プロセスモデル、ルールモデル、データモデルはステークホルダー要求事項やソリューション要求事項に主に使われます。インターフェースモデルはソリューション要求事項です。主にITシステムへの要求です。
アウトプット
- アナリシス・
- モデル（複数）
アウトプットのモデルが複数なことに注意してください。決して一つだけのモデルですべての要求が分析できるわけではありません。データの視点、プルセスの視点など複数の角度（視点）から要望や要求を分析する必要があります。最近では特にプロセスからビジネスルールや意思決定を分離して管理することがビジネス上の優位性をもたらすことに注目され始めてきています。
7.3 要求事項の定義と詳細化
- 定義
さまざまな相手に求められる適切な詳細度、適切な様式、および適切な公式度で、要求事項および他の種類のプロダクト情報を精緻化し、文書化するプロセスです
- ベネフィットは次の二つです
(a)プロダクト情報についての詳細を明確にすることを助け、チームが効果的に作業できるようにすること
(b)すべてのステークホルダーがアクセスし処理できる方法でプロダクト情報を蓄積すること
インプット
- アナリシス・アプローチ
- アナリシス・モデル
- 確認済み引出し結果
- 関係と依存関係
- SHエンゲージメントとSHコミュニケーションのアプローチ
ツールと技法
- ビジネス・ルール・カタログ
- Readyの定義
- 用語集
- プロダクト・バックログ
- 要求管理ツール
- ストーリー精緻化
- ストーリー・スライシング
- ユースケース
- ユーザー・ストーリー
これら技法のなかで、Readyの定義、ストーリー精緻化、ストーリーマッピングなどのアジャイル系の技法に注目してください。このBAガイドはかなりアジャイル開発を意識していることが分かります。
アウトプット
- 要求事項と他のプロダクト情報
このアウトプットの要求事項はビジネス要求事項、ステークホルダー要求事項、ソリューション要求事項などが含まれます。主な対象はステークホルダー要求事項とソリューション要求事項なのですが、さらにビジネス要求事項まで含まれることも注目です。
ここですべてのプロダクト情報を合わせたものとして要求事項パッケージを作成します。要求事項パッケージとは次のような要求に関連するドキュメントです。ウォーターフォール型では公式なドキュメントとして作成されることが多いと思います。
- RFP
- BRD
- 要求仕様書類（例：要求事項定義書）
7.4 受入れ基準の定義
- 定義
ソリューションのひとつ以上の側面の開発が成功したことの証明となる基準について合意を得るプロセスです - ベネフィット
実現されることについての共通理解の基礎を与えることに加え、要求事項を洗練することを助ける補完的な洞察を与えるます
インプット
- アナリシス・アプローチ
- アナリシス・モデル
- 要求事項と他のプロダクト情報
- ソリューション評価アプローチ
ツールと技法
- 振る舞い駆動開発
- Doneの定義
- ストーリー精緻化
アウトプット
- 受入基準
7.5 要求事項の検証
- 定義
要求が十分な品質であることを確認するプロセスです - ベネフィット
要求事項が組織の規定された標準を満たす方法で表現されたり、理解されたりする可能性が高まること。すべての利害関係者へ要求事項を伝えることを可能にし、最終的なプロダクトの品質に貢献します
インプット
- アナリシス・アプローチ
- BA組織標準
- コンプライアンスまたは規制標準
- 要求事項と他のプロダクト情報
ツールと技法
- INVEST
- ピア・レビュー
- INVESTは次の6項目の略語です。
-Independent（独立している）
-Negotiable（交渉の余地がある）
-Valuable（価値がある）
-Estimable（見積もり可能）
-Small（小さい）
-Testable（テスト可能）
アウトプット
- 検証された要求事項と他のプロダクト情報
要求事項の検証はあくまでも要求事項の形式的な品質のチェックです。BA組織標準やINVESTを満足しているからと行ってビジネス的に意味のあるものであるかは何も問われていません。そのビジネス的に意味があるものかをチェックするのがつぎの妥当性確認です。ソフトウェア開発ではソフトウェアの検証はテストで行います。単体テストや総合テストです。そしてソフトウェアの妥当性確認はユーザーによる受入れ検査です。ユーザーにとって意味のあるものか（使い物になるのかどうか）はユーザーによる受入れ検査でチェックされますね。それと類似のことを要求事項においても行います。
7.6 要求事項の妥当性確認
- 定義
要求事項がビジネス・ゴールとビジネス目標を満たしているか確認するプロセスです。言い換えるとステークホルダー要求事項、ソリューション要求事項、移行要求事項がビジネス要求事項と整合することを確実にします。 - ベネフィット
ステークホルダーの期待を逸するリスクや、誤ったソリューションを提供するリスクを最小限に抑えます
インプット
- 受入れ基準
- アナリシス・アプローチ
- ビジネス・ゴールとビジネス目標
- 要求事項と他のプロダクト情報
ツールと技法
- デルファイ法
- ゴール・モデルとビジネス目標モデル
- トレーサビリティ・マトリクス
- ウォークスルー
アウトプット
- 妥当性確認された要求事項と他のプロダクト情報
要求事項の検証と妥当性確認を独立したプロセスで行えるのはなぜでしょうか。ビジネスアナリシス以外の知識体系ではほとんど見うけられません。CMMIやソフトウェアエンジニアリング知識体系（SWEBOK）では主に要求事項の検証までです。ビジネスアナリシスのみビジネス要求を定義しているからなせる業と言えます。
7.7 要求事項と他のプロダクト情報の優先順位付け
- 定義
個々のプロダクト情報がどのようにステークホルダーの目標を達成するかを理解し、作業の順位付けを促進するために、他の合意された優先順位付け要素と共にその情報を利用するプロセスです - ベネフィット
要求事項がどのようにしてゴールと目標を達成するかについてすべてのステークホルダーの考えを一致させること、そして、それに基づいて要求事項をイテレーションやリリースに割り当てる方法を見極めます
インプット
- アナリシス・アプローチ
- ビジネスのゴールと目標
- 変更要求
- 関係と依存関係
- 要求事項と他のプロダクト情報
ツールと技法
- バックログ・マネジメント
- ゴールモデルとビジネス目標モデル
- イテレーション計画
- カンバン・ボード
- 優先順位付けの仕組み
- ストーリー・マッピング
- トレーサビリティ・マトリクス
アウトプット
- 優先順位付けされた要求事項と他のプロダクト情報
7.8 プロダクトリスクの特定・分析
- 定義
ソリューションの定義、開発、および期待される結果の成功に前向き、または後向きの影響を与える前提条件と不確かさをあらわにし検討するプロセスです - ベネフィット
ビジネスアナリシス活動の不確かさへの予防的マネジメントを助けることと、プロダクトの潜在的な強みと弱みを明らかにし先を見越して対処すること
インプット
- アナリシス・アプローチ
- ビジネス・ゴールとビジネス目標
- EEF
- プロダクト・スコープ
- 要求事項と他のプロダクト情報
ツールと技法
- コンテキスト・ダイアグラム
- エコシステム・マップ
- 引出し技法
- 見積り技法
- 組織図
- プロセス・フロー図
- プロダクト・バックログ
- リスク・バーンダウンチャート
- リスク登録簿
- 根本原因分析と好機分析
- SWOT分析
アウトプット
- プロダクト・リスク分析結果
7.9 プロダクト・デザイン案の評価
- 定義
ビジネス・ゴールとビジネス目標、想定導入コスト、実現可能性、および付随するリスクに基づいて、ソリューション・デザイン案を特定し、分析し、比較し、そしてこの評価結果を利用して、提示されたデザイン案に関する推奨を行うプロセスです。 - ベネフィット
デザイン案の情報に基づいた推奨が可能となります
インプット
- .1 ビジネス・ゴールと ビジネス目標
- .2 EAとBA
- .3 優先順位付けされた要求事項と他のプロダクト情報
ツールと技法
- 親和図法
- ブレーンストーミング
- 競合分析
- フォーカスグループ
- プロダクト・バックログ
- リアル・オプション
- ベンダー評価
アウトプット
- .1 実行可能なデザイン案