ビジネスモデリングを
プロジェクトに応用する
連載：ビジネスモデリング事始（6）

オージス総研
左川 聡
2004/3/23

---

ビジネスの機能、構造のモデル化に続き、「ビジネスの振る舞い」を表現する方法を解説しよう。これらの手法を身に付けることで、業務改革やIT投資効果の算出などのプロジェクトがスムーズに進められる。（→記事要約へ）

---

ビジネスの振る舞いから何が分かるか？

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

　第4回でビジネスの機能をモデル化する手法を、第5回でビジネスの構造を表現する方法を説明しました。最後に、ビジネスの振る舞いを記述する方法について説明します。各資産はどのようにしてプロセスを実現しているのか、その動きを明らかにする方法について見ていきます。

　ここでは、ビジネスの振る舞いを「相互作用」「ワークフロー」「ライフサイクル」という3つの観点からとらえます。

■ビジネスのメカニズムを検証する「相互作用」

　まず、相互作用について説明します。UMLの相互作用図を作成することにより、プロセス構造で構成された各資産の役割分担が適切か否かを検証します。関連のある各資産の間でメッセージをやりとりさせることによって、各資産の相互作用をシミュレーションし、価値を産出するメカニズムが適切かどうかを確認します。

　例えば「責務が集中しすぎている資産はないか」「同じ機能を実現している複数の資産、役割の重複はないか」「まったく何の役割も担っていない資産はないか」などをチェックします。すると同じ機能を実現している複数の情報システムや作業者が可視化されます。こうした重複資産もコンスタントにコスティングされていきますので、それだけ企業の利益を圧迫することになります。相互作用を検証することにより、ビジネスの構造を再編成して価値産出のメカニズムを効率化するなど、コストダウン対策を立てられるようになります。

■ビジネスルールを明確化する「ワークフロー」
　続いて、ワークフローについて説明します。プロセス単位にアクティビティ図を作成することによって、「誰が」「何を」「いつ行うか」という作業の流れの観点から、プロセスの実現を明らかにします。このとき、アクティビティ図のレーンに各資産を対応させ、1つ1つのアクティビティを資産の機能、つまりクラスの操作に対応させて考えます。

　ワークフローによってビジネスルールが明確になり、さまざまなメリットが生まれます。例えばプロセス単位にアウトソーシングを考える場合、その単位でビジネスルールを指定することができます。また、ワークフローに対してABC分析を適用することで、プロセス単位のコスト（プロセスコスト）を算出できます。また現状のプロセスコストと改善後のプロセスコストを比較することによって、業務改善の妥当性を検証することができます。

図1　プロセスの実現：ワークフロー（図をクリックすると拡大します）

　ビジネスの振る舞いを可視化した結果を受けてビジネスの構造を洗練させます。相互作用によって見直された役割分担は、ビジネスの構造に反映されます。相互作用図でやりとりされるメッセージは、そのメッセージを渡された資産（クラス）の操作として割り当てます。また、ワークフローを構成する1つ1つのアクティビティは、それを実行する資産に対応したクラスの操作として割り当てます。

図2　構造モデルの洗練：ワークフローから（図をクリックすると拡大します）

■ビジネスや資産の繊維状態を表す「ライフサイクル」
　最後に、ライフサイクルについて説明します。ビジネスや資産の状態が遷移する場合、それをUMLの状態遷移図を使って表すことができます。例えば、事業部（組織単位）がビジネスの単位であれば、その単位にライフサイクルを記述します。

　このようなビジネスの振る舞いを表したモデルを「ビジネスビヘイビアモデル」と呼びます。

　以上のように、UMLによってもうかる仕組み、

• ビジネスのプロセス
• プロセスを誰がどこで実現するのか：組織および資産とネットワーク
• プロセスをどのように実現するのか：相互作用とワークフロー

が可視化されます。また、プロセス体系、組織体系、ネットワーク体系によってビジネスアーキテクチャが構成されます。

ビジネスモデルを現場で活用する

■ビジネスモデルをベースにして業務プロセスを改善する

　ここでは、UMLで作成されたビジネスモデルを活用して業務プロセスを改善する方法について説明します。

・現状プロセスのコストを測る
　業務プロセスを改善するには、（1）まずUMLで現状のビジネスを可視化する（As-Isモデル*1の作成）ことから始めます。（2）そして、その中から業務改善を行うプロセスを選定します。（3）続いて、選定されたプロセスのプロセスコストを算出します。プロセスのワークフローを表すアクティビティ図を見て、各アクティビティに対してチャージレートや時間、経費などを測ります。（4）それを合計してプロセス単位のコストを算出します。

アクティビティ 所要時間（HR） コスト（円） 引き合い 0.2 1,400 信用調査 5 19,500 見積もり書の発送 1.5 10,500 注文書・契約書の確認 1.8 12,600 注文請書の発送 0.5 3,500 受注伝票の起票 0.3 2,100 受注台帳への記録 0.2 1,400 出荷指示書の発行 0.3 2,100 出荷の消し込み 0.2 1,400 在庫引当 0.3 1,500 製造指図書の発行 0.3 1,500 製品の組み立て・入庫 6 32,400 製品の出荷 2.5 12,500 物品受領書の受領 0.2 1,000 製品有高帳の更新 0.2 1,000 出荷報告書の発行 0.5 2,500 売り上げ伝票の起票 0.3 2,250 得意先元帳への記録 0.2 1,500 ワークフロー全体 12.7 75,310

図3　As-Isモデルのプロセスコスト

　このときワークフローの流れの中に同期スレッドがあれば、最長のスレッドの時間をスレッド全体の時間にします。また、条件付きスレッドがある場合は、その発生率で重み付けをします。さらに、代替スレッドがあった場合も、その発生率で重み付けをします。

・各アクティビティの付加価値分析を行う
　次に、アクティビティ図を見て各アクティビティのバリューランキングを行います。そして、付加価値が低いものに対する改善策を策定します。このとき、情報システムを導入することよる自動化など、ITを活用することを考えます。そして、その結果を受けて改善後のワークフローを作成します。（To-Beモデル*2の作成）。

*1 現状モデルのことです。 *2 将来像モデルのことです。

アクティビティ 付加価値 情報システム化方針 引き合い 高 × 信用調査 低 × 見積もり書の発送 高 × 注文書・契約書の確認 高 × 注文請書の発送 高 × 受注伝票の起票 低 画面入力 受注台帳への記録 低 自動作成（C）、画面確認 出荷指示書の発行 低 自動通知 出荷の消し込み 低 自動更新（U）、画面確認 在庫引当 低 自動更新（U） 製造指図書の発行 低 自動通知 製品の組み立て・入庫 高 × 製品の出荷 高 納品書、物品受領書の自動印刷 物品受領書の受領 高 × 製品有高帳の更新 低 画面入力 出荷報告書の発行 低 自動通知 売り上げ伝票の起票 低 画面入力 得意先元帳への記録 低 自動作成（C）、画面確認

図4 付加価値分析の例

・現状プロセスと将来像モデルのコストからROIを算出
　続いて、ABC分析によってTo-Beモデルのプロセスコストを算出します。

アクティビティ 所要時間（HR) コスト（円） 引き合い 0.2 1,482 信用調査 5 19,500 見積もり書の発送 1.5 11,114 注文書・契約書の確認 1.8 13,336 注文請書の発送 0.5 3,705 受注伝票の起票 0.2 1,482 受注台帳への記録 0.1 741 出荷指示書の発行 0 0 出荷の消し込み 0.1 741 在庫引当 0.2 1,058 製造指図書の発行 0 0 製品の組み立て・入庫 6 32,400 製品の出荷 2.5 13,226 物品受領書の受領 0.2 1,058 製品有高帳の更新 0.2 1,058 出荷報告書の発行 0 0 売り上げ伝票の起票 0.2 2,033 得意先元帳への記録 0.1 1,017 ワークフロー全体 11.1 68,911 投資対効果の算定 　 ↑ → As-IsとTo-Beの差分に より削減コストを算出

図5　To-Beモデルのプロセスコスト

　これによって、As-IsモデルとTo-Beモデルのプロセスコストの差分が分かります。例えば情報システム導入により、業務プロセス改革による削減コストを算出することができます。削減コストが算出できれば、それをベースに「情報システム導入による投資対効果」を算出できます。投資に対するリターンを見込むことができれば、情報システムを開発するなど、実際の業務改善が実施されることになります。

■ビジネスモデルをベースにして情報システムを開発する

　続いて、UMLで記述されたビジネスモデルをベースに情報システムモデルを作成する方法について紹介します。

　まず、ビジネスモデルの中のどの部分を情報システム化するかを明確にします。

■情報化対象の選定
・	情報化対象プロセスの選定
		開発対象のプロセスを1つまたは複数選定します。
・	情報システムの選定
		選定されたプロセスに対応するTo-Beモデルのプロセス構造を確認して、そこに参加する情報システムのうち開発対象となる情報システムを明確にします。
・	操作の明確化
		対象となる情報システムの資産構造を参照し、開発対象となる操作を明確にします。To-Beモデルのプロセスの実現を確認して、相互作用やワークフローに関連している情報システムのメッセージやアクティビティに対応する操作を見つけ出します。
・	関連資産の明確化
		To-Beモデルのプロセスの実現（ワークフローや相互作用）を確認して、開発対象の操作に関連する協調相手（コラボレーター）となる資産を見つけ出します。
・	エンティティの明確化
		To-Beモデルのプロセス構造を確認して、開発対象の情報システムや、その協調相手に関連しているエンティティを明確にします。

　続いて、ビジネスモデルを情報システムモデルへ展開します。

■サブシステムの作成
		「情報システムの選定」で選定した情報システムをサブシステムに割り当てます。

■ユースケースモデルへの展開
・	操作からユースケースへの展開
		上述した操作の選定で選定された操作を1つの情報システムのユースケースに割り当てます。
・	アクターへの展開
		「関連資産の明確化」で明確にされた資産1つ1つを情報システムのアクターに割り当てます。
・	オブジェクトモデルへの展開
		「エンティティの明確化」で明確になった、開発対象プロセスのすべてのエンティティから概念モデル（*3）を作成します。概念モデルを作成する際は、実際にプロセスを運営する専門家にヒアリングをして概念構造を探っていく手段が大変有効です。システム開発が進んでいく中で、アプリケーション開発者は、概念モデルをベースにして、ソフトウェアの仕様を表す分析モデルを作ります。

*3 ここでは、概念モデルを、開発対象領域を構成する概念と、それらの意味的な関係（概念構造）をクラス図で表したものという意味で使用します。

図6　概念モデルの例（図をクリックすると拡大します）

■データモデルへの展開
		エンティティの明確化で明確になった、開発対象プロセスのすべてのエンティティからER（Entity-Relationship）モデルを作成します。

　このように、UMLで記述されたビジネスモデルをベースに情報システムを開発することができます。

図7　ビジネスモデルから情報システムモデルへの展開 このように、UMLでビジネスモデルを作ることによって、それをベースに業務改善や情報システム開発をすることができます。

　以上のように、UMLでビジネスモデルを作ることによって、それをベースに業務改善や情報システム開発をすることができます。

図8　UMLによるビジネスモデリングとその活用（図をクリックすると拡大します。PDFダウンロードもできます）

このページのポイント

ビジネスの振る舞いを、「相互作用」「ワークフロー」「ライフサイクル」でとらえる 「相互作用」「ワークフロー」「ライフサイクル」がそれぞれ何を明らかにし、どんなメリットがあるかを押さえよう ビジネスモデルをベースに、改革すべき業務やシステム化の対象が見えてくる ビジネスモデルをシステムの機能や操作、データモデルに展開することで最適なシステムを円滑に構築できる

第5回へ

この記事へのご意見をお寄せください

managemail@atmarkit.co.jp

■要約 今回は「ビジネスの振る舞い」を表現する技法と、実際にモデリングを業務改革・IT導入検討などに活用する方法について解説しよう。 ここではビジネスの振る舞いを、「相互作用」「ワークフロー」「ライフサイクル」の3つの観点から描くことにする。ビジネスの相互作用が可視化できれば、そのメカニズムの適正や無駄な部分を分析できる。またワークフローをモデル化して把握することにより、ビジネスルールを明確にできる。そしてUMLの「状態遷移図」を使うことにより、ビジネスや資産のライフサイクルが見えてくる。 こうしたビジネスモデルを実際のプロジェクトに置き換えるにはどうすればいいか。まず「業務改革」プロジェクトにおいては、現状モデル（As-Isモデル）の洗い出しとコスト算出を行い、次に将来像モデル（To-Beモデル）の明確化とコストを明らかにすることで、どのような改革を施行すればいくら投資が必要になり、その効果がどれくらいかが数字で見えるようになる。 次に、ビジネスモデルをベースにしたシステム開発について説明しよう。開発対象となるビジネスプロセスを選び、情報システムを選定し、システムの操作や関連資産、エンティティを明確化にする。選んだ情報システムに対し、サブシステムを割り当て、ユースケースやデータモデルへと展開していく。こうしてUMLで描いたビジネスモデルを基に、業務改革やシステム導入が円滑に進められるようになる。

profile

左川 聡（さがわ さとし） オージス総研 UML技術チーム所属。UMLビジネスモデリング、EAのソリューション整備や教育およびコンサルティング業務に従事している。

ビジネスモデリング事始

■記事の「要約」がメールで読めます■ 記事の「要約」を毎週水曜日にメールでお届けしています。 下の「＠IT情報マネジメント メールマガジン」からお申し込みください。 サンプルを見る

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）