先週は、最近の決算報告で不採算案件の説明をせざるをえなくなったシステムインテグレーターを紹介しました。ビジネスアナリシスを実践しないとこのようなことになってしまう、という実例です。もし、このシステムインテグレーターが何もしないで、この状態がそのまま続くと、この悪影響はさらにひどくなります。決算の営業利益がマイナスになってしまい、赤字決算につながることまで容易に推測できますから、たいへん困ります。
今週は、逆にビジネスアナリシスを実践したらどれだけメリットが出るのかを考えてみましょう。赤字プロジェクトを減少することだけがビジネスアナリシス導入の効果なのでしょうか。まだほかにも大きな効果が期待できます。ビジネスアナリシスの代表的な特徴とそれによるメリット（効果）を紹介します。
ビジネス要求を明確にする：
システムインテグレーターのプロジェクトマネジャーは意外と顧客案件のビジネス要求を知らないものです。例えば、弊社のビジネスアナリシス研修で参加者によく聞く質問です。
読者の皆様もお考えください。
「現在、あなたの参加しているプロジェクトの本当の目的（理由）を知っていますか？」
例えば、
- ビジネスの売上金額（増）
- ビジネスの利益（増）
- 新製品・サービスの提供とそれによる売り上げ・利益
- など。
ユーザー企業の読者なら、当然ご存知の方が多いと思います。しかしシステムを構築する立場のシステムインテグレーターのプロジェクトマネジャーの場合、プロジェクトの品質（Quality）、コスト（Cost）、納期（Delivery）に関して責任があるので、コストは当然管理するためにもしっかり把握しているはずです。しかしプロジェクトの結果、顧客はビジネスでいくらの売り上げを増加しようとしているのか、ビジネスの利益をいくら増加しようとしているのか（それがビジネス要求です）など、までは把握していないことが多いようです。
では、システムインテグレーターのプロジェクトマネジャー（またはビジネスアナリスト）が顧客のビジネス要求を明確にできるようになるとどのようなメリットがあるのでしょうか。BABOKのエンタープライズアナリシスの知識があれば、顧客にビジネスの真のニーズに気づいてもらえるようになります。RFPに書いていないより重要なビジネス機会を得るかもしれません、また、目の前の小さな課題を解決することが大きなコスト削減につながる可能性が明確になるかもしれません。
RFPが常に正しい要求を書いてあるとは限らないのです。顧客のRFPが正しくないこともありうるという事に気づくことも重要です。ですからRFP通りにシステムを構築しても顧客満足につながらないこともあります。
これは、有名な狩野モデルです。ビジネスアナリシスを実践することにより、RFPにかかれていない真のビジネス要求を明確にすることができると、その効果は計り知れません。顧客は自分たちの考えていた以上のビジネス成果が出せることがわかったり、自分たちの考えていたのと異なるやり方の方が、より低コストでビジネス要求を満たせることがわかったりします。まさに、図の「喜びのニーズ（魅力的品質）」が実現することになります。その時のシステムインテグレーターのプロジェクトマネジャー/ビジネスアナリストの立場はどうなるでしょうか。顧客からの信用が飛躍的に高まることになるでしょう。提案価格はもはや大きな問題ではありません。価格競争から脱却することが可能です。十分なマージンのある見積もりを提示することもができます。競合上の優位性が確立されます。
先週のシステムインテグレーターの場合はプロジェクトの本当の目的を把握していたのでしょうか。はなはだ疑問ですね。
特に効果の著しい知識エリアとタスク
- 知識エリア「引き出し」
- 要求に優先順位を付ける
- 要求を妥当性確認する
- 要求のトレーサビリティをマネジメントする
- 要求を割り当てる
知識エリア「引き出し」はBABOKの最大の特徴です。下記9つの豊富な引き出しテクニックを推奨しています。
- ブレーンストーミング
- 文書分析
- フォーカスグループ
- インターフェース分析
- インタビュー
- 観察
- プロトタイピング
- 要求ワークショップ
- 調査とアンケート
ビジネスアナリシスの研修で聞く質問です。読者もお考えください。
「あなたは上記9つの引き出しテクニックの中で、いくつのテクニックを使用していますか？」
使えるテクニックが少ないと、引き出せる情報が限られてしまいます。先週のシステムインテグレーターの例ではプロジェクトメンバーはいくつのテクニックを使って要求の引き出しを行ったのでしょうか。興味のある点ですが公表されていないのでわかりません。
BABOKの場合、大事なことは「引き出し」がタスクではなく、独立した知識エリアとなっていることです。それだけBABOKにおいて「引き出し」が重要視されていることを意味します。
プロジェクトマネジメントの知識体系PMBOK第5版では、プロセス「5.2要求事項収集」が該当します。知識エリア「プロジェクト・スコープ・マネジメント」の中の一つのプロセスとして扱っています。このプロセスは重要なので第4版から追加されたのですが、その扱いはBABOKほど重くありません。また、「引き出し」と「要求事項収集」という用語の違いにも注目してください。「収集」は既にある物を単に集めることです。要求事項がすでに明確に存在することを暗示しています。一方、BABOKの「引き出し」は「潜在的なものを外に取り出す」という意味で、顧客の気が付いていない潜在的な要求を引き出すことまで意味します。ですからBABOKでは、「ビジネスアナリストは真のニーズを引き出すことに責任を負う」（BABOKガイドP3）とまで宣言しているのです。読者の皆様のプロジェクトでは、ステークホルダーの真のニーズを引き出すことに責任を負っているのはどなたでしょうか？ 責任者は明確になっていますか？
「引き出し」能力（テクニックを伴うスキル）が十分に高ければ、先週の不採算プロジェクトの要因だった「現行機能調査不足」等が解消できるのがわかると思います。さらに、顧客の気の付いていない真のニーズまで明確にすることが可能です。
次の「要求に優先順位を付ける」タスクでは、主にビジネス価値をベースに優先順位を付けます。ビジネス価値の少ない要求は実装から外されるだけでなく、分析の対象からも外されます。
三番目「要求を妥当性確認する」タスクでは、ビジネス要求（ビジネスケース）に貢献するステークホルダー要求、ソリューション要求のみに絞られますから、いわゆる金メッキ的な要求が入り込む余地がありません。スコープクリープを未然に防ぐことが可能です。
四番目の「要求のトレーサビリティをマネジメントする」タスクでは、すべての要求がビジネス要求からソリューションコンポーネントまでをトレースすることを確実にします。ムダのない（使われない機能）ソリューションを構築できることになります。
これら3つのタスクが実行できれば、すべての要求がビジネスに価値をもたらし、スリムで無駄のないソリューションにつながることがわかると思います。
五番目は「要求を割り付ける」タスクです。このタスクはソリューションの価値を最大化するために、ステークホルダー要求、ソリューション要求をソリューションコンポーネントとリリースに割り付けます。ソリューションコンポーネントはITとは限りません。ビジネスプロセス、ビジネスルール、組織構造、アウトソース、などが対象です。すべての要求をITに割り付けるとコストが高くなります。コストパフォーマンスを最大化するように、IT以外のソリューションコンポーネントにも割り当てるのです。結果、コストはかなり減少するはずです。ただ、システムインテグレーターの立場とは利害が相反することがありますから注意が必要です。システムインテグレーターはやはり、ITコストを押し上げる方向に動きます。自社の売り上げを第一に考える傾向があるのはやむを得ないことかもしれません。「要求を割り当てる」タスクの目的はソリューションのビジネス価値を最大化することです。システムインテグレーターの売り上げを最大化するのではありません。もしこれが実現できれば、大きな顧客満足につながります。先週のシステムインテグレーターの例では、どこにも顧客の満足を向上することが経営の指標にないのは大変残念に思います。
では、上記のようにビジネスアナリシスが実践できプロジェクトが成功し、顧客のビジネスへの貢献が顕著になったあかつきには、どうなるでしょうか。システムインテグレーターの立場も大きく向上するでしょう。プロジェクトマネジャーの地位も確立し、顧客からの信用も大きく改善されます。社内でも、成功プロジェクトとして表彰されるかもしれません。成功したプロジェクトマネジャーの次のキャリアとしては、何が期待できるでしょうか。ハイレベルなビジネスアナリストかもしれません。それともCIOでしょうか。良いことずくめですね。
最後に、上記BABOKのタスクをプロジェクトにおいてどのように実現すればよいのでしょうか。それは、プロジェクトマネジャーが上記タスクをプロジェクトのアクティビティとして定義し、タスクのアウトプットをプロジェクトのWBSとして作成することです。そしてアクティビティの実行順序を設定し、アクティビティ資源と所要期間を見積もり、スケジュールを作成します。タスクの実行はプロジェクトマネジャーが自ら行っても構いませんし、他のチームメンバーに依頼しても構いません。ただし、ビジネスアナリシスのスキルを有しているメンバーであることが必要です。