プロジェクト中　（その1）

2016/09/18

【プロジェクト中】

左図ではプロジェクト中では主に知識エリア「要求アナリシスとデザイン定義」の活動ということになりますが、それだけではなく知識エリア「引き出しとコラボレーション」の活動が必須であることはお分かりになるでしょう。「引き出しとコラボレーション」に関しては前回に詳しく解説しましたので、簡単に済ませます。

引き出しの3つのタイプの中で、プロジェクト中では主「協働型」テクニックを使用します。具体的には、

インタビュー：
観察：
ワークショップ：
ブレーンストーミング：
フォーカス・グループ：
マインド・マッピング：

さらに、

文書分析：
調査やアンケート：

などもあります。

それでは、メインの知識エリアを解説しましょう。

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

プロジェクト中のビジネスアナリシスの活動について解説します。プロジェクト中のビジネスアナリシスはツールを活用することを奨励しています。要求が複雑になればなるほど、モデリングや要求を管理する手間がかかります。それを合理的に行うためにはツールの活用が不可欠になってきています。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
・データ・モデルと情報	・ユースケースやユーザー・エクスペリエンスを含むユーザー相互作用	・アクティビティーフロー・能力	•監査とセキュリティー・ビジネス・モデル