【BABOK(R) よもやま話】 (7) 「ツール」

BABOK(R) よもやま話 (7) 「ツール」

前回は「絆」というテーマでした。人と人とのつながりや、ステークホルダー・エンゲージメント、すなわち「絆」がビジネスアナリシスを成功するためには不可欠であるという事でした。

今週はBABOKガイドバージョン3のタスクの構成で新しく加わった「ガイドラインとツール」について、特に「ツール」について解説したいと思います。

まず、タスクの全体像です。

IGOEモデルBABOKタスク

本質的には以前のバージョン2のタスクの構成と大きく変わらないのですが、新しい構成要素が「ガイドラインとツール」です。ツールの解説の前にタスク全体を見ます。

「インプット」「ガイドラインとツール」「テクニック」「ステークホルダー」「アウトプット」の解説は以下の通りです。

 

 

 

 

 【インプット】

  • インプットとは、アウトプットを生み出すために使用されたり変換されたりする情報であり、タスクを開始するために必要な情報を代表する。インプットの中には、明らかにビジネスアナリシスのスコープ外で生成されたものも、ビジネスアナリシスのタスクによって生成されたものもある。

【ガイドラインとツール】

  • この項では、インプットからアウトプットへの変換に必要なリソースを挙げる。タスクを実行する理由や方法を記述したものがガイドラインである。ツールはタスクを実行するために用いるものである。
  • ガイドラインとツールに、他のタスクのアウトプットを含むことがある。

以前はガイドラインに相当するものは「インプット」に含まれていました。典型的な例は「組織のプロセス資産」です。RFP(提案要求書)のひな形やテンプレートが該当します。「要求パッケージを準備する」タスクの中では、これらは「インプット」の一部として扱われていたのですが、タスクの中で使われますが、「RFPのひな形」そのものを変更することはしませんね。「RFPのひな形」を変更するのはBACOE(ビジネスアナリシスにおけるPMOの位置付けの組織や機能)の役割です。BABOKのタスク(ビジネスアナリストの仕事)にはありません。ですから「組織のプロセス資産」はある意味「インプット」なのですが、新しいバージョンでは「ガイドライン」という別の項目にわけたのです。

【アウトプット】

  • アウトプットとは、タスクの実行によって得られる結果である。アウトプットには、タスクが正常に完了した結果として作成されたもの、変換されたもの、または状態が変化したものがある。

【テクニック】

  • この項では、ビジネスアナリシスのそのタスクの実行に使用できるテクニックを挙げる。

 

【ステークホルダー】

  • この項では、そのタスクの実行に関与する可能性の高いステークホルダーや、そのタスクから影響を受けるステークホルダーの一般的なリストを挙げる。

IGOEモデル_プロセス

左図はビジネスプロセスでよく用いられるIDEF0というプロセスの表記方法です。IGOEモデルとも称します。Input、Guide、Output、Enablerを略したものがIGOEです。BABOKガイドバージョン3のタスクのモデルと似ていませんか。そうです。BABOKガイドバージョン3のタスクのモデルはプロセスモデルで有名なIGOEモデルを採用したのです。インプット、アウトプットは全く同じで、Guideに相当するのが「ガイドラインとツール」、Enablerに相当するのが「テクニックとステークホルダー」です。

そろそろ本題の「ツール」に移りましょう。

 

 

タスク「ガイドラインとツール」の中にツールがリストされているタスクは次のとおりです。

「3.4 ビジネスアナリシス情報マネジメントを計画する」タスク:

  • 情報マネジメント・ツール:各組織は、ビジネスアナリシス情報を保存、検索、共有するためのツールを使用する。ツールにはホワイトボードのような単純なものもあれば、Wikiや本格的な要求マネジメント・ツールのように複雑なものもある。

「5.1 要求をトレースする」タスク:

  • 要求管理ツール/リポジトリ:ビジネスアナリシス情報の保管と管理に使用する。要求管理ツールには、テキスト文書を使った簡単なものから、専用の要求管理ツールを使った複雑なものまでさまざまな種類がある。

「5.3 要求に優先順位を付ける」タスク:

  • 要求管理ツール/リポジトリ:優先順位付けのための要求属性が含まれており、ビジネスアナリストが優先順位に応じて要求をソートしたりアクセスしたりするのに役立つ。

「5.5 要求を承認する」タスク:

  • 要求管理ツール/リポジトリ:要求の承認を記録するツール

「7.1 要求を精緻化しモデル化する」タスク:

  • モデリング・ツール:要求を表現するマトリクスやダイヤグラムの作成と保管に役立つソフトウェア・プロダクト。モデル化機能を持つ要求ライフサイクル管理ツールもあれば、そうでないものもある。
  • 要求ライフサイクル管理ツール:要求とデザインを記録し、整理し、保管し、共有するのに役立つソフトウェア・プロダクト

「7.2 要求を検証する」タスク:

  • 要求ライフサイクル管理ツール:たとえば、アトミックである、曖昧さがない、優先順位が付いている、といった特性の多くに関連する課題をチェックする機能を持つツールもある。

「7.4 要求アーキテクチャと定義する」タスク:

  • アーキテクチャー管理ソフトウェア:モデリング用ソフトウェアは、要求アーキテクチャー内の関係の量、複雑性、およびバージョンを管理するのに役立つ。

 

まとめてみると次の5種類となります。

  • 情報マネジメント・ツール
  • 要求管理ツール/リポジトリ:
  • 要求ライフサイクル管理ツール
  • 要求アーキテクチャ管理ソフトウェア
  • モデリング・ツール

それでは、具体的なツールを見ていきます。

 【情報マネジメント・ツール】

Wikiなど、一般情報を共有するためのポピュラーなツールです。説明を省略します。

【要求管理ツール/リポジトリ】

「百聞は一見にしかず」。具体的なツールをご覧ください。

Raquest1

 

 

 

 

 

 

 

 

Raquest2

要求管理ツールを使った影響図です。要求を変更するとどこに影響が出るのかを一目瞭然グラフィカルに表示してくれます。

 

 

 

 

 

 

Rational1

 

左図はIBM/Rational のトレーサビリティの解説の図です。

詳細は下記URLのWebページをご覧ください。

http://jasst.jp/archives/jasst10e/pdf/C6.pdf

 

 

 

 

RaQuest2

トレーサビリティの表示です。左側がステークホルダー要求です。上側がそれに対応するソリューション要求を表しています。真ん中の緑色の矢印が2種類の要求の間の関係を示しています。

赤いラインはステークホルダー要求とソリューション要求が対応していない部分です。赤く色づけしてくれるので注意が喚起されますね。

 

 

 

【要求アーキテクチャ管理ソフトウェア】

要求アーキテクチャ1

 

この管理ソフトの場合はZachmanのエンタープライズ・アーキテクチャをベースにしたビューを提供しています。上図の各四角い窓がビューポイントです。「データー(What)」「Function(How)」「ネットワーク(Where)」「人(Who)」..などです。

 

 

 

 

 

要求アーキテクチャ2

ビューポイントをクリックすると、そのポイントにおけるビューが表示されます。要求の構造がグラフィカルに表示してくれるので、ハイレベルでの要求の抜け・モレが無くなります。

ずいぶん便利なソフトウェア・ツールが出回っているものです。

 

 

 

 

 

昨年11月のラスベガスでのBBCカンファレンスでもツールの展示が大変多くのに驚かされました。なかにはモデリングと要求管理が自動的にリンクしているものまであり、その先進性には驚くばかりです。これだけ普及していれば北米のユーザー企業がITシステムを社内開発するのも大きな負担にはならないことも納得できるというものです。

ただ残念なことに日本ではまだあまり普及していません。ツールを積極的に使用している北米のビジネスアナリストの生産性は、まだエクセルベースが多い日本のエンジニアとは比較にならないくらい高いことが想像できます。そしてBABOK®ガイドバージョン3は要求管理ツールの使用を積極的に勧めています。特にアジャイル環境ではこのような要求管理や、ライフサイクル管理が不可欠になっています。