あなたが描いているのはBPMN図ではありません
「BPMN図を描いています。」と言われるフローを見ると「これはBPMNの記号を使っていますがBPMN図ではありません。」と言うしかないというものを見受けることがあります。私は「BPMN図もどき」と呼んでいます。そういった「もどき」が世の中に沢山あり、それをBPMN図だと思っている人がいるということを非常に残念に思います。
その原因は
・BPMN図を描くことの目的が不明確であること。
・BPMN仕様そのものには、わかりやすく描くための記述ルールに関しては何も書かれていない。
ということにあるのだと思います。
「BPMN図もどき」は
・BPMN仕様に違反をしています。仕様違反をしているということはモデリング（一定のルールに沿った抽象化）ができていないということです。BPMSの実装に使うことができないです。（これは後述します。）
・次にブルース・シルバーが言う「悪いBPMN」です。具体的に記述されていないために読み手によって、いろいろな意味として読むことができるもの、説明をしてもらわないと何が書かれているかわからないものです。すなわち共通言語的に改善議論の中心に置くことができないです。
・BPMN仕様が何のためにあり何を規定しているのか。
・仕様だけでは不足している記述方法を補っているブルース・シルバーのスタイル・ルールとは。
・そもそもBPMNは何のために作られたのか。
について簡単に説明をしたいと思います。
私は今でもブルース・シルバーが提唱しているスタイルルールの意味は「こういうことだったのか」という発見があります。
改めて「BPMNメソッド＆スタイル」を読み返し「BPMNとはどうあるべきなのか」、また「その基本思想からBPMSはどうあるべきなのか」を述べてみたいと思います。
目次
１．BPMN仕様とモデリング
２．「良いBPMN」とノーテーション
３．BPMNは何のために作られたのか
４．まとめ
１． BPMN仕様とモデリング
BPMNが伝統的なフローチャートとの違いに関して、ブルースは以下のようにまとめています。（２０１３年に翻訳したときよりも、わかりやすい表現で記述します。）
・業務フローを描く人が、独自の意味作らないこと（作る必要がないこと）。
・イベントトリガー（何かのキッカケでそのプロセスが始まる、止まる、変化するなど）での動作を記述すること。
・内部の業務の流れだけでなく、外部とのやりとりを表現していること。
BPMNはビジネスプロセス「モデル」＆「ノーテーション」です。BPMN仕様が決めていることはモデリング（抽象化）の基準です。残念ながらノーテーション（記述法）に関しては、ほとんど記述されていないのが実態です。しかしながら、このモデリング基準すら守られていないBPMN図が沢山、世の中にあふれており、それをBPMN図だと言ってしまっている人達がいるということです。モデリングの基準が守られていない場合、正統なBPMエンジン（BPMNを解釈して処理をする機能）を持つBPMSでは使い物にはならないでしょう。
２．「良いBPMN」とノーテーション
ブルースは、BPMN仕様から欠けているノーテーションの部分を補うために「スタイルルール」というものを作りました。
「BPMNメソッド＆スタイル」には、BPMN仕様を決めるときにBPMNが「ビジネス向けの図式化表記法」と「実行可能プロセス言語」（BPMS上で動かすための言語としての役割）の綱引きが最初から存在していた。と書かれています。
簡単に言うと後者が勝ったということです。そのために実行可能プロセス言語を強く意識した仕様しかBPMN2.0には残らなかったのでしょう。
しかし、ブルースはBPMN1.2時代にBPMNの記述がビジネスの世界で受け入れられたことを大切に考えていたのだと思います。すなわち、ビジネス向けの業務フローの描き方であり、かつ実行可能プロセス言語としての役割を持つべきだと考えたことによって「スタイルルール」を作られたのだと思います。
３．BPMNは何のために作られたのか
BPMNは、どのような思想で作られたのかを簡単にまとめてみました。BPML.orgというコンソーシアムが作ったものが最初だと言われています。
※「BPMNメソッド＆スタイル」日本語版の文章から解釈
BPMNが作られた根本思想はここにあると思います。BPMコンソーシアムが提唱しているBPMの改善ステップの「ステップ５」までは実務者が作ることをお勧めしていることと根本思想は合致します。「ビジネス向けの図式化表記法」と「実行可能プロセス言語」の綱引きが発生したようですが、ブルースは「綱引き」ではなく両方が満足する表記方法を提唱しており、BPMコンソーシアムもその考え方を、日本企業に適した形にして発展させて来たつもりです。
４．まとめ
「ITからビジネスへの権限移譲」「簡単なフローチャーとを描くことによって、あまり技術的でない人達がトランザクション型のアプリケーションを構築できるようになる。」ということがBPMNの根本思想であるとすると、それに対応するように常にBPMSは進化しなければならないでしょう。
２０２３年６月１５日の第一回BPM情報共有会（動画配信中）でのSBフレームワークス（株）の米光賢一氏の言葉を借りると今のBPMSでは「誰のためのローコード開発ツールなのか」という疑問の声がありました。ちょっと複雑なこと（複雑でもないことですら）すぐに「IT技術者がいないと構築できない。」というのでは「ITからビジネスへの権限移譲」をBPMSベンダーは拒んでいるかのように見られてしまうのは本意ではないでしょう。すべてのBPMSがそうであるわけではないですが、ユーザーから（開発ベンダーからでは無く）進歩が見えないBPMSではBPMの発展を推し進めるのではなく止めてしまうことになるでしょう。短期の利益を考えることの帰結が長期の利益を失うことになることに繋がらないことを願うばかりです。しかしながらBPMが10年以上前の流行語で終わらなかったのはIT業界の常識（流行語使い捨て文化）では考えられなかったことであり、そうなったのはBPMNの存在があったからだということを忘れてはならないでしょう。
