ユースケース図の書き方と実践例｜迷いがちなアクター定義と粒度
「ユースケース図って、どこまで細かく書けばいいんだろう？」
「外部システムもアクターとして書いていいんだっけ？」
「これ、本当にお客様との合意に役に立つの？」
要件定義の現場で、そんな風に手が止まってしまうことはありませんか？ ユースケース図はUMLの中でも知名度が高い反面、実は「粒度」や「定義の仕方」で最も迷いやすい図でもあります。
今回は、要件定義フェーズでお客様と「システムの境界（何ができるか）」をスッキリ整理するための、「ユースケース図」の実践的な書き方と活用のコツを解説します。
この記事でわかること
- ユースケース図の役割と構成要素
- 【実践サンプル】基本の書き方と、外部システムの扱い方
- 図の作成手順（5ステップ）と、要件漏れを見つけた後のアクション
- 現場で迷いがちな「粒度（どこまで書くか）」や「アクター定義」のコツ
ユースケース図とは？
ユースケース図は、一言で言うと「システムが外部に対してどんな価値（機能）を提供するのか」を図解したものです。
ここで大事なのは、システムの中身（どう作るか）ではなく、システムの「外側から見た振る舞い」にフォーカスすることです。「誰が」「何のために」そのシステムを使うのかを可視化します。
ユースケース図を構成する4つのアイテム
ユースケース図を構成するパーツは、実は以下の4つだけです。シンプルだからこそ、各アイテムの定義の仕方が重要になります。
| アイテム | 表し方（記号） | 説明・現場でのポイント |
|---|---|---|
| アクター | 人型 | システムを利用する「人」や連携する「外部システム」です。※特定の個人名（例：山田さん）ではなく、「役割（ロール：経理担当者など）」で定義するのが鉄則です。 |
| ユースケース | 楕円 | アクターがシステムを使って実現したい「目的」です。※専門用語を避け、「商品を注文する」などの動詞で記述します。 |
| システム境界 | 四角枠 | 開発対象となるシステムの範囲を示します。※この枠の「内側が作るもの」「外側が作らないもの」という明確な意思表示になります。 |
| 関連 | 実線 | アクターとユースケースを結び、対話（コミュニケーション）があることを示します。※原則として矢印は使わず、シンプルな線で表現します。 |
PMがユースケース図を重視する3つの目的
なぜPMはこの図を要件定義で重視すべきなのでしょうか。それは、この図がプロジェクトの「品質」と「納期」を守る強固な基盤になるからです。
- スコープの明確化 「これはシステム化するが、これは手運用のまま」という境界線を顧客と合意し、際限のない機能追加（スコープクリープ）を防ぎます。
- コミュニケーションの円滑化 直感的な図があることで、エンジニアだけでなくお客様も「そうそう、これがやりたかった」と共通認識を持ちやすくなります。
- 受け入れテストの目次（検収条件） 最終的に「この図に書かれたユースケースが全部動けばOK」という、検収条件のベースとして活用できます。
【実践サンプル】ユースケース図の基本と外部システムの扱い
ユースケースは、アクターとシステムの境界で「どのような価値のやり取りが必要か」をお客様と一緒に洗い出して記述します。
1. 基本的なユースケース図のサンプル
ここでは、内部の細かいロジック（DBへの登録処理など）ではなく、あくまで「アクターがシステムを使って何を達成したいか」というビジネス上の目的にフォーカスします。
- アクター（左）： 取引先
- アクター（右）： 販売部
- ユースケース： 「商品を注文する」「注文商品の在庫を確認する」
（※図解イメージ：システム境界の枠内に2つのユースケースがあり、それぞれが対象のアクターと線で結ばれている状態）
2. 【重要】外部システムも「アクター」に入れる
ここが意外と抜けがちですが、アクターは人間だけではありません。連携する外部システムも立派なアクターです。
自動でデータを送ってくる「商品管理システム」や、在庫状況を問い合わせる「在庫管理システム」などを右側に配置してユースケースと繋ぐことで、システムの外部依存関係が一目で分かるようになります。
これを網羅することで、「他社や他部署とのインターフェース調整が必要なポイント」が早期に明確になり、スケジュール遅延を未然に防ぐことができます。
ユースケース図の作成手順（5ステップ）
現場で役立つ図を最短で作るための、現実的なステップです。
- アクターを特定する: 誰が使うのか、どんな外部システムと繋がるのかを洗い出します。
- ユースケースを洗い出す: アクターごとに「このシステムを使って何を達成したいか」を書き出します。
- システム境界を設定する: 開発範囲の枠を書き、ユースケースを中、アクターを外に配置します。
- 関連を線で繋ぐ: どのアクターがどの機能を利用するのかを線で結びます。
- ユースケース記述で深掘りする: 主要なユースケースについて、具体的な「操作手順」を箇条書きなどで補足します。ここで初めて、例外的なエラー挙動などの要件漏れに気づくことができます。
【重要】要件漏れを見つけた後のアクション
手順5で詳細を深掘りし、新たな要件や漏れに気づいた後は、以下のサイクルを回して図の精度を上げることが重要です。単に「気づいて終わり」にせず、モデルに還元するプロセスがPMの腕の見せ所です。
- ユースケース図へのフィードバック 新たなアクターやユースケースが必要だと分かれば、即座に図に戻って要素を追加し、全体像を更新します。
- 代替フロー・例外フローの定義 「入力ミスがあった場合」や「外部システムがダウンしていた場合」など、正常系（ハッピーパス）以外の動きを記述に追加し、ガードを固めます。
- ステークホルダーへの再確認 更新した図と記述を持って、改めてお客様と「この条件で間違いありませんか？」と合意形成を行います。
実務で役立つアドバイス：失敗を防ぐ5つのポイント
「とりあえず書いた」だけの図にならないために、現場で意識したい重要なポイントを5つに整理しました。
① お客様が理解できる言葉で書く
ユースケース名は専門用語を避け、お客様が普段使っている言葉で書くのが鉄則です。「DBにレコードを登録する」ではなく「会員情報を登録する」と書きましょう。そうしないと、お客様は真剣に図をチェックしてくれません。
② 命名規則を統一して信頼感を高める
「名詞＋動詞（例：本を借りる）」などのルールを決めましょう。「貸出処理」と「本を借りる」が混在していると、図の信頼感が損なわれます。ドキュメントの品質を保つことは、PMへの信頼に直結します。
③ サブアクターも漏れなく記述する
「一般ユーザー」だけでなく「管理者」や「システム運用者」も見落とさないようにしましょう。後になって「運用のためのログ出力機能が必要だった！」という手戻りを防ぐため、あらゆるアクターを想像することが大切です。
④ ユースケースの粒度（抽象度）を揃える
「本の貸出を行う」という大きな機能と、「ログインボタンをクリックする」という細かな操作が混ざらないように注意しましょう。 基本的には、ユーザーが一つの目的を完了し、一旦作業を終えられる単位（＝席を立てる単位）で揃えるのがベストです。「ログインする」は目的を達成するための手段であり、それ単体ではユースケースにしないのが一般的です。
⑤ 線の意味（対話）を正しく使う
アクターとユースケースを繋ぐ線は「対話（コミュニケーション）があること」を示します。データの流れや処理の順番を矢印で表現したくなりますが、複雑な矢印の乱用は避け、原則として単純な線（実線）を使いましょう。
まとめ：ユースケース図は「共通認識」を作る最強ツール
ユースケース図は、完璧なUMLを描くことがゴールではありません。 「これを作るんですよね？」という問いかけに対して、関係者全員が「YES」と言える状態を作ることが本当の目的です。
まずは白い紙にアクター（人型）と丸を書いてみるところから始めてみてください。きっと、頭の中がスッキリ整理されるはずです。
次に読むべきおすすめ記事
「何ができるか」が固まったら、次はその機能を実現するための「データ構造」や「スケジュール」の整理に進みましょう。
- [システムコンテキスト図の書き方｜情報の境界線を確定させる] 機能の前に、まずはシステム全体の「データの出入り」を定義しましょう。
- [PDM（プレシデンスダイアグラム法）実践ガイド] 決まった機能をいつ、どの順番で作るか。依存関係を整理して遅延を防ぎます。
- [PERT/CPMによるクリティカルパス特定と見積もり術] プロジェクトのデッドラインを明確にし、最短ルートでゴールを目指す技術です。
