いよいよ最終回です。ビジネスアナリシス実務ガイドのドメイン「ビジネスアナリシス計画」を解説します。

BABOKでは知識エリア「ビジネスアナリシス計画とモニタリング」が対応します。

恒例となりますが、BABOK V2の知識エリアをご覧ください。

 BABOK V2　知識エリア：　ビジネスアナリシスの計画とモニタリング

この知識エリアには次の6つのタスクがあります。

2.1 ビジネスアナリシスへのアプローチを計画する
2.2 ステークホルダーの分析を主導する
2.3 ビジネスアナリシスのアクティビティを計画する
2.4 ビジネスアナリシスのコミュニケーションを計画する
2.5 要求マネジメントプロセスを計画する
2.6 ビジネスアナリシスのパフォーマンスを管理する

各々のタスクの概要を解説します。

 2.1 ビジネスアナリシスへのアプローチを計画する

ビジネスアナリシス活動の全体像を規定します。キックオフまでに決めておくべきことは何でしょうか。

要素は次のとおりです。

1. ビジネスアナリシスの作業のタイミング
2. ビジネスアナリシスの成果物の公式度と詳細度のレベル
3. 要求の優先順位付け
4. 変更管理
5. ビジネスアナリシス計画プロセス
6. ステークホルダーとのコミュニケーション
7. 要求アナリシスと要求マネジメントのツール
8. プロジェクトの複雑性

2.2 ステークホルダーの分析を主導する

どのようなステークホルダーがいるのかを分析し、対策を講じます。
要素は次の通りです。

1. ステークホルダーの識別
2. ステークホルダーグループの複雑性
3. ステークホルダーの態度と影響力
4. ビジネスアナリシスの作業に対するステークホルダーの権限レベル

このタスクは計画ではなく、実行するタスクです。重要なことはイニシアチブの期間中、継続的に実行することです。一度だけ実行すればよいというものではありません。

 2.3 ビジネスアナリシスのアクティビティを計画する

ビジネスアナリシスの活動全体を規定します。
他の知識エリアのすべてのタスクの暗黙のインプットとなります。
要素は次の通りです。

1. ステークホルダーの地理的分布
2. プロジェクトとイニシアチブの種類
3. ビジネスアナリシスの成果物
4. ビジネスアナリシスのアクティビティの決定

2.4 ビジネスアナリシスのコミュニケーションを計画する

ビジネスアナリシスの成果物（RFP、BRD、要求仕様書など、）を何時、誰に、どのように伝達するべきかを計画します。
要素は次の通りです。

1. ステークホルダーの地理的分布
2. 文化
3. プロジェクトの種類
4. コミュニケーションの頻度
5. コミュニケーションの公式度

2.5 要求マネジメントプロセスを計画する

引き出してまとめた要求をどのように管理するのかを計画します。
要素は次の通りです。

1. リポジトリ
2. トレーサビリティ
3. 要求属性の選択
4. 要求の優先順位付けプロセス
5. 変更管理
6. 要求マネジメントプロセスのテーラリング

2.6 ビジネスアナリシスのパフォーマンスを管理する

ビジネスアナリストの活動計画のPDCAを回します。計画したタスクを実行した後のチェックとアクションに相当します。
要素は次の通りです。

1. パフォーマンスのメジャー
2. パフォーマンスの報告
3. 予防処置と是正処置

続いてPMIのビジネスアナリシス実務ガイドをご覧ください。

PMI　ビジネスアナリシス：　実務ガイド：　ビジネスアナリシス計画

次の3つのタスク（らしいものもの）があります。

• 3.3　ステークホルダー分析を実施するまたは改善する
• 3.4　ビジネスアナリシス計画書を作成する
• 3.5　ビジネスアナリシス作業を計画する

ビジネスアナリシス計画はあるのですが、活動をモニターしレビューするタスクがありません。知識体系でないのでモレがありますが我慢するしかありません。

このドメインの特徴はプロジェクトマネジャーとビジネスアナリストの協働ポイントが大変多いことです。なんと合計17個もあります。それを見るだけでも、この書籍のメッセージが伝わってきます。特に計画時においてビジネスアナリストとプロジェクトマネジャーは緊密に連携することを強く薦めています。ウォーターフォールの場合はさらに重要になります。

各々のタスクの主な協働ポイントを紹介します。

3.3　ステークホルダー分析を実施するまたは改善する

このタスクはBABOKの「ステークホルダーの分析を主導する」タスクと同等と考えて差し支えありません。計画ではなく、実行系のタスクです。このタスクにも2つの協働ポイントがあります。

協働ポイント

• プロジェクト・マネジャーとビジネスアナリストが、ステークホルダー分析においてどのように協働し、共に作業するかは組織により異なる。しかし、作業の重複を避けるために、両者がプロジェクト・チームやプロダクト・チームと協力し合って作業すれば、より効率がよくなる。

 協働ポイント

• プロジェクト・マネジャーは、ステークホルダーとのコラボレーションとコミュニケーションを含むプロジェクト活動に十分な時間を割くため、プロジェクトの複雑性のレベルを理解することに関心を持つ。

3.4　ビジネスアナリシス計画書を作成する

このタスクの内容を見ると、実に多くの事項をビジネスアナリシス計画書に記述することが分かります。具体的な内容がよくまとまっています。その中は、以下の通りです。

• 引き出しの計画
• アナリシスの計画
• 優先順位付けプロセスの定義
• トレーサビリティアプローチの定義
• コミュニケーション・アプローチの定義
• 意思決定プロセスの定義
• 要求事項の検証プロセスと妥当性確認プロセスの定義
• 要求事項変更プロセスの定義
• ソリューション評価プロセスの定義

このタスクの協働ポイントのいくつかを紹介します。

 協働ポイント

• ビジネスアナリストは、賛同を得るために、主要なステークホルダーと協働しながらビジネスアナリシス計画書を作成すべきである。

 協働ポイント

• ビジネスアナリシス計画書は、要求事項マネジメント計画書と一緒に使うことで効果を発揮する。

 協働ポイント

• プロジェクト・マネジャーとビジネスアナリストはそれぞれ教訓セッションを実施する。すなわち、プロジェクト・マネジャーは完了したプロジェクト活動に関するフィードバックを得る。そしてビジネスアナリストは完了したビジネスアナリシス作業に焦点を当てる。

 協働ポイント

• トレーサビリティの数が適切だとプロジェクト・リスクを減らすのに役立つが、あまり多くのことをトレースすると、プロジェクト・チームの作業を阻害し、コストとスケジュールに影響を与える。

3.5　ビジネスアナリシス作業を計画する

3.4で作成した計画書に基づいた作業（アクティビティ）を計画します。
PMBOKでの「タイムマネジメント」と思えば良いと思います。

このタスクにもいくつかの協働ポイントがあります。

協働ポイント

• プロジェクトのために作成されるビジネスアナリシス成果物は、ビジネスアナリストが決定するが、単独では判断しない。ビジネスアナリストは、スポンサー、プロジェクト・マネジャー、および主要なステークホルダーに意見を求め、ステークホルダーの期待が満たされることを確実にする。”ビジネスアナリストは、プロジェクト・マネジャーと密接に作業すべきである。なぜなら、成果物はプロジェクト・スケジュールに影響を与え、下流のプロジェクト作業への依存関係が発生する可能性があるためである。“

 協働ポイント

• ビジネスアナリストとプロジェクト・マネジャーは、主要なステークホルダーがプロジェクトに対して持つ役割と責任について完全に理解し、合意することを確実にするために利害を共有すべきである。プロジェクト・マネジャーがプロジェクトを通してステークホルダーの期待をマネジメントする一方、ビジネスアナリストは、ビジネスアナリシス活動中、ステークホルダーの期待をマネジメントする。ステークホルダーが期待通りに関わることが確実となるように、両者は一緒に作業する機会をもつ。

合計7回にわたり、PMI発行の「実務者のためのビジネスアナリシス：実務ガイド」の解説をしてまいりました。

読者の皆様の感想など聞かせていただけると嬉しいところです。

よろしくお願いします。

続いてのドメイン「ソリューション評価」に対応するのはBABOK　V2の知識エリア「ソリューションのアセスメントと妥当性確認」です。v3では「ソリューション評価」が最も近い知識エリアになります。

まず、BABOK　V2の知識エリア「ソリューションのアセスメントと妥当性確認」をご覧ください。

BABOK V2　知識エリア：　ソリューションのアセスメントと妥当性確認

この知識エリアには次の6つのタスクがあります。

• 7.1　提案ソリューションをアセスメントする
• 7.2　要求を割り当てる
• 7.3　組織の準備状況をアセスメントする
• 7.4　移行要求を定義する
• 7.5　ソリューションを妥当性確認する
• 7.6　ソリューションのパフォーマンスを評価する

「7.1　提案ソリューションをアセスメントする」タスク

いよいよ、ソリューションを実装するべきかの最終判断をするのがこのタスクです。

単独のソリューションをアセスメントする場合は、その実装を正当化できるようなビジネスバリューがるかどうかを判断します。複数のソリューションをアセスメントする場合は、どのソリューションが最大のビジネスバリューを提供するかを判断します。

もし、実装（投資）を正当化できるほどの価値が認められない場合、プロジェクトを撤回する提案がなされることがあります。それだけビジネスアナリストの責任は重大です。

 「7.2　要求を割り当てる」タスク

ソリューションの価値を最大化するためにステークホルダ要求とソリューション要求を、ソリューションコンポネントとリリースに割り当てます。この「価値を最大化するために．．．」というくだりが極めて重要です。言い換えると、すべての要求をIT（ソフトウェア）に割り当ててしまうとコストが膨れ上がります。手作業やプロセスの変更で満たされる要求はないのでしょうか。

日本ではIT要求に焦点を当てた要求定義が多いようです。BABOKでは要求を実装する対象はITのみならず、組織構造、役割、プロセス、ポリシー、ルールなども実装対象として要求をとらえています。ですから、幅広いソリューションコンポーネント（要求の実装対象）を対象に要求を割り当てます。

もう一つは、リリース計画にも要求を割り当てます。すべての要求を一度に実装すると

開発期間は長くなります。限定した機能でも早期にリリースすることがビジネス価値を高めることもよくあります（ソフトウェア商品など）。競争相手に先駆けて市場を制覇することを考慮するのもビジネスアナリシスの重要なポイントです。

 「7.3　組織の準備状況をアセスメントする」タスク

文化（風土）のアセスメントでは、ステークホルダーに共通する信念や態度や感情、及び変革を受け入れようとする意欲をアセスメントします。

運用のアセスメントでは教育・訓練などが実施されているかをチェックします。

ここで重要なステークホルダーに「組織変革マネジメントのSME」がいます。

 「7.4　移行要求を定義する」タスク

準備状況をアセスメントした結果をもとに、移行要求を定義します。

移行期間において、新旧2つのソリューションが並行に稼働し、情報を移動しなければいけません。また新ソリューションを効率よく運用できるように教育・訓練を実施する必要があります。

組織的変革が極めて重要です。ビジネスアナリストは組織変革をマネジメントするプロセスの開発に参加することになります。

 「7.5　ソリューションを妥当性確認する」タスク

ソリューションの検証（「ソリューション要求」通りに振る舞うかをチェック）はビジネスアナリストではなくテスト担当者の責任です。そのあとソリューションが完成し、ユーザーの受け入れ（UAT）において妥当性を確認します。

欠陥のあるソリューションのアウトプットを調査し、ソリューションのアウトプットが品質レベルの許容範囲に届かないケースを調べて欠陥を識別します。欠陥の重大性、障害発生の可能性、ビジネスに及ぼす影響の重大性、およびビジネスが欠　　陥の影響を吸収できる許容範囲を決定します。

  「7.6　ソリューションのパフォーマンスを評価する」タスク

ソリューションがどれだけ効果的かを実運用において評価します。

ソリューションがもたらす価値を理解し、定量的、定性的なパフォーマンスメトリクスを収集します。パフォーマンス低下の原因があれば次期ビジネスニーズとなります。

ソリューションメトリクスの妥当性を確認する

長年使用していると定義したパフォーマンスメトリクスから見ると優れていても、ビジネス価値につながらない場合は、ビジネスに直結するメトリクスに変更します。

最後にソリューションのリプレイスまたは破棄まで考えます。

• 稼働費用と初期投資
• 機会費用
• 必要性
• 埋没費用（サンクコスト）

ただ、この一つのタスクでソリューションの運用開始から最後のリプレイスまたは廃棄までカバーするのはかなり無理があるのではないでしょうか。

続いて、PMI　BA実務ガイドを見ましょう。

PMI　BA実務ガイド：　ソリューション評価

PMIの「ビジネスアナリシス実務ガイド」のドメイン「ソリューション評価」には次の9つのタスク（もどき）があります。

•  6.3　評価のための推奨されるマインドセット
• 6.4　ソリューション評価を計画する
• 6.5　何を評価するのかを決める
• 6.6　いつ、どのように ソリューションの結果の妥当性を確認するか
• 6.7　受入基準を評価し、欠陥に対処する
• 6.8　推進か中断の決定を促進する
• 6.9　ソリューションのサインオフを獲得する
• 6.10 ソリューションの長期のパフォーマンスを評価する
• 6.11 ソリューションのリプレースとフェーズ・アウト

BABOK V2の知識エリア「ソリューションのアセスメントと妥当性確認」と比較するとタスクの構成が大きく異なることに気が付きます。

手短に言えば、BABOK V2の「7.5　ソリューションを妥当性確認する」タスクと「7.6　ソリューションのパフォーマンスを評価する」タスクだけに焦点が絞られているようです。BABOK V2の他のタスク「7.1　提案ソリューション．．．」「7.2　要求を割り当てる」「7.3組織の準備状況．．．」「7.4　移行要求．．．」に該当するタスクは、BA実務ガイドには存在しません。

では、BA実務ガイドの各タスクの具体的な内容をご覧ください。

 「6.3 評価のための推奨されるマインドセット」

.1 早期かつ頻繁に評価する

評価は予測型ライフサイクルの終わりに行われることが多い（例えば、
ユーザー受入テストやソリューションのリリースなど）。
反復型や適応型のライフサイクルではある時間枠の終わり（例えばイテレーションやスプリント）に評価を行い、カンバン方式のような時間枠が決まっていない適応型アプローチの場合はユーザー・ストーリーの提供時または完了時に評価を行う。

.2 要求事項分析、トレーサビリティ、テスト、評価を補助的活動として取り扱う

「6.4　ソリューション評価を計画する」タスク

評価活動を計画する際に考慮すべき要因のリストです。

• プロジェクトや組織のゴール、目標またはリスクのうち、この評価活動では、どれをモニタリングし、追跡し、確認するか。
• 評価を実施するために必要な時間と労力のコストを誰が負担するのか。
• ソリューションまたはインフラに、評価基準を測定する能力が組み込まれているか。
• 評価に使用する測定データを抽出する方法は既にあるか。
• 選択した評価方法は、効果的で比較的安価に実施できるか。
• 評価結果を報告し公開するための方法が既に存在するか。

6.5　「何を評価するのかを決める」タスク

1. .1 ビジネス上のゴールと目標を考慮する
2. .2 重要業績評価指標を考慮する
3. .3 追加の評価メトリックスや評価受入基準を考慮する
4. .3.1 ソリューション評価へのインプットとしてのプロジェクト・メトリックス
5. .3.2 顧客メトリックス
6. .3.3 セールスとマーケティングのメトリックス
7. .3.4 業務のメトリックスと評価
8. .3.5 機能性　非機能

.4 組織が評価を継続できることを確認する

具体的なメトリクスが解説されていて素晴らしいと思います。BABOKは汎用的で抽象的なタスクになっているので、コンテキストは広いのですが具体性に欠けています。その点ことBA実務ガイドはITソリューションに限定されていてもより具体的な記述になっているので、IT関係の読者には大変ありがたいものとなっています。

6.6　「いつ、どのように ソリューションの結果の妥当性を確認するか」タスク

このタスクでは、主に効果的なテクニック（技法）についての解説です。

1.  調査とフォーカスグループ
2.  探索型テストおよびユーザー受入テストの結果
3.  一日体験テスト(DITL)の結果
4.  統合テスト結果
5.  機能性に期待される結果対実際の結果
6.  非機能要求事項の期待される結果対実際の結果
7.  成果測定と利益の財務計算

6.7　「受入基準を評価し、欠陥に対処する」タスク

1.  期待される結果と実際の結果との比較
2.  許容範囲と実測値を評価する
3.  欠陥を記録し対処する

「6.8 推進か中断の決定を促進する」タスク

「6.9 ソリューションのサインオフを獲得する」タスク

例えば、プロジェクトに対する公式のサインオフは、次のような特性がある場合に、一般的な手続きとなる。

•  事業全体または組織全体にわたって影響のあるプロジェクト
• 許容範囲が達成できない欠陥や失敗があった場合に、死亡あるいは生命、財産、金融ソルベンシーへの受け入れ不可能なレベルのリスクになる可能性があるプロダクト
•  厳密な予測型ライフサイクルに従っている組織でのプロジェクト
•  厳しく規制された産業。例えば、銀行や保険あるいは医療機器、臨床研究、製薬会社など

6.10 「ソリューションの長期のパフォーマンスを評価する」タスク

1.  メトリックスを決定する
   評価の開始前までに重要なメトリックスを特定する。
2.  メトリックスを獲得し、パフォーマンスを測定する
3.  結果を分析する
4.  ソリューションと組織の限界を評価する
5.  ソリューションのパフォーマンスを改善するために推奨されるアプローチ

6.11 「ソリューションのリプレースとフェーズ・アウト」タスク

非常に具体的でわかりやすいと思います。言い方を変えると完全にITソリューションに限定されています。IT関係の読者にとってはうれしい限りですね。図解も豊富で、さすが実務ガイドとうたっているだけのことはあると思います。他のドメインと比較してもより丁寧に解説されています。おそらく執筆者が他のドメインとは異なるのでしょう。ドメインごとに執筆者が異なり、書き方、粒度、タスクのとらえ方が独特なようです。

最後にこのドメインの協働ポイントを紹介します。

協働ポイント

• プロジェクト・マネジャーとビジネスアナリストは監査およびプロジェクトのステークホルダーと連携し、組織にとって必要な、またプロジェクトのために必要なサインオフ活動を決定するために協力すべきである。

長くなりましたので、BABOK v3は割愛します。

続いてのドメイン「トレーサビリティとモニタリング」に対応するのはBABOK　V2の知識エリア「要求のマネジメントとコミュニケーション」です。v3では「要求のライフサイクルマネジメント」が最も近い知識エリアになります。

BABOK V2：　「要求のマネジメントとコミュニケーション」

この知識エリアでは要求をマネジメントする次の3つのタスク、

• 4.1　ソリューションスコープと要求をマネジメントする。
• 4.2　要求のトレーサビリティをマネジメントする。
• 4.3　再利用に備えて要求を保守する

そして要求を伝達（コミュニケーション）する次の2つのタスク

• 4.4　要求パッケージを準備する。
• 4.5　要求を伝達する。

があります。

 「4.2　要求のトレーサビリティをマネジメントする」タスク

要求のトレーサビリティは、ビジネス要求からステークホルダー要求、ソリューション要求、設計、チームが作成する成果物、そしてソリューションコンポーネントまでを双方向につないでいく作業です。さらに要求同士の関連も明確にします。ですからどんなにステークホルダーが強く主張してもビジネス要求につながらない要求は認められないことがあります。

「4.1ソリューションスコープと要求をマネジメントする」タスク

要求（およびソリューションスコープ）の変更を管理し、最終承認までを扱います。一旦承認された要求はベースライン化できます。その後の変更は変更管理プロセスで管理されます。

「4.3　再利用に備えて要求を保守する」タスク

作成された要求が他のプロジェクトや運用時にも参照できるように保守、管理します。
BABOKでは、上記3つのタスクは主に要求管理ツールを使用することが推奨されています。要求が複雑になると、トレーサビリティを効果的に管理するためにはツールが必要です。

「4.4　要求パッケージを準備する」タスク

RFPやBRDなど要求に関するドキュメントを作成します。「要求パッケージ」はビジネスアナリストが作成するさまざまな要求に関するドキュメントで、典型的なものは次の通りです。

• RFP
• BRD
• プロダクトロードマップ
• 要求仕様書
• ビジョン文書

多くの組織では要求文書用のテンプレートが事前に作成されていますが、これらを総称して「要求パッケージ」と呼びます。BABOKのタスクのうまいところで、例えば、上記異なる5種類のドキュメントを作成するとしても、抽象化したタスクとしては「要求パッケージを準備する」となります（ズルい！かもしれませんね）。

「4.5　要求を伝達する」タスク

これも伝達する要求（や要求パッケージ）の数だけ繰り返される継続的なタスクです。ある時はRFPを伝達し、ある時はBRDを伝達します。少なくとも作成されたパッケージの数だけ実行されます。

つづいてPMIのビジネスアナリシス実務ガイドを見ていきます。

PMI　ビジネスアナリシス実務ガイド：　「トレーサビリティとモニタリング」

PMIの「ビジネスアナリシス実務ガイド」のドメイン「トレーサビリティとモニタリング」には次の7つのタスク（もどき）があります。

• 5.2　トレーサビリティ
• 5.3　関連性と依存関係
• 5.4　要求事項の承認
• 5.5　承認済み要求事項のベースライン化
• 5.6　トレーサビリティ・マトリクスを用いて要求事項をモニタリングする
• 5.7　要求事項ライフサイクル
• 5.8　要求事項の変更をマネジメントする

全て要求事項（とプロダクトスコープ）を管理（承認を含めて）することに関するタスクと言えます。

リストを見て気が付きましたが、BABOKの「要求を伝達する」タスクに該当するタスクがありません。この章の概説では「5.6　トレーサビリティ・マトリクスを用いて要求事項をモニタリングする」タスクを通じて要求事項が伝達されることになっているのですが、このタスクの中にはその具体的な記述がありません。作成した要求事項文書は伝達しないのでしょうか。知識体系ではありませんので全てのタスクを網羅する必要はありませんが、少し寂しく感じます。タスクの具体的な内容を見ていきます。

5.2　トレーサビリティ

次の要求事項属性を用いたトレーサビリティ・マトリックスが紹介されています。

• ID
• 要求事項記述
• ビジネスニーズ・好機、ゴール、目標
• プロジェクト目標
• WBS成果物
• プロダクト設計
• プロダクト開発
• テストケース

これはPMBOK第5版のP119に掲載されている図そのものです。要求→設計→開発→テスト　と　下流工程にトレースすることに主眼が置かれているようです。PMBOK第5版と整合を取るためにはやむを得ないのかもしれませんが、もっと上流にフォーカスしてもらいたいような気がします。

5.7　要求事項ライフサイクル

要求事項のライフサイクルを次のように管理する例が紹介されています。

• 提案
• 承認済み
• 進行中
• 完了

一つの考え方として有効ですが、BABOKの要求のライフサイクルの考え方とは異なるようですので注意が必要です。BABOK v3の要求のライフサイクルは後述します。

5.8　要求事項の変更をマネジメントする：タスク

次の変更管理ツールが紹介されています。

• コンフィギュレーション・マネジメント・システム（CMS）
• バージョン管理システム（VCS）

BABOKで紹介されている要求管理ツールは要求そのものを管理しますが、PMIのBA実務ガイドが紹介しているものはどちらかというと設計・構築（実装）で役に立つドキュメントの構成や版を管理することに主眼が置かれています。ビジネスアナリシスというより、プロジェクトマネジメント（設計、構築、テストまで含む）の中での作業にフォーカスされています。PMIらしいというか、PMBOKとの整合性を考えているのかもしれませんね。ビジネスアナリシスへの考え方の違いが出ているようです。

PMIのBA実務ガイドの特徴である「協働ポイント」を紹介します。

 [協働ポイント]

• 誰がスコープをマネジメントするかについて、プロジェクト・マネジャーとビジネスアナリストの間に、しばしば混乱が生じる。プロジェクト・マネジャーにプロジェクト・スコープをマネジメントする責任があるのに対し、ビジネスアナリストにはプロダクト・スコープをマネジメントする責任がある。要求事項を追跡するプロセスは、ビジネスアナリストがプロダクト・レベルでスコープ・マネジメントに関与する明確な例である。第4章で紹介したいくつかの要求事項の引出しと分析モデルも、ビジネスアナリストがモデリングを行っている間、どのようにプロダクト・スコープを分析するかを示す。

最後にBABOK v3をご覧ください。

BABOK v3：　「要求のライフサイクルマネジメント」

要求のライフサイクルの流れは次のとおりです。

• ビジネス・ニーズを要求として表現するところから始まり
• ソリューションの開発作業の間、ライフサイクルは続き
• ソリューションとそれを表現する要求が廃棄された時点で終了します

ソリューションが実装されたからといって、要求の管理が終わるわけではありません。
ソリューションが存続している間ずっと、要求は価値を提供し続けますから、要求を適切に管理する必要があるのです。今はやりのDevOpsと共通の考え方と理解してください。
これが、新しいビジネスアナリシスの要求のライフサイクルの考え方です。PMIのBA実務ガイドの考え方とは異なりますので注意しましょう。

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

次の5つのタスクがあります。

• 5.1　要求をトレースする
• 5.2　要求を維持する
• 5.3　要求に優先順位を付ける
• 5.4　要求変更を評価する
• 5.5　要求を承認する

5.1　「要求をトレースする」　タスク

BABOK V2の「要求のトレーサビリティをマネジメントする」タスクと同じ内容です。左図で、右側のデザイン、コード、テストではなく「ビジネス・ニーズ」↔「ビジネス要求」↔「ステークホルダー要求」↔「ソリューション要求」を結びつけることに主眼を置いています。このBABOK v3の解説の図が　PMIのBA実務ガイド　と　BABOK v3の　トレーサビリティの考え方の違いをよく表しています。

「5.2　要求を維持する」タスク：

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

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

「5.3　要求に優先順位を付ける」タスク：

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

「5.4　要求変更を評価する」タスク：

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

「5.5　要求を承認する」タスク：

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

後半では、「引き出し」が終了し要求を分析することになります。

まずは、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

第3回：【要求事項の引き出しと分析】（前半）

このドメインはBABOKでいう「引き出し」と「要求アナリシス」の2つの知識エリアを合わせた位置付けになります。前半（主に「引き出し」に該当する部分）と後半（主に「要求アナリシス」に該当する部分）に分けて解説します。

BABOK V2：　知識エリア「引き出し」

タスクそのものは次の4つですから単純です。

• 3.1 引き出しを準備する
• 3.2 引き出しアクティビティを主導する
• 3.3 引き出しの結果を文書化する
• 3.4 引き出しの結果を確認する

むしろ引き出しの豊富なテクニックの方が重要です。

• ブレーンストーミング（9.3節）
• 文書分析（9.9節）
• フォーカスグループ（9.11節）
• インターフェース分析（9.13節）
• インタビュー（9.14節）
• 観察（9.18節）
• プロトタイピング（9.22節）
• 要求ワークショップ（9.23節）
• 調査とアンケート（9.31節）

各テクニックの後ろの節番号は　共通テクニックとして第9章にまとめてある節の番号です。上記のようなテクニックは複数のタスクで活用されるので、独立した第9章で解説しています。

PMI　実務ガイド：　要求事項の引き出しと分析（前半）

続いて実務ガイドです。タスクらしいものは次の5つです。

• 4.3 引き出しを計画する
• 4.4 引き出しを準備する
• 4.5 引き出し活動を実施する
• 4.6 引き出し活動のアウトプットを文書化する
• 4.7 引き出しを完了する

最後に「4.8 引き出しの課題や難題」という節があります。

全体的にはBABOK V2のタスクと類似していますが、最大の違いはテクニック（引き出し技法）の解説が全て「引き出し活動を実施する」タスクの中に含まれていることです。読み手に取ってみると大変親切に思えます。BABOKでは一々第9章を参照しなければいけないので手間がかかります。一方いくつかのテクニック（例えばブレーンストーミング）は引き出しだけで行うのではなく、様々な場面（別のタスク）でも使います。一長一短というところでしょうか。

テクニックそのものを見ると、

• ブレーンストーミング
• 文書分析
• ファシリテーション型ワークショップ
• フォーカス・グループ
• インタビュー
• 観察
• プロトタイピング
• アンケートと調査

BABOKとほとんど同じです。「インターフェース分析」がないだけです。タスクも似ていますが、最後の「引き出しを完了する」は実務ガイドに特有です。確かにいつ引き出しを完了するかは重要なことがあります。

「4.5引き出し活動を実施する」タスクはテクニック（引き出し技法）の解説を含めて13ページもあり、至れり尽くせりの感じで解説されています。初めてビジネスアナリシスを学習する人にとってはありがたいと思えるでしょう。一方別のタスク、例えば「4.6 引出し活動のアウトプットを文書化する」タスクは1ページもなく僅か6行のみです。タスクの間でバランスが取れていない感じがします。

[協働ポイント]：ファシリテーション型ワークショップ

• ひとつのファシリテーション型ワークショップに多数のビジネスアナリストが出席するのが常に有効とは限らない。これはプロジェクト・マネジャーとビジネスアナリストが協力する機会である。プロジェクト・マネジャーが書記のような何らかの役割を果たすことにより、この取組みを支援することもできる。そのことで、ビジネスアナリストは課題や情報の引き出しに集中できる。

大変すばらしいプロジェクトマネジャーとビジネスアナリストとの協働ポイントだと思います。日本でこれができるプロジェクトマネジャーがどのくらいいるのでしょうか。日本のプロジェクトマネジャー全員がこの実務ガイドを読まれることを強く薦めます。

 BABOK v3：　知識エリア「引き出しとコラボレーション」

知識エリアのタイトルが「引き出しとコラボレーション」なので、「引き出し」に関するタスクとステークホルダーとのコラボレーション（協働）に関するタスクが混ざっています。

• 4.1 引き出しを準備する
• 4.2 引き出しを実行する
• 4.3 引き出しの結果を確認する
• 4.4 ビジネス情報を伝達する
• 4.5 ステークホルダーのコラボレーションをマネジメントする

最初の3つが「引き出し」で、後半の2つが「コラボレーション」に該当します。

新しいBABOK v3では次のことを強調しています。

「引き出しとコラボレーションの作業は決してビジネスアナリシスの「フェーズ」では
ない。それは、ビジネスアナリシスの作業が発生している限り継続される」

さらに、

「引き出しとコラボレーションは、計画的に行われるもの、計画されずに行われるもの、
あるいは、その両方がある。」

全く新しい考え方が導入されました。V2まではビジネスアナリシスのすべての活動は計画に基づくものでしたが、このv3では「計画されない引き出し活動」が公式なものになったのです。

そして、引き出しを次の3種類に分類しています。

• 協働型：ステークホルダーとの直接のやり取りを伴う。
  （例：インタビュー、ワークショップ、ブレーンストーミングなど：筆者）
• 調査型：チェンジに関与するステークホルダーが直接には認知していない資料または情報源から、情報を体系的に発見し、調査する。
  （例：データマイニング：筆者）
• 実験型：何らかの管理された試験がなければ知ることのできなかった情報を特定する。
  実験はこの種の情報を発見するのに役立つ。実験には、観察研究、概念実証、およびプロトタイプが含まれる。
  （例：プロトタイピング、コラボレーションゲームなど：筆者）

そして、テクニックも以下のように大幅に増加しました。なんと18種類！！

• インターフェイス分析
• インタビュー
• 観察
• 協働ゲーム
• コンセプト・モデリング
• 調査やアンケート
• データ・マイニング
• データ・モデリング
• ビジネス・ルール分析
• フォーカス・グループ
• ブレーンストーミング
• プロセス分析
• プロセス・モデリング
• プロトタイピング
• 文書分析
• ベンチマークと市場分析
• マインド・マッピング
• ワークショップ

テクニックの種類が増えた理由は上記2つのこと、すなわち：

• 引き出しはフェーズではなく、ビジネスアナリシスのすべてのアクティビティとともに行われること、そして
• 引き出しとコラボレーションは計画的に行われるものだけではないことです。

そのため、活用できるテクニックも倍増されたことになります。

特に「協働ゲーム」は共感、プロトタイピングを組み合わせたテクニックで、最近話題のデザイン思考がもとになっています。デザイン思考でニーズを発見しながらプロトタイピングでモノを作り始め、テストしながらだんだん製品化していく。それをビジネスモデル・キャンバスでビジネスモデルを作成する。これが新しいビジネスのやり方です。BABOK v3は最近の手法を大幅に取り入れていることが分かります。

価値の高いビジネスを実践するためには、プロジェクト開始以前がいかに重要であるかが分かります。すなわち、本当に意味のあるニーズ（要求ではありません）を発見することがより重要である、という立場です。

従来（BABOK V2）はプロジェクトの中で要求を引き出す（elicit）ことに注力していました（PMIの実務ガイドも同じ立場です）が、新しいBABOK v3では、要求ではなくニーズ（顧客が気が付いていない）を発見（discover）することにまで注力するようになりました。それは最終的に価値の大きなビジネスを実現するためには、顧客がまだ気が付いていない真のニーズを発見することが不可欠であるということです。ですから計画されない「引き出し」活動まで言及するようになったのです。

こうして2つの知識体系と実務ガイドを比較してみると、その違いがよく分かります。BABOK V2とPMI実務ガイドは主にプロジェクトの中のビジネスアナリシス活動を対象にしています。ところが最新のBABOK v3はプロジェクトが発生する前のビジネスアナリシス活動にも大きく注力しています。

以上で【要求事項の引き出しと分析】の前半を終了します。

次回は後半を解説します。

第2回：【ニーズ評価】

PMIはこの実務ガイドの必要性として次のことを強調しています。

「多くの組織では効果的なビジネスアナリシスがプロジェクト作業に組み込まれていない。その結果として、プロジェクトは意図した事業価値を提供できていない。」

• 過去12カ月では、完了したプロジェクトの64%しか当初のゴールと事業目的を達成していない。
• 過去12カ月では開始したプロジェクトの16%が失敗と見なされた。
• プロジェクト失敗の主な原因として、37%の組織が「不正確な要求事項の収集」を挙げた。

「．．．今日において成熟したビジネスアナリシスの実務を備えている組織は劇的にプロジェクトの成功率を向上させているが、そうでない組織ではコスト高が続いている。」

要求事項をマネジメントすることがいかにプロジェクトの成功に影響を与えるかがお分かりになると思います。そして要求事項を扱うビジネスアナリシスがプロジェクトにとって必要不可欠なものであるかが分かります。日本においてどれだけのプロジェクトがビジネスアナリシスの実務を備えているでしょうか。今、まさにそのことが問題になっていると言えます。

それでは、「2. ニーズ評価」の解説をはじめましょう。

PMIの「ビジネスアナリシス：実務ガイド」の「2. ニーズ評価」はBABOK V2では知識エリア「エンタープライズアナリシス」に該当します。またBABOK v3では知識エリア「戦略アナリシス」が最も近いものと言えます。それではまた、この3つを比較していきます。

BABOK V2　知識エリア「エンタープライズアナリシス」

次の5つのタスクがあります。

• 5.1 ビジネスニーズを定義する
• 5.2 能力ギャップをアセスメントする
• 5.3 ソリューションアプローチを決定する
• 5.4 ソリューションスコープを定義する
• 5.5 ビジネスケースを定義する

緑色の吹き出しの中はタスクの中の「要素」の項目だけ記載しています。詳細な解説までは出していません。上図でわかるようにタスクへのインプット、アウトプットが明記されています。

（図のクリックで拡大）

各タスクごとのテクニックをご覧ください。

5.1 ビジネスニーズを定義する

• ベンチマーク（9.2節）
• ブレーンストーミング（9.3節）
• ビジネスルール分析（9.4節）
• フォーカスグループ（9.11節）
• 機能分解（9.12節）
• 根本原因分析（9.25節）

5.2 能力ギャップをアセスメントする

• 文書分析（9.9節）
• SWOT分析（9.32節）

5.3 ソリューションアプローチを決定する

• ベンチマーク（9.2節）
• ブレーンストーミング（9.3節）
• 決定分析（9.8節）
• 見積もり（9.10節）
• SWOT分析（9.32節）
• フィージビリティ分析

5.4 ソリューションスコープを定義する

• 機能分解（9.12節）
• インターフェース分析（9.13節）
• スコープモデリング（9.27節）
• ユーザーストーリー（9.33節）
• ステートメント

5.5 ビジネスケースを定義する

• 決定分析（9.8節）
• 見積もり（9.10節）
• メトリクスとKPI（重要成果達成指標）（9.16節）
• リスク分析（9.24節）
• SWOT分析（9.32節）
• ベンダーのアセスメント（9.34節）

上述のようにBABOK V2では各タスクごとに使用されるテクニックがリスト化されています。テクニック名の後ろのカッコ内の9.xx節番号は第9章のテクニック章の節番号です。

同じテクニックが複数のタスクで使用できる（例えばSWOT分析など）ため、第9章にテクニックをまとめて解説されています。ただ、本文中はテクニック名だけなので、わかりづらいという難点があります。

 実務者のためのビジネスアナリシス：　実務ガイド　ドメイン「ニーズ評価」

第2章の節をご覧ください。

• 2.1　本章の概要
• 2.2　ニーズ評価を実施する理由
• 2.3　問題または好機を特定する
• 2.4　組織の現状を評価する
• 2.5　ビジネスニーズに対応する活動を推奨する
• 2.6　ビジネスケースを策定する
• 実はタスクが明示されていなく（序章ではタスクを特定すると明記してあったのですが）、上記のような章立てになっていますので、項のタイトルが動詞句である「問題または好機を特定する」などをタスクとみなして上の図を作成してあります。概ねタスクの順番は黄色の矢印とみなして差し支えないと思います。BABOK V2は5つのタスクですが実務ガイドは4つですが、かなり似た内容になっています。

少し詳細に見ていきます。
実務ガイドの最初（おそらく）のタスクの詳細です。

• 2.3　問題または好機を特定する
•   2.3.1 ステークホルダーを特定する
•   2.3.2 問題または好機を 調査する
•   2.3.3 状況を評価するために関連するデータを収集する
•   2.3.4 状況記述の草案を作成する
•   2.3.5 状況記述に対してステークホルダーの承認を得る

残念ながら、インプットやアウトプットは何も規定されていませんが、内容（BABOKの要素に該当する部分）の記述がより詳細で具体的です。親切でわかりやすいと言ってよいと思います。また、テクニックの具体例も示されており、大変わかりやすいと思います。

紹介されているテクニック（技法）は次の通りです。

• SWOT分析
• なぜなぜ分析
• 因果関係図
• 　・魚の骨図
• 　・連関図
• 　・プロセスフロー
• 親和図法
• ベンチマーキング
• 重み付き順位付け

ただ、上記9個のみしか紹介されていなくて、これで本当にビジネス要求が作成できるのか少し不安になるかもしれません。しかし初めてビジネスアナリシスを学習する人やプロジェクトマネジャーには、まずこの程度の知識を持っていただければ十分ではないでしょうか。

前回述べた、[協働ポイント]の具体例です。　「2.3.1　ステークホルダーを特定する」の最後の部分に次のような記述があります。

協働ポイント

• プロジェクト・マネジャーとビジネスアナリストの双方がステークホルダー特定とRACI分析に関心をもつ。プロジェクト・マネジャーがプロジェクトを通じての役割の分析に関心をもつ一方で、ビジネスアナリストは、より詳細な下位レベルでの分析を実施したり、あるいはニーズ評価や要求事項引出しといった特定の領域に集中したりすることがある。お互いに支援し合い、この作業を一緒に実施することもある。お互いの取組みが重複しないようにすることが大切である。

これがこの実務ガイドの最大の価値です。プロジェクト・マネジャーとビジネスアナリストがうまく協力し合わない限りプロジェクトの成功はありません。成功の秘訣とも言える2つの重要な専門職の協力の仕方をまとめてあります。

BABOK v3: 知識エリア「戦略アナリシス」

タスクは次の4つです。

• 6.1 現状を分析する
• 6.2 将来状態を定義する
• 6.3 リスクをアセスメントする
• 6.4 チェンジ戦略を策定する

「ビジネス目標」が「将来状態を定義する」タスクのアウトプット（上図を参照）であることに注目してください。BABOK V2と実務ガイドでは「ビジネスのゴールと目標」は組織から与えられ、それを洗練する（BABOK V2の場合）あるいは評価する（実務ガイドの場合）立場であったのですが、大きく変わりました。ビジネスアナリシスの定義の違いがここに出ています。

また、「リスクをアセスメントする」タスクが加わりました。これも大きな変化です。BABOK V2および実務ガイドでは、リスクはタスクではなく、タスクの下の要素（BABOK V2の場合）やそれ以下のサブ項目（実務ガイドの場合）でしか扱われていません。それはビジネスリスクがすでに考慮されたビジネス目標が上位（おそらくスポンサー）から与えられるので、ビジネスアナリシスの活動の中でリスクはさほど大きく扱われなくてもよいということのようです。 ところがBABOK v3はビジネスそのものを対象としています。プロジェクトで作成するプロダクトだけが対象ではありません。プロダクトはビジネス変革（チェンジ）に必要なソリューションの一つの構成要素（ソリューションコンポーネント）でしかありません。そのためビジネスリスクをしっかりアセスメントし、ビジネスのゴールや目標も決める立場に変わったのです。

テクニックでもビジネスモデルキャンバスが加わったことはビジネスモデルを定義することもビジネスアナリシスの一部であることを意味します。すなわち、ビジネスそのものを定義することを含むようになりました。プロジェクトで作成するプロダクトを主な対象とするBABOK V2および実務ガイドとは本質的に異なることを理解する必要があります。

そのためでしょうか、活用できるテクニックの数も大変多くなりました。
例えば「現状を分析する」タスクでは

• SWOT分析　　　　　　　　　  ・インタビュー
• 課題トラッキング　　　  　　　　・観察
• 機能分解　　　　　　　　　　・教訓
• コンセプト・モデリング　    　　　・根本原因分析
• 財務分析　　　　　　　　　　・スコープ・モデリング
• 組織モデリング　　　　　  　　・調査やアンケート
• データ・マイニング　　　　　　・ビジネス・ケース
• ビジネス能力分析　　　　 　　・ビジネスモデル・キャンバス
• 評価指標とKPI　　　　　  　　・フォーカス・グループ
• プロセス分析　　　　　　  　　・プロセス・モデリング
• 文書分析　　　　　　　　    　・ベンダー評価
• ベンチマーキングと市場分析　　・マインド・マッピング
• リスクの分析とマネジメント　　      ・ワークショップ

なんと、26個のテクニックが推奨されています（決してすべてのテクニックを使用しなければいけないというわけではありません）。

また、このタスクに関与するステークホルダーは

• 運用サポート：
• エンド･ユーザー：
• 規制者：
• 業務領域の専門家：
• 顧客：
• サプライヤー：
• 実装の専門家：
• スポンサー：
• テスト担当者：
• プロジェクト・マネジャー：

かなり種類の多いステークホルダーがこのタスクに関与することが分かります。

実務ガイドと同等のレベルで比較する意味がないかもしれません。

PMI日本支部が【実務者のためのビジネスアナリシス：実務ガイド】を日本語化し、出版しました。

筆者は日本語版の翻訳チームの一員でしたので、連載で解説をしたいと思います。特に、BABOKとの関係について解説する予定です。

【序論】

この「ビジネスアナリシス：実務ガイド」を解説するのに、すでに読者におなじみのBABOKと比較してみます。まずこのガイドそのものの目的をBABOKガイドの目的と比較してみます。

 IIBAのBABOKガイドは専門職（Profession）を定義することに主眼が置かれていますが、PMIの実務ガイドは「ビジネスアナリシスに必要な知識、スキル、およびタスクを特定する」とのことです。

続いてビジネスアナリシスの定義ですが、かなり違うことに気が付きます。

 BABOKガイドのV2では「ステークホルダーの橋渡しとなるタスクとテクニック」だったのですが、今回発行されたPMIの実務ガイドでは「．．．要求事項を引出し、文書化し、．．．マネジメントする一連の活動」ですが、いわばBABOK V2の「ステークホルダー間の橋渡しとなるタスク」を具体的に表現したものと言えます。すなわち、PMIの実務ガイドのビジネスアナリシスの定義はBABOKのV2をもとにしているようです。

ところがBABOK v3の「ニーズを定義し、．．．．チェンジを引き起こすことを可能にする専門活動（Practice）」は「要求」ではなく「ニーズ」ですし、今までになかった「チェンジ」や「価値」が出てきました。BABOK v3ではビジネスアナリシスの定義そのものが大幅に変わりました。BABOK v3の新しい定義については今回は深入りしませんが、別のところで解説しています。こちらを参照ください。

【タスクの特徴】と【タスクの構成】を比較してみます。

ここは本格的な「知識体系」と「実務ガイド」の違いでしょうか。タスクを特定するはずだったのですが、タスクへのインプットやアウトプットは何も記述されていません。しかし、「実務ガイド」の強みはあるはずです。それは次のプロジェクト・マネジャーや他の役割の人との関連がよく記述されていることです。

【プロジェクト・マネジャー、ビジネスアナリスト、その他の役割との関係】

これがこの「実務ガイド」の最大の価値です。

「本実務ガイドは、業界にビジネスアナリシスで行う作業について深い理解をもたらすことにより、また、ビジネスアナリシスがプロジェクト全体の作業にいかに不可欠かを説明することにより、プロジェクト・マネジャーとビジネスアナリストの役割間における協働を改善することを目指している」。PMIではプロジェクト・マネジャーとビジネスアナリストとの良好な関係を築くことがプロジェクトを成功に導く重要な要素であるという認識です。筆者も全く同感です。ただし、日本ではまだプロジェクトにビジネスアナリシスが不可欠であるという認識が少ないのが現状です。こちらの方が大きな問題です。

北米ではプロジェクト内にビジネスアナリストが存在することが常識になっています。最近のPMBOK（第4版以降）では、プロジェクトにビジネスアナリストがいることが前提で知識体系が構築されていますが、日本ではそのことを知らないプロジェクト・マネジャーが殆どのようです。また、PMBOKを教える立場の人ですら理解している人は多くありません。例えば、PMBOKの「要求事項収集」というプロセスは第4版から追加されたプロセスですが、収集するべき「ビジネス要求事項」「ステークホルダー要求事項」「ソリューション要求事項」などはビジネスアナリストが作成することが前提です。ただ、常識なので、そのことが何も記述されていません。日本では、ここをまず改善する必要があります。それからビジネスアナリストとプロジェクト・マネジャーとの関係構築となります。

ガイドの構成（章立て）を比較してみます。

「実務ガイド」は本格的な「知識体系」ではありませんので、比較的コンパクトです。その分軽くて持ち運びも可能ですね。

最後にビジネスアナリシスの対象範囲の比較です。これはビジネスアナリシスの定義の違いに由来しています。

これも対象範囲が狭いので、実務ガイドの内容はかなり具体的な記述や事例が多く、読んでもわかりやすくなっています。一方BABOK、特にv3はプロジェクトのみならずエンタープライズ全体までを対象にし、IT（アジャイルを含む）からBPM、ビジネスインテリジェンス（ビッグデータ関連）、ビジネス・アーキテクチャまで領域が拡大されましたので、書籍のページ数も472ページにもなり、記述も若干抽象的なものになっています。

読み手、特に初めてビジネスアナリシスを知ろうという人にとってはPMIの「ビジネスアナリシス：実務ガイド」が最もわかりやすいと思います。

次回は、「ニーズ評価」を解説したいと思います。