PMI-BA　全体像

【PMI ビジネスアナリシス・ガイド】　解説　（1）

米国PMIからBusiness Analysis Guideが発行され（2017年）、最近PMI日本支部よりPMIビジネスアナリシス・ガイド（日本語版）が出版されました（2019年7月）。　筆者は従来よりIIBA日本支部のBABOK担当理事を務めていますが、このたびPMI日本支部のPMI-BAガイド翻訳チームにも参画しPMI-BAガイドの日本語化にも協力させていただきました。おかげでIIBAとPMI、両方のビジネスアナリシスに関する知識体系に精通することになりましたので、これからPMI-BAガイドの解説を連載でお届けいたします。まず、PMI-BAガイドの全体像です。

序章
ビジネスアナリシスの実施環境
ビジネスアナリストの役割
ニーズ評価
ステークホルダー・エンゲージメント
引出し
アナリシス
トレーサビリティと監視
ソリューション評価

PMBOK®ガイドにお馴染みの方はお気づきかと思いますが、章の構成がPMBOK®ガイドと同じで第4章から知識エリアです。序章では、このガイドで記述される次の要点がまとめられています。

ビジネスアナリシスの作業とそれが重要な理由を明らかにする。
ビジネスアナリシスのタスクや活動を効果的に実行するために必要なコンピテンシー、プロセス、ツール、技法を説明する。
ビジネスアナリシスに関連する概念を明らかにする。
ビジネスアナリシス活動を実行する人たちと協働ポイントを強調する。
組織やビジネスアナリシス専門家のための共通のビジネスアナリシス用語を提供し、広める。

PMI-BAガイドでのビジネスアナリシスの定義は次の通りです。

ビジネスアナリシスは、ソリューションの実現を支援するために実行される一連の活動。

具体的には次のことを行います。

問題と機会を見極め、ビジネス・ニーズを特定し、それらのニーズに合致する実行可能なソリューションを推奨して、戦略的な意思決定を支援する。
要求事項やその他のプロダクト情報を引出し、分析し、特定し、伝達し、マネジメントする。
ベネフィットを定義し、価値を測定し実現しその結果を分析するためのアプローチを定義する。

参考までにIIBAのBABOKのビジネスアナリシスの定義は次の通りです。

ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動

BABOKの方が抽象的かもしれませんね。PMI-BAガイドはより具体的でわかりやすいと言えます。また、プルジェクトマネジメントとビジネスアナリシスの違いを次のように明確にしています。

プロジェクトマネジメントの主な焦点はプロジェクトであり、
ビジネスアナリシスの主な焦点はプロダクトである。

言い換えると、プロジェクトにおいてプロダクトの仕様（要件定義）の責任者はビジネスアナリストだということです。当たり前と言えばそれまでなのですが、日本では残念ながらビジネスアナリスト不在のプロジェクトが多いので、2つの役割の区別があまり意味を成しません。その分、プロジェクトマネジャーにしわ寄せが行っているのが実情ではないでしょうか。PMBOK®ガイドはプロジェクト内にビジネスアナリスト（要求の専門家）がいることが前提で構築されています。そのことを認識していない組織（発注側にも、受注側も）が多いように見受けられます。プロジェクトの失敗例が後を絶たないのもうなずけるというものです。やっと最新のPMBOK®ガイド第6版でプロジェクト内のビジネスアナリシスの重要性が遅まきながら記述されるようになりました。これからは事態が改善されることを期待します。 PMIらしくポートフォリオ、プログラムやプロジェクトのマネジメントとの関係も明確にしています。

「ビジネスアナリシスは、状況を明らかにし、組織が取り組みたいと望んでいる問題や機会を完全に理解することから始める。この作業はプロジェクト開始前の事前作業とみなされる。プロジェクト開始前の活動の結果は、特定のプロジェクトがポートフォリオやプログラムを提供する価値を理解するための情報を提供する。」

ここで重要なのは「プロジェクト開始前の事前作業（Pre-Project）」と明言していることです。いかにもプロジェクトマネジメントが主体であるという立場が鮮明です。 PMI-BA®ガイドには次の6つの知識エリアがあります。

ニーズ評価
ステークホルダー・エンゲージメント
引出し
アナリシス
トレーサビリティと監視
ソリューション評価

PMBOK®ガイドと同じ、プロセス群という考え方があり、次の6つのプロセス群があります。

定義・整合　：新しいプロダクトの開発や既存プロダクトの改修や撤退、プロダクト、ポートフォリオ、プログラム、プロジェクトの全体的な組織戦略と整合する実行可能性を調査します。
立上げ　：プロジェクトなどの目標を定義し，リソースを適用します。
計画　：ビジネスアナリシスを実行するための最適なアプローチを決定し、内部、外部のステークホルダーを分析します。
実行　：要求やプロダクト情報を引き出し、モデル化し、検証し、妥当性を確認し、承認し、優先順位付けなどを実行する。
監視・コントロール　：継続的に実行され、プロジェクトなどで提案された変更要求の影響を評価し、BAパフォーマンスを評価し、ステークホルダーとの継続的なコミュニケーションとエンゲージメントを確実にします。
リリース　：ソリューションの全部または一部をリリースする必要があるかどうかを判断し、運用チームに移行する準備ができているという合意を得ます。

立上げ、計画、実行、監視・コントロール　はPMBOK®ガイドと全く同じなので、PMBOK®ガイドにお馴染みな読者には親しみやすいと思います。そうするとPMBOK®ガイドでお馴染みの知識エリアとプロセス群との関係が気になりますよね。尚、知識エリアの具体的内容は次回以降で解説しますので少しお待ちください。次の表がPMBOK®ガイドでもお馴染みのプロセス群と知識エリアとの対応表です。

［画像クリックで拡大］

各知識エリア内にある合計35個プロセスが、「定義・整合」から「リリース」までのプロセス群に割り振られているのをご覧ください。PMBOK®ガイドときわめて類似していることが分かります。
各知識エリアの詳細は次回以降の連載で解説いたしますのでお待ちください。

第2章のビジネスアナリシスの実施環境はPMBOK®と類似していますので省略します。

第3章はビジネスアナリストの役割について懇切丁寧に解説されています。

第1章でプロジェクトマネジメントとビジネスアナリシスの違いでもありましたが、その責任に違いを再度強調しています。

プロジェクト・マネジャーはプロジェクト実行の成功に責任をもつ
ビジネスアナリストは、プロダクト実現の成功に責任をもつ

日本ではビジネスアナリスト不在のプロジェクトが多いようですが、プロダクト実現の成功に責任を持つ人がいないのでは、プロジェクトの成功率が上がらないのもうなずけるというものではないでしょうか。

ビジネスアナリストが協働関係を持つ役割の解説が多くあります。

ビジネス・ステークホルダーと顧客
設計チーム
ガバナンス
政府機関
機能部門マネジャー
ポートフォリオ・マネジャーとプログラムマネジャー
プロジェクト・マネジャー
プロジェクト・スポンサー

最も重要なプロジェクト・マネジャーとの協働関係をご紹介します。

ビジネスアナリストとプロジェクト・マネジャーは、この２者の間で強い関係とパートナーシップが構築されると、プロジェクトの成功に大きな影響を及ぼすことができる。プロジェクト・マネジャーとビジネスアナリストの仕事上の関係はお互いの信頼と尊敬の上に築かれるべきである。そして、お互いに相手の強みを活かすようあらゆる努力をすべきである。協働は、スポンサー、ステークホルダー、その他のプロジェクト・メンバーに対してともに前面に出て対応するのに必須である。コミュニケーションは整合するべきであり、ほとんどの活動において双方が相手を支援できるようにすべきである。

まさにプロジェクトはプロジェクト・マネジャーとビジネスアナリストが2人三脚で進めるべきことがよくわかると思います。

次回からは各知識エリアを解説します。