第１回：ＢＰＭＮ仕様違反のＢＰＭＮ図例（データオブジェクト編）

 　ＢＰＭＮ仕様（Specification)は２０１３年１１月にＩＳＯ１９５１０版、１２月にＯＭＧ版が出ていますが、どちらも主な内容は同じだと思います。前回のコラムにも書きましたが、ＢＰＭＮ仕様書(以下仕様書）は５００ページ以上あり非常に難解な文章で記述例が少なく、ルールがまとまって記載されておらず、ちりばめられています。仕様書だけを熟読してもＢＰＭＮの正しい記述を学ぶのは非常に難しいです。仕様書をベースとした資格の取得をしても、実践的に正しいＢＰＭＮ図を描くということができないのはそのためです。個々の記号の意味や接続方法は勉強できるかもしれませんが、実際の業務プロセスを、どのように描くかということは学ぶことは厳しいと思います。
　世界的にも評価が高いＢＰＭＮの記述解説書「ＢＰＭＮメソッド＆スタイル」（ブルース・シルバー著、２０１３年山原が翻訳企画、岩田氏と共に翻訳、出版、日本語版は現在廃刊、以下Ｍ＆Ｓ）があります。現在の我々のセミナーは仕様書とＭ＆Ｓに我々の経験からＢＰＭＳ実装を考慮したＢＰＭＮ図の描き方を加えて書いた「業務改革、見える化のための業務フローの描き方」（２０１８年出版：マイナビ出版）をベースにしています。

　総務省のサイトから公開されている最新と思われる（令和６年１月）プロセス図（【住民記録システム】業務フロー）（https://www.soumu.go.jp/main_content/000926270.pptx）をベースに、今回はデータオブジェクトの使い方について解説したいと思います。「ＢＰＭＮメソッド＆スタイル」に記載されているルールが、仕様書のどこに、どのように書かれているかという形で述べていきます。
　勘違いしていただきたくないのは総務省のプロセス図の中に仕様違反があることを批判するために書いているわけではありません。正しいＢＰＭＮ図が普及してほしいと願っているだけです。ＢＰＭＮ図の記号、記述方法には明確な「意味」があります。しかしながら間違いが発生するのは仕様書の難解さに問題があり、世の中には仕様違反のＢＰＭＮ図が溢れてしまっています（これはブルースも指摘していることなので、日本だけではありません）。それらを参考にされると、さらに間違ったＢＰＭＮ図が発生することになります。ＢＰＭＮ仕様は、言わばJAVAのプログラミングルールや数学の記号のようなものです。「自分はこの書き方がわかりやすいと思う」として仕様違反をしていては、プログラムエラーが発生する、正しい数式でモデル化ができなくなります。読みやすい、読みやすくないという点はあるものの、人によって解釈の異なるプログラミングや数式はありません。ＢＰＭＮにおいても、同様でありＢＰＭＮ仕様は最低、守らなくてはならないルールです。

１． データオブジェクトとは

　ブルース・シルバーの言葉を借りると「The data object shape looks like a dog-eared page.」角がおられたページと言っているように以下の図形です。

　
　Ｍ＆Ｓでは「ＢＰＭＮ１．２では、データオブジェクトは(中略）意味を持たないダイアグラムの注釈、あるいはルール（すなわち、図をわかりやすくするための補足的な記号）だと考えられていました」と書かれており、ＢＰＭＮ２．０では「データオブジェクトは実際のプログラミングの構築対象物になります。プロセスレベルでは、ローカルな変数、つまりプロセスインスタンスが実行されている間、その内部に一時的に保存されるデータを表します。」と書かれています。
　仕様書のＰ204に「Data Object elements MUST be contained within Process or Sub-Process elements.」とあるように「データ オブジェクト要素は、プロセスまたはサブプロセスの要素内に含まれなければなりません。」と書かれています。Ｍ＆Ｓでは、このことは明記されていないのですが、仕様を補足するブルースが作った「スタイルルール」では以下の描き方を禁止しています。
（Method&Style 英語版　P79 Figure6-11 引用）

　すなわちプール(プロセス）外にデータオブジェクトを記述することと、メッセージフローにデータオブジェクトを関連で接続することは仕様違反となります。スタイルルールでは以下の描き方をするように勧めているのは、仕様違反を防止させるためにブルースが考えたのだと思います。
　

スタイルルール「メッセージフローのラベルにはメッセージの名前を直接付ける」

　データオブジェクトの使用方法ですがＭ＆Ｓでは「アクティビティまたはイベントからデータオブジェクトへのデータ出力関連と、それに続くデータオブジェクトから別のアクティビティまたはイベントへの入力関連によって表現されます。」「簡易表現として（中略）シーケンスフローに方向を持たない関連で接続することも許されています。」よって以下の図のように描けることになります。（上図のように描くことがベストだとブルースは言っています。）イベントからのデータの入出力表現は、メッセージフローのラベルで表現されることとなるため不要であることが多いです。よって、Ｍ＆Ｓでも仕様書でもイベントからデータ出力、イベントへの入力のデータ関連例が載せられていません。
　

 

　仕様書では、記述方法はデータオブジェクトの項ではなく、データ関連（Ｐ220～223）の項で説明されています（これが「ちりばめられている。」ということです）。クラス図の説明などを省き、ブルースがＭ＆Ｓで書いた部分の裏付け部分を抜粋します。
The purpose of retrieving data from Data Objects or Process Data Inputs is to fill the Activities inputs and later push the output values from the execution of the Activity back into Data Objects or Process Data Outputs.ここでの「The purpose」はデータ関連の目的です。「データ オブジェクトまたはプロセス データ入力からデータを取得するデータ関連の目的は、アクティビティの入力値を入力し、その後、アクティビティの実行からの出力値をデータオブジェクトまたはプロセスデータに出力することです。」
How Data Associations are used to represent inputs and outputs of Activities.(上図上）
Alternatively, Data Objects MAY be directly associated with a Sequence Flow connector (上図下) to represent the same input/output relationships.
.データ関連を使用してアクティビティの入力と出力を表す方法。(上図上）
あるいは、データ オブジェクトをシーケンスフローに関連に直接付けて、同じ入出力関係を表すこともできます。(上図下）

２．仕様違反のポイント

　 前述の【住民記録システム】業務フローの１ページに以下のフローが記載されています。赤丸で示した①と③のデータオブジェクトの描き方は残念ながらＢＰＭＮ仕様違反になります。ＢＰＭＮ１．２時代のルール（データオブジェクトが補足記号であったころ）で描かれたＢＰＭＮ図を参考にしてしまったからだと思います。②に関しては、仕様違反ではないのですがＢＰＭＮ図としてデータオブジェクトが意味するところが理解できないです。

①メッセージフローに接続されているデータオブジェクトの内容は、前述のスタイルルールにもあるようにメッセージフローそのものに記述するべきでしょう。（下図参照）
②想像力を働かせても入力照合の仕事が理解できないです。ＢＰＭＮ図からは「入力照合をして入力確認票をアウトプットする。」と読めます。
しかしながら、受理した資料をどこで入力しているのでしょうか。窓口はマニュアルタスクなのでシステムにはインプットしていません。「受理した資料の内容を入力したデータと受理した資料を照合し入力確認票としてアウトプットとして出す。」という意味で描かれているのであれば以下のように描くべきでしょう。ただしアウトプットされたデータオブジェクト（入力確認票）は、この１件の処理が終わると消える（物理的なものであれば廃棄する）ことを意味しています。本当に現実はそうなのでしょうか。

入力確認票は、もしかすると以下の２つの使い方をされているのかもしれません。

・入力確認票は永続的に保管される場合は、下図のようにデータストアで表現すべきでしょう。

・下図のように二重チェックのために誰かに受け渡されて再確認をしているのかもしれません。

　現実の業務がわからないため、あくまでも想像です。元の図では残念ながら「『入力確認票』とは、どのように使われるものですか？」という質問をしないとわからない内容のプロセス図です。これではＢＰＭＮ図を読むだけでは業務が理解できませんしＢＰＭＳに実装できないです。

③本人確認情報はデータストア間のデータを表しているのだと思います。データ関連そのものに「本人確認情報」というラベルをつけるべきでしょう。（上図確認）

３．まとめ　

　ＢＰＭＮ１．Ｘでは、ＢＰＭＮはデータの表現に関して不明確だという批判があったようです。そこでＢＰＭＮ２．０では、データオブジェクトの意味の明確化、データストアの追加ということを行ったのだと思います。データオブジェクトは、主にアクティビティ間のデータや書類の受渡しを明確にしています。そしてシステムレベルでは変数として定義すべきものとされています。データオブジェクトは、現状分析、改善後の姿のＢＰＭＮ図を描く上でも非常に重要なものです。現状では紙やＥｘｃｅｌデータなどで受け渡しをしていたものを、紙やＥｘｃｅｌ作業などを廃止する改善検討のポイントになるからです。
　Ｍ＆Ｓでは、スタイル（ルール）を「仕様の公式ルールを超えた図形要素の使い方とその組み合わせ方の基本原則を指しています。」「そのうち多くは図形要素に名前を付けるラベリング作業です。」と書かれています。
　すなわち、ＢＰＭＮ仕様では規定されていないラベリングルールを定めることで（複数の）仕様のルールが守られるようにしているということです。
前述の「メッセージフローのラベルにはメッセージの名前を直接付ける」というスタイルルールがメッセージフローの正しい（わかりやすい）使い方とデータオブジェクトの仕様違反を防ぐという両方の意味があることが良い例であると言えます。

次回はシーケンスフローに関する仕様違反について書いていきたいと思います。

 

 

関連コラム・ページ

・あなたが描いているのはBPMN図ではありません
・BPMとは
・BPMSとは
・BPMNとは
・BPM導入支援サービス
・モデルプロセス導入支援サービス