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