【設計シリーズ:16】ユースケース図～システムの振る舞いを可視化する最初のステップ～

概要

本稿は、システムが「誰に、何を提供するのか」を可視化するUML「ユースケース図」の包括的な解説レポートです。システムの利用者であるアクターと、機能であるユースケースという基本要素から説き起こし、<>や<>といったユースケース間の関係性を整理します。

具体的な「オンライン動画学習プラットフォーム」を題材に、Mermaid形式での作図手順をステップ・バイ・ステップで提示。開発現場での認識齟齬を防ぎ、円滑なコミュニケーションを促進するためのポイントと活用法を詳述します。

: 【設計シリーズ】システム開発でよく使う設計書 TOP20
システム開発の現場で必須となる設計書をTOP20ランキングでご紹介。開発の起点となる要件定義書から、品質保証のためのテスト仕様書、円滑な運用を支えるマニュアルまで。各ドキュメントの役割と重要性を簡潔に解説し、プロジェクト全体の流れを可視化します。エンジニアやPM必携の知識です。
続きを見る

はじめに

システム開発の羅針盤とも言える「設計」。この連載シリーズでは、システム設計の様々な側面に光を当て、その手法や考え方を解説しています。第16回となる今回は、要件定義の核心を担う「ユースケース図」を特集します。

ユースケース図は、これから開発するシステムが「誰に、どのような価値（機能）を提供するのか」を直感的に表現するための図です。複雑なシステムの全体像を、利用者（アクター）とシステムの機能（ユースケース）というシンプルな要素で描き出すことで、開発者、顧客、そしてエンドユーザー間の認識のズレを防ぎ、プロジェクトを円滑に導くための強力なコミュニケーションツールとなります。

この記事では、ユースケース図の基本的な概念から、具体的な書き方、そして実践的な活用シナリオまでを、豊富なサンプルと共に詳しく解説していきます。特に、作図ツールとして注目されているMermaid形式での記述方法に焦点を当て、すぐに使えるサンプルコードを多数提示します。この記事を読み終える頃には、あなたもユースケース図の本質を理解し、自信を持ってプロジェクトに活用できるようになるでしょう。

ユースケース図とは何か？～基本要素の理解～

ユースケース図は、UML（Unified Modeling Language）の一つであり、システムの機能的要求をモデル化するために用いられます。その構成要素は非常にシンプルで、主に以下の4つから成り立っています。

1. アクター (Actor)

アクターは、システムと相互作用を行う「外部の存在」を指します。人（ユーザー）に限らず、他のシステムやデバイスなどもアクターになり得ます。システムに対して何らかの操作を行い、その結果を受け取る役割を担います。

役割: システムの利用者や、システムと連携する外部エンティティを定義します。
表現: 一般的に、棒人間のアイコンで表現されます。
ポイント:
- 主アクター (Primary Actor): 特定の目的を達成するために、システムを能動的に利用するアクター。例えば、「商品を注文する顧客」などが該当します。
- 副アクター (Secondary Actor): 主アクターの目的達成を補助したり、システムから情報を受け取ったりするアクター。「在庫を管理する外部システム」や「注文を処理する従業員」などが考えられます。

Mermaidでは、アクターは以下のようにシンプルに記述できます。

graph LR
    User(ユーザー)

2. ユースケース (Use Case)

ユースケースは、「アクターがシステムを利用して達成できること」、つまりシステムの具体的な機能やサービスを表します。アクターの視点から見て意味のある、一連の処理のまとまりです。

役割: システムが提供すべき機能を明確にします。
表現: 楕円で表現されます。
命名規則: ユースケースの名前は、その機能が何であるかを明確に伝えることが重要です。「（目的語を）～する」という動詞句で命名するのが一般的です。（例：「商品を検索する」「アカウントを登録する」）

Mermaidでは、ユースケースは丸括弧 () で囲んで表現します。

graph LR
    UC(商品を検索する)

3. 関連 (Association)

関連は、アクターとユースケースを結ぶ実線のことです。どのアクターがどのユースケース（機能）を利用できるのか、その関係性を示します。

役割: アクターとシステムの機能との間のインタラクションを定義します。
表現: アクターとユースケースを結ぶ一本の線で表現されます。

Mermaidでは、矢印 --> を使ってアクターとユースケースを繋ぎます。

graph LR
    User(ユーザー) --> UC1(商品を検索する)

4. システム境界 (System Boundary)

システム境界は、開発対象となるシステムの「内側と外側」を明確に区別するための四角い枠です。この枠の中にユースケースを配置し、枠の外にアクターを配置します。

役割: システムのスコープ（範囲）を視覚的に定義します。
表現: 大きな四角形で、その中にユースケース群を配置します。

Mermaidでは、subgraph を使用してシステム境界を表現します。subgraphの名前はダブルクォーテーション "" で囲むのがポイントです。

graph LR
    subgraph "ECサイトシステム"
        UC1(商品を検索する)
        UC2(商品を注文する)
    end

    User(顧客) --> UC1
    User --> UC2

ユースケース間の関係～図をより豊かにする表現～

基本的な要素だけでもユースケース図は作成できますが、より複雑なシステムの振る舞いを効率的に表現するために、ユースケース間にはいくつかの特別な関係を定義することができます。ここでは代表的な「インクルード (Include)」「エクステンド (Extend)」「汎化 (Generalization)」の3つを紹介します。

1. インクルード (Include) 関係 <<include>>

インクルードは、「あるユースケースが、別の共通機能を持つユースケースを必ず利用する」という関係を示します。複数のユースケースに共通する処理（部品）を別のユースケースとして切り出し、再利用性を高めるために使われます。

コンセプト: 共通処理の部品化。
例: ECサイトにおいて、「商品をカートに入れる」「注文履歴を見る」「レビューを投稿する」といった多くの機能は、実行する前に「ログインする」という処理を必要とします。この「ログインする」を独立したユースケースとし、他のユースケースからインクルード関係で結びます。
表現: 利用する側のユースケースから、利用される共通機能のユースケースへ、<<include>> というステレオタイプを付けた破線の矢印を引きます。

Mermaidでは、関連のラベルとして |<<include>>| を記述します。

graph LR
    subgraph "ECサイトシステム"
        UC1(商品をカートに入れる)
        UC2(注文履歴を見る)
        UC_Login(ログインする)
    end

    User(顧客) --> UC1
    User --> UC2

    UC1 -->|include| UC_Login
    UC2 -->|include| UC_Login

この図は、「商品をカートに入れる」や「注文履歴を見る」を実行するには、必ず「ログインする」という処理が含まれることを示しています。

2. エクステンド (Extend) 関係 <<extend>>

エクステンドは、「あるユースケースの実行中に、特定の条件を満たした場合にのみ、別のオプション機能のユースケースが実行される」という関係を示します。基本となるフローからの分岐や、オプション機能を表すのに適しています。

コンセプト: オプション機能の追加。
例: 「商品を注文する」というユースケースの途中で、もし顧客が「クーポンコード」を持っていれば、「クーポンを適用する」というオプション機能が実行できます。この処理は必須ではないため、エクステンド関係となります。
表現: オプション機能のユースケースから、基本となるユースケースへ、<<extend>> というステレオタイプを付けた破線の矢印を引きます。（矢印の向きがIncludeとは逆になる点に注意してください）

Mermaidでは、関連のラベルとして |<<extend>>| を記述します。

graph LR
    subgraph "ECサイトシステム"
        UC1(商品を注文する)
        UC_Coupon(クーポンを適用する)
    end

    User(顧客) --> UC1
    UC1 -->|extend| UC_Coupon

この図は、「商品を注文する」という基本的な流れに対して、「クーポンを適用する」がオプションの機能であることを示しています。

3. 汎化 (Generalization)

汎化は、より抽象的な要素（親）と、より具体的な要素（子）の間の「is-a-kind-of（の一種である）」という関係を示します。これはアクター間、ユースケース間の両方で利用できます。

コンセプト: 継承関係。
例（アクターの汎化）: ECサイトに「一般会員」と「プレミアム会員」という2種類のアクターがいるとします。両者とも「商品を検索する」ことはできますが、「プレミアム会員」だけが「限定セールに参加する」ことができます。この場合、「会員」という抽象的なアクターを親とし、「一般会員」と「プレミアム会員」を子として汎化関係で表現できます。
表現: 具体的な要素（子）から抽象的な要素（親）へ、白抜きの三角矢印を引きます。

Mermaidでは、--|> という矢印で汎化関係を表現します。

graph LR
    subgraph "ECサイトシステム"
        UC1(商品を検索する)
        UC2(限定セールに参加する)
    end

    Member(会員)
    NormalMember(一般会員) --> Member
    PremiumMember(プレミアム会員) --> Member

    Member --> UC1
    PremiumMember --> UC2

この図により、「一般会員」と「プレミアム会員」は共に「会員」の一種であり、「会員」ができることは両者とも可能であることが分かります。その上で、「プレミアム会員」固有の機能があることも示されています。

【実践】オンライン動画学習プラットフォームのユースケース図を作成する

それでは、ここまでの知識を総動員して、具体的なシステムのユースケース図を作成してみましょう。題材として「オンライン動画学習プラットフォーム」を取り上げます。

Step 1: システムの概要とアクターの洗い出し

まず、どのようなシステムで、誰が利用するのかを定義します。

システム名: オンライン動画学習プラットフォーム
概要: ユーザーが様々なジャンルの動画講座をオンラインで学習できるプラットフォーム。受講生は講座を購入・視聴でき、講師は講座を作成・販売できる。
アクター:
- 受講生 (Student): システムの主な利用者。講座を探し、受講し、学習を進める。
- 講師 (Instructor): 自身の持つ知識やスキルを動画講座として作成し、プラットフォーム上で公開・販売する。
- 管理者 (Administrator): システム全体を管理する。ユーザーアカウントの管理や、公開される講座の承認などを行う。
- 決済システム (Payment Gateway): 外部の連携システム。有料講座の購入処理を担当する。

Step 2: アクターごとのユースケースの洗い出し

次に、各アクターがシステムに対して何を行いたいか、という観点でユースケースを洗い出します。

受講生 (Student):
- アカウントを登録する
- ログインする
- プロフィールを編集する
- 講座を検索する
- 講座詳細を閲覧する
- 講座を受講（購入）する
- 動画を視聴する
- 学習進捗を確認する
- 講師に質問する
- 講座にレビューを投稿する
講師 (Instructor):
- （アカウント登録、ログイン、プロフィール編集は受講生と共通）
- 講座を登録する
- 講義動画をアップロードする
- 受講生の質問に回答する
- 収益レポートを確認する
管理者 (Administrator):
- （ログインは共通）
- ユーザーを管理する
- 講座を承認／非承認にする
- 講座カテゴリを管理する

Step 3: ユースケース図の作成 (Mermaid形式)

洗い出したアクターとユースケースを元に、Mermaidで図を作成していきます。まずは主要な機能に絞ったシンプルな図から始め、徐々に関係性を追加して詳細化していきます。

【基本図：主要機能】

まず、受講生と講師の最も基本的なやり取りを図にしてみましょう。

graph LR
    direction LR

    subgraph "オンライン動画学習プラットフォーム"
        UC_SEARCH(講座を検索する)
        UC_TAKE(講座を受講する)
        UC_WATCH(動画を視聴する)
        UC_CREATE(講座を登録する)
        UC_UPLOAD(動画をアップロードする)
    end

    Student(受講生) --> UC_SEARCH
    Student --> UC_TAKE
    Student --> UC_WATCH

    Instructor(講師) --> UC_CREATE
    Instructor --> UC_UPLOAD

このシンプルな図だけでも、システムの根幹をなす機能と、それを利用するアクターが一目瞭然です。

【詳細図：共通機能と外部連携の追加】

次に、<<include>> 関係と外部システム連携を追加して、より現実に近い図にしてみます。多くの操作で「ログイン」が必要になること、そして講座の受講時には「決済システム」と連携することを表現します。

graph LR
    direction LR

    subgraph "オンライン動画学習プラットフォーム"
        UC_TAKE(講座を受講する)
        UC_WATCH(動画を視聴する)
        UC_QUESTION(講師に質問する)
        UC_CREATE(講座を登録する)
        UC_LOGIN(ログインする)
    end

    Student(受講生) --> UC_TAKE
    Student --> UC_WATCH
    Student --> UC_QUESTION

    Instructor(講師) --> UC_CREATE

    Payment(決済システム)

    UC_TAKE -->|include| UC_LOGIN
    UC_WATCH -->|include| UC_LOGIN
    UC_QUESTION -->|include| UC_LOGIN
    UC_CREATE -->|include| UC_LOGIN
    UC_TAKE --> Payment

「ログインする」というユースケースを共通部品として切り出すことで、図がスッキリし、システムの前提条件が明確になりました。また、外部アクターである「決済システム」を追加することで、システムの連携範囲も示せています。

【発展図：オプション機能と管理者機能の追加】

さらに、<<extend>> 関係と、管理者アクターを追加してみましょう。「講座を受講する」際に、オプションとして「クーポンを利用する」機能を追加します。また、管理者による「講座の承認」というワークフローも表現します。

graph LR
    direction LR

    subgraph "オンライン動画学習プラットフォーム"
        direction LR
        UC_TAKE(講座を受講する)
        UC_CREATE(講座を登録する)
        UC_APPROVE(講座を承認する)
        UC_COUPON(クーポンを利用する)
    end

    Student(受講生) --> UC_TAKE
    Instructor(講師) --> UC_CREATE
    Admin(管理者) --> UC_APPROVE

    UC_TAKE -->|extend| UC_COUPON
    UC_APPROVE --> UC_CREATE

この図では、「クーポン利用」が必須ではないオプション機能であることが <<extend>> によって示されています。また、「講座の登録」と「講座の承認」が関連していることも分かり、講師と管理者の間にある一連の業務フローが垣間見えます。（厳密なフローはシーケンス図などで表現しますが、ユースケース図でも関連性を示すことはできます）

このように、シンプルな基本図から始め、<<include>> や <<extend>>、他のアクターなどを段階的に追加していくことで、複雑なシステムも分かりやすくモデル化していくことが可能です。

ユースケース図を作成・活用する際のポイント

ユースケース図は強力なツールですが、その効果を最大限に引き出すためには、いくつかのポイントを意識する必要があります。

1. 粒度を適切に保つ

ユースケースの粒度（大きさ）がバラバラだと、図が非常に分かりにくくなります。「ログインする」と「システムを利用する」では、抽象度が全く異なります。同じレベルのタスクでまとめるように意識しましょう。例えば、「ユーザー情報を変更する」というユースケースがあるなら、「名前を変更する」「メールアドレスを変更する」「パスワードを変更する」といった細かすぎるユースケースを並べるのではなく、それらは「ユーザー情報を変更する」というユースケースの詳細シナリオとして、別途「ユースケース記述」で定義するのが一般的です。

2. 命名規則を守る

前述の通り、ユースケースは「（目的語を）～する」という命名規則で統一しましょう。これにより、図を見るだけでアクターがシステムで何を行えるのかが直感的に理解できます。「ユーザー管理」のような名詞ではなく、「ユーザーを管理する」という動詞句で記述することが重要です。

3. 「完璧」を目指しすぎない

ユースケース図は、プロジェクトの初期段階で関係者間の認識を合わせるためのコミュニケーションツールです。最初から完璧な図を描こうとする必要はありません。まずは主要な機能を洗い出して描き、チームや顧客とレビューを重ねながら、徐々に詳細化し、育てていくというアプローチが有効です。

4. ユースケース記述（Use Case Description）とセットで考える

ユースケース図はシステムの機能一覧を鳥瞰図のように示すものですが、個々の機能が具体的にどのような手順で実行されるのか（正常系シナリオ）、エラー時はどうなるのか（異常系シナリオ）といった詳細までは表現できません。これらの詳細は、「ユースケース記述」と呼ばれるテキストベースのドキュメントで補完します。

ユースケース記述の例（「ログインする」）

ユースケース名: ログインする
アクター: 会員
事前条件: 会員登録が完了していること。
事後条件: ユーザーが認証され、システムへのアクセスが許可される。
基本フロー（正常系）:
1. ユーザーはメールアドレスとパスワードを入力し、ログインボタンをクリックする。
2. システムは入力された情報を検証する。
3. 検証が成功した場合、システムはユーザーのダッシュボードページを表示する。
代替フロー（異常系）:
- 3a. メールアドレスまたはパスワードが不正な場合、システムはエラーメッセージを表示し、再入力を促す。

このように、図とテキスト（記述）をセットで用いることで、システムの振る舞いを網羅的に定義することができます。

まとめ～コミュニケーションを駆動する設計図～

今回は、「設計シリーズ」の第16回として、ユースケース図の世界を深く探求しました。

ユースケース図は、単なるお絵描きではありません。それは、システムの目的と価値を最もシンプルな形で描き出す、プロジェクトの礎となる設計図です。アクターという「誰が」と、ユースケースという「何をできる」を明確にすることで、要件定義の曖昧さを排除し、開発チームとステークホルダーが同じゴールを目指すための共通言語となります。

今回紹介したMermaidを使えば、テキストベースでバージョン管理も容易なユースケース図を誰でも手軽に作成できます。

アクターとユースケースという基本要素から始める。
システム境界でスコープを明確にする。
includeで共通機能を、extendでオプション機能を整理する。
必要に応じて汎化でアクターやユースケースの関係を構造化する。
ユースケース記述と連携させ、詳細なシナリオを補完する。

このステップを意識することで、あなたのプロジェクトはより見通しが良く、スムーズに進行するはずです。

ユースケース図でシステムの「外側からの振る舞い」を定義した次は、その内部でオブジェクトがどのように連携して機能を実現するのかを示す「シーケンス図」や「クラス図」へと設計は進んでいきます。ユースケース図は、まさにその第一歩となる重要な成果物なのです。

ぜひ、次のプロジェクトではユースケース図を積極的に活用し、チーム全体のコミュニケーションを活性化させ、成功へと導いてください。

: 【設計シリーズ】システム開発でよく使う設計書 TOP20
システム開発の現場で必須となる設計書をTOP20ランキングでご紹介。開発の起点となる要件定義書から、品質保証のためのテスト仕様書、円滑な運用を支えるマニュアルまで。各ドキュメントの役割と重要性を簡潔に解説し、プロジェクト全体の流れを可視化します。エンジニアやPM必携の知識です。
続きを見る

【設計シリーズ:16】 ユースケース図 ～システムの振る舞いを可視化する最初のステップ～

【設計シリーズ】システム開発でよく使う設計書 TOP20