プロジェクト中　（その4）

2016/10/08

【プロジェクト中】　（その4）

今週は次のタスクを解説します。

知識エリア【引き出しとコラボレーション】

ビジネスアナリシス情報を伝達する

知識エリア【要求アナリシスとデザイン定義】

デザイン案を定義する
潜在価値を分析しソリューションを推奨する

【ビジネスアナリシス情報を伝達する】タスク：

このタスクは知識エリア「引き出しとコラボレーション」の中のタスクです。
なぜ「プロジェクト中」の後半で解説するのがよいのかを説明します。

それはまず冒頭で述べたように、知識エリアのくくり方が論理的に似たタスクを集めたものでしかなく、フェーズやタスクの実行順序とは関係ないからです。ステークホルダーとのコラボレーション（協働作業）という意味合いで、知識エリア「引き出しとコラボレーション」に含まれていますが、タスクを実行するタイミングとしては、プロジェクト中で要求が固まってきた頃に頻繁に実行されます。

これから解説しますが、RFPやBRD（Business Requirement Document:ビジネス要求文書）、要求仕様書など（これらを「要求パッケージ」と言います）を作成し、それを関係するステークホルダーに伝達するのがこのタスクです。ですから「要求アナリシスとデザイン定義」のいくつかのタスクを実行して要求がまとまってきた頃に実行されます。

ビジネスアナリストは、適切な時期に、適切な情報を、そのニーズに沿った形式で、ステークホルダーに伝達しなければいけません。そのためには、BA情報パッケージをまとめる必要があります。このBA情報パッケージは以前「要求パッケージ」と呼ばれていたものです。バージョン3では要求のみならず、そのもととなる「ニーズ」から始まり、要求、デザイン、ソリューションコンポーネントなど、幅広い情報を扱うようになりました。そのため従来「要求」を重点に扱ってきたものを一般化し「ビジネスアナリシス情報（BA情報）」という言い方に変わりました。

BA情報パッケージの例としては、次のようなものがあります。

ビジネスケース
BRD（ビジネス要求文書）
RFP（提案要求書）
要求仕様書、要件定義書など、
プロダクトロードマップ

必要なパッケージを準備しなくてはいけません。
要求やデザインをまとめた文書（ウォーターフォールの場合）がメインで形式としては公式文書、非公式文書、プレゼンテーションがあります。
ウォーターフォールを好む組織では公式な書式やテンプレートが用意されていると思います。

BRD（ビジネス要求文書）は日本ではあまり聞きなれないかもしれません。ビジネス要求とステークホルダー要求をまとめたドキュメントです。一部の組織ではソリューション要求まで含めているものも見かけます。北米ではビジネスアナリシスの公式文書として重要視されています。

上記のBA情報パッケージ（BRD、RFP、要求仕様書、など）が作成される都度、このタスクは実行されます。いつ誰にどのBA情報パッケージを伝達するのかは「3.2 ステークホルダー・エンゲージメントを計画する」タスクで計画します。

伝達手段としては、

グループ・コラボレーション（すなわちワークショップやレビューなど）
個別コラボレーション（インタビュー）
E-mailその他

知識エリア「要求アナリシスとデザイン定義」

【デザイン案を定義する】タスク：

最初に行うことは、ソリューション・アプローチを決めること、すなわち購入するのか、作成するのか、あるいはそれらを組み合わせるのかを決めます。

作成：スクラッチ開発や、既存のソリューションを改修することです。インプットの要求（妥当性が確認された、優先順位付き）をもとにデザイン案を作成します。
購入：要求を満たす商品（SWパッケージ）の中からソリューション・コンポーネントを選択します。RFPに対してベンダーが提案してきたソリューション提案やソフトウェアパッケージやクラウド・ソリューションが該当します。
また、作成と購入の組み合わせもあります。

続いて、要求をソリューション・コンポーネントに割り当てます。その目的はソリューションの価値を最大化するためです。すべての要求をIT（ソフトウェア）に割り当ててしまうとコストが膨大になってしまうおそれがあります。コストパフォーマンスを考慮し、最適なバランスを考えてコンポーネントに割り当てます。またリリースに割り当てることも重要です。競争相手のあるソリューションの場合、リリース時期によってその価値は大きく変わります。すべての要求を一度のリリースに割り当てると、市場への投入時期が競争相手より遅くなり、ソリューションによる売り上げが目標を達成しなくなるかもしれません。そのようなことのないように、要求をリリースに割り当てる必要もあります。

要求をITに割り当てたものがITシステム要件となります。
デザイン案を定義することはシステム要件定義を含みます。

日本でのやり方と少し異なるのでわかりづらいかもしれません。

要求の定義を思い出してください。
「要求は、ニーズの理解しやすい表現である。要求では、その要求を満たすことによって、どのような価値を提供できるかに焦点を当てる。」

具体的には要求は、次のようなソリューション・コンポーネントを対象とします。

IT（ソフトウェア・アプリケーション）
ビジネス・ポリシー、ビジネス・ルール
ビジネス・プロセス
人、職務機能と責任
組織構造
意思決定
その他

上記はBABOKバージョン2で提唱されていたものです。V3では「ニーズの理解しやすい表現」と、さらに抽象化されてしまい、わかりづらくなってしまったかもしれません。

上の図は知識エリア「戦略アナリシス」のアウトプットである、「ソリューション・スコープ」や「ギャップ」から、知識エリア「要求アナリシスとデザイン定義」の「モデリングする」タスクや「要求アーキテクチャを定義するタスク」そして「デザイン案を定義する」タスクのテクニックをエンタープライズアーキテクチャの5W1Hの観点で並べてみたものです。上から下までスムーズにつながることがお分かりになるでしょうか。

BABOKガイドを読み通しても、ソリューション・スコープから、モデリング、要求アーキテクチャ、デザイン案の要素のつながりは見えにくいものです。それは知識体系としての網羅的にまとめているため、実際のビジネスアナリシス業務の流れとは関係が薄いためでしょう。ですからエンタープライズ・アーキテクチャ（EA）もしくは5W1Hで縦串を通して眺めるとわかりやすいのではないでしょうか。

このタスクでより重要なことは前述したようにIT（およびソフトウェア）以外のソリューション・コンポーネントに要求を割り当てることです。下のような図になります。

多くの日本のシステム開発ではこのIT以外の要素がおろそかになっているのではないでしょうか。それを表すのが下の図です。

要求も最初からITシステムに関することのみに焦点が当てられています。

それを極端に表現してみると次の図のようになります。

これではITシステムを作成することが目的になってしまっているようです。

ビジネスを改善することが本来の目的で、ITシステムは手段のはずです。手段の目的化になってしまっている感じです。

【潜在価値を分析しソリューションを推奨する】タスク

このタスクの目的は複数のデザイン案の中から、潜在価値が最大なものを選択し推奨することです。

各デザイン案の潜在価値を他の案と比較して評価します。推奨したい最善の案が存在しない場合もあれば、最善の案が明確である場合もあります。また、提案されたデザインのすべてが却下され、適切なデザインを再定義しなければならないこともあります。また、何もしないことが最善案ということもありえます。

ですから、次のことを行います。

まず、期待する便益を明確にします。プラスの価値として便益、リスクの減少、ポリシー・法規制の遵守、ユーザー・エクスペリエンスの改善などがあります。
ついで、予想コストを明確にします。購入／実装のコストのみならず、運用コストや保守コスト、工数、無駄な時間、情報リソースのコスト、人的リソースのコスト等があります。
そして、潜在価値を決定します。上記便益と予想コストをもとに算出します。
最後に、各デザイン案を評価し、ベストなソリューションを推奨します。

市場セグメントを代表する顧客は、その要求の便益とデザイン案のコストの分析に参加します。プロジェクト・マネジャーはチェンジの効果が出たときに、リスクまで含めて、潜在的な影響を把握するために、選定プロセスを管理します。そしてスポンサーは、ソリューションを購入または開発の支出を承認し、最終的な推奨案を承認します。