企業がビジネスの目的を実現するには、関係者が勝手な価値観や利害で行動するのではなく、事業目標を共有することが重要だ。そのためには、“ビジネスの見える化”を実現する「ビジネスモデリング」が欠かせない。そこで4回にわたり、モデリングのプロが、ビジネスプロセス・モデルを作成する際の基本的な考え方や方法、作成したモデルの活用方法などについて解説する。

大川 敏彦
ウルシステムズ シニアマネジャー（現 ウィズクライン代表取締役）

　“ビジネスの見える化”あるいは“ビジネスプロセスの見える化”ということは、これまでも様々なメディアを通して言われています。システム開発に携わっている読者のなかには、要件定義のために業務フローを書いたり概念（データ）モデリングを行ったりして、見える化を日々実践している方もいらっしゃると思います。コンサルタントなど、ほかの人が記述した業務フローや業務要件をもとにシステムを開発している、という方もいらっしゃるでしょう。

　ある程度経験を積んだITエンジニアであれば、モデリングの手法についても、いろいろなものを試されているのではないでしょうか。筆者はコンサルタントという立場で様々な企業のビジネスや業務にかかわっており、いろいろなモデルに接する機会があります。

　目にすることが一番多いのは、業務を行う担当者や組織が、縦方向もしくは横方向に伸びた、いわゆる「スイムレーン（swimlane）」として書かれており、その上に業務やアクティビティ（業務を構成する作業の単位）を表す“箱”と、それらをつなぐ“矢印”が書いてあるモデル、いわゆる「業務フロー図」です（図1）。この図では、顧客、受注担当者、出荷担当者が、スイムレーンとして描かれています。

図1●モデルの例
図1●モデルの例
[画像のクリックで拡大表示]

　また、UMLが普及した現在では、UMLの表記法を用いた図面を見る機会も増えてきました。このほかにも、例えば製造業のお客様と仕事をすると、産能大方式で書かれた図面を見ることがありますし、官公庁ではいわゆるエンタープライズ・アーキクチャ（EA）に基づいた図面群を見ることがあります。

　このようにモデルの表現方法は様々ですが、表現する対象に注目すると、ビジネスモデリングによって作成するモデルは、大きく2種類に分けることができます。一つはビジネスの“流れ”を表現する「ビジネスプロセス・モデル」、もう一つはビジネスで使用する“もの”の定義、構造、関係性などを整理する「概念（データ）モデル」です。前者はビジネスの動的な側面を、後者はビジネスの静的な側面を表現しており、いずれもビジネスを表現するには不可欠なものです。

　しかし、業務を理解したり説明したりする初期の段階では、たとえシステム化されている場合でも、ER図（Entity-Relationship Diagram）を使って概念モデルを作成することはほとんどありません。UMLのクラス図で作られた概念モデルも、表記法に不慣れな人には取り組みづらいでしょう。ましてやモデルを作成することなど、できるはずもありません。多少のあいまい性があるとしても、用語の定義などが文章で書かれた用語集や、帳票などの現物を使うことが多いと思います。

　こう考えると、「ビジネスの見える化」の初期段階での作業は、ビジネスプロセス・モデル（業務フロー）の作成であると考えてよいと思います。そこで本連載では4回にわたって、このビジネスプロセス・モデルを作成する際の基本的な考え方や方法、作成したモデルの活用方法などについて話を進めていくことにします。

“見える化”という本来の目的を実現できているか？

　ビジネスプロセス・モデルの作成手法としては、先ほど挙げたもの以外にも著名な方法論がたくさんあります。例えばIDEFやARIS、古くはワークデザインがありますし、最近ですとBPMNなどがあります。UMLを使用している人は、アクティビティ図になじみが深いかもしれません。

　このように、いろいろな主義や思想に基づいて様々な手法が考案されており、それらを使ってビジネスモデリングを行っている読者も多いと思います。ところで、そのような方々に一度考えてみていただきたいことがあります。皆さんが行っているモデリングは“ビジネスの見える化”あるいは“ビジネスプロセスの見える化“という本来の目的を、どれくらい実現できているでしょうか？以下のようなことがよく起こっていないでしょうか？

　【ケース１】膨大なビジネスプロセス・モデルを作成したが、時間や労力ばかりかかって、結局使われることがなかった。

　【ケース2】ユーザー部門にヒアリングしながら業務フローを作成したが、それが現状の業務を記述したものなのか理想像を記述したものなのかが、途中から分からなくなった。あるいは、両方が混在したモデルになったため、整理し直す必要が生じた。

　【ケース3】最新のモデリング方法論の研修を受けて、その記述ルールに従ってビジネスプロセス・モデルを作成したが、仕様通りの記述方法では表現できない部分が発生し、自己流の記述や説明書きを多用してしのいだ。

　【ケース4】自己流で作った業務フローで、設計・開発を担うベンダーに業務要件を伝えようとしたが、記述の不明確さ、記述レベルの荒さ、図面同士の不整合、記述漏れなどがあると指摘され、作り直すことになった。

　このようなことが、なぜ起こるのでしょうか。これに対してお答えする前に、ビジネスプロセス・モデリングとは何なのか、そしてビジネスプロセス・モデリングがなぜ必要なのか、ということについて、改めて考え直してみたいと思います。

ビジネスプロセス・モデリングとは何か？

　ビジネスプロセス・モデリングという言葉を文字通り解釈すると、ビジネスプロセスをモデリングする、ということになります。

　ビジネスプロセスとは「ある事業目的のために、企業内あるいは企業間で行われる作業もしくは作業手順」と定義できます。言葉で表現してみると分かりづらいですね。ひとまずは、皆さんが直感的にイメージされる業務あるいは業務手順と考えてよいと思います。

　次に、モデリングとは「モデルを作成する」ということですが、そもそもモデルとは何でしょうか。モデルと聞いて筆者が思い出すのは、子供の頃に作成したプラモデルです。理工系の学生だった頃には、モデルを使って考えることを教えられた気がします。読者のなかには、風洞実験などに用いるクレイ（粘土）モデルを思い出す方もいるかもしれません（図2）。

図2●モデルとは？
図2●モデルとは？

　これら様々なシーンで用いられているモデルの共通の性質はなんでしょう。それは“強調”と“省略”です。ある目的を実現するのに必要な属性を強調し、必要でない属性を省略するということです。

　プラモデルは、鑑賞（作成そのもの？）を目的として、対象である自動車や飛行機などの形状を強調し、それ以外の内部の仕組みや材質などは省略します。自然現象を理解するためのモデルは、必要な物理的属性のみを強調し、それ以外の属性は省略して、思考実験や実実験などに利用します。風洞実験のクレイモデルは、風の流れが正しく表現されていればよいので、外形だけを強調（精密に表現）し、それ以外は省略します。

　このように考えを進めていくと、ビジネスモデリング、あるいはビジネスプロセス・モデリングとは、「ある目的のために、ビジネスのある属性を強調し、ある属性を省略して表現すること」と定義できるのではないでしょうか。以降では、このことについてより詳しく考えていくことにします。