UMLアクティビティ図の読み方・描き方｜分岐・並行処理・同期を業務フローで理解する

担当者から「申込み後に審査して、承認されたらアカウントを作る」と聞いても、通知は審査前後のどこで実行するのか、差戻しは誰が行うのか、失敗したときにやり直すのか、という疑問は残ります。文章だけでは処理順や並列関係が曖昧になりやすいため、処理の流れを合意する視覚的なモデルが役立ちます。

アクティビティ図は、画面遷移だけでなく、人による承認、バッチ処理、API呼び出し、通知、外部委託の作業まで、業務のまとまりをアクションとして表せます。

UML（Unified Modeling Language）はシステムの構造や振る舞いを表す標準的なモデリング言語です。その中のアクティビティ図は、アクション同士の制御・データの流れを表現します。とくに処理順、分岐、並行実行と待ち合わせに向いています。

判断・マージは同じひし形、フォーク・ジョインは同じ太い棒を使います。入力矢印と出力矢印の数、前後の文脈で働きを読み分けます。

例として、自社SaaSの法人申込みを考えます。申込みを受け付け、不備があれば差戻し、不備がなければ審査を承認します。承認後は契約登録と通知の準備を並行実行し、両方終えてから利用開始します。

この図ではアクションを技術処理だけに限定しません。現場が行う「審査を承認」も、システムが行う「契約を登録」も同じフロー上で扱えます。実際の要件定義では、失敗時の連絡先・期限・再試行方針を追加します。

判断（Decision）は1つの流れを条件で振り分けます。出力側の矢印に[審査OK]と[差戻し]のようなガード条件を記載します。条件が互いに排他的で、想定する入力を網羅しているか確認しましょう。

マージ（Merge）は分岐した経路がその後同じ処理を行う場合の合流です。一般に、フォークした並列作業がすべて終わるのを待つためのものではありません。ここを取り違えると、未完了の処理を残したまま次工程に進む図になります。

フォーク（Fork）は1本の制御を複数の並列経路へ分けます。ジョイン（Join）は並列経路の完了を同期して次へ進めます。例えば契約の記録と請求先の確認を同時に進めても、初回請求を確定するには両方の結果が必要です。

UMLアクティビティの意味を理解するときは、処理の実行可能性を伝えるトークンをイメージすると分かりやすくなります。初期ノードから制御トークンが流れ、アクションが実行されると次のノードへ進みます。フォークは複数の経路に制御を供給し、ジョインは必要な入力を待ち合わせます。

ジョインの具体的な可否はUMLの規則やジョイン仕様に従います。本記事とラボでは、標準的な「2つの作業が両方完了したら次へ進む」場面に絞って説明します。

スイムレーン（Activity Partition）を設けると、営業・審査担当・システム・経理のどこが実行する処理か整理できます。業務要件定義では、業務手順と責任の所在を同時に確認できる点が利点です。

レーンは責任の議論に役立ちますが、それだけで権限設計やRACIが完成するわけではありません。認可、承認履歴、例外時の責任まで別途定義します。

実務では正常系だけの図は十分ではありません。入力不備・審査否決・外部API停止・承認期限切れ・処理中の取消しなどを洗い出し、各例外がどこへ戻るか、誰に通知されるか、二重処理が起きないかを検討します。

例えば通知が失敗しても契約登録を取り消す必要がない業務なら、同期条件を見直すことがあります。反対に、必要書類が未完成のまま利用開始できない業務なら、完了確認を必須にします。図の形より先に、業務ルールを明確にすることが大切です。

初めに現場から開始条件・完了条件・登場人物・入力／出力を聞き取ります。次に正常系だけを描き、分岐条件や並行できる処理を足し、最後に例外と責任分担を確認します。業務担当には図を使って「この順番で困らないか」と聞き、開発担当には「実装可能な境界か」と確認します。

一般的なフローチャートは順序と分岐をシンプルに伝えられる一方、描き手によって並列処理の意味が曖昧になることがあります。UMLアクティビティ図は、並列処理・同期などの意味を共通記法で表現できるのが強みです。

BPMNは業務プロセス向けに、イベント、タスク、ゲートウェイ、メッセージフローなどを詳細に表現する記法です。業務プロセスを部門・組織間で標準的にモデル化したい場合はBPMN、ソフトウェア設計と整合した制御フローを描きたい場合はUMLアクティビティ図が使いやすいことがあります。どちらが常に優れているという関係ではありません。

レビュー時は、すべての分岐に条件があるか、並列化したタスクの終了待ちを表せているか、ループの脱出条件があるか、取消し・例外時の出口があるかを確認します。また「確認する」という一語だけで、何を検証し、誰が責任を負うか不明になっていないかも重要です。

図の矢印は、時間経過の長短やデータ整合性まで保証しません。必要なら待機時間、タイムアウト、ログ記録、権限などを補足文書に分けて定義します。

業務フローができたら、処理時間と待ち時間、外部API依存、ピーク時の同時申込み、データ保持期間、監査証跡などを洗い出せます。例えば契約登録と通知準備を並行化すると時間を短縮できる可能性がありますが、片方の失敗が後続に及ぼす影響も考える必要があります。

実装ではジョブキュー、非同期イベント、ワークフローエンジンなどを採用する場合があります。ただしアクティビティ図は要求される振る舞いを表すモデルであり、特定の実装技術を自動的に決めるものではありません。

まず承認経路で並列作業を片方しか終わらせない状態を試し、なぜ同期できないか確認してください。次に差戻し経路で、並列処理自体が実行されないことを確かめます。2つ目のラボでは、目的から適したUML図を判断します。

小規模SaaS企業でも、申込み審査・課金・解約・障害報告など、部門をまたぐ重要フローから描くのが実用的です。大規模な設計書を最初から作らず、問題が起きやすい1つの業務を題材に、担当者と30分程度で現状を確認し、次の改善案を合意する使い方から始められます。

変更後も図を放置せず、実装された処理・運用手順・テストケースと一致するように保守します。開発と業務の共通言語として機能させることが最も重要です。

アクティビティ図は、「何を、どの順番で、どの条件で、並行して行うか」を可視化します。判断とマージ、フォークとジョインを使い分け、業務フローの漏れや思い込みを発見できます。

クラス図は構造、状態マシン図は状態遷移、ユースケース図はユーザーから見た機能を中心に扱います。目的に合った図を選び、必要に応じて組み合わせることで、業務担当と開発担当の認識差を減らせます。