| KIU研究会レポート（1） |
BPMのフレームと国際活動の現状・今後について
生井 俊
2006/1/19
| 2005年11月30日、「経営とITの融合」研究会（以下、KIU研究会）の第1回会合が開催された。今回は、WfMC運営委員会 副議長／環太平洋代表の貞金佳尚氏がBPMのフレームと国際活動の現状と今後について、報告・講演を行った。その模様をお伝えする。（→記事要約<Page2>へ） |
第1回KIU研究会は、まずKIU研究会事務局からは各委員の紹介、および本研究会の研究テーマと運営方法、「アジャイル・エンタープライズ」コーナーについての趣旨説明があった。引き続き、「アジャイル・エンタープライズ ソリューション研究」として、WfMC 運営委員会 副議長／環太平洋代表の貞金佳尚氏が報告・講演を行った。講演に対しては、質疑応答とディスカッションが行われ、参加者それぞれの立場・視点を踏まえた熱い議論が交わされた。以下、貞金氏の講演をお伝えする。
| - | WfMCのモットーは「変化に対応できるものが生き残る」 |
|
|||
WfMCは非営利のワークフロー管理システム標準化団体で、本部は米国のフロリダにあります。staffware社のジョン・パイク社長が運営委員会の議長を務めています。運営委員会は、欧州・アフリカ大陸、北米・南米、アジア・環太平洋の3つに分かれていて、私は副議長としてアジア・環太平洋を担当しています。パンパシフィックなのでニュージーランド、オーストラリア、東南アジア、極東アジアも含みます。
今回は、なぜスタンダード（標準化）が必要なのかと、プロセスの考え方やBPMをスタンダードにする国際ルールなどのコンセプトの部分、それからスタンダードと組織の関係、全体の動きはどうなっているのかをお話しします。
| - | 言語などの標準化によりベンダと客のリスクが減少 |
- - PR -
まず、なぜ「スタンダード」が必要なのかですが、スタンダードによってユーザーとベンダ双方のリスクを減少させることになるだろうと思っているからです。お客さんから見れば、標準があれば一定の基準に基づいて考えることができます。当然、ベンダから見ても、お客さんに一定の基準があれば、それに合わせたベクトルを持つことができます。
そのために必要なことが2点あります。1つは「言語の標準化」です。プロセスの可視化とよくいいますが、可視化することにより対象に対しての共通認識ができます。もう1つは、いかに機能として最低限のものを押さえていくか──すなわち「機能の絞り込み」です。ベンダはいろいろ定義をしたがりますが、それはユーザーから見ると決していいとは限りません。要はシンプル・イズ・ベストで、一番簡単なものの仕組みを作っていこうという方針です。
お客さんから見るとオプションが増えていくわけですから、標準化によるリスクの削減のための「機会を与えます」というのがあります。つまり、いろいろな機能がありますから討議をしていく中で、ミニマイズしていくわけです。次に、ベンダに対しては「ロックアップしていくのはやめましょう」とメッセージしています。それから「ツール間の互換」を必ず持たせなければなりません。環境を変えたら使えない──ではいけないはずです。そういった状況をなくすためにも、「最低限の機能は何か」を討議し、異機種間でもツールの互換を持たせていきます。これらの4点は、お客さんにとって非常にメリットがあります。
一方、ベンダにとっても、標準化は「研究・開発費を減らす」などのメリットがあります。ベンダはベンダでしっかりやって、お客さんのニーズに対してどう供給していくか、同じ器の中でどう色を出していくかが、ベンダに求められているこれからの役目だと思います。
共通化を図るときに、どういうスタンスで共通化していけばベンダにとっても生き残りになるかも語られています。そこでは、「プロセス」「情報」「組織」を、切っても切れない関係の「3つの輪」ととらえています。「プロセスと組織」の関係では、役割と責任あるいはガバナンスといったところを見ます。「プロセスと情報」の関係では、使うものや生産するモデル、通信モデルといったもの、データベースのやり方とかワークフロー的な通信のやり方とかを見ます。「組織と情報」となるとセキュリティです。これはアクセスもそうですが、基本的に誰がこの情報に関するオーナーシップを持っているのか、許可権限を持っているのかを考えていかなければなりません。この3つを踏まえて、われわれは全体的なシステムを考えていかなければなりません。
| - | BPMNが使えるベンダは世界に26社のみ |
このためにわれわれが何をしなければいけないか──。これまでいくつか「国際標準仕様」がありましたが、だんだん淘汰されてきました。いま、国際標準の中核の1つとして、BPMN（Business Process Modeling Notation）があります。BPMNとは、BPMIという組織がビジネスプロセスを表記するために作った標準仕様です。BPMNも当初は非常に欠陥があり、かなりシステム寄りのアーキテクチャでした。しかし、いまはOMGも含めたモデリング──つまり人間寄り、もっとプロセスの上流工程のことを築かなければいけないということで、かなり上流工程をこの表記法の中に入れ込んでいます。BPMNは現在、2.0ができています。
 |
| 図1 国際標準仕様（図版拡大） (C)WfMC/BPMI |
現在、このBPMNが使えるツールを提供しているベンダは、発表されているもので世界に26社あります。BPMNはあくまでも表記法でグラフィカルなインターフェイスだけですから、BPMNで書いたからといって異なるツールで扱えるとは限りません。それを使えるようにするのが、XPDL（XML process Definition Language）とBPEL（Business Process Execution Language）です。XPDLはWfMCが、BPELはOASISが仕様を策定しています。このオブジェクトに落としていくと、初めて異なるベンダのツール同士で、同じ表記が扱えるようになります。
BPMNで表記したら、BPELもしくはXPDLのオブジェクトに落とし込みます。落としたものは、どのツールでも同じものが書けるという状態に持っていこうとしています。これが全体的な考え方の1つです。それからBPELを広くして、WSCI（Web Services Choreography Interface）──これはインターフェイスですが、こういったものを通していき、レイヤが下りてくると通信領域まで入ってきます。いま、われわれが盛んにやっているのは、この領域をどうするかです。Wf-XMLは有機的にBPMNとつながっていって、その中にオブジェクトを埋め込んでいく形になります。これが1つのレイヤになっています。
一番上に見えるのがあくまでも表記法、その下に定義を行うルールエンジンなどがあり、これを実行エンジンがオブジェクト生成します。自動的にコードを作るわけです。ここはベンダの領域になります。
| - | BPMの領域とモデリングの概念モデル |
これはBPMの空間がどうなっているか示した図です。
 |
| 図2 BPMスペース |
いわゆるITベンダ／ITデベロッパには、当然「ライフサイクル」「ワークフロー」「EAIプロセス」「コンポーネントアセンブリ」があります。今後、いろいろなアプリケーションが、コンポーネントアセンブリの形になるのではないかといわれています。つまり、1つのプロセスを何らかの単位でコンポーネント化して、それを後からアセンブルしていくというやり方です。SAPの製品などもともとのそういうコンポーネントを用意しておき、それをアセンブルして1つの大きいシステムにしていきます。こうしたコンポーネントをどう組み上げていくかという点は、現在討議されている最中です。これはコンサルタントとITベンダを含めて、やっていかなければいけないと思います。
それからEAIプロセス──すなわち、つなぎ込みの問題があります。実行エンジンとしてのワークフローは、ITデベロッパが受け持ちますが、ここだけでは絶対にすべてを解決できません。業務の現場では、これはPDCAサイクルとして徐々にやっていきますから、この意味でのBPMは有機的にとらえなければなりません。
その中で、一番下に「オーディティング」という分野があります。「オーディティング」「モニタリング」「ビジネスメジャメント」──これは、バランスト・スコアカード（BSC）でいうKPIだけではなく、プロセスとしてのメジャメントです。プロセスとして重要だという考え方で、これまで協議があまりされていませんでした。ホワイトカラーの生産性向上などが指摘されていますが、その指標化をどうするかを含めて、もう少し考えていく必要があります。「シミュレーション」の世界までいくとBSCでいうモニタリングもありますが、バンドの領域です。ビジネスアクティビティのモニタリングに入ってきます。
次に、モデリングの概念モデルです。
 |
| 図3 モデリング概念モデル |
一番上が「ノーテーション」という表記に関する「コンセプチュアルモデル」です。これはWfMCが10年間研究し、BPMNを含めたモデリングを作っていこうということで、分類を全部調べました。その下が、過去討議されてきたプロセスを継承する「エグゼクタブルモデル」です。グラフィカルノーテーションやビジネスルールにおけるノーテーションはなかったのですが、これらが非常に重要だとして、リソースモデルなどを含めたノーテーション、可視化をどうこの中に入れるかを考えています。
今回新たに、「サービスディフィニション」という考え方が入ってきました。この中にリソースモデルという、「リソース」「プロセス」「インフォメーション」の融合体と、「サービス」という考え方を入れます。ここにはプロセスだけでも、ワークフローだけでもなく、リソースモデルとしてこの中に有機的に組み込んでいこう、と。これがBPMの根幹となっているところです。
それから、この下の「エグゼクティングインスタンス」では、できるだけバグがない構造を自動的に作っていきます。「サービスインタラクション」は、プロセスとメッセージングとありますので、それをどう考えていくか。BPMの中には当然メッセージングという考え方が入ってきます。後は、最終結果として組織とどう有機的に融合させるかという「リソース」です。プロセスの抽出、実行を行って、最後はこういう有機的なものにします。
| 1/2 |  |
|
||||||||
