第6章 プロジェクト終了後のビジネスアナリシス
ビジネスアナリストの活動の中にはプロジェクト終了後においても、プロジェクト中から引き続き行わなければいけない活動があります。それは要求マネジメントです。要求はシステムが納入され運用されてもまだ価値を提供し続けます。ですからプロジェクト終了後の運用中においても適切に管理する必要があるのです。具体的には次のようなタスクがあります。
要求をトレースする：
影響分析や、カバレッジ、割り当てのために、要求、デザイン、ソリューション・コンポーネント、その他のワーク・プロダクト間の関係を分析し、維持します。プロジェクト終了後においても要求の新たな追加が考えられますから、トレーサビリティは重要です。
要求を維持する：
ライフサイクル全体を通じて要求とデザインを正確かつ最新に保ち、状況に応じた再利用を容易にします。特に再利用は運用中で可能になります。
要求に優先順位を付ける：
特定の要求とデザインに関連する価値、緊急性、リスクをアセスメントし、常に、最も重要なものに対して分析または実装、もしくはその両方に関する作業が実施されるようにします。プロジェクト最中のみならず、運用中においてもシステム改修への要求の優先順位付けは重要です。
変更要求を評価する：
新たなステークホルダー要求および変更されたステークホルダー要求を評価し、チェンジのスコープ内で対応する必要があるかどうかを判断します。プロジェクト終了後の運用中にも変更要求が出てくる可能性があります。
要求を承認する：
ガバナンス・プロセスに関与するステークホルダーと協力し、要求およびデザインについて合意を形成し、承認を獲得します。
これらの活動はプロジェクト中で行うだけでなく、プロジェクト終了後、運用中でも行わなければいけません。そして多くの作業は手作業（エクセル）ではなく専用の要求管理ツールで行うことが奨励されています。
[画像クリックで拡大表示]
プロジェクトが終結したからと言ってビジネスアナリシスの仕事は終了ではありません。ここがプロジェクトマネジャーとの大きな違いです。一般にプロジェクトが顧客に受け入れられるとプロジェクトが終結し、プロジェクトのメンバーは解散します。プロジェクトマネジャーもお役目ご免になりますね。よく考えると、プロジェクトで作成したプロダクトが成功しているかどうかはまだわからないのに、プロジェクトの責任者であるプロジェクトマネジャーはどこかへ行ってしまいます。何か変だと思いませんか。しかし現実はそのようです。では、プロダクトが成功したかどうかを見極める責任は一体誰なのでしょうか。
実はビジネスアナリストがそれを担っています。あまり知られていないかもしれませんが。もちろんスポンサーが最終責任者ですが、納入されたプロダクトがビジネス的に成功しているかどうか、そうでない場合は何をしたらよいのかを見極めるのもビジネスアナリストなのです。ビジネス的な価値が出ていればよいのですが、そうでない場合はプロダクト内の問題（ITで言えば欠陥・バグです）の深刻度、再発の可能性、業務オペレーションに及ぼす影響、さらに事業がその影響をどの程度吸収できるかを判断します。そしてどの問題は解決する必要があり、どの問題は他のアクティビティーやアプローチで軽減でき、どの問題は許容できるかを明らかにします。
また、プロダクト以外の問題、すなわちエンタープライズ側の問題として、組織文化をアセスメントしますが、これはプロジェクト内でステークホルダー・エンゲージメントが高まっていたはず（やる気になっていること）ですが、運用時でのエンゲージメントのチェックにもなります。この時点でエンゲージメントが下がっていると、使われないシステムになりかねないので極めて重要です。
さらに、組織的変革が必要なソリューションにもかかわらず組織がまだ変革されていない場合は組織的変革を提案することにもなります。
組織的変革の活動の例：
- レガシー（従来のソリューション）のままではパフォーマンスが上がらないのみならず、組織の将来が危うくなる恐れがあることを明確に伝える。
- 変革を進めるために連帯チームを結成する。
- 新ソリューション導入後の成功した将来像のビジョンを作成し、戦略を考える。
- 作成したビジョンをさまざまな方法で周知徹底する（ポータルサイト、など）。
- アーリーアダプターの人たちに自発的に変革を体験してもらう。
- その短期的な成功事例を認め、他の多くの人たちにPRする。
- マジョリティの人たちにも、安心して移行を働きかけ、さらに変革を進める。
- 変革を企業文化に定着させる。
（ジョン・コッター「企業変革力」を筆者がカスタマイズしたもの）
ここで重要なのはチェンジを実現することです。いくらバグのない（少ない）ITシステムが構築されて納入されても、ユーザー（顧客）が使用（それがチェンジ）してくれない限り価値は生まれません。いかにして使って（チェンジして）もらうかがポイントです。そのためには良いプロダクトを作成することだけでなく、顧客（やユーザー）が喜んで受け入れてもらうことが何よりも重要です。ですからビジネスアナリシス/BABOKはこのチェンジに重きを置いた知識体系になっていることをご理解いただければと思います。このようにプロダクトのみならず、それを使用するステークホルダー、受け入れてもらう組織構造や組織文化、そしてそれらの相互作用で価値を創出するという、エンタープライズ全体的な視点で考えるアプローチのことをシステム思考と言います。
このシステム思考を理解することがビジネスアナリシスにとって極めて重要です。
【システム思考】
問題や状況を、複数の要素がつながっている全体構造として考える思考であり、次のような考え方をします。
- 「全体」は単なる「部分」の総和ではありません。森は森。木、数万本の集合ではありません。相互作用した全体が意味を持ちます。
- 「問題は全体構造にあります」
- 要素をむやみに排除しません、切り捨てません。
当たり前のことを言っているようにも聞こえるかもしれません。
これは、システム思考とは対極的な位置づけにある分析的思考と比較するとその違いがよく分かります。
分析的思考では、問題や状況を構成している要素（部分）に分けて考える思考（要素分解思考とも言います）であり、次のような考え方をします。
- 「全体」は「部分」の総和です。森は木の集合です。木の相互作用は重視しません。
- 「問題は特定の部分にある」と考えます。ですからその特定部分を取り除くことが問題解決につながります。
- 重要でない要素は排除します、切り捨てます（重点的思考です）。
分析的思考では、アウトプットを重視する客観主義ですので、次のことに重きを置きます。
- 「細部（種類）の複雑性」に着目します
- 分解するための次のような枠組みが重要です
- 「MECE」、「ロジックツリー」、「マトリクス」、「フレームワーク」など
- また「事実と意見を分ける」ことはその基本です。
一方、システム思考はアウトプットではなくプロセスを重視し、動態的であり、客観ではなく主観（内省主義）ですから、次のことに重きを置きます。
- 変化の過程（流れ）、「時間的流れ・順序」「空間的隔たり」「行動の遅れ」
- 人や組織のメンタルモデル（価値観、世界観）まで考慮します
- 自分（気持ち、内的システム）と外部とのつながり
- 長期的で、全体的な課題像を重視しますから、戦略・ビッグピクチャ―・勝ちパターンなどを考察します
分析的思考は、従来問題解決の手段として広く活用されていてその価値は万人が認めるものです、決して分析的思考が劣っているということを主張しているのではありません。この点は注意が必要です。
実はシステム思考が活用されている場面は意外に多く見受けられます。例えば経済学。景気（消費者心理が重要）、気象の予報（天気予報）など。地球の温暖化はまさにシステム思考と言えます。
下図は分析的思考とシステム思考との比較をまとめたものです。
実はBABOKはシステム思考の影響を大きく受けています。
筆者が気付いただけでも下図のようにシステム思考が随所に反映されています。
例えば、ビジネスアナリシスの定義「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにチェンジを引き起こすことを可能にする専門活動」もシステム思考の影響を受けています。具体的にはエンタープライズ：「組織とソリューションからなるシステム」。このシステムはまさにシステム思考の「システム」です。
チェンジを引き起こすためにはステークホルダーの内面（心情や価値観）にまで気を配ることが重要です。単にITシステムを構築するだけでなく、喜んで使ってもらうためにはどうしたらよいかまで考える必要がありますが、まさにシステム思考と言えます。
さらに、「4.5ステークホルダーのコラボレーションをマネジメントする」タスクはステークホルダーの「自発的意思」すなわち、内面（ひとの気持ち）を対象とした新しいタスクでありシステム思考そのものと言えます。システム思考を知らないとBABOK® を理解することができないと言っても過言ではありません。考えてみれば、ビジネスそのものもシステム思考と考えた方がよくわかるのではないでしょうか。ビジネスの全てが分析的思考で構成されていると考えることは難しく、システム思考として捉えた方が合理的かもしれません。
この次のサイクルへの進み方には次のようにいくつかの場面（コンテキスト）があります。
- 受入れ時の問題解決：
バグ修正の小規模なプロジェクト - 受入れ後の運用時の問題：
ソリューションの改修プロジェクトになります。この場合は単なる問題解決（バグ修正）のみならず機能強化も実施されることになりますが、以前取り残された要求（優先順位が高くなくベースラインから外れたもの）を取り込むことを考えるのではなく、その時点の現状（Current）のビジネス状態を反映したものにすることが大切です。 - 長期間に使用していたソリューションの場合：
継続費用（特に保守料）と初期投資を比較したり、機会コストや埋没コストを考慮して、ソリューションを廃止し、新たなソリューション構築のプロジェクトをスタートすることを提案することもあります。
最後にプロジェクト・マネジャーとビジネスアナリストの役割の比較です。
出典： Business Analysis: Best Pracatice for Success by Steven P. Blaise John Wiley & Sons, Inc.
このリストをご覧になった多くのプロジェクト・マネジャーが共通に口にするのは次のようなことです。
- 「でも、左側のBAの役割の仕事もかなりやっています」
- 「やらされていますね」
- 「誰もやってくれないから仕方なくやっています」
ではビジネスアナリシスの仕事に関する研修を受けていますか、と尋ねると帰ってくるのは決まって次のようなことです。
- 「ビジネスアナリシスの研修は受けたことありません。勘と経験と度胸（KKD）で自己流でやっていますから、うまくいくときもあればうまくいかないときもあります。」
大変残念です。このままではいつまでたっても失敗プロジェクトが減りそうにありません。また研修も受けていないのに自己流でビジネスアナリシスの仕事までやらされている日本のプロジェクト・マネジャーは大変お気の毒だと思います。
裁判沙汰にまで発展することになればなおさらです。
真の解決策はプロジェクト委託契約をしっかりすることではありません。ステークホルダーの要求をしっかり定義できるビジネスアナリストを採用または育成することです。
従来のプロジェクト・マネジャー（PMBOK第5版までのPMP）は受講したPMBOK関連の研修では、ビジネスアナリシトとの協働の必要性を何もご存じないと思います。
そしてプロジェクト・マネジャーは本来のプロジェクトマネジメント業務に専念しビジネスアナリストと協働でプロジェクトをマネジメントすることしかありません。