ユースケース図とは？必要な場面、書き方を具体例とともに解説

業務システムやサービスの複雑化が進むなかで、システム開発の初期段階から要件を整理し、共有する重要性が高まっています。なかでも注目されているのが、利用者と機能の関係を視覚的に整理できる「ユースケース図」です。

本記事では、ユースケース図の基本概念や構成要素、作成手順、活用例までを体系的に解説します。

第三者検証の重要性｜資料ダウンロード

ユースケース図とは

まずは、ユースケース図の基本概念や役割、主な活用シーンについて解説します。

ユースケース図の基本概念と役割

ユースケース図は、ソフトウェアや業務システムにおける「機能」と、それに関与する外部の利用者やシステム（アクター）との関係を視覚的に整理する図です。システムが実際の業務フローや利用シーンの中でどのような振る舞いをするのかを把握するために活用されます。

例えば勤怠管理システムでは、「社員」「承認者」「管理者」といった関係者（アクター）と、「勤怠を入力する」「申請を承認する」といった具体的な行動（ユースケース）を整理します。

ユースケース図を作成することで、開発者・業務担当者・テスターといった関係者間で共通認識が生まれ、要件漏れや認識のズレを防ぎやすくなります。

UMLとの関係性

ユースケース図は、「UML（Unified Modeling Language）」という共通表記法に含まれる図の1つです。

UMLは、システムの構造や振る舞いを視覚的に表現するための標準的なモデリング言語として、幅広い開発現場で採用されています。

UMLにはクラス図・シーケンス図・アクティビティ図などさまざまな種類がありますが、なかでもユースケース図は構成が比較的シンプルで、システムの利用者と機能の関係を直感的に把握できるという特徴があります。そのため、初学者や非エンジニアでも理解しやすく、開発の初期段階で関係者間の認識をそろえる手段としてよく用いられます。

システム開発における活用シーン

ユースケース図はすべてのプロジェクトで必須となるわけではありませんが、次のような場面では特に有効です。

• 新規システム開発時の要件定義フェーズ
• 既存システムの機能整理・再設計
• 外部委託や複数チーム間での設計共有
• テスト計画時におけるユースケースベースのテスト設計

特にまだ製品の全体像が見えていない新規プロジェクトでは「誰がどのようにシステムを利用するか」を文章だけで説明するのは難しい場合が少なくありません。

ユースケース図を使えば、利用者と機能の関係を視覚的に整理でき、設計時の前提や想定について関係者間で認識をそろえることができます。

また、後工程のテスト設計においても、ユースケース図をもとに業務フローに沿ったシナリオを立てることで、実運用に即したテストケースを網羅的に作成しやすくなります。

ユースケース図の主な構成要素

ユースケース図は、主に「アクター」「ユースケース」「システム境界」「関係」の4つの要素で構成されます。これらの要素を正しく整理することで、図の意図が明確になり、要件定義や設計工程における精度向上につながります。

アクター

アクターとは、システムと外部から相互作用するユーザーや外部システムのことを指します。

例として、勤怠管理システムでは「社員」や「管理者」といった利用者がアクターとなります。また、給与計算システムなど、外部システムが、アクターに該当するケースもあります。

アクターを正確に洗い出すことは、ユースケースの漏れを防ぎ、システムが果たすべき役割を明確にするうえで重要です。

ユースケース

ユースケースとは、システムが提供する個別の機能や操作を指します。

例えば勤怠管理システムにおいては「勤怠入力」「休暇申請」「承認処理」などがそれにあたります。

ユースケースは、原則として楕円形の記号で表現され、アクターとの関係を線でつなげられます。どのアクターがどの機能を利用するのかを整理することで、システムの全体像を視覚的に把握しやすくなります。

システム境界

システム境界は、ユースケース図の中でシステムの範囲を示すための枠線を指します。アクターは枠の外側に、ユースケースは枠の内側に配置されることで、「どの機能がシステム内部で提供されているか」が明確になります。

特に複数システムが関与するプロジェクトでは、システム境界を明示しておくことで責任範囲の混乱を防ぎ、設計段階での認識ズレを回避しやすくなります。

関係

関係（リレーションシップ）は、アクターとユースケース、あるいはユースケース同士のつながりを表します。主に次の3種類の関係がよく使われます。

• 関連（Association）
  アクターとユースケースの基本的な関係を表す
  例：「社員」が「勤怠を入力する」操作を行う場面
  
  
• 包含（Include）
  共通する処理を独立したユースケースとして切り出し、他のユースケースに組み込む関係
  例：「勤怠入力処理」ユースケースに含まれる「バリデーション」（入力内容のチェック）
  
  
• 拡張（Extend）
  特定の条件下で追加的に実行されるユースケースを示す
  例：「勤怠を入力する」ユースケースに対して、必要な場合だけ行われる「打刻忘れの補足入力」

これらの関係を適切に整理することで、図全体の構造を整理しやすくし、仕様の曖昧さを防ぐことができます。

ユースケース図の作成手順

ユースケース図は、次の5つの手順に沿って作成されます。それぞれの工程で抜け漏れを防ぎながら、図全体を整理していきましょう。

1. システムの利用者（アクター）を明確にする

はじめに、システムと関わる外部の利用者（アクター）を特定し、それぞれの役割を整理します。例えば、勤怠管理システムでは、次のようなアクターが想定されます。

アクター	役割内容
社員	勤怠を入力する
上長（承認者）	部下の勤怠を確認・承認する
管理者	勤怠データの修正や全体の管理を行う
給与計算システム（外部）	勤怠データを受け取る

このように、外部システムも含めてシステムと関係のあるアクターを抜け漏れなく整理していきます。

2. ユースケース（機能）を洗い出し、グループ化する

次に、システムの機能をユースケースとして整理します。業務フローや仕様書をもとに、主要な操作や処理を漏れなく洗い出していきます。

ユースケース名	内容
勤怠を入力する	社員が出勤・退勤などの勤務情報を登録する
休暇申請を行う	社員が休暇申請の登録をする
打刻修正を行う	社員が打刻した情報の修正登録をする
勤怠を承認する	上長が部下の勤怠情報を確認・承認する
勤怠データを出力する	管理者が勤怠データをCSV等で出力する
勤怠データを受け渡す	勤怠データを外部の給与計算システムへ送信

機能が多い場合は、関連する処理ごとにグループ化すると、図全体の見通しがよくなります。例えば、勤怠管理システムでは、「勤怠を入力する」「休暇を申請する」「打刻を修正する」「勤怠を承認する」などの処理は、すべて「申請機能」として1つのグループに整理できます。

3. アクターとユースケースを関連付け、全体像を整理する

ユースケースとアクターが明確になったら、両者を線で結び「どのアクターがどの機能に関係するのか」を図にします。複数のアクターが関係するユースケースには、該当するアクターすべてを結びつける必要がある点に注意します（例：「打刻修正申請の処理」ユースケースでは、社員が修正申請を行い、上長が承認または差し戻しを行う）。

4. 必要に応じて関係性（Include/Extend）を追加する

ユースケース同士に共通の処理や補助的な機能がある場合には、「Include」や「Extend」といった関係を設定します。

• Include：複数のユースケースで繰り返し使われる共通処理を切り出す
  
  
• Extend：任意または条件付きで発生する処理を分離して表現する

関係を明記することで、プロダクトがどのような機能を備えているかがわかりやすくなり、共通機能の再利用や修正がしやすくなります。

5. パッケージやノートを活用し、図の可読性を向上させる

ユースケースの数が多くなる場合や、補足説明が必要な場合には、「パッケージ」や「ノート」を活用します。

• パッケージ：関連するユースケースを論理的にグルーピングしたもの
  
  
• ノート：図内に記載する補足的な説明や条件

特に複数の業務領域やシステムを一図にまとめる場合には、こうした補助要素で情報を整理することが重要です。

ユースケース図の具体例

ユースケース図は、業種やシステムの規模を問わず幅広い場面で活用されています。

ここでは、比較的イメージしやすい「ECサイト」と「業務システム」の例を取り上げながら、それぞれのユースケース図がどのように構成されるかを解説します。

ECサイトのユースケース図の例

ECサイトでは、主にエンドユーザー（一般利用者）と管理者の2種類のアクターが登場します。ユーザー側は「商品を探す」「カートに入れる」「購入手続き」といった操作を行い、管理者側は「商品を登録・管理する」「注文情報を確認する」といった業務を担当します。

これらの操作や業務を整理すると、次のようなユースケース図にまとめることができます。

このように整理することで、ユーザー視点と管理者視点の両方から、システムが提供する機能の全体像を可視化できます。

業務システムにおけるユースケース図の例

業務システムでは、社内の複数部門が関与することが一般的です。そのため、ユースケース図を使って業務フローや役割分担を可視化しておくことが重要です。顧客管理システム（CRM）を例にとると、営業担当者やマネージャー、カスタマーサポートなどがアクターとなり、各機能への関与を図示できます。

このようにユースケース図を活用することで、部門ごとの役割や責任範囲が明確になり、システム設計やテスト設計の効率化につなげることができます。

ユースケース図を作成する際に意識したいポイント

ユースケース図を実務で効果的に活用するためには、いくつか意識しておきたいポイントがあります。

詳細すぎず、適切な粒度で作成する

ユースケースの粒度が細かすぎると、図が複雑になり、本来の目的である「全体像の把握」が難しくなります。一方で、粗すぎると具体的な機能の把握や要件の検討が不十分になります。

そのため、業務単位やユーザーの操作単位など、「意味のあるまとまり」を基準に粒度を調整することが重要です。また、複数の関係者が図を見たときに、意図が読み取りやすいレベルを意識するようにしましょう。

関係者が直感的に理解できる形にする

ユースケース図は開発者だけでなく、業務担当者や品質管理者、時にはクライアントも確認する資料になります。そのため、専門知識の有無にかかわらず理解しやすいように情報を整理することが不可欠です。

専門用語を極力避けることに加えて、図のレイアウト、ラベルの名称、グルーピングに配慮することで、誰でも理解しやすい図を目指しましょう。

システムの仕様変更や追加機能に合わせて、定期的に見直す

ユースケース図は一度作成したら終わりではなく、開発の進行に伴って見直しが必要になります。仕様変更や機能追加があった際に、図を放置すると内容が古くなり、誤解や手戻りの原因になります。

設計ドキュメントとしてユースケース図を活用する場合は、変更履歴を記録したり、レビューのタイミングで更新するなど、運用ルールの整備も併せて検討するとよいでしょう。

実務に役立つユースケース図作成に向けて

ユースケース図を活用することで、アクターと機能の関係を明確に整理でき、要件定義や設計フェーズにおける品質向上につなげることができます。

視覚的にわかりやすいユースケース図を作成できれば、関係者間での認識のズレや仕様漏れを未然に防ぎ、プロジェクト全体のスムーズな進行に大きな効果を発揮します。

AGESTでは、上流工程から品質を作り込むための「ドキュメントインスペクションサービス」を提供しています。ユースケース図を含む開発ドキュメントのレビューや改善提案を通じて、実務に即した設計とテストの実現をサポート。業務システムに精通した専門チームが、貴社の開発現場に寄り添いながら品質向上と効率化を支援します。

詳しくは、サービス詳細ページをご覧ください。

ドキュメントインスペクションサービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ