ユースケースとは？発注者が要件定義で知るべき意味と図の読み方
ベンダーとの要件定義の打ち合わせで、「ユースケースを整理してきてください」と言われたことはないでしょうか。「ユースケースって何だろう？」「図を自分で作らないといけないのかな？」と困ってしまう方が多いようです。
実は、発注者がユースケース図を自分で作成する必要はほとんどありません。ただ、「何をどうベンダーに伝えるか」を理解しておくことは、要件定義をスムーズに進める上でとても重要です。
この記事では、IT・システム開発の文脈における「ユースケースとは何か」を発注者向けにわかりやすく解説します。読み終えたら、次の打ち合わせまでに何を準備すべきかが明確になるはずです。
目次
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
こんな方におすすめです
ユースケースとは？2つの意味と本記事での定義
「ユースケース」という言葉は、実はビジネスの場面で2つの異なる意味で使われています。混乱を防ぐために、まず整理しておきましょう。
ビジネス文脈の「ユースケース」との違い
① ビジネス・マーケティング用語としての「ユースケース」
新製品やサービスの説明資料などで「このサービスのユースケース」という使い方を目にすることがあります。この場合の「ユースケース」は「活用シーン・使用例」を意味します。「このツールはこのような場面で役立ちます」という紹介の文脈で使われる用語です。
② IT・システム開発用語としての「ユースケース」
本記事で扱うのはこちらです。要件定義の打ち合わせでベンダーが使う「ユースケース」は、システムがどのように使われるかを整理したシナリオ・記述手法のことを指します。UML（統一モデリング言語）と呼ばれる設計の標準規格の一部として定義されており、システム開発の要件定義フェーズで広く活用されています。
なぜ要件定義でユースケースを使うのかというと、「誰が・何をできるシステムか」を関係者全員で共有するためです。ベンダーと発注者が共通のイメージを持てるよう、システムの利用シーンを整理したのがユースケースです。
ユースケース図の構成要素をわかりやすく解説
ユースケースには「ユースケース記述」（テキスト形式）と「ユースケース図」（図形式）の2種類があります。ベンダーから渡される資料にユースケース図が含まれている場合に備えて、図の読み方を最低限理解しておきましょう。難しいUML記法を習得する必要はありません。以下の3つの要素を覚えておけば十分です。
アクター（誰が）
アクターとは、システムを利用する「人」または「外部のシステム」のことです。ユースケース図では、人型のアイコンで表現されます。
例えば「宿泊予約システム」であれば、「宿泊客」「ホテルスタッフ」「決済システム」などがアクターになります。
アクターは必ずしも人間だけではありません。外部の決済サービスや他のシステムもアクターとして登場することがあります。
ユースケース（何をする）
楕円形（だ円形）で表現される要素で、システムが行う機能・処理のことです。各アクターとの間に線が引かれ、「この機能はこのアクターが使う」という関係を表します。
「宿泊客は予約を検索する」「ホテルスタッフは予約を確認する」といった内容が、楕円の中に書かれます。
システム境界（どこまでがシステムか）
大きな長方形の枠で表現され、その枠の内側がシステムで担う機能の範囲を示しています。枠の外側にいるアクターが、枠の内側の機能（ユースケース）を利用するという構造です。
「このシステムが何をするのか・しないのか」の範囲を視覚的に示すために使われます。
要件定義でユースケース図を使う目的・効果
なぜ要件定義でユースケースが使われるのかを、発注者の立場から理解しておきましょう。
業務フロー図とユースケース図の違い
発注者の多くは「業務フロー図ならExcelで作ったことがある」という経験をお持ちです。業務フロー図とユースケース図は似て非なるものですが、両者は補完関係にあります。
業務フロー図 |
ユースケース図 |
|
|---|---|---|
表現するもの |
業務の手順・流れ（誰が・いつ・何をする） |
システムの機能一覧（誰が・何をできるか） |
主な用途 |
業務プロセスの整理・改善 |
システムの要件定義・機能整理 |
作成者 |
発注者側で作成することも多い |
主にベンダーが作成 |
業務フロー図は「Aさんがデータを入力したらBさんが確認する」という人の手順を表します。一方、ユースケース図は「システムがAさんに何を提供するか」を整理したものです。
要件定義では、この両方が揃うことで「どのような業務を・どのようなシステムで・どのように効率化するか」の全体像が見えてきます。業務フロー図が既にある場合は、それがユースケースを整理する際の重要な素材になります。
ユースケースを使う主な効果は以下の3つです。
- 認識のズレ防止: 「誰が何をできるシステムか」をベンダーと発注者で共通言語化できる
- 機能の漏れ防止: アクターを洗い出すことで、利用者や機能の見落としを防げる
- スコープの明確化: システムの範囲内・外を明示することで、追加費用の発生を抑えられる
発注者はユースケースにどこまで関与すべきか（核心）
ここが最も重要なポイントです。
結論から言えば、ユースケース図の作成はベンダーに任せて大丈夫です。発注者が準備すべき情報は別にあります。
ベンダーが「ユースケースを整理してください」と伝えてくるとき、図の作成を求めているケースはほとんどありません。「システムを使う人と、その人が何をしたいかを整理してきてほしい」という意図が多いです。
発注者が準備する3つの情報
次の打ち合わせまでに、以下の3ステップで情報を整理してみてください。
ステップ1: システムを使う「誰か（アクター）」をリストアップする
そのシステムを使う人・組織・外部システムをすべて洗い出します。
例:
- 社内の営業担当者
- 管理職（一覧・承認機能を使う）
- 経理担当者（請求データを閲覧する）
- 外部の顧客（問い合わせフォームを使う）
ポイントは「システムにアクセスする可能性のある全員」を漏れなく書き出すことです。
ステップ2: 各アクターが「何をしたいか（ユースケース）」を箇条書きにする
ステップ1でリストアップした各アクターについて、「このシステムで何をしたいか」を書き出します。
例:
- 営業担当者: 案件を新規登録したい / 自分の担当案件を一覧で確認したい
- 管理職: 全案件を一覧で確認したい / 案件のステータスを変更したい
- 経理担当者: 月次の売上データを確認したい
ステップ3: 「システムの範囲外」を明示する
「今回のシステムには含めない機能」を明確にしておくことで、後から「あれも対応してほしい」となる費用増加リスクを下げられます。
例:
- 「Excelへのエクスポート機能は今回は不要」
- 「外部の在庫管理システムとのAPI連携は対象外」
- 「スマートフォンアプリは今回は作らない」
ベンダーに渡せる簡易ユースケース記述の書き方と例
上記3ステップで整理した内容を、以下のフォーマットでベンダーに渡すと要件確認がスムーズになります。図ツールを使う必要はなく、テキストで十分です。
フォーマット:
[アクター]は[ゴール]したい。[前提条件・制約があれば記載]
具体例:
営業担当者は、担当する案件の情報（商談状況・金額・期日）を登録・更新したい。
外出先でもスマートフォンから閲覧できることが望ましい。
管理職は、全営業担当者の案件一覧と進捗状況を一覧で確認したい。
自分では登録や更新は行わない（閲覧専用）。
経理担当者は、月ごとの成約案件の売上データをCSV形式でダウンロードしたい。
（Excelで加工するため、PDF形式では不可）
このような「誰が・何をしたいか・制約は何か」をシンプルに書いたものがあれば、ベンダーはそれを元にユースケース図に落とし込んでくれます。
ユースケース図が特に役立つプロジェクト・そうでないプロジェクト
ユースケース図はすべてのシステム開発プロジェクトで必要なわけではありません。以下を参考に、ベンダーと相談してみてください。
ユースケース図が特に役立つプロジェクト
- 複数の役割（管理者・一般ユーザー・外部ユーザーなど）が存在するシステム
- 画面数が多く、権限による機能制御が複雑なシステム
- ステークホルダーが多く、認識のズレが起きやすいプロジェクト
- 複数の部署や外部システムが絡み合うシステム
ユースケース図がそこまで必要ではないプロジェクト
- 利用者が1種類でシンプルな機能のシステム（LP・簡易な申し込みフォームなど）
- 既存システムの小規模な機能追加・改修
- プロトタイプ・MVP開発など、素早く試すことを優先するフェーズ
「ユースケース図が必要かどうか」はプロジェクトの規模や複雑さによって変わります。判断に迷った場合はベンダーに率直に確認するのが最善です。秋霜堂株式会社でも、要件定義の初期段階でどのドキュメントが必要かを一緒に整理するサポートを行っています。
まとめ
この記事のポイントを3点でまとめます。
-
ユースケースとは「システムの利用シナリオを整理した手法」 IT・システム開発の文脈では、「誰がシステムを使って何をするか」を整理した記述または図のことをユースケースと言います。
-
発注者はユースケース図を自分で描く必要はない ベンダーが作成します。発注者の役割は「誰が・何をしたいか・何は対象外か」の情報を整理してベンダーに伝えることです。
-
テキスト形式の簡易ユースケース記述で十分 図ツールは不要です。「[アクター]は[ゴール]したい。[制約]」というシンプルな形式で書いたものをベンダーに渡すだけで、要件確認が大きく前進します。
次の打ち合わせまでに、まずはシステムを使う人のリストと「この人は何をしたいか」を書き出してみてください。それだけでも、ベンダーとの対話がぐっとスムーズになるはずです。
要件定義の全体的な進め方については要件定義の進め方ガイドも合わせてご覧ください。
システム開発の発注に関するご相談は、秋霜堂株式会社のTechBandまでお気軽にどうぞ。要件定義の段階から一緒に考えるサポートを行っています。
【サンプル】システム開発 提案依頼書（RFP）
