業務フローリファクタリングの具体的な実現法：特集：業務フローリファクタリング（後編）（3/3 ページ）

[今田忠博, 菅野裕，＠IT]

キャンセルアクティビティ（Cancel Activity）パターン

　別のフローからの送信されたキャンセルのイベントを受信し、実行中のタスクを中断します。

　イベントを受け取ると、トークンは通常フローではなく、例外フローに流れます。例外フローでは、キャンセルによって生じた補償処理などを行います。キャンセルアクティビティパターンは、長時間実行中のタスクや、中断されているタスクを取りやめる場合に使います。

　キャンセルの対象がタスクではなく、ほかのアクティビティを含んだサブプロセスの場合、キャンセルケース（Cancel Case）パターンを使います。

別名：キャンセルタスク（cancel task）、アクティビティの破棄（kill activity）、アクティビティの取り消し（withdraw activity）

ビジネスプロセス図

図16 キャンセルアクティビティパターン（BPMN図）

　BPMNでは、キャンセルアクティビティパターンは中間イベントを使って図16のように表現できます。

　Bは長時間実行されるタスクです。Aが完了するとBが実行されますが、並列でユーザーやシステムからのキャンセルイベントを待っています。Bの実行中にキャンセルメッセージが届くと、Bは直ちに実行を中断して、トークンを例外フローであるCに流します。キャンセルされることなくBが完了した場合、トークンはCには流れません。Bがまだ実行されていない場合や、すでに完了している場合には、キャンセルメッセージが届いても例外フローには流れません。

　同じことを、図17のようにUMLのステートマシン図でもあらわすことができます。Bの状態にある場合のみ、キャンセルイベントを受け、キャンセル状態に移ることができます。

図17 キャンセルアクティビティパターン（ステートマシン図）

実例：

　出前や宅配業務における、注文のフローを例にとります。

図18 キャンセルアクティビティパターン例『料理の宅配』　（クリックで拡大）

　顧客から注文を受けると、注文を受けた料理の調理を開始します。調理が完了すれば、料理を顧客のもとへ配送し、フローは完了します。

　この業者では、まだ調理中で配送されていない注文については、注文のキャンセルに応じています。料理の調理中に顧客から注文のキャンセルがあった場合は、直ちに調理を中断し、注文をキャンセルする処理を行います。

　ステートマシン図で表現すると、図19のようになります。調理中のときのみ、キャンセル中への遷移が許されています。

図19 キャンセルアクティビティパターン例『ステートマシン図』

注意点：　キャンセルアクティビティパターンは、イベントを受けて例外フローに処理を流すものです。タスクやサブプロセス内で起こったエラーによるタスク個別の補償処理は、別の仕組みを使うべきです。

コラム：タスク個別の補償処理

　BPMN図では、タスク個別の補償は、補償中間イベントを使って次のように表現できます。

図20 BPMNによる補償

　「商品を手配する」に失敗した場合、課金した分は払い戻す必要があります。補償アクティビティである「払い戻す」は、後続のタスクを持ちません。「商品を手配する」に失敗すると、親プロセスの例外フローへトークンが流れますが、その前に補償アクティビティが実行されます。

関連するパターン：

・キャンセルケース（Cancel Case）

キャンセルの対象となるタスクがサブプロセスの場合、キャンセルケースパターンを使います。

パターン利用でコミュニケーションを促進する

　業務を大きな視点でとらえると、特定のサービスを生み出すシステムとして考えることができます。システムであれば、入出力や振る舞いが決まっていて、ソフトウェアのように振る舞いを変えない範囲でリファクタリングすることができるはずです。

　この記事では、「将来像の業務フローを描いた段階で精査することで、システム化の前に業務の流れ自体を整理し、リソースの競合や非効率な作業を見直す」ということを目的に、ワークフローパターンを使った業務フローのリファクタリングを紹介しました。

　業務フローのリファクタリングにワークフローパターンを利用することで、図をシンプルにすることができます。また、パターンには注意点や関連するパターンが定義されているため、パターンの名前を利用することで関係者のコミュニケーションが促進されます。「この業務は○○パターンで表せるよね」とか「○○パターンの場合は、△△パターンについても検討が必要そうだね」といった具合です。

　現実には「既存の業務フローの表現自体がまったくおかしい」ということもあり得ます。そういった場合には、そもそも業務フローを書く段階で理解しておくべき点や、注意すべき点を押さえておく必要があります。

　これらについては、また別の機会に紹介したいと思います。現時点では要求開発アライアンスの牛尾剛氏が「モデリング・リファクタリングのススメ」として業務フローに現れる不吉なにおいを独自にカタログ化した記事が面白く、参考になると思います。

筆者プロフィール

今田 忠博（いまだ ただひろ）

株式会社豆蔵 BS事業部。SIの現場でSE、PMなどを経験。SI現場で悲惨な体験をし、開発現場を効率的にしたいと2004年に豆蔵に移籍。SIプロジェクトのアーキテクトやフレームワークの設計・実装、PM支援、要件定義コンサルタントなどの業務を経験。そもそも要求が間違っていると、そのあといくらがんばっても幸せになれないと理解する。現在、要求から設計、実装をつなぐ方法を模索中。著書に『Trac入門』（共著／技術評論社）、記事に『5分で絶対に分かるプロジェクト管理』（＠IT）などがある。

菅野 裕（すがの ゆたか）

株式会社豆蔵 BS事業部。SIベンダにて業務システムの設計・構築に携わった後、2004年より現職。システム開発の現場でアーキテクチャの構築や新技術導入の支援、エンジニアの育成などに従事している。著書に『Trac入門』（共著／技術評論社）、『Rubyによるデザイン・パターン』（共訳／ピアソン・エデュケーション）がある。

「特集：業務フローリファクタリング」バックナンバー

• 業務フローリファクタリングの具体的な実現法