BPMNのモデリング・ステップとBPMN 2.0適合基準
本サイト訪問者のサーチ検索キーワードに”BPMN 2.0”が多いので今回は、2011年11月17日の投稿記事、「Bruce Silver氏のBPMN 2.0ブック第2版が日本でも入手可能に！」の末尾で紹介した「BPMNモデリング・ステップ」とOMGのBPMN 2.0仕様との関連性について、もう少し詳しく解説したい。
これまでのBPMN 1.xは、記述モデルと分析モデルの用途に主眼が置かれていた。一方、実行可能モデルの用途として見た場合は、図形要素や属性が不足しており、不完全だった。BPMN 2.0では、米IBMや独SAP、米OracleといったメジャーなBPMSベンダーが中心となって開発を進めたことにより、実行可能モデルの用途で使うための仕様強化が図られ、「ビジネスからITまでの広い範囲のモデリング要件をカバーする」という当初の開発目標は達成できた。しかしその反面、図形要素や属性の種類が多く複雑になったため、ビジネス・ユーザーにとってわかりやすいというBPMN本来の良さが失われる結果となった。この問題を解決するためにBPMN 2.0ベータ2で追加されたのが、仕様書2章のComformance(適合基準）だ。この概念は少々複雑なので図1に整理してみた。
図1. BPM製品のBPMN適合基準
適合基準（Conformance）は、BPM製品のBPMN 2.0仕様準拠レベルを定義している。当然、この基準作りには、ビジネス・プロセス・モデリングの一般的な方法論と「BPMNモデリング・ステップ」の考え方が配慮されている。 また、モデル駆動型開発で言うところのPIM（Platform Independent Model、プラットフォーム独立）とPSM（Platform Specific Model、プラットフォーム依存）の領域が明示されてる。図1左の「プロセス・モデリング適合」はプラットフォーム独立（PIM）を、右上の「プロセス実行適合」はプラットフォーム依存（PSM）を表している。図1右下の「コレオグラフィ・モデリング適合」は、BPMN 2.0から新たに追加された、プロセス間のメッセージ交換手順やルールを図で表記する基準である。この適合基準は、PIMの領域に限って規定している。プロセス・モデリング適合では、記述モデル、分析モデル、実行可能モデルの3つのステップで使用する図形要素と属性の範囲を、それぞれ、記述適合クラス、分析適合クラス、共通実行可能クラスの3つのクラスに対応させて規定している。
分析適合クラスは、記述適合クラスを包含し、共通実行可能クラスは、分析適合クラスを包含の一部を包含（※読者のご指摘により変更しました）する。このように、スーパークラス／サブクラスの関係を明示して、モデルで定義する内容の詳細度を段階的に拡大している。 たとえば、”人の作業”と”システムの作業”を表すタスクの図形要素を図2に示す。モデリング・ステップが進むに連れ使用可能な図形が増えていく。このようにITの専門家でないビジネス・ユーザーでも限られた少数の図形でプロセス・フローの骨格を定義できるように利用者側へのガイドがBPMN仕様に盛り込まれている。
図2. モデリング・ステップとタスク詳細化の変遷
適合基準は、かなり厳しい基準で、”BPMN 2.0完全準拠のプロセス・モデリング・ツール”と呼べるのは、共通実行可能クラスで規定した図形要素と属性の範囲に加えて、コラボレーション図やカンバセーションズ図（BPMN 2.0から新たに追加された図表記）、そのほかの諸規定を100％満足した場合に限る、と規定されている。
BPMN 2.0適合基準を反映したビジネスプロセス・モデリングツールの実例
では、この適合基準がどのようにビジネスプロセス・モデリングツールの製品開発に反映しているか、実際の製品例を紹介する。
図3は、ITP Commerce Process Modeler 5 for Microsoft Visio SR6 のBPMN 2.0ダイアグラム・モード選択時に表示されるオプションである。 モデリング・ステップに対応する適合基準を選択することで使用できる図形表記を制限し、モデル表記レベルの統一が可能になっている。これまでは、利用者のモデリングスキルや経験度合いによって使用図形がマチマチになりモデル表記のレベルが統一できないことがモデリング作業課題の点の1つであった。ツールがこの適合基準を導入したことによって、この課題の幾分か（全てではない）は解決できるようになっている。また、ITの専門家でないビジネス・ユーザーには、レベル１ないしレベル２の少数図形だけでプロセスを記述できる手軽さと基準を提供できるのである。
同製品は、BPMNトレーニングの実践者であるBruce Silver氏のフィードバックに基づいて改良がなされており、いち早く同基準を導入した好事例の製品である。
図3. モデリングツールのBPMN適合基準選択オプション
プロセスモデルの多言語表記
図3の”Current diagram language”に示すとおり、グローバル企業が国を超えてビジネス・プロセスを標準化および統制管理できるよう１つのプロセスモデルを多言語で表現できる機能がモデリング・ツールに装備され始めている。この傾向は実行エンジン側のプロセス実行モデルでも同様で、Oracle BPM Suite 11gの最新リリースでも多言語翻訳機能が装備されている状況だ。
間違いやすいモデリングツール選択
SI事業者の中には、BPMツールベンダーが提供するビジネスプロセス・モデリングツール（プラットフォーム依存のプロセス実行モデル定義専用）で十分と主張する方々がいる。しかし、この主張はモデリングツールをプロセスモデル実装者側のIT視点でしか見ていないと私は考えている。下図4は実際のBPMプロジェクトで作成された分析モデリング段階の成果物の一例である。プロセスで取り扱う文書、データ、顧客や外部協力組織とのデータのやりとりなどが記述されていることに着目していただきたい。これらの記述はプロセスを流れるデータとアクティビティへの入出力相互関連を表していおり、プロセスを分析し改善設計をするうえで非常に重要な情報である。実は、実行エンジン側のプロセス実行モデルは、一般的に次の図形要素を表現しない。または、できないのである。
- 入出力データを表現するデータオブジェクト（図例の文書アイコンとその関連が失われる）
- 複数のプール（プロセス）とその相互関係（図例の”自部門”プールだけが対象となる）
これは、実行エンジンが１プロセスモデルあたり、単一プール（プロセス）を実装の対象としていることと、データオブジェクトとその関連情報は、図の背後に隠れた詳細仕様に記述するためだ。したがって、モデリングツールの選択にあたって、プロセスモデルの記述・分析ステップと実装設計のステップでは、同じBPMN表記図形を使うと言ってもプロセス実行モデルでは表現できない図形があることを理解しておく必要がある（図2の適合クラスに示すプロセス適合クラスのズレがその意味を表している）。また、ビジネスプロセス・モデリングの過程では、ビジネス・ユーザーをモデリング協働作業に誘いこむやさしい仕掛け（ファシリテーション）と頻繁な書き直し（ビジュアル・シンキング）が生じることを覚悟してツールを選択しておかなければならない。このため、プロセスモデル設計者用とプロセスモデル実装者用に分けてそれぞれの作業に適したツールを選択するのが一般的である。BPMN-DIやXPDLなどのモデル交換フォーマットが論議される背景には、このように設計（記述・分析）と実装との間にモデリング目的の違いがあることを理解しておくべきだ。
図4. 分析モデリング段階のプロセスモデル例
出典： “GoodEggしくみや” 山原雅人氏ご提供
