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