要求アナリシスとデザイン

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

[図のクリックで拡大表示]

プロジェクト中のビジネスアナリシスの活動について解説します。プロジェクト中のビジネスアナリシスはツールを活用することを奨励しています。要求が複雑になればなるほど、モデリングや要求を管理する手間がかかります。それを合理的に行うためにはツールの活用が不可欠になってきています。V3のタスクそのものもツールを意識した構成に変わってきたことを認識してください。具体的にはタスクの構成要素としての「ガイドラインとツール」です。BABOKガイドのP.6です。

ツールはタスクを実行するために用いるものである。

そのものずばり、タスクを実行するにはツールが必要ということが前面に出てきています。
それでは、各タスクをツールとの関係を加味して解説します。

【要求を精緻化しモデリングする】タスク：

マトリクスやダイアグラム（図解）で要求をモデル化する方法です。数多くのモデリングテクニックがありますが、5W1Hで整理するとわかりやすいです。

What	Who/Where	How/When	Why
データと情報	人と役割	アクティビティーフロー、能力	根拠
・データ・ディクショナリー・データ・フロー図（DFD）・データ・モデリング・用語集・状態モデリング・インターフェイス分析	・組織モデリング・役割・権限マトリクス・ステークホルダーリスト・マップ	・プロセス・モデリング・ユースケースとシナリオ・ユーザー・ストーリー・ビジネス能力分析・機能分解・プロトタイピング	・意思決定モデリング・スコープモデリング・ビジネス・モデル・キャンバス・根本原因分析・ビジネス・ルール分析

Whyの欄にある「意思決定モデリング」はこのバージョンで新しく取り上げられたテクニックです。
詳細は別の解説記事をご覧ください。→　　【意思決定の自動化】

つづいて、要求を分析したり、要求の属性を表現します。
モデリングするのには、モデリング・ツールを使うのが便利です。

【要求を検証する】タスク：

このタスクの目的は、要求とデザインの仕様とモデルが、品質標準を満たしており、使用目的に適していることを確実にすることです。

具体的には、以下の要求の品質特性をチェックします。

アトミックである（atomic）：自己完結していること。
完全である（complete）：
一貫性がある（consistent）：
簡潔である（concise）：無関係あるいは不必要なものが内容に含まれていない。
実現可能である（feasible）：
曖昧さがない（unambiguous）：
テストが容易である（testable）：
優先順位が付いている（prioritized）：
理解が容易である（understandable）：

検証するためにはチェックリストが便利です。

また、要求ライフサイクル管理ツールを使うと、アトミックである、曖昧さがない、優先順位付け等の特性をチェックしてくれるものもあります。ここでもツールが便利です。

ところで上記9つの品質特性をすべて満足していれば、そのソリューションは有効でしょうか。役に立つソリューションかどうかという観点で見ると何か欠けているものがあるのではないでしょうか。それをチェックするのは次の「要求の妥当性を確認する」タスクです。要求を検証するタスクはあくまで形式的な品質をチェックするだけにとどまっています。一貫性があり、あいまいでなく、実現可能．．．のような、形式的な品質をチェックすることと、ビジネスとして役に立つこと（それが妥当性という意味です）を独立に別々にチェックすることをBABOKでは強く勧めています。これは以前のバージョンから引き継がれているのですが、最近では他の知識体系でも要求の検証と要求の妥当性確認を別々に行うことがポピュラーになりつつあります。7年前のBABOKバージョン2がその先駆けとなっていることは特筆するべきことだと思います。

【要求の妥当性を確認する】タスク：

このタスクで、すべての要求とデザインが、ビジネス要求に沿ったものであり、必要な価値の提供に役立つものであることを確実にします。形式的な品質のみならず、本当にビジネス的に意味のある要求のみを採用するべきというBABOKの強い考え方が表れているタスクです。

そのためにビジネスアナリストは次の3点を行います。

まず要求を実装すれば便益が得られるという前提条件を明確にし、その前提のリスクを管理します。
ビジネス・ケースなどでは、将来状態やチェンジ戦略で期待される便益が定義されているはずですが、具体的な測定基準までは定義されていませんので、ビジネスアナリストは評価基準（メトリクス）を定義します。要求の評価基準が定義できればビジネス的に便益につながります。
最後に、便益をもたらす要求とソリューション・スコープとの整合性をチェックします。スコープと要求が整合しなければ、ソリューションスコープを変更するか（追加予算が必要）その要求を削除するか決めます。

上記3点を実施することにより、要求の妥当性が確認されます。

【要求アーキテクチャを定義する】タスク：

このタスクもツールを前提としたタスクと言えます。ツールなしにはこのタスクを実行するのはかなり困難でしょう。ツールは「アーキテクチャー管理ソフトウェア」と言います。

左図のようなツールが北米では普及しています。モデリングのツールと一体となっているものが多く、1つのモデルで要求を表現すれば別のモデルでもその要求を表現してくれます。

上図の上の窓のような部分をビューポイント（プロセスモデルやデータモデルに相当）と言います。その窓をクリックするとそのモデル（例えばプロセスモデル）での表現（ビューと言います）を下側のグラフィック表現で見せてくれるわけです。そのためには、例えばプロセスモデルを作成するときに、プロセスのフローだけを記述するのではなく、インプット/アウトプットのデータの関係、そのプロセスを制御するビジネスルールなどをプロセスの構成要素として明確にしなければいけません。

ですからビューポイントも5W1Hで整理するとわかりやすくなります。

What	Who/Where	How/When	Why
・データ・モデルと情報	・ユースケースやユーザー・エクスペリエンスを含むユーザー相互作用	・アクティビティーフロー・能力	•監査とセキュリティー・ビジネス・モデル

「要求を精緻化しモデリングする」タスクのテクニックとの対応が明確になっていることが分かります。前々回に解説した、5W1Hで整理したソリューション・スコープ、ギャップを上位の階層として上乗せするとより明瞭になります。

スコープを記述したモデルと同じ（または類似の）モデルを使用してでギャップを記述し、そのギャップを解消するために類似のモデルを使用してで要求をモデリングし要求アーキテクチャを作成すればよいことが分かります。

こうして5W1Hで整理したモデリング（テクニック）を縦方向につなげていくと抜けや漏れのない要求を作成するのに役に立ちます。

さらに、次回取り上げるトレーサビリティをマネジメントすることにも大きな役割を果たしてくれます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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