2010年2月22日

このタスクへのインプットは、　「前提条件と制約」、「要求（優先順位付き、かつ承認済み）」、「ソリューション（選択肢）」　です。

このタスクでは、複数のソリューション（候補）がある場合には、もっともビジネス価値の高いものを選択します。また、ソリューション（候補）が一つの場合は、その実装を正当化できるだけの価値があるかどうかを、見極めます。

【質問】

Q1：ソリューション（候補）はだれが作成するのですか？

ビジネスアナリストはソリューションを作らないのでしょうか。

Q2：このタスクはいつ実行するのでしょうか？

Q3：どのように、もっともビジネス価値の高いものを選択するのですか？

Q4：ソリューション（候補）が実装するだけの価値が正当化できなかったらどうするのでしょうか。

Q5：このタスクのアウトプットはどのタスクで使用されるのでしょうか。

Q6：このタスクに関与する主なステークホルダー誰ですか？

A1：ベンダーがRFPに呼応して提案してくれますので、そのソリューション（複数）をアセスメントします。A社、B社、C社などからソリューションの提案が出てきます。

ビジネスアナリストの仕事はRFPを作成することと、そのソリューション提案を評価するのが主な仕事です。自分がソリューションを作ることではありません。役割が異なりますね。

また、社内プロジェクトの場合はRFPと言わずに、BRD（ビジネス要求文書）と言います。社内RFPだと考えてよいと思います。

A2：タスクの実行時期ですが、上記インプットが揃っていればいつでもできます。

やはりソリューション（候補）が準備されている必要があります。

A3：選択方法

要求には優先順位がついていないと、ソリューション候補に優先順位を付けるわけにはいきませんね。複数のソリューション（候補）がある場合、以下のようなランク付けが有効です。

何を評価項目とするのか、その重要度（重みづけ）をどのように決めるかなどは、ビジネスや組織で決めることです。

A4：実装するだけの価値が正当化できなかったらどうするのでしょうか。

それはビジネス上の価値が正当化できませんから、このイニシァチブをキャンセルすることを提言することになります（少なくともBABOK(R)ではそのような考え方をします）。ただ、日本の市場ではどこまで可能でしょうか。ビジネスアナリストはその勇気を持つ必要があるということではないでしょうかす。

A5：このタスクのアウトプット。

アウトプットは「提案ソリューションのアセスメント」です。

このアウトプットを使用するのは「ソリューションの選択」または「ソリューションの設計」で、ともに外部のタスクで、ビジネスアナリストの仕事ではありません。

A6：関与するステークホルダー

ドメインのSMEは選択過程に参加してもらいましょう。プロジェクトマネジャは選択プロセスを計画し、マネジメントしてもらいます。サプライヤ（ベンダー）にはソリューション（候補）の情報を提供してもらいます。そして、スポンサーはリソースの投入を承認し、最終提案を承認してもらいます。

お分かりのように、このタスクのアウトプットで最終的な承認をもらいます。それだけ重要なタスクということになります。