第6回： 【ソリューション評価】
続いてのドメイン「ソリューション評価」に対応するのはBABOK V2の知識エリア「ソリューションのアセスメントと妥当性確認」です。v3では「ソリューション評価」が最も近い知識エリアになります。
まず、BABOK V2の知識エリア「ソリューションのアセスメントと妥当性確認」をご覧ください。
BABOK V2 知識エリア： ソリューションのアセスメントと妥当性確認
この知識エリアには次の6つのタスクがあります。
- 7.1 提案ソリューションをアセスメントする
- 7.2 要求を割り当てる
- 7.3 組織の準備状況をアセスメントする
- 7.4 移行要求を定義する
- 7.5 ソリューションを妥当性確認する
- 7.6 ソリューションのパフォーマンスを評価する
「7.1 提案ソリューションをアセスメントする」タスク
いよいよ、ソリューションを実装するべきかの最終判断をするのがこのタスクです。
単独のソリューションをアセスメントする場合は、その実装を正当化できるようなビジネスバリューがるかどうかを判断します。複数のソリューションをアセスメントする場合は、どのソリューションが最大のビジネスバリューを提供するかを判断します。
もし、実装（投資）を正当化できるほどの価値が認められない場合、プロジェクトを撤回する提案がなされることがあります。それだけビジネスアナリストの責任は重大です。
「7.2 要求を割り当てる」タスク
ソリューションの価値を最大化するためにステークホルダ要求とソリューション要求を、ソリューションコンポネントとリリースに割り当てます。この「価値を最大化するために．．．」というくだりが極めて重要です。言い換えると、すべての要求をIT（ソフトウェア）に割り当ててしまうとコストが膨れ上がります。手作業やプロセスの変更で満たされる要求はないのでしょうか。
日本ではIT要求に焦点を当てた要求定義が多いようです。BABOKでは要求を実装する対象はITのみならず、組織構造、役割、プロセス、ポリシー、ルールなども実装対象として要求をとらえています。ですから、幅広いソリューションコンポーネント（要求の実装対象）を対象に要求を割り当てます。
もう一つは、リリース計画にも要求を割り当てます。すべての要求を一度に実装すると
開発期間は長くなります。限定した機能でも早期にリリースすることがビジネス価値を高めることもよくあります（ソフトウェア商品など）。競争相手に先駆けて市場を制覇することを考慮するのもビジネスアナリシスの重要なポイントです。
「7.3 組織の準備状況をアセスメントする」タスク
文化（風土）のアセスメントでは、ステークホルダーに共通する信念や態度や感情、及び変革を受け入れようとする意欲をアセスメントします。
運用のアセスメントでは教育・訓練などが実施されているかをチェックします。
ここで重要なステークホルダーに「組織変革マネジメントのSME」がいます。
「7.4 移行要求を定義する」タスク
準備状況をアセスメントした結果をもとに、移行要求を定義します。
移行期間において、新旧2つのソリューションが並行に稼働し、情報を移動しなければいけません。また新ソリューションを効率よく運用できるように教育・訓練を実施する必要があります。
組織的変革が極めて重要です。ビジネスアナリストは組織変革をマネジメントするプロセスの開発に参加することになります。
「7.5 ソリューションを妥当性確認する」タスク
ソリューションの検証（「ソリューション要求」通りに振る舞うかをチェック）はビジネスアナリストではなくテスト担当者の責任です。そのあとソリューションが完成し、ユーザーの受け入れ（UAT）において妥当性を確認します。
欠陥のあるソリューションのアウトプットを調査し、ソリューションのアウトプットが品質レベルの許容範囲に届かないケースを調べて欠陥を識別します。欠陥の重大性、障害発生の可能性、ビジネスに及ぼす影響の重大性、およびビジネスが欠 陥の影響を吸収できる許容範囲を決定します。
「7.6 ソリューションのパフォーマンスを評価する」タスク
ソリューションがどれだけ効果的かを実運用において評価します。
ソリューションがもたらす価値を理解し、定量的、定性的なパフォーマンスメトリクスを収集します。パフォーマンス低下の原因があれば次期ビジネスニーズとなります。
ソリューションメトリクスの妥当性を確認する
長年使用していると定義したパフォーマンスメトリクスから見ると優れていても、ビジネス価値につながらない場合は、ビジネスに直結するメトリクスに変更します。
最後にソリューションのリプレイスまたは破棄まで考えます。
- 稼働費用と初期投資
- 機会費用
- 必要性
- 埋没費用（サンクコスト）
ただ、この一つのタスクでソリューションの運用開始から最後のリプレイスまたは廃棄までカバーするのはかなり無理があるのではないでしょうか。
続いて、PMI BA実務ガイドを見ましょう。
PMI BA実務ガイド： ソリューション評価
PMIの「ビジネスアナリシス実務ガイド」のドメイン「ソリューション評価」には次の9つのタスク（もどき）があります。
- 6.3 評価のための推奨されるマインドセット
- 6.4 ソリューション評価を計画する
- 6.5 何を評価するのかを決める
- 6.6 いつ、どのように ソリューションの結果の妥当性を確認するか
- 6.7 受入基準を評価し、欠陥に対処する
- 6.8 推進か中断の決定を促進する
- 6.9 ソリューションのサインオフを獲得する
- 6.10 ソリューションの長期のパフォーマンスを評価する
- 6.11 ソリューションのリプレースとフェーズ・アウト
BABOK V2の知識エリア「ソリューションのアセスメントと妥当性確認」と比較するとタスクの構成が大きく異なることに気が付きます。
手短に言えば、BABOK V2の「7.5 ソリューションを妥当性確認する」タスクと「7.6 ソリューションのパフォーマンスを評価する」タスクだけに焦点が絞られているようです。BABOK V2の他のタスク「7.1 提案ソリューション．．．」「7.2 要求を割り当てる」「7.3組織の準備状況．．．」「7.4 移行要求．．．」に該当するタスクは、BA実務ガイドには存在しません。
では、BA実務ガイドの各タスクの具体的な内容をご覧ください。
「6.3 評価のための推奨されるマインドセット」
.1 早期かつ頻繁に評価する
評価は予測型ライフサイクルの終わりに行われることが多い（例えば、
ユーザー受入テストやソリューションのリリースなど）。
反復型や適応型のライフサイクルではある時間枠の終わり（例えばイテレーションやスプリント）に評価を行い、カンバン方式のような時間枠が決まっていない適応型アプローチの場合はユーザー・ストーリーの提供時または完了時に評価を行う。
.2 要求事項分析、トレーサビリティ、テスト、評価を補助的活動として取り扱う
「6.4 ソリューション評価を計画する」タスク
評価活動を計画する際に考慮すべき要因のリストです。
- プロジェクトや組織のゴール、目標またはリスクのうち、この評価活動では、どれをモニタリングし、追跡し、確認するか。
- 評価を実施するために必要な時間と労力のコストを誰が負担するのか。
- ソリューションまたはインフラに、評価基準を測定する能力が組み込まれているか。
- 評価に使用する測定データを抽出する方法は既にあるか。
- 選択した評価方法は、効果的で比較的安価に実施できるか。
- 評価結果を報告し公開するための方法が既に存在するか。
6.5 「何を評価するのかを決める」タスク
- .1 ビジネス上のゴールと目標を考慮する
- .2 重要業績評価指標を考慮する
- .3 追加の評価メトリックスや評価受入基準を考慮する
- .3.1 ソリューション評価へのインプットとしてのプロジェクト・メトリックス
- .3.2 顧客メトリックス
- .3.3 セールスとマーケティングのメトリックス
- .3.4 業務のメトリックスと評価
- .3.5 機能性 非機能
.4 組織が評価を継続できることを確認する
具体的なメトリクスが解説されていて素晴らしいと思います。BABOKは汎用的で抽象的なタスクになっているので、コンテキストは広いのですが具体性に欠けています。その点ことBA実務ガイドはITソリューションに限定されていてもより具体的な記述になっているので、IT関係の読者には大変ありがたいものとなっています。
6.6 「いつ、どのように ソリューションの結果の妥当性を確認するか」タスク
このタスクでは、主に効果的なテクニック（技法）についての解説です。
- 調査とフォーカスグループ
- 探索型テストおよびユーザー受入テストの結果
- 一日体験テスト(DITL)の結果
- 統合テスト結果
- 機能性に期待される結果対実際の結果
- 非機能要求事項の期待される結果対実際の結果
- 成果測定と利益の財務計算
6.7 「受入基準を評価し、欠陥に対処する」タスク
- 期待される結果と実際の結果との比較
- 許容範囲と実測値を評価する
- 欠陥を記録し対処する
「6.8 推進か中断の決定を促進する」タスク
「6.9 ソリューションのサインオフを獲得する」タスク
例えば、プロジェクトに対する公式のサインオフは、次のような特性がある場合に、一般的な手続きとなる。
- 事業全体または組織全体にわたって影響のあるプロジェクト
- 許容範囲が達成できない欠陥や失敗があった場合に、死亡あるいは生命、財産、金融ソルベンシーへの受け入れ不可能なレベルのリスクになる可能性があるプロダクト
- 厳密な予測型ライフサイクルに従っている組織でのプロジェクト
- 厳しく規制された産業。例えば、銀行や保険あるいは医療機器、臨床研究、製薬会社など
6.10 「ソリューションの長期のパフォーマンスを評価する」タスク
- メトリックスを決定する
評価の開始前までに重要なメトリックスを特定する。 - メトリックスを獲得し、パフォーマンスを測定する
- 結果を分析する
- ソリューションと組織の限界を評価する
- ソリューションのパフォーマンスを改善するために推奨されるアプローチ
6.11 「ソリューションのリプレースとフェーズ・アウト」タスク
非常に具体的でわかりやすいと思います。言い方を変えると完全にITソリューションに限定されています。IT関係の読者にとってはうれしい限りですね。図解も豊富で、さすが実務ガイドとうたっているだけのことはあると思います。他のドメインと比較してもより丁寧に解説されています。おそらく執筆者が他のドメインとは異なるのでしょう。ドメインごとに執筆者が異なり、書き方、粒度、タスクのとらえ方が独特なようです。
最後にこのドメインの協働ポイントを紹介します。
協働ポイント
- プロジェクト・マネジャーとビジネスアナリストは監査およびプロジェクトのステークホルダーと連携し、組織にとって必要な、またプロジェクトのために必要なサインオフ活動を決定するために協力すべきである。
長くなりましたので、BABOK v3は割愛します。