2021/3/11タスクとサブプロセス人の作業やITシステムの処理を表すアクティビティにはタスクとサブプロセスの2種類があります。第3回で説明したように、「+」記号が付いていないのがタスクで、付いているのがサブプロセスです。タスクはこれ以上詳細に可視化しないアクティビティ、サブプロセスはさらに詳細を可視化するアクティビティです。今回は、タスクとサブプロセスという2つのアクティビティにはどのようなタイプがあるのか、その概要を確認していきます。詳しい使い方については「BPMN仕様の理解を深めよう」で説明します。タスクのタイプタスクは左上の記号で作業や処理のタイプを区別することができます。区別をしない場合は記号を付けない抽象タスクを使用します。区別する場合に使用するタイプとして、BPMN仕様では7つが用意されています。BPMNをBPMSで動かす際の動作を考慮して動作や処理の内容が定義されています。ユーザタスク:BPMSやその他のITシステムを利用しながら人が実行する作業を表しますマニュアルタスク:ITシステムを利用しない人の作業を表します受信タスク:プロセス外部から受け取ることを表します。受け取った後の作業や処理は含まれません送信タスク:プロセス外部に渡すことを表します。渡す資料やデータなどを作成する作業や処理は含まれませんサービスタスク:Webサービスやその他のアプリケーションとの連携処理を表します。System)の処理を表します。それをBPMSが呼び出し実行結果を受け取るのがルールタスクの役割ですなお、以上のようなタイプ分けは自由な拡張が認められています。DMNs」ではケースタスクが追加されています(ケースマネジメントと呼ばれる機能と連携するタスクを表します)。サブプロセスのタイプサブプロセスには、ここまで見てきた通常のサブプロセスの他に3つのタイプがあります。アドホックサブプロセス:アドホックとは、サブプロセスの中のアクティビティ(タスクとサブプロセス)を、実行者がサブプロセスを実行する時に決める振る舞いのことです。提案書作成アドホックサブプロセスでは「提案内容から書いても実施スケジュールから書いても良い」ということを表しますトランザクションサブプロセス:トランザクションとは、サブプロセスの中にある複数のアクティビティのうち、中途半端に一部だけが実行されてしまうことがないようにする仕組みのことです。全て実行されるか、キャンセルの時は全てが実行されないようにします。旅行予約トランザクションサブプロセスでは「航空機予約はできないけれどホテル予約だけできた」という中途半端な結果にはなりませんイベントサブプロセス:ある事象(イベント)が発生した時だけ実行されるものをイベントサブプロセスと呼びます。予約キャンセル・イベントサブプロセスには「顧客から予約キャンセル依頼を受け取った時に実行される一連の作業や処理」が含まれますなお、図のイベントサブプロセスでは右上に丸記号が記入されていますが、その丸記号は前述の業務フローツールが拡張したものです。サブプロセスを点線で記述するだけでイベントサブプロセスであることを表します。タスクとサブプロセスに付加情報を加えるループアクティビティ(アクティビティに繰り返し矢印を追加):作業や処理を繰り返し実行することを表しますマルチインスタンス並列アクティビティ(アクティビティに縦三本線を追加):マルチインスタンスとは複数に分けて実行することです。並列とは同時に実行することです。1件の購入依頼に対して、複数の人で手分けをして発注する様子を表したりしますマルチインスタンスシーケンシャルアクティビティ(アクティビティに横三本線を追加):シーケンシャルとは逐次に実行することです。ループアクティビティと似ていますが、違いは下図の通りです。最初に何回繰り返すかが決まっているか、繰り返す度にさらに繰り返すかを決めるのかという違いです補償アクティビティ(アクティビティに巻き戻し記号を追加):トランザクションサブプロセスの中で使われることが多いアクティビティです。補償とはキャンセルが発生した時に実行前の状態に戻すことです。予約トランザクションサブプロセスにおける補償アクティビティは「予約を取り消す」という作業になりますコールアクティビティ(アクティビティを太線):コールとは共通部品を呼び出すことです。アクティビティを太線にすると、そのアクティビティの振る舞いは別のところで共通的に定義されていることを表しますなお、ここで説明した5つの付加情報は複数組み合わせることもできます。下図は、タスクに3つの付加情報(ループアクティビティ、補償アクティビティ、コールアクティビティ)を追加したものです。お勧めセットへの図形追加を考える追加の候補として、まずは「記述適合サブクラス」である以下の3つが挙げられます。ユーザタスクサービスタスクコールアクティビティタスクのタイプについては、ITシステムの処理の違いを意識して7つのタイプを描き分ける必要性はないと思います。そのような描き分けはBPMSで動かすフローを描くときまで不要だと思います。人の作業か、ITシステムの処理かをユーザタスクとサービスタスクで描き分けるので十分だと思います。筆者はユーザタスクも、サービスタスクもあまり使いません。ITシステムのレーンを追加してレーンで描き分けることを好むからです。この点については「(11)スイムレーン」の回で、もう少し掘り下げて説明します。サブプロセスのタイプについては、経験上、業務フローを描くのにトランザクションサブプロセスとイベントサブプロセスを使いたいと考えた人には巡り合えていません。企画や設計業務のように作業の順序をあらかじめ決めにくいときに、アドホックサブプロセスが使いたくなることはあります。多くの業務では使わなくても描けてしまうと思います。アクティビティの付加情報については、コールアクティビティとループアクティビティが追加を考えてみて良いと思います。業務の標準化について考える場合など、共通的な振る舞いを強調したい場合があります。そのような場合にはコールアクティビティが役に立ちます。同じことを繰り返し実行する作業は時間がかかる場合が多く、RPA導入などによる改善効果が期待できます。そのような作業をループアクティビティでマーキングすることが意味を持つ場合があります。マルチインスタンスを使った業務フローを描くと、そのフローを使った説明についてこれない人が多いと思います。bpmn-kobo.com。