第２回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（シーケンスフロー編）
今回はシーケンスフローの仕様違反に関して、前回と同様ＢＰＭＮの記述解説書「ＢＰＭＮメソッド＆スタイル」（ブルース・シルバー著、以下「Ｍ＆Ｓ」）での解説と、その解説がＢＰＭＮ仕様書（以下「仕様書」）の、どこに、どのように記載されているかという形で述べていきます。
(本文、Ｍ＆Ｓ、「業務改革、見える化のための業務フローの描き方」を含めてＢＰＭＮ仕様におけるコレオグラフィーに関しては対象としてない。という前提となります。そのためコレオグラフィーに関する記述部分は省略します。コレオグラフィーが何かに関しては機会があれば書いてみたいと思います。）
総務省のサイトから公開されている（https://www.soumu.go.jp/main_content/000872456.pdf（以下「本資料」）をベースに、シーケンスフローについて解説していきます。「本資料には地方公共団体情報システム機構『地方公共団体の情報システム調達における機能要件の表記方法に関する調査研究』（平成27年３月）（以下「調査研究資料」）を参考に、表記方法の国際標準であるBPMN（Business Process Model and Notation）の手法を用いて記述した。」とあります。この調査研究資料（https://www.j-lis.go.jp/data/open/cnt/3/1518/1/all.pdf）の中に、「地方公共団体の情報システム調達における機能要件の表記方法利用ガイド」（以下「ガイド」）があるのですが、本資料は残念ながら、このガイドに従って描かれていません。その理由は、調査研究資料が「ＢＰＭＮを伝統的なフローチャートと同様に独自解釈し独自応用によって記述することができる。」という誤解を与えてしまっている可能性があることです。「仕様そのものを守らなくてならないものである」ということが明記されていないこと、またこのガイドそのものの中にも仕様違反の例が記載されてしまっていることも問題でしょう。
この調査研究資料（ガイド含む）にはＢＰＭにおいて、以下の点から誤解を生じさせる問題を孕んでおり、これは違う機会にコラムに書くことにします。誤解を生じさせる可能性がある点を以下のように、まとめておきます。
１．ＢＰＭＮ図がシステム調達における業務要件定義の資料作成を目的にしていること
→ＢＰＭＮはＢＰＭを実現するためのＢＰＭＳ実装を主な目的としている。（コラム「あなたが描いているのはＢＰＭＮ図ではありません」参照）
２．ＢＰＭＮを手法と表現していること
→ＢＰＭが手法であり、ＢＰＭを実現するためのＢＰＭＮはモデリングと表記法である。
３．ＢＰＭＮ仕様が作成された目的を説明されていないこと
→ＢＰＭＮ仕様は、主にＢＰＭを実現するためのＢＰＭＳ、ＢＰＭＮ記述ツールを構築（開発）するための規定である。
４．ＢＰＭＮ図を描くのは、情報システム部門や事業者へ委託するものだとしていること
→ＢＰＭＮ仕様が作られた当初の目的は「ITからビジネスへの権限移譲」「簡単なフローチャートを描くことによって、あまり技術的でない人達がトランザクション型のアプリケーションを構築できるようになる。」です。（コラム「あなたが描いているのはＢＰＭＮ図ではありません」参照）
5. 「実行可能プロセス」に対する認識。実行可能プロセスが記号が増えたり、記述方法が複雑になるように思わせる記述がある
→実行可能プロセス（レベル３）はＢＰＭＮ仕様では規定されていない。実行可能プロセスとはＢＰＭＳに実装され動かすことができるプロセスである（画面レイアウトデータやプロセスを実行するのに必要なデータがなどが設定されているもの）。またレベル２の認識にも誤解を与えそうな部分がある。
６．表記方法に自由度があることがＢＰＭＮ仕様を守らなくても良いという誤解を与えていること
→ここは今回のテーマであるシーケンスフローで自由度と仕様を守るということの違いを後述します。
ＢＰＭは、そもそも誤解を生じさせやすい手法です。どのように説明すべきかは我々の１０数年の経験においての試行錯誤からセミナーでお伝えをしています。地方公共団体情報システム機構の調査資料は「本来、異なった目的で作られたＢＰＭＮ図を応用して情報システム調達における業務要件定義のためのガイドである」ということを明記しないとＢＰＭＮに対して誤解を生じさせている懸念があります。ただし、このような目的でＢＰＭＮ図を使うことに対して否定しているわけではありません。ＢＰＭＮはＭ＆Ｓに従って描くと、人の業務を含めて業務を理解しやすいフローになるからです。ただし、先人が言っている「永遠の課題」はＢＰＭＮ図を描くだけでは解決できません。（コラム：「一般的な業務フローとＢＰＭＮ図との違い」「モデルプロセス導入改善とBPM導入方法について」参照）
ＢＰＭ，ＢＰＭＮ、ＢＰＭＳに関しては様々な誤解情報が飛び交っているということです。何を読んだか、誰から説明を受けたかによって解釈がバラバラとなっていますが、基本は普遍的なマネジメント手法であり、BPMコンソーシアムでは、それらの誤った解釈を是正していきたいと日々活動をしています。
１．シーケンスフローとは
Ｍ＆Ｓ（英語版Ｐ４５、日本語版Ｐ４８）では「ダイアグラムに実線のコネクターとして描かれたシーケンスフローは、プロセスステップの順序立った実行を表現します。」次に「シーケンスフローの最後尾のノードが完了すると、矢印のノードの開始が有効になります。実行可能プロセスでは、制御の実際の流れを表します。最後尾の接続ノードが完了すると、矢印のノードは自動的にプロセス・エンジンによって開始されます。」このセンテンスはわかりにくいので下図で説明をします。
「シーケンスフローの先端と最後尾に接続できる唯一の要素は、BPMN 2.0のメタモデルでフロー・ノード（flow node）と呼ばれ、アクティビティ、ゲートウェイ、およびイベントです。」（中略）「プロセスレベル内のすべてのアクティビティ、ゲートウェイおよびイベントは、イベントを終了するために開始イベントから終了イベントまでのシーケンスフローの連鎖の上に配置する必要があります（BPMN仕様はこれを絶対に要求していませんが、『メソッド＆スタイル』ではパラレル・ボックスのようないくつかの例外を除いて要求します）。」
「シーケンスフローの両端には、フロー・ノードに接続する必要があります。一端が接続されていない場合、モデルは有効になりません。」
ＢＰＭＮ仕様Ｐ９５に「シーケンス フローは、プロセスのフロー要素の順序を示すために使用されます。それぞれシーケンス フローには、ソースとターゲットが 1 つだけあります。ソースとターゲットは次のセットから選択する必要があります。フロー要素: イベント (開始、中間、終了)、アクティビティ およびゲートウェイです。」フロー要素（Flow Elements）と用語を使っていますが内容は同じです。
ではＢＰＭＮ仕様が開始イベントから終了イベントまで、すべてのフローノードがシーケンスフローで繋がっていなければならないということをＢＰＭＮ仕様が「絶対に要求していない」というのは、仕様上のどこに書かれているのでしょうか。
まずＢＰＭＮ仕様Ｐ４０に表７．３にシーケンスフローの接続のルールがまとめてあるのですが、各フローノードとアクティビティへの接続が、接続可能であることを示す「↗」では無く「‰」（パーミル）になっています。この意味は謎で、ここでは良くわからないです。
次に BPMN仕様Ｐ238、Ｐ246では開始イベントは使用を推奨するとしており、描かれていない場合は暗黙的なトリガー無し開始を意味する。終了イベントが省略されている場合は「結果がない」（すなわち、どこかに対してのトリガーはない）と書かれています。これが「絶対に要求していない」ということのようです。ただし開始イベントを使用したら、終了イベントを使用するように規定されています。
開始イベントから終了イベントまで、すべてのフローノードがシーケンスフローで繋がっていなければならないということをＢＰＭＮ仕様が「絶対に要求していない」ということは、わかりました。しかしながら実際にＢＰＭＳを開発する上では開始イベント、終了イベントがないと、様々な不都合があり、開始イベント、終了イベントがないフローを実装し実行可能なＢＰＭＳを少なくとも私は見たことがありません。
ここでのポイントは「プロセスレベル内のすべてのアクティビティ、ゲートウェイおよびイベントは、イベントを終了するために開始イベントから終了イベントまでのシーケンスフローの連鎖の上に配置する必要があります。」ということです。
２．仕様違反のポイント
冒頭の本資料に以下のような記述があります。
赤枠の部分はシーケンスフローが途切れています。残念ながらこの記述はＢＰＭＮ仕様に違反をしています。開始イベントがあれば、終了イベントを持たなくてはならない。という仕様にも違反をしています。
ＢＰＭＳへの実装を認識できている人であれば、ＢＰＭＮ仕様を忘れていたとしも、このような記述ができないことがわかると思います。選挙人はＢＰＭＳを使う人ではないためにブラックボックスプールとして記述されています。「投票用紙等交付」をしたあと、トークン（ボール？）がＢＰＭＳを使っていない選挙人に渡り、その後、ＢＰＭＳを使っていない選挙人から中間イベントにトークンが戻り再開されると言う意味で書かれているようです。しかし選挙人はＢＰＭＳを使っていないのでトークンのやり取りをすることができません。これではＢＰＭＳがエラーとなり動きません。
正しくは以下のようになります。トークンはＢＰＭＳ内（プロセス内）で受け渡しされます。
その他、本資料の凡例は、個別の記号を独自解釈し独自の意味を与えてしまっています（例えば黒い封筒が描かれた送信タスク。送信タスクと中間送信イベントは、まったく同じ意味で自動送信を意味しますが、人がメール等を送信しているという独自の意味を与えてしまっています。）地方公共団体情報システム機構のガイドとも異なった独自解釈をしており各自治体などが本資料を参考にされないことを願うばかりです。
３．まとめ
冒頭にも書きましたが、ＢＰＭ、ＢＰＭＮ、ＢＰＭＳは様々な誤解を生じる発信が残念ながらされています。まず古い資料を信用するのはやめましょう。（ＢＰＭＮ１．Ｘの仕様を参考にしている可能性もあります。）また、同じような内容なのに描き方が異なっているＢＰＭＮ図を見た場合は、何が正しいのかを確認する必要があります。「両方とも正しい記述で自由度があるんだな」という間違った認識をすることだけはやめていただきたいと思います。少なくとも記号の意味は１つです。使い方、接続ルールも決まっています。
ＢＰＭＮ図の自由度とは以下のようなことであって、記号の意味や接続方法を自由に解釈していいということではありません。以下の２つの図はまったく同じことを意味しています（どちらも仕様違反はありません）。どちらの方がわかりやすいかは別の問題です。プログラミングでも、他の人が読んでもわかりやすく書く人と、そうでない人の差と同じあり、そのプログラムがエラーとならずに動くか動かないかという問題ではないです。ＢＰＭＮ仕様は、少なくともＢＰＭＳが「動く」ように最低、守らなくてはならないルールです。ＢＰＭＳを今は使わないから自由に書いていいい、自由に解釈していいということにはなりません。ＢＰＭＮ図は誰が読んでも同じ意味として伝わる。という特徴を失うことになるからです。
次回は、メッセージフローに関して記述したいと思います。
関連コラム・ページ
・第１回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（データオブジェクト編）
・あなたが描いているのはBPMN図ではありません
・一般的な業務フローとＢＰＭＮ図との違い
・モデルプロセス導入改善とBPM導入方法について
・BPMとは
・BPMSとは
・BPMNとは
・BPM導入支援サービス
・モデルプロセス導入支援サービス
