エンジニアがシステム開発で使用するUML（統一モデリング言語）はさまざまですが、すべてに共通して言えることは「論理的かつ視覚的に表現されている」ということです。
UMLやアクティビティ図、フローチャートなど、エンジニア初心者の方は専門用語の多さに戸惑うことも多いです。
この記事を読んで、アクティビティ図について理解を深めましょう。
目次
アクティビティ図とは？
アクティビティ図とはUML（統一モデリング言語）の一種で「システム実行の流れと条件分岐」を図解したものです。具体的には、ある作業の開始から終了までの機能を、実行される順序どおりに記述します。
システムの流れを記述するのがUMLですが、アクティビティ図では「実体の制御の流れ」について描写しています。実体の制御とは「どのような行動（アクティビティ）が発生するか」を指します。よってアクティビティ図はほかのUML図に比べ「どのような行動が発生するのか」を視覚的に理解しやすいです。
システム開発の目的は「クライアントの業務効率化」が多いので、アクティビティ図を作成しておけば、システム開発メンバーがクライアントの仕事内容を理解しやすくなります。その結果、クライアントが求めていた機能を備えたシステムを正確に実装することができます。
アクティビティ図のメリット
アクティビティ図を使用するメリットは「処理手順に無駄がないか」を視覚的に俯瞰して判断できる点です。処理手順をロジカルに表現するので、複雑なシステムでも「論理的にムダのない構造になっているか」をチェックしやすいです。
アクティビティ図はシステムだけでなく、作業員の行動の最適化にも活用可能です。作業する「内容」を書くので、実行する主体がシステムでも人間でも関係ありません。製造業でも、作業手順書の改善などで活用可能です。
人間のしていた作業をシステムに置き換える場合、どこまでシステムで代替可能か検討する場合にもアクティビティ図は使用されます。こうした特性上、アクティビティ図は「ITリテラシーの高くない人が見ても直感的に理解しやすい」という特徴を持ちます。
アクティビティ図の構成要素
アクティビティ図に限らず、UMLは記述のルールが明確に決まっています。記述ルールをシステム開発者の間で統一した結果、仕様書の汎用性や可読性を高めた歴史的背景があります。ルールを無視したアクティビティ図は、アクティビティ図と呼べません。
ここではアクティビティ図を描くときに使用される、基本的な5つの要素「アクション」「判断ノード」「制御フロー」「開始ノード」「終了ノード」について解説します。
「アクション」は名前のとおり、ユーザーまたはシステムが実行するタスクの内容を指します。
「判断ノード」はアクティビティ図内のフロー上における条件分岐する場所を指します。特徴は、ひとつの入力に対して複数の出力が発生するという点です。
「制御フロー」は手順間の流れのことです。たとえばECサイトのアクティビティ図を想像しましょう。「商品の注文情報が入る」→「出荷準備に入る」というアクティビティの間を矢印でつなぎます。この矢印が「制御フロー」です。制御フローは「コネクター」と呼ばれることもあります。
「開始ノード」「終了ノード」は名前のとおり、アクティビティの開始と終了段階を意味します。
アクティビティ図の記号
アクティビティ図の構成要素の次は、実際にアクティビティ図を描くときに使う記号（表示形式）について解説します。上記5要素はもちろん、ほかにも使用される記号（表示形式）についても紹介していきます。
- 開始ノード・・・黒点で表示します。アクティビティの開始を表します。
- 終了ノード・・・黒点を中心に丸で囲んで表示します。アクティビティの終了を表します。
- アクション・・・角の取れた長方形で表示します。記号内にアクション（制御）の内容を記入します。
- 判断ノード/マージノード・・・ひし形で表します。フローの分岐、もしくは複数フローの合流を表します。
- 最終制御・・・丸の中にバツ印で表示します。それまでのアクション（制御）で使用されたトークンをすべて破棄します。
- フォークノード・・・太い黒線で表示します。複数の非同期処理が実行される、もしくは終了することを意味します。
- データストア・・・長方形で表示します。データを保持する装置を意味します。
- オブジェクト・・・長方形で表示します。アクティビティ（制御）の対象となるオブジェクトを表します。
- パーティション・・・正方形を十字で四分割して表示します。アクティビティ（制御）がどの領域に属するかを表すための領域分けとして表示します。
- 例外・・・例外が発生して、アクティビティ（制御）が移行することを表します。
- 送信ノード・・・オブジェクトにシグナルを送信することを表します。
- 受信ノード・・・シグナル発生の待機を表します。
- 待機ノード・・・タイマー制御（N秒に1度など）を表します。
フローチャートとアクティビティ図の違いは？
採用する規格にもよりますが、一般的にフローチャートは並列処理の記述ができないことが多いです。もし記述ルールにこだわらないのであれば、フローチャートとアクティビティ図の違いはほぼないと言えるでしょう。
ただし、独自の記述ルールは保守性・可読性が低下するリスクがあります。ビジネスロジックを明瞭にする目的ならアクティビティ図、ソフトウエアの詳細設計ならフローチャートもしくはほかのUML図の利用をおすすめします。
注意点ですが、アクティビティ図は詳細なシステムの設計仕様書としては不向きです。ソフトウェアのロジックを詳細に示すのであればほかのUML図を利用すべきで、アクティビティ図は参考資料として添付するのが無難です。
アクティビティ図の作り方
アクティビティ図の構成要素や表記法の次は、実際のシステム開発プロジェクトをイメージして「アクティビティ図を1から作成するためにはどうするべきか」を解説します。
アクティビティ図の例
最初に、どのような場面でアクティビティ図を使うべきか確認しましょう。
アクティビティ図は「システムの処理内容の流れ」をグラフィカルに表現する手法です。システム開発ではクライアントの業務を理解するのに役立ちます。またクライアント側としても、システムがどのような機能を実装するのか、直感的に理解しやすいです。
大規模なシステム開発になるほど事前の認識の共有が重要になります。アクティビティ図は処理手順をシンプルに表記できるので、開発初期の要件定義フェーズでは特に重要な資料となります。
ただしアクティビティ図のみでは、システムの仕様設計書としては不十分です。アクティビティ図をもとに、ほかのUML図を用いて詳細な仕様設計書を作成することをおすすめします。
アクティビティ図の書き方
「工場の出荷管理システム」の新規開発プロジェクトをイメージして、実際にアクティビティ図の作成手順を確認してみましょう。
作業内容はシンプルで、「登場人物の把握」「アクティビティの把握」「レーンを分けて流れを描く」のみです。
登場人物を洗い出す
まずは登場するユーザーとシステムを洗い出しましょう。ここではシンプルに、登場人物は「出荷担当者」「出荷管理システム」のふたつのみにしましょう。
登場人物、と表現しましたが正確には「オブジェクトの洗い出し」です。人間のみならず、関係するシステムも最初に把握しておきましょう。
人物ごとの行動（アクティビティ）を洗い出す
作業に関係するオブジェクトを洗い出せたら、次はオブジェクトごとの行動（アクティビティ）を洗い出しましょう。
出荷担当者であれば「商品の在庫を確認する」「商品の出荷準備をする」「商品の在庫量は適切か確認する」、出荷管理システムは「新規の出荷依頼がとどいたことを表示する」「出荷準備がすべて完了しているか表示する」「在庫数の水準は適切か表示する」などが挙げられます。
レーンを書く
登場人物と発生するアクティビティをすべて把握したら、ここからアクティビティ図を作っていきましょう。手書きのアクティビティ図で解説すると、A4用紙の真ん中をレーン（線）で区切り、左右に分けます。
左側を「出荷担当者」、右側を「出荷管理システム」にしましょう。A4用紙の上部に登場人物名を記入すると、新規のアクティビティ図を作成する準備が整いました。
各アクティビティの流れを描く
ここからは、洗い出したアクティビティをもとに、矢印を用いて作業の流れを表しましょう。
出荷管理システムのフローを挙げると、「出荷情報の表示」「在庫の確認」「出荷準備」「出荷が完了しているか表示」「在庫数の水準が適切か表示」「在庫数の確認」です。
このフローをレーンをまたいで上から下に記述することで、作業の流れについて理解することができます。
アクティビティ図を確認する
最後に一番重要なポイントですが、作成したアクティビティ図が最適なものかチェックしましょう。
出荷管理システムの例を挙げると、在庫以上の注文が発生したときにどう処理するか、そもそも在庫数の表示を出荷管理システムで実装すべきか、などが考えられます。
アクティビティ図は作成してからが本番です。ロジックに抜け漏れがないか、無駄な手順が含まれていないか確認しましょう。
アクティビティ図の活用方法
最後にアクティビティ図を活用するシーンと、作成の手間を削減する便利ツールについて紹介します。
かいつまんで説明すると、アクティビティ図はクライアントとのヒアリングおよびシステムの仕様説明といったシーンで利用されることが多いです。また、ツール自体は手書きでもエクセルでもできますが、クオリティを確保するのであれば専用の有料ツールをおすすめしています。
プログラムの処理方法を可視化
クラス図やシーケンス図など、システムの処理をロジカルに図示するUML図はほかにもあります。しかし、それらは詳細に記述できるあまり「分かりやすさ」という面では必ずしもベストとは言えません。
アクティビティ図は「システムの仕様」ではなく「そのシステムはどんな役割をするのか」を分かりやすく表現しています。よってクライアントへの説明・成果物にもとめる機能の認識共有、という面で優れた効果を発揮します。
ビジネスの業務フローを可視化
アクティビティ図はクライアントへの説明だけでなく、プロジェクトの開発メンバーに対する認識共有にも使えます。
というのも、プロジェクトメンバーはシステム開発のプロですが、クライアントの業界・業務について熟知しているわけではありません。
クライアントの求める機能とプロジェクトメンバーがイメージしている機能にズレが生じないよう、クライアントの仕事の流れを説明するのに役立ちます。
ツール導入でアクティビティ図をキレイに描こう
アクティビティ図を作成するだけならエクセルの機能でも十分ですし、極論ですが手書きでも十分記述できます。ただし、エクセルにしても手書きにしても「情報のリアルタイム共有」という面では弱いです。
専用ツール「Cacoo」を導入すると、クラウド上でデータを管理できるためリアルタイムの情報共有が可能です。また、権限付与機能にも対応しているので、誤ってメンバーがデータを改変してしまうリスクも少ないです。
専用ツールはテンプレートも豊富なので、UML図ビギナーが使用してもある程度以上のクオリティを維持できます。もちろん、ほかのUML図の作成にも対応しています。
UML図を使ったプロジェクト管理を真剣に考えているのであれば、Cacooはおすすめですよ。
アクティビティ図は必須なのか
アクティビティ図について理解はできたかと思います。ただ、ほかのUML図を学んだことがある人なら「ユースケース図など、ほかのUML図でも対応できるのではないか」と思うかもしれません。
アクティビティ図はシステム開発の仕様書よりも、「クライアントとシステムベンダー、お互いの仕事の理解を助けるツール」といった認識で使われることが多いです。
その意味では、クライアントがシステム部門の人などITリテラシーの高い方であれば無理にアクティビティ図を作成するメリットはないかもしれません。
アクティビティ図に限らず、UML図は用途に応じてさまざまな手法があります。興味がある人はぜひほかのUML図についてもチェックしてみましょう。
