[経営とITを結ぶビジネスアナリシス〜BABOK V3の基礎知識〜]

2015年9月11日(金)近藤 史人（IIBA日本支部 教育委員）

リスト

知識エリア：ソリューション評価

　「ソリューション評価」とは、「引き出しとコラボレーション」で引き出した価値を検証することである。現在運用しているソリューション、あるいは、導入したソリューションのパフォーマンスを評価し、それが望ましい状態に至っていないのであれば、ソリューション自身か、それを使用しているエンタープライズ（企業）かのどちらかにパフォーマンスを阻害する要因がある。それを取り除くようアクションを推奨する。

　ソリューション評価は、図2に示す5つのタスクからなっている。

図2：「ソリューション評価」の5つのタスク（BABOKガイドV3を基に清水千博氏が作成）
拡大画像表示

タスク1＝ソリューション・パフォーマンスを測定する

　パフォーマンスの測定項目を決め、その項目の妥当性を確認し、データを収集するタスクである。重要なことは、ビジネス目標を入力にしている点である。測定項目をビジネス目標を達成できるかどうかに関連して定義しなくてはならない。

　その際に有効なのが、「業績測定参照モデル」のような、ビジネスの成果とそれをもたらす構造を定義したモデルだ。業績測定参照モデルは、IT投資の効果を客観的に測定するための仕組みで、米国政府のエンタープライズアーキテクチャー（EA）管理室（FEAPMO）が2003年に発表した。梃子の押し手と、それを押した結果、何が動くかを可能な限り定量化してモデル化したものである。

タスク2＝パフォーマンス測定結果を分析する

　データの測定値を分析する。その際に重要なのは、異常値や傾向によるデータのゆがみ、さらにデータの正確性に注意することである。自社のパフォーマンスが特出しているのか、それとも世間並みなのかは、データの値だけでは判断できない。

　定義した測定指標の何をどれだけ動かせば望ましい価値が得られたことになるのか、あらかじめモデルで梃子の押し手と作用側を想定していれば、努力と、それにより得られる成果がある程度想定できる。

タスク3＝ソリューションによる限界を評価する

　ソリューションが期待するパフォーマンスを実現できていない際に、ソリューション内部の要因に制約があるかどうかを評価する。ソリューション内部のボトルネックが、全体のパフォーマンスの足を引っ張る事はよくあることだ。

　ソリューションに問題がある場合、根元の問題から、考え得る問題の原因をロジックツリーで“なぜなぜ5回”展開するのは有効な方法である。これ以外に、原因は考えられないところまで展開して、1つずつ根元近くの太い枝から潰していく。さらに問題の影響度がどこまで及ぶのかを調査し、緩和策があるのか、緊急に手を打たなければならないのかを検討する。

タスク4＝エンタープライズによる限界を評価する

　ソリューションが期待するパフォーマンスを実現できていない際に、エンタープライズに制約があるかどうかを評価する。エンタープライズの制約は、ソリューションと異なり、人間的な要因が多い。組織文化や、ステークホルダーへの影響、ステークホルダーからの影響、組織構造に与える変更、ソリューションを運用できる能力などを評価する。

タスク5＝ソリューションの価値を向上させるアクションを推奨する

　ソリューションの価値を向上させるアクションの推奨は、この推奨案が、概念実証（Proof of Concept）やプロトタイプ、ベータバージョンのソリューションに適用される場合は、本格的なソリューションの導入に備えたものになる。これまで長年運用されてきたソリューションに対して適用される場合は、新しくこれからチェンジを起こすきっかけになるだろう。

　以上、「真のニーズの発見と価値提案」というテーマで「引き出しとコラボレーション」「ソリューション評価」の二つの知識エリアを見てきた。次回は知識エリア「要求アナリシスとデザイン定義」と「要求のライフサイクルマネジメント」を解説する。

　読者は、次のような問題意識を持っていないだろうか。

「日本のシステム開発では、仕様書とコードは残るが、『何のためにこの機能が必要だったのか』といった機能の意味をたどる“要求のトレーサビリティ”に関しては、まともに実施されている現場を見たことがない。構築から数十年も経ったシステムは、度重なるパッチが当たり、内部を理解する人が誰も居ない。仲居さんの道案内がなければ食堂にたどり着けない温泉宿のようなものだ。

複雑怪奇極まる暗渠となったシステムの上で、業務は時間とともに進化するが、システムは進化できない。結果、エンドユーザーはシステムの周りに、ExcelやAccessを使った自己防衛システムを構築する。こうした応急処置が恒久的なものになり、複雑極まりない業務が続いている。これが日本の実態だ。
こうした日本企業が抱えるシステムのアキレス腱を早く何とかしなければ本当にまずい」

　「要求アナリシスとデザイン定義」と「要求のライフサイクルマネジメント」は、そうした問題に解決策を与えるための知識エリアである。

筆者プロフィール

近藤 史人（こんどう ふみと）
IIBA（International Institute of Business Analysis）日本支部 教育委員、第一コンピュータリソース（DCR）エグゼクティブ・ビジネスアナリスト。1984年日本ディジタルイクイップメント（DEC)入社。会社の合併に伴い1998年コンパックコンピュータ、2002年日本ヒューレット・パッカード（HP）へと社名は変わったが、一貫して業務分析、業務改革、全社ITの再構築の企画など超上流の業務に従事。HP時代には、HPグローバルのコンサルティングメソドロジーを米国本社チームと開発。2008年に日本HPを退職し、Modus Academyでビジネスアナリスト育成コースの講師、DCRで大手企業のコンサルティングなどに携わっている。