UML言語で記述される図の一つであるユースケース図について、4つの作成ステップをご紹介します。ここでは「オンライン注文システム」のユースケース図を書きます。
なお、UMLについての丁寧な定義は以下の通りです。システム開発においてあると便利な図の描き方を、とある団体がルールブックとしてまとめてくれている（標準化している）もの、と理解下さい。
統一モデリング言語（とういつモデリングげんご、英: Unified Modeling Language, UML）は、ソフトウェア工学で用いられる、汎用的かつ開発方面に特化させたモデリング言語である。システム設計を視覚的に図式化しての標準化されたモデリング手法の提供を目的にしている。UMLの略語で呼ばれることが多い。オブジェクト指向分野でよく用いられている。（引用元：Wikipedia）
※本記事では、ルールブック通りに100点の図を描くのではなく、システム開発に携わるメンバーで認識合わせするためのたたき台になるような、70点の図を素早く描くことを意図しています。
1. 登場させたいアクターを決める
前提なのですが、1つのユースケース図にすべてを盛り込むことは（小規模なシステムでない限りは）かなり難しいと考えています。ですので、今から描くユースケース図で触れたい内容を”アクター”から考え決定すること、を最初のステップとしています。
例えば、オンライン注文システムはどんなシステムなのか、文章で表現してみました。以下のトグルを開いて見て頂くと分かる通り、一見すると幅広い”アクター”がユースケース図に登場する対象となり得そうです。
ユースケース（文章での表現）
顧客はフェイスブック広告からウェブサイトにアクセスし、広告で見た商品ページに飛びます。サイト内にしばらく滞在し、他の商品も閲覧して欲しい商品を見つけたら、数量を選択してカートに追加します。必要な商品をすべて選んだ後、カートの内容を確認し、配送先情報と支払い方法を入力します。注文内容を最終確認し、注文を確定します。
システムは注文を処理し、在庫を確認します。支払いが完了すると、注文確認メールが顧客に送信されます。店舗側は新しい注文を受け取り、商品を準備して発送します。顧客は注文状況を追跡でき、必要に応じてカスタマーサポートに問い合わせることができます。発送が完了するまでの間であれば注文のキャンセルも可能です。
一方で、今から描くユースケース図はどのステークホルダーに向けたものなのでしょうか？マーケティング部、物流・在庫管理部、カスタマーサポート部、IT・システム部、外部ベンダー、などの様々なステークホルダーが存在する中で、特にこの図を参照する必要がある人は誰でしょうか？
今回は、「物流・在庫管理部」と「カスタマーサポート部」を巻き込み、意思決定をするための図とします。結果的にアクターは以下の3つを選びました。
- 顧客
- カスタマーサポート担当
- 発送担当
とてもシンプルになりましたよね。このように見る人の顔を思い浮かべて”アクター”の取捨選択をすることは、ユースケース図が複雑化しすぎることを防ぎ、労力を最小限にユースケース図をアウトプットすることができるテクニックの1つです。
2. 表現したいユースケースを洗い出す
アクターが決まったら、楕円形のオブジェクトにユースケースを洗い出します。空のオブジェクトを用意して一気にテンポよくユースケースを書いていくと、粒度感が整うのでおすすめです。「こんな細かいことまでユースケースに挙げるべき？」と迷ったときは、ぜひ前後のユースケースと見比べてみてください。
今作っているユースケースがたたき台なのであれば、追加するかどうか迷ったユースケースはあえて追加せず「メモっておく」のも一つの方法です。
3. アクターに合わせて配置する
洗い出したユースケースを関連するアクターに合わせてまとめ、図の中で配置します。この途中でユースケースの漏れに気づいたら、遠慮なく追加頂いて構いません。つまり、2. と3. は行ったりきたりしながらぜひ柔軟にブレストを進めて下さい。
4. 線でつなげる
最後にアクターとユースケースを線で繋げて完成です。ここまでで70点ぐらいの図ができあがりました。（お疲れさまでした！）ここから先は、業務整理や要件定義、システム開発などの進行に合わせて都度図をアップデートしていきましょう。様々な人の目に触れることも完成度を高める重要な要素です。
+α 関係性を表現する
UMLで定義されるユースケース図の記載ルールには、以下のようなアクターとユースケース、およびユースケース同士の関係性を表現できるルールがあります。
- 関連（単純な実線）
- 包含（点線矢印で<<include>>）
- 拡張（点線矢印で<<exclude>>）
- 汎化（実線矢印）
この「包含」と「拡張」がとてもややこしいのでざっくり表現しますと、
- ユースケースAが実現されるときには”必ず”ユースケースBも実現されるよね（含まれているよね、機能の一部だよね）
- ユースケースCが実現されるとするなら、次にユースケースDも実現する可能性があるよね（Dもできると便利だよね）
という関係性を表現することができます。ただし、ユースケース図の活用用途に立ち返ると「このユースケースは（システムで）実現すべきか？」を明らかにし、ステークホルダー間で合意することが主な目的でした。ですのでこれらの関係性は、ユースケース図においてはあまり重要な要素ではないかなと思います。
まとめ
ユースケース図の4つの作成ステップをご紹介しました。ユースケース図は、誰が何をできるのか（どのアクターがどのユースケースを実行できるのか）、を俯瞰的に把握できる便利な図です。また、比較的”システム”っぽく無い、ビジネスフレンドリーな図でもあります。幅広いステークホルダーを上手に巻き込めるツールとしてぜひご活用下さい。
フクロウの図表ラボ 