UMLを使ってビジネスの機能を可視化する：ビジネスモデリング事始（4）

情報マネージャが実際にビジネスをモデリングするにはどうすればいいのか。今回から3回にわたって、UMLを使ってビジネスモデルを記述する方法を解説する。

ビジネスモデルを作成する

本記事は、「ITアーキテクト」と＠ITの各フォーラムが展開する、分析／設計工程に焦点を絞った『ITアーキテクト連動企画』記事です。

　ここでは、UMLを使ってビジネスの仕組みを「機能」「構造」「振る舞い」という観点から記述する方法について紹介します。

　ビジネスの仕組みのうち、最初に明らかにするのはビジネスの機能です。ビジネスの目的は、「利益を追求することにより、ステークホルダー（注1）に経済価値を提供し続けていくこと」です。そこでまず、目的を遂行するために「ビジネスは何をするのか」（機能）を明らかにします。

　UMLでは、価値を産出するための機能1つ1つを「ユースケース」という単位で表します。また、価値を提供する相手や価値を産出するためにかかわっている外部要素を「アクター」として表します。UMLのユースケース図は、このユースケースとアクターによって作成されます。

図1　ユースケース図の例

　続いて、ビジネスの機能を「誰が実現するのか」（構造）を明らかにします。

　ビジネスを構成するものには、「人」「物」「金」「情報」などがあります。UMLではこれらを「クラス」として表し、クラス間の関係を「クラス図」で表現します。最後に、ビジネスを構成する要素がビジネスの機能を「どのように実現するのか」（振る舞い）を明らかにします。

　これは、ユースケース単位に「相互作用図」や「アクティビティ図」を作成することによって行います。相互作用図は、構成要素がお互いにどのように作用しながら機能を実現するのか（相互作用）を表すのに使用します。アクティビティ図は、構成要素がどのように作業を進めながら機能を実現するか（ワークフロー）を表すのに使用します。

図2　アクティビティ図の例

　相互作用図を作り、ビジネスを構成する人や物などの要素間の相互作用を見ることによって、役割分担の妥当性を検証することができます。例えば、同じ情報を管理している複数の情報システムや、何の役割も担っていない作業者が可視化されます。また、アクティビティ図をベースにABC分析を行うことができます。具体的には、ワークフローを構成する各アクティビティにかかるコスト（工数、金額）を測り、それを合算することで、ユースケース単位のコストが明確になります。さらに各アクティビティの付加価値を分析し、改善後のワークフローを考え、それに対するコストを測り業務改善の妥当性を検証することができます。相互作用やワークフローによって機能を検証した結果をビジネス構造のモデル（クラス図）に反映することによって洗練させていきます。

　このように、UMLによってもうける仕組み、

• そのビジネスは何をするのか
• 誰がするのか
• どのようにするのか

が可視化されます。

図3　UMLによるビジネスモデリングのアプローチ

　それでは、ビジネスの機能、構造、振る舞い1つ1つについて詳しく見ていきましょう。

ビジネスの機能

　まず、ビジネスの機能についてです。価値を産出する働きには、何があるのか考えてみましょう。

　企業では、利益を追求するために事業を行います。事業を行うためには元手が必要になります。そこで株主や銀行から資金を調達する必要があります。そして、その資金で事業に必要なものをそろえます。例えば製造業であれば、製品を作るために必要な機械や工場、物を売る商売であれば店舗を構える必要があります。従業員も雇わなければなりません。

　準備ができたら、いよいよ事業開始です。準備段階で用意したさまざまな物や人をうまく活用して効率的に利益を上げていきます。産出した利益の一部は資金を提供してくれた株主や銀行に還元し、残りは事業を拡張するために使います。企業は利益を追求するために、このような活動を繰り返すわけですが、これだけでは不十分です。これらの活動を効果的かつ円滑に進めるために計画を策定し、その結果を評価する活動や、事業に必要なものや人を維持するための活動も必要となります。この典型的な企業活動を機能別に表すと図4のようになります。

図4　典型的な企業活動（クリックで拡大）

　図の各機能を「プロセス」として説明します。なぜならば、企業の機能は、「目的を持ち、その目的を遂行するために関連する一連の活動（アクティビティ）から成る集合」だからです。プロセスを実現するビジネスの構成要素は、複数の組織にまたがるので、プロセスは組織横断的な単位となりす。このように利益を追求するための目的を持ち、それを遂行するために関連する一連のアクティビティの集合を「エンタープライズプロセス」と呼びます（ここでは、エンタープライズプロセスを単に「プロセス」と記述します）。

　プロセスは、それが遂行されることによって、何らかの価値を産出するとともに、資産の状態変化をもたらします。例えばビジネスプロセスは、顧客に付加価値を提供した結果、財務資産（売掛金や現金）を増加させます。また資産確立プロセスや資産維持プロセスは、資産自体の持つ価値を増加させます。例えば「人材を教育することによって人的資産の価値が増加する」と考えると分かりやすいかもしれません。

図5　エンタープライズプロセス

　この企業の各プロセス、価値を産出する単位を、UMLのユースケースで表します。上述したプロセスを典型的なものとして図6のように表します。

図6　典型的なプロセス（クリックで拡大）

　次に、ユースケースにかかわっているアクターについて解説します。アクターとして表される対象は、主にステークホルダーです。またWebサービスなどを利用してプロセスに直接関連している外部の情報システムがあれば、それもアクターになります。このように、アクターは人に限っているわけではありません。

　アクターとユースケースで、ビジネスモデルのユースケース図を作成します。これを「ビジネスプロセスモデル」と呼びます。

図7　ビジネスプロセスの例

　このとき、企業の全プロセスを1つのユースケース図に表そうとしたら煩雑になります。そこで意味がある単位にグループ化し、プロセスを体系的に整理します。UMLではモノをグループ化するための部品として、「パッケージ」を用意しています。このパッケージを使用してグループ化します。

　ここでは、上述した典型的なプロセスの種類単位で分類し、さらに、企業を構成する事業単位で行われるプロセス、全事業で共通のプロセスで分類します。便宜上、事業単位のプロセスを「メインプロセス」、全事業共通のプロセスを「サポートプロセス」と呼びます。一般的に、メインプロセスは主活動であるビジネスプロセス、サポートプロセスとしては、支援活動であるビジネスプロセス以外のプロセスというように分類されると考えられますが、製品開発プロセスなどインベストメントプロセスの一部を事業単位で行っている場合など、必ずしもそうとは限りません。

　実際、このようにプロセス体系を記述してみると、ステークホルダーに対する必要なプロセスが欠けているなど、機能的な問題が可視化されます。

図8　プロセス体系（クリックで拡大）

　次回は、ビジネスの構造をモデリングする方法について解説します。