知識エリア：　ソリューションのアセスメントと妥当性確認：

やるべきことが本当にできているかを明確にします

ここで記述するタスクは、ソリューションがビジネスニーズを満たすことを確認し、ソリューションの実装を成功へと推し進めるタスクです。

この知識エリアでは6つのタスクがあります。

• 提案ソリューションをアセスメントする
• 要求を割り当てる
• 組織の準備状況をアセスメントする
• 移行要求を定義する
• ソリューションを妥当性確認する
• ソリューションのパフォーマンスを評価する

 

 

 

以下、タスクを解説します。
（タスクをクリックするとその詳細を説明するページにリンクされます。）

7.1　提案ソリューションをアセスメントする

RFPに回答してくれたソリューション選択肢を比較検討します。ランク付けして最もビジネス価値の高いものを選択します。

7.2　要求を割り当てる

要求をソリューションコンポーネントとリリースに割り当てます。アジャイル開発では要求の優先順位の高いものからビルドすることになります。ウォーターフォール開発でリリースが1回のみの場合は、ソリューションコンポーネントまたはサブシステムに要求を割り当てることです。どちらかというとアジャイル開発を意識したタスクのようです。

7.3　組織の準備状況をアセスメントする

重要なのは組織文化（風土）のアセスメントです。ERPなど失敗例が報告されていますが、原因のほとんどはこの組織文化が新しいソリューションによる変革を受け入れないためのようです。自社のプロセスを重んじる組織文化（日本企業の過去の成功要因でした）では、プロセスをERPに合わせるのではなく、自分のプロセスにシステムを合わせるように多くのカスタマイズをしてしまい、新機能や新バージョンに対応に手間取り、結局うまく機能しなくなっている例もあります。そうならないように、アセスメントが必要です。

7.4　移行要求を定義する

レガシーからERPに移行することを考えてみれば分かりやすいと思います。データ変換、過渡期における新旧2つのソリューションの使い方、要員の教育など、移行に必要な要求をまとめます。

7.5　ソリューションを妥当性確認する

「検証（Verification）と妥当性確認（Validation）」の妥当性確認に相当します。
「ソリューション要求」を満たしていることをチェックするのは「ソリューションの検証」で、「ステークホルダー要求」を満たしていることをチェックするのが「ソリューションの妥当性確認」です。
「ソルーションの検証」は、テスト担当者の責任で、「ソリューションの妥当性確認」がビジネスアナリスト（一部エンドユーザー）の責任です。
テスト担当者によって発見された欠陥は当然ステークホルダー要求に影響を与えますから、ビジネスアナリストが妥当性（欠陥がどの程度ステークホルダー要求を満たしていないか）を確認しなくてはいけません。その程度により、修正するべきか、次の解決策まで待つか、我慢して使用するか、を決めます。

7.6　ソリューションのパフォーマンスを評価する

ソリューションの運用時にそのパフォーマンスを評価します。実際にビジネス価値をどの程度発揮しているのかを測定します。

このタスクはビジネスアナリストが要求をまとめた新ソリューションで行うだけでなく、現行（旧いソリューション）で行うこともありえます。レガシーのパフォーマンスを評価し、新ソリューションへのニーズのインプットもしくは「5.2　能力ギャップを診断する」タスクのインプットになります。