📐

実践的なユースケース図の書き方

2025/10/20に公開

 はじめにユースケース図は、「誰が」「何をしたいのか」をシンプルに表現するためのUML図です。

しかし、実務では「内部処理を書いてしまう」「冗長に分解しすぎる」といった誤用が多く見られます。
この記事では、ECサイトを題材に、実践的でわかりやすいユースケース図の描き方を紹介します。

 基本ルールアクター：システム外部の利用者や他システム
ユースケース：アクターの目的（＝何をしたいか）
関係：アクターとユースケースを線で結ぶ

include / extend ：内包処理や拡張処理を表現する
《ポイント》

アクターの目的ベース で書く
UI操作や内部処理は書かない

 ECサイトの例
 メインユースケース顧客が商品を検索する
顧客が商品を購入する
顧客が注文履歴を確認する
管理者が商品情報を管理する
@startuml
left to right direction

actor 顧客 as Customer
actor 管理者 as Admin

rectangle "ECサイト" {
  usecase "商品を検索する" as UC_Search
  usecase "商品を購入する" as UC_Purchase
  usecase "注文履歴を確認する" as UC_OrderHistory
  usecase "商品情報を管理する" as UC_ProductAdmin
}

Customer --- UC_Search
Customer --- UC_Purchase
Customer --- UC_OrderHistory
Admin --- UC_ProductAdmin
@enduml

 サブユースケースの分解メインユースケース内に表現すべきサブユースケースが含まれている場合、include / extend を用いて可視化させます。
「顧客が商品を購入する」を、概念レベルで分解します。
商品をカートに追加する
配送先を指定する
支払い方法を選択する
注文を確定する
@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "商品を購入する" as UC_Purchase
  usecase "商品をカートに追加する" as UC_AddToCart
  usecase "配送先を指定する" as UC_SpecifyAddress
  usecase "支払い方法を選択する" as UC_SelectPayment
  usecase "注文を確定する" as UC_ConfirmOrder
}

UC_Purchase ..> UC_AddToCart : <<include>>
UC_Purchase ..> UC_SpecifyAddress : <<include>>
UC_Purchase ..> UC_SelectPayment : <<include>>
UC_Purchase ..> UC_ConfirmOrder : <<include>>

Customer --- UC_Purchase
@enduml

 内包処理の表現（include）メインユースケースで必ず実行されるサブユースケースは、include で表現します。
@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "商品を購入する" as UC_Purchase
  usecase "注文履歴を確認する" as UC_OrderHistory
  usecase "顧客を認証する" as UC_Authenticate
}

Customer --- UC_Purchase
Customer --- UC_OrderHistory

UC_Purchase ..> UC_Authenticate : <<include>>
UC_OrderHistory ..> UC_Authenticate : <<include>>
@enduml

 拡張処理の表現（extend）条件によって実行されるサブユースケースは、 extend で表現します。
@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "商品を購入する" as UC_Purchase
  usecase "ギフト包装を選ぶ" as UC_GiftWrap
  usecase "クーポンを適用する" as UC_ApplyCoupon
}

Customer -- UC_Purchase

UC_Purchase <.. UC_GiftWrap: <<extend>>\n条件：ギフト選択
UC_Purchase <.. UC_ApplyCoupon: <<extend>>\n条件：クーポン入力
@enduml

 よくあるNG例と改善例
 NG例1：UI操作を書いてしまう@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "ログイン画面を開く" as UC_OpenLogin
  usecase "検索ボタンを押す" as UC_ClickSearch
}

Customer --- UC_OpenLogin
Customer --- UC_ClickSearch
@enduml

 どこがNG?これは操作手順であって、目的ではありません。

 改善例@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "顧客を認証する" as UC_Authenticate
  usecase "商品を検索する" as UC_Search
}

Customer --- UC_Authenticate
Customer --- UC_Search
@enduml

 NG例2：内部処理を書いてしまう@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "注文情報をDBに保存する" as UC_StoreOrder
  usecase "在庫テーブルを更新する" as UC_UpdateStock
}

Customer --- UC_StoreOrder
Customer --- UC_UpdateStock
@enduml

 どこがNG?ユースケース図では、内部処理は意識しない方が良いです。

 改善例「注文を確定する」と言った、目的ベースで表現します。
注文確定時に在庫が更新される旨は、ユースケース記述（ユースケースの付加情報）として書くのが良いでしょう。
@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "注文を確定する" as UC_FixOrder
}

note right of UC_FixOrder: 注文確定時、在庫情報が更新される

Customer --- UC_FixOrder
@enduml

 NG例3：冗長に分解しすぎる@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "商品を購入する" as UC_Purchase
  usecase "商品を入力する" as UC_InputProduct
  usecase "商品を保存する" as UC_StoreProduct
  usecase "商品を更新する" as UC_UpdateProduct
}

Customer --- UC_Purchase

UC_Purchase ..> UC_InputProduct : <<include>>
UC_Purchase ..> UC_StoreProduct : <<include>>
UC_Purchase ..> UC_UpdateProduct : <<include>>
@enduml

 どこがNG?「商品を購入する」に含意される行為を細かく分けすぎると、冗長になります。

サブユースケースは、「カートに追加する」「配送先を指定する」程度に留めるのが適切です。

 改善例@startuml
left to right direction

actor 顧客 as Customer

rectangle "ECサイト" {
  usecase "商品を購入する" as UC_Purchase
  usecase "カートに追加する" as UC_AddCart
  usecase "配送先を指定する" as UC_SelectShippingAddress
}

Customer --- UC_Purchase

UC_Purchase ..> UC_AddCart : <<include>>
UC_Purchase ..> UC_SelectShippingAddress : <<include>>
@enduml

 まとめユースケース名は「アクターが○○○を□□□する」の形式で書く
○○○が概念モデル（静的モデル）、□□□がビジネスロジック（動的モデル）になることを意識する

UI操作や内部処理は書かない
サブユースケースは冗長にせず、概念的な責務に分解する
共通処理は include 、条件付き処理は extend で表現する

 おわりにユースケース図は、「システムがどう動くか」ではなく「利用者が何をしたいか」を表現するものです。
ぜひ、日々の設計やレビューで「これはアクターの目的を表しているか？」という視点を意識してみてください。