（６）ソリューション評価
- 本章全体の解説
- 1.ソリューションパフォーマンスの測定
- 2.パフォーマンス測定結果を分析する
- 3.ソリューションによる限界を評価する
- 4.エンタープライズによる限界を評価する
- 5.ソリューションの価値を向上させるアクションを推奨する
本章全体の解説
「ビジネスニーズ 」に対して「ソリューション」を評価し、その価値のすべてを実現することを妨げる障壁や制約条件の除去を推奨することが目的です。ソリューション評価は、チェンジ着手の前、チェンジ中の評価、ソリューション適用後のいずれでも生じます。
1.ソリューションパフォーマンスの測定
ビジネス目標をもとに、実装されたソリューションのパフォーマンスを測定します（定義＋実施）。パフォーマンス測定項目は上位の測定項目と整合させます。
2.パフォーマンス測定結果を分析する
測定結果を統合して解釈します。
ソリューションの価値を判断するのに測定データが不足している場合は、追加の測定を行うかソリューションのリスクとして扱うかのどちらかを取ります。データを分析する際は、データ収集期間を考慮して異常値や傾向のゆがみが入らないように留意します。
3.ソリューションによる限界を評価する
ソリューション内部の問題を見つけます。
なお、次のエンタープライズによる限界評価と並行して行っても問題ありません。
ソリューションがパフォーマンスを出せない場合、ソリューション内部の一部のコンポーネントが全体の効率を下げている可能性があります。また、具体的に品質を下げているアウトプットを特定し問題を調査します。特定した問題がどのような影響を与えるか把握しどの程度許容できるか判断します。
4.エンタープライズによる限界を評価する
ソリューション外部の問題を見つけます。
価値の実現を阻害しやすい組織文化、ステークホルダの影響分析、組織構造、運用を評価します。
5.ソリューションの価値を向上させるアクションを推奨する
潜在価値と実際の価値のギャップを埋める行動をします。
ソリューションによる限界とエンタープライズによる限界を勘案し、パフォーマンス測定を見直すか改善案（推奨案）を作成します。
以上が、ソリューション評価のまとめです。
（５）要求アナリシスとデザイン定義
- 本章全体の解説
- 1.要求を精緻化しモデル化する
- 2.要求を検証する
- 3.要求の妥当性を確認する
- 4.要求アーキテクチャを定義する
- 5.デザイン案を定義する
- 6.潜在価値を分析しソリューションを推奨する
本章全体の解説
ここでは、要求を洗練していくという反復的な側面と戦略をソリューション案に繋げるまでの工程的な側面の２つを扱います。
＜反復的な側面＞
＜工程的な側面＞
1.要求を精緻化しモデル化する
引き出した情報を整理します。大抵の場合、表か図（あるいは両方）の形式で整理します（用語集、権限マトリクス、データフロー図など）。整理の過程では、ビジネスアナリシス情報を要素に分解します。要求の明確な表現と分類を検討します。要求を分類することで要求の抜け漏れに気付くきっかけにもなりますし、要求の理解を深めることができます。要求の抽象レベルはステークホルダにより理解のしやすさが異なります。経営者であれば抽象的なレベルが理解しやすくシステムエンジニアには具体的なレベルの方が理解しやすくなります。抽象レベルを変えた際に意味が変わらないよう注意する必要があります。
2.要求を検証する
要求・デザインの品質は使用適合性が重要な特性です。これはステークホルダによって判断されます。検証プロセスは繰り返し実行され、チェックリストを活用することが品質のチェックに役立ちます。
3.要求の妥当性を確認する
整理した要求がビジネス要求と整合しているか確認します。
ビジネスの要求には表現されていない前提条件があることがあるため、要求の前提条件を明確にします。期待された便益がもたらされるか測定できるよう評価基準を定義します。デザインと要求が整合しない場合は、将来状態を見直すか要求を見直す必要があります。
なお、2.要求の検証と3.要求の妥当性確認は混同しがちですが、違いを表現すると以下の通りです。
4.要求アーキテクチャを定義する
要求アーキテクチャとはチェンジに必要なすべての要求一式です。要求の表現は単一ではなく、ビューポイントごとに異なります。一つのビューポイントに大量の情報を入れすぎると複雑になり本来の目的を失います。ビューポイントのイメージは以下の通りですが、実際は要求一覧のような形式の情報の方がボリューム的には多いです（個人的見解）。
5.デザイン案を定義する
要求をソリューションコンポーネントに当てはめ、望ましい将来状態を達成するための複数のデザイン案を示します。
6.潜在価値を分析しソリューションを推奨する
どのようなチェンジでも価値の増大と減少の両方が同時に起きます。便益とコストの2つを目に見えないものも考慮して比較します。各デザイン案の評価を行い最も効果的なトレードオフとなっていることを確認します。
以上が、要求アナリシスとデザイン定義のまとめです。
（４）戦略アナリシス
本章全体の解説
全体のイメージ
この章の全体像は何かにチャレンジするときの一般的な考え方と一致します。まず、現状を把握して、理想の状態を定義し、そのギャップを埋める方法を考えるということです。ギャップにはリスクがあるという点も一般的ですね。
タスクをまとめると以下の通りです。
インプットとアウトプットの関係がやや複雑なのでよく整理しておくことをお勧めします。
1.現状を分析する
このタスクの目的はチェンジの必要性を理解することです。
分析の要素として以下の8つがあげられています。重要な点を補足すると、ここでのビジネスニーズとは、ステークホルダの視点ではなく、エンタープライズの視点です。
2.将来状態を定義する
このタスクの目的は、ビジネスニーズの達成に必要な条件を明確にすることです。
分析の要素として以下の11つがあげられています。
- ビジネスのゴールと目標：SMARTな目標であること
- ソリューション空間のスコープ：検討すべきソリューションの範囲
- 制約条件：予算、時間など
- 組織構造と組織文化
- 能力とプロセス
- テクノロジーとインフラストラクチャ
- ポリシー
- ビジネスアーキテクチャ
- 内部資産
- 前提条件の特定：たいてい決定的な前提条件が存在する。不確実な場合は早くテストすべき。
- 潜在価値：潜在価値＝便益-コスト
3.リスクをアセスメントする
リスクはチェンジ戦略の選択（調整）に影響を及ぼすため、把握しておくことが重要です。リスクのすべてを知ることは不可能で不確かさは残りますが、その影響を算定することはできます。
リスクの洗い出しは難しいですが、過去の教訓や専門的判断が役に立ちます。制約条件や前提条件、依存関係を整理することはリスク分析の切り口となり得ますし、リスクそのものであることもあります。発生確率と影響度合いでマイナスの影響を算定します。ただし、組織のリスク許容度（リスク回避型／中立／選好）により、リアクションは異なります。このリスク許容度を加味し、対応方針を決定します。リスクを伴って進行する場合は、影響を受けるステークホルダを事前に特定しておきます。
テクニックの章にあるリスク分析の方法もここで併せて整理します。プロセスとしてはこちらの方がしっくりくると思います。
- リスクの特定：リスクの洗い出し。専門家、過去の経験、
- 分析：リスクレベルの理解、リスクレベルの見積もり
- 評価：価値の比較
- 対応：回避／転嫁／軽減／受容／増加
4.チェンジ戦略を策定する
いくつかのチェンジアプローチの中から１つを選定します。
チェンジ戦略の表現は、チェンジチームやステークホルダの考え方によって変わります（ビジネスケース/作業範囲記述書/戦略計画の一部）。
要素として以下の5つがあげられています。
1.ソリューションスコープ
ソリューションの境界を定義します。新しく提供される能力が何かをわかるように記述します。スコープを明確にするためにスコープ外の記述が入ることもあります。私はRFPをイメージするのが良いと思っておりますが、注意点はイニシアティブ（プロジェクト）を通して発展（変化）する可能性があることです（RFPは外部への提示を想定していますが、ここでは必ずしも外部への提示を想定していません）。
2.ギャップ分析
現状と将来のギャップを定義します。
3.エンタープライズの準備状況のアセスメント
チェンジを実施できる力があるか、維持できるかを評価します。
4.チェンジ戦略
（チェンジ戦略策定の要素にチェンジ戦略があるため混乱してしまいます。）
個人的に重要だと感じている点はチェンジ戦略は複数のチェンジを含むことがあるという点です。経験と照らし合わせると、以下のような例があります。
- １システムを変えるのがメインだとしても、変更しない他のシステムとのインタフェース改修が起きるケース
- 1システムを変えることで、今までシステムが行っていた一部をRPA化したり、一部の運用を変えるケース
5.移行状態とリリース計画
移行・リリース計画を立てます。
以上が、戦略アナリシスのまとめです。
（３）要求ライフサイクルのマネジメント
本章全体の解説
要求とデザインの発生から廃棄までのマネジメント（ライフサイクル）を扱います。要求のライフサイクルは、ビジネスニーズを要求という形にするところから始まり、ソリューション開発期間中はライフサイクルは継続します。ソリューションが実装されても管理対象となりえます。要求が廃棄されればライフサイクルは終了となります。
また、要求はライフサイクルの中で洗練されていきます。序論の中でも掲載した図をもう一度載せておきます。
本章内のタスクを整理すると以下の通りです。
基本的に要求とデザインがタスクによって洗練されるだけです（トレースするタスクを行うとトレースされた要求になる）。ただ、要求変更の評価はインプットアウトプットが他のものと異なるので注意してください。
1.要求をトレースする
要求をトレースするとは要求の系統を文書化することです。
要求やデザインが詳細化されると管理している表現が異なります。詳細化によりレベルが変わった要求やデザインを同じ系統のものとして管理しておく必要があります。この関係性が追えないと当初の要求が本当に実行されたのか（前方トレーサビリティ）がわからなくなったり、デザインを見直したい場合にそもそもなぜそのソリューションを必要としたのか（後方トレーサビリティ）が判断できなくなります。要求管理ツールが大きな力を発揮します。
また、トレーサビリティは有益ではありますが、公式度が高くなるほど一般的にコストがかかります。そのため、便益とコストのバランスをとるという観点も重要な要素です。
トレーサビリティの関係には以下の種類があります。
- 派生：要求が別の要求から派生した場合
- 依存：要求に依存関係がある場合
- 必然性：別の要求と同時に実装されないと意味のないもの
- 作業効率：関係する要求が実装されれば効率的に実装できるもの
- 充足：要求を満たした実装の要素となっているか
- 妥当性確認：実装の要素は要求を満たしているか
このタスクにより、表明された（トレースされた）要求とデザインに変わります。
2.要求を維持する
ここでは、要求のライフサイクルを通し、要求の精度と一貫性を維持することが目的です。これによりアクセスしやすくなり、要求の再利用もしやすくなります。要求の中には長期的に使用する要求もあります。それらは要求の一部しか実装されなかったり、長期的に改良する場合があります。業務領域の専門家にニーズが反映されているか定期的に確認することも有効です。
要求を適切に管理するには、正確性と最新性の確保が重要です。また、コンテキストと要求本来の意図が失われないようにする必要があります。
要求の属性も重要な要素です。情報源や優先順位があると管理がしやすくなります。
適切な抽象度で保管しておくと要求を長期で利用する際に再利用しやすくなります。
このタスクにより、精緻化・モデル化された（維持された）要求とデザインに変わります。
3.要求に優先順位をつける
要求の相対的価値を決め、価値の最大化を目指します。
評価方法の代表としては、MoSCoW 分析があります。
優先順位付けに影響する要因には以下のものがあります。
1.便益
2.ペナルティ
3.コスト
4.リスク
5.依存性：要求間の依存性
6.時間依存性：時間によって要求の価値が変わる
7.安定性：要求が変わる可能性
8.規制やポリシー順守
他に優先順位に関してのトピックは、立場により優先順位は異なるという点と、時間の経過とともに優先順位は変化するという点です。
このタスクにより、優先順位付けされた要求とデザインに変わります。
4.要求変更を評価する
要求/デザインの変更プロセスと捉えています。アプローチにより評価の公式度は異なります。（予測型は公式度が高い。適応型は公式度が低い）
変更を評価する際に影響分析をする要素は以下の5つです。
- 便益
- コスト
- 影響：影響が及ぶ顧客、影響が及ぶビジネスプロセス
- スケジュール
- 緊急性：重要度のレベル。規制、安全性
影響分析の結果、明らかになった影響と解決策は文書化し、すべてのステークホルダへ伝達します。
5.要求を承認する
インプットは、検証された要求とデザインです。承認に関してはビジネスアナリストに責任が求められるところです。
ステークホルダーの承認を得る
ビジネスアナリストにはステークホルダの承認を得る責任があります。サインオフの権限を誰が持っているか理解しておく必要があります。ただし、意思決定に影響を及ぼすステークホルダが多数いることにも注意が必要です。
衝突と課題の管理
承認を得る前にステークホルダ間で意見が衝突することは多々あります。衝突が発生した場合はステークホルダで調整するよう促します。これは実務でもすごく役立つ視点です。私も内心ではどちらかの肩を持ちたいような場合でも、議論を整理するような話の持っていき方で当事者同士で意見を言ってもらうようにしています。
合意を獲得する
承認は投資を正当化できることをステークホルダ全体で認識した証です。ステークホルダに理解してもらう責任があります。
承認を追跡し伝達する
承認の決定は責任をもって記録します。承認を得た後も、要求のステータスを把握できるようにしておく必要があります。（承認済み/実装済み）
このタスクにより、承認された要求とデザインに変わります。
以上が、要求ライフサイクルのマネジメントのまとめです。
（２）引き出しとコラボレーション
本章全体の解説
他の章はフェーズを意識した方が理解できる側面が多いですが、本章はどのフェーズでも使用するもの、どの知識エリアでも横断して使用するものと捉えておいた方が良いです。計画的なこともあれば、計画的ではなく実行されることもあります。
私なりの言葉で表現すると、ビジネスアナリシス情報の扱い方を洗練しモデル化した知識エリアです。
1.引き出しを準備する
ニーズとステークホルダエンゲージメントアプローチをインプットにし、引き出しアクティビティ計画をアウトプットします。
ここでの重要な要素は引き出しのスコープを整理し、適切なテクニックを選択することです。スコープを理解していると、聞きたいことと違う話に発展していった場合に、話を戻すことができます。逆にスコープを事前に意識せずに情報を引き出そうとすると、話がずれた場合に非効率になるだけでなく、対応できない期待感をステークホルダ（情報提供者）に与えてしまう可能性があります。テクニックの例としては、インタビューで行うのか、ブレーンストーミングで行うのかなどの方法があります。
また、ステークホルダ（情報提供者）の協力を得るために、事前に補足資料のレビューを依頼しておくことも重要です。
2.引き出しを実行する
計画に基づいて引き出しを実行します（スコープから議論がずれた場合の対処、引き出し達成の判断を行います）。
引き出しは以下の3種類があります。
- 協働型：インタビューやワークショップなど
- 調査型：資料等から情報収集、
- 実験型：観察研究、概念実証（PoC）、プロトタイプ
また、テクニックとしてどのようなものがあるかは、一度整理しておくとよいと思います。
3.引き出しの結果を確認する
引き出しの実行結果を確認します。確認観点は主に二つです。
- 引き出しの結果を情報源と比較する
- 引き出しの結果をその他の引き出しの結果と比較する
ここではガイドラインとツールも重要です。
- 引き出しアクティビティ計画
- 既存のビジネスアナリシス情報
引き出しを実行するタスクと確認タスクを分けているのは、引き出しの後振り返ると問題を含んでいることがあるという経験則からであろうと推測します。
4.ビジネスアナリシス情報を伝達する
ビジネスアナリシス情報はステークホルダに伝わり、協力をえられるようになってこそ意味があります。そのため、情報、伝達時期、形式、表現を適切にしましょうという趣旨です。ビジネスアナリシス情報（多種多様）の伝達は、双方向かつ反復的です。ステークホルダが理解できない場合は、情報配信、伝達形式を複数用意することが必要になる場合もあります。
ビジネスアナリシスパッケージ（情報の表現方法の型）
わかりやすく伝えるためには、ビジネスアナリシスパッケージを利用することが有効です。BABOKでは、以下の３つを上げています。私はこの分類は公式度に基づいた分類であると捉えています。
- 公式：組織のテンプレート。会社で使うことが決められているもの。
- 非公式：（組織のルールではないが）イニシアティブ内で使用するもの。
- プレゼンテーション：わかりやすくするために作成した資料すべて
コミュニケーションのプラットフォーム
情報の伝え方も重要です。
- グループコラボレーション：一斉に関係者を集めて議論
- 個別コラボレーション：個別にヒアリング/説明
- Emailまたはその他非口頭的手段：関係者の成熟度が高く説明があまり必要ない場合に有効
5.ステークホルダーのコラボレーションをマネジメントする
イニシアティブの成功のためには、ステークホルダの協力を得られるように活動することが重要です。ステークホルダとの関係構築が弱いとチェンジへの抵抗や上質な情報提供がされないなどの悪影響をもたらします。ステークホルダエンゲージメントで重要なのは以下の３点です。
コミットメントを得る
なるべく早い段階でステークホルダからコミットメントを得ます。コミットメントへの期待と望ましい成果を明確にできれば、伝達方法は公式でも非公式でも構いません。
モニタリングする
他の作業を優先する、求められる品質を提供しない、承認の遅れ等は危険信号のため、継続的にモニタリングします。
コラボレーションする
情報、アイデアを（隠そうとせず）自由にやり取りすることを奨励すれば、ステークホルダはチェンジを支持するようになります。ステークホルダエンゲージメントがうまくいっている状態とは、自分の貢献が認められているとステークホルダが感じている状態です。
以上が、引き出しとコラボレーションのまとめです。
（1）ビジネスアナリシスの計画とモニタリング
- 整理の仕方
- この章全体の解説
- 1.ビジネスアナリシスアプローチを計画する
- 2.ステークホルダエンゲージメントを計画する
- 3.ビジネスアナリシスガバナンスを計画する
- 4.ビジネスアナリシス情報マネジメントを計画する
- 5.ビジネスアナリシスパフォーマンス改善策を特定する
整理の仕方
まず、各知識エリアの整理の仕方は、タスクとそのインプット、アウトプットを整理します。欲を言えば、ガイドラインとツールも整理した方がいいのですが、情報が多くなり理解のスピードが遅くなるため、タスク・インプット・アウトプットの３つを覚えてください。インプット・アウトプットは他のタスクと関係するため、これらを整理するだけでも全体を深く理解することができるようになります。
この章全体の解説
この知識エリア（ビジネスアナリシスの計画とモニタリング）では、イニシアティブの計画と管理を扱っています。
1.ビジネスアナリシスアプローチを計画する
ニーズをもとにイニシアティブをどのようなアプローチで行っていくかを定義します。
アプローチの中での大きな選択では、予測型か適応型か（ウォーターフォールで行くのかアジャイルで行くのか）を決めるというのがイメージしやすいでしょう。実際はこの2択で決まるものではなく、プロセスやテンプレート、成果物などの定義を行います。
ビジネスアナリシスのアクティビティもここで特定します。多くの場合では、都度都度特定するというより、組織の方法論（テンプレート化されたリスト）を採用することが多いです。
決定したアプローチに基づき、いつ何をするかの計画を立てます。この時には、リソースや他のイニシアティブ、優先度などを考慮します。
また、複雑さやリスクによりアプローチが修正されることがあります。
作成したビジネスアナリシスア（BA）プローチ計画は、主要なステークホルダに合意される必要があります。以下の点について合意を得ます。
- BAのアクティビティを特定
- 現実的な見積もり
- ステークホルダの役割と責任
レビューの中で上がった課題はビジネスアナリストが文書化し、解決を模索します。
2.ステークホルダエンゲージメントを計画する
ステークホルダの分析を行い、コミュニケーションアプローチを定義し、リスクへの対応計画を立てることが重要です。
注意点は、ステークホルダ分析は繰り返し実施されることです。最初に分析をして終わりではありません。
まずは、ステークホルダリストを作成し、誰が存在するかを明らかにします。さらに権限と責任やステークホルダに与える影響、ステークホルダがもたらす影響も整理します。ステークホルダを洗い出すうえでは、企業の組織図やビジネスプロセス、スポンサーの助言が参考になります。
ステークホルダとのコラボレーションは多くの場合、計画に行います。そこで、コラボレーションのアクティビティと成果物の定義を行います。
コミュニケーションの考慮事項が満たせているかビジネスアナリストはチェックし、コミュニケーション計画書へ反映します。
3.ビジネスアナリシスガバナンスを計画する
ビジネスアナリストは、次の４つを定義します。
意思決定のプロセス、変更管理プロセス、優先順位付けプロセス、承認プロセス
4.ビジネスアナリシス情報マネジメントを計画する
BA情報をどのように保存し、アクセスするかのアプローチを計画します。ビジネスアナリストはBA情報を整理する責任を持ちます。
5.ビジネスアナリシスパフォーマンス改善策を特定する
パフォーマンス分析はイニシアティブを通して行われます。まずは、パフォーマンス測定項目を確立し、監視、分析して改善策を検討していきます。
パフォーマンスという言葉からソリューションのパフォーマンスを連想するかもしれませんが、ここでは、ビジネスアナリスト（ビジネスアナリシス活動）のパフォーマンスをイメージした方がよいでしょう。測定項目とすることで行動を推奨することもあれば、妨げることもあるので注意して設定する必要があります。
なお、次の測定項目の例は試験に出る可能性があります。
- 正確性と完全性／知識／効率性／組織のサポート／重要性／戦略性／適時性
パフォーマンスの分析は受益者であるステークホルダの観点で評価されます。
改善の対策は以下の３つに分類されます。
- 予防：マイナス影響の発生確率を減らす。
- 是正：マイナス影響の度合いを減らす。
- 改善：プラス影響の発生確率や度合いを増やす。
以上が、「ビジネスアナリシスの計画とモニタリング」エリアのまとめです。
BABOK 序論の整理（後半）
要求の分類
序論で書かれている要求の分類をまとめると以下のようになります。
- ビジネス要求：チェンジ開始の理由：ゴール、目標、期待する成果
- ステークホルダ要求：ビジネス要求を達成するためのステークホルダのニーズ
- ソリューション要求：ステークホルダ要求を満たすソリューションの能力と品質※機能要求と非機能要求に分けられる。
- 移行要求：円滑に移行する条件（データ変換、教育訓練）。チェンジが完了すると不要となる。
ただ、要求の整理をするのであれば、併せて要求は洗練されていくという要素もここでまとめておきます。詳細は要求のライフサイクルで扱いますが、要求は洗練されていくという要素を押さえておいてください。
ステークホルダ
BABOKに登場しうるステークホルダは一度確認しておいてください。なお、ステークホルダは知識エリア・活動によって関与度が異なります。ここが出題ポイントとなります。例えば、「○○という活動で一番関係ないのはだれか？」というようものや「○○という知識エリアで△△の責任を負うのはだれか？」というような問いです。ステークホルダは、すべての領域で関係してくるため、横断的に整理しておくことをお勧めします。
なお、知識エリアでまとめると以下のようになります。
例に挙げているものは、あくまでイメージを膨らませるためのものです。職種、部門によってステークホルダが決まるわけではありませんのでご注意ください。
要求とデザイン
ここでは、要求とデザインは必ずしも明確に分けられないという点が重要なメッセージです。要求とデザインは行ったり来たりすることがありますし、ニーズに焦点を当てれば要求となるが、ソリューションに焦点を当てるとデザインとなります。これは実務でも役立つ視点だと思います。
私なりのイメージを表現すると以下の通りです。
