PMI 【実務者のためのビジネスアナリシス：実務ガイド】解説（2）（ニーズ評価）

 

第2回：【ニーズ評価】

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

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

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

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

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

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

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

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

比較_BA実務ガイド_エンタープライズアナリシス 2016年11月28日

次の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章にテクニックをまとめて解説されています。ただ、本文中はテクニック名だけなので、わかりづらいという難点があります。

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

比較_BA実務ガイド_ニーズ評価 2016年11月28日

第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: 知識エリア「戦略アナリシス」

比較_BA実務ガイド_戦略アナ 2016年11月28日

タスクは次の4つです。

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

 

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

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

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

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

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

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

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

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

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

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