ベンダーとの要件定義の打ち合わせで、「ユースケースを整理してきてください」と言われて戸惑った経験はないでしょうか。自席に戻ってから「ユースケースって何だろう」「図を自分で作らないといけないのかな」と不安になる発注担当者は少なくありません。
検索してみると「書き方5ステップ」「PlantUMLで作図」といった記事ばかりが並び、いきなり作図ツールの解説が始まって、「やはり自分が描かないといけないのか」とますます不安になってしまうかもしれません。
ですが、結論を先にお伝えします。発注者がユースケース図を自分で作成する必要は、ほとんどありません。作図はベンダーの仕事です。発注者が準備すべきなのは「誰が・何をしたいか・何は対象外か」という3つの情報だけです。
この記事では、IT・システム開発の文脈における「ユースケースとは何か」を発注者向けにわかりやすく解説し、次の打ち合わせまでに準備すべき内容と、ベンダーにそのまま渡せるテンプレートまでご紹介します。読み終えるころには、「自分は何をすればいいのか」がはっきりして、次の打ち合わせが驚くほどスムーズになるはずです。
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
入力いただいたメールアドレスにPDFをお送りします。
ユースケースとは？要件定義における意味をわかりやすく
ユースケースとは、システムを「誰が・どのように使うか」を整理した利用シナリオです。要件定義の文脈では、「誰が・何をできるシステムか」を発注者とベンダーで共有するために使われます。
つまり、難しい技術ドキュメントというより、「このシステムを使う人と、その人がやりたいこと」を整理したメモのようなものだと考えてください。発注者がまず押さえるべきは、この一文だけで十分です。
ただし「ユースケース」という言葉は、ビジネスの場面で2つの異なる意味で使われています。混乱を防ぐために、まずここを整理しておきましょう。
「ユースケース」のビジネス用語とIT用語の違いは？
ベンダーが要件定義で言う「ユースケース」と、マーケティング資料で見かける「ユースケース」は別物です。まず両者の違いを表で整理します。
ビジネス・マーケティング用語 | IT・システム開発用語 | |
|---|---|---|
意味 | 活用シーン・使用例 | システムの利用シナリオ・記述手法 |
使われる場面 | 製品紹介・営業資料 | 要件定義・システム設計 |
例 | 「このツールのユースケースはこちら」 | 「ユースケースを整理してください」 |
本記事で扱うのは | ー | こちら |
ビジネス・マーケティング用語としての「ユースケース」は「活用シーン・使用例」を意味します。新製品やサービスの説明資料で「このサービスのユースケース」と使われる場合は、「このツールはこのような場面で役立ちます」という紹介の文脈です。
一方、要件定義の打ち合わせでベンダーが使う「ユースケース」は、IT・システム開発用語です。こちらは、システムがどのように使われるかを整理したシナリオ・記述手法を指します。UML（統一モデリング言語）と呼ばれる設計の標準規格の一部として定義されており、システム開発の要件定義フェーズで広く活用されています（Lucidchart「ユースケース図とは」）。
本記事で扱うのは、後者のIT・システム開発用語としてのユースケースです。なぜ要件定義でこれを使うのかというと、「誰が・何をできるシステムか」を関係者全員で共有するためです。ベンダーと発注者が共通のイメージを持てるよう、システムの利用シーンを整理したものがユースケースだとお考えください。
「ユースケース」と「ユースケース図」は何が違う？
ユースケースには「ユースケース記述」（テキスト形式）と「ユースケース図」（図形式）の2種類があり、発注者が用意するのは図ではなくテキストで十分です。「ユースケース＝図を描くこと」と思い込む必要はありません。
両者の違いを整理すると次のようになります。
ユースケース記述（テキスト） | ユースケース図（図） | |
|---|---|---|
形式 | 文章・箇条書き | アイコンと線による図 |
作る人 | 発注者でも書ける | 主にベンダーが作成 |
必要なツール | メモ帳・Wordで十分 | 作図ツール（ベンダーが使用） |
役割 | 「誰が何をしたいか」を言葉で整理 | テキストを視覚的に俯瞰する |
発注者が打ち合わせまでに用意するのは、左側の「ユースケース記述」です。これは特別なツールを使わず、メモ帳やWordで「営業担当者は案件を登録したい」のように箇条書きするだけで成立します。右側の「ユースケース図」は、発注者のテキストをもとにベンダーが作図する成果物だと考えてください。
ですから、「ユースケースを整理してきて」と言われても、図を描くソフトを探す必要はありません。次の章で、発注者が実際に準備する中身を具体的に見ていきます。
発注者はユースケース図を自分で描くべき？
発注者がユースケース図を自分で描く必要はありません。図の作成はベンダーに任せて大丈夫です。発注者が準備すべきなのは、図そのものではなく、その材料となる情報です。
ベンダーが「ユースケースを整理してください」と伝えてくるとき、図の作成を求めているケースはほとんどありません。「システムを使う人と、その人が何をしたいかを整理してきてほしい」という意図がほとんどです。
ここが、この記事の最も重要なポイントです。図を描く技術を学ぶ必要はなく、次の打ち合わせまでに準備すべきは「誰が・何をしたいか・何は対象外か」という3つの情報だけ、と覚えておいてください。次の章では、その3つの情報を実際にどう書き出すかを、テンプレートとあわせて解説します。
発注者が準備する3つの情報とは？テンプレート付きで解説
発注者が次の打ち合わせまでに準備すべき情報は、(1) システムを使う人（アクター）、(2) 各人がしたいこと、(3) システムの範囲外、の3つです。作図ではなく、以下の手順で「言葉のリスト」を作るだけで完結します。
ステップ1：システムを使う「人」をリストアップする
そのシステムを使う人・組織・外部システムをすべて洗い出します。この「使う人」を、ユースケースの世界では「アクター」と呼びます。
- 社内の営業担当者
- 管理職（一覧・承認機能を使う）
- 経理担当者（請求データを閲覧する）
- 外部の顧客（問い合わせフォームを使う）
ポイントは「システムにアクセスする可能性のある全員」を漏れなく書き出すことです。ここで人を取りこぼすと、その人向けの機能ごと見積もりから漏れ、後から追加費用が発生する原因になります。
ステップ2：各人が「何をしたいか」を箇条書きにする
ステップ1でリストアップした各人について、「このシステムで何をしたいか」を書き出します。
- 営業担当者：案件を新規登録したい / 自分の担当案件を一覧で確認したい
- 管理職：全案件を一覧で確認したい / 案件のステータスを変更したい
- 経理担当者：月次の売上データを確認したい
ここで書き出した一つひとつが「ユースケース（その人がシステムでやりたいこと）」にあたります。技術用語を意識する必要はなく、「誰が、何をしたいか」を素直に並べれば大丈夫です。
ステップ3：「システムの範囲外」を明示する
「今回のシステムには含めない機能」を明確にしておくことで、後から「あれも対応してほしい」となる費用増加リスクを下げられます。
- 「Excelへのエクスポート機能は今回は不要」
- 「外部の在庫管理システムとのAPI連携は対象外」
- 「スマートフォンアプリは今回は作らない」
範囲外を最初に決めておくと、見積もりの前提が固まり、ベンダーとの認識ズレを防げます。要件定義でトラブルになりやすいのは、この「やらないことの線引き」が曖昧なケースです。
ステップ4：ベンダーに渡せる簡易ユースケース記述に整える
ステップ1〜3で書き出した内容を、ベンダーに渡せる1つのテキストにまとめます。図ツールは不要で、次のシンプルな形式で十分です。
[アクター]は[ゴール]したい。[前提条件・制約があれば記載]
このフォーマットに沿って書くと、次のようになります。
営業担当者は、担当する案件の情報（商談状況・金額・期日）を登録・更新したい。
外出先でもスマートフォンから閲覧できることが望ましい。
管理職は、全営業担当者の案件一覧と進捗状況を一覧で確認したい。
自分では登録や更新は行わない（閲覧専用）。
経理担当者は、月ごとの成約案件の売上データをCSV形式でダウンロードしたい。
（Excelで加工するため、PDF形式では不可）
このように「誰が・何をしたいか・制約は何か」をシンプルに書いたものがあれば、ベンダーはそれを元にユースケース図に落とし込んでくれます。発注者がやるべきはここまでで、作図はベンダーの仕事です。次の打ち合わせには、この箇条書きを印刷するかファイルで持参するだけで準備完了です。
ステップ5：業務フロー図がある場合は一緒に渡す
すでにExcelなどで業務フロー図を作った経験がある場合、それも貴重な素材になります。新たに作り直す必要はなく、手元にあるものをそのまま渡してください。
業務フロー図は「Aさんがデータを入力したらBさんが確認する」という人の手順を表します。一方、ユースケースは「システムがAさんに何を提供するか」を整理したものです。両者は補完関係にあり、業務フロー図があると、ベンダーがユースケースを整理する際の手がかりになります。
業務フロー図 | ユースケース図 | |
|---|---|---|
表現するもの | 業務の手順・流れ（誰が・いつ・何をする） | システムの機能一覧（誰が・何をできるか） |
主な用途 | 業務プロセスの整理・改善 | システムの要件定義・機能整理 |
作成者 | 発注者側で作成することも多い | 主にベンダーが作成 |
業務フロー図が既にあれば「これ、参考になりますか」と渡すだけで構いません。発注者が新しく図を起こす必要はないことを、改めて強調しておきます。
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
入力いただいたメールアドレスにPDFをお送りします。
ユースケース図はどう読む？覚えるのは3つの要素だけ
ベンダーからユースケース図が渡されたときに覚えておくべき要素は、アクター・ユースケース・システム境界の3つだけです。難しいUML記法を習得する必要はありません。
発注者が図を「描く」必要はありませんが、ベンダーが作った図を「読んで確認する」場面はあります。要件に漏れがないかをチェックするために、次の3要素だけ押さえておけば、図の意味は十分に読み取れます。
アクターとは？（誰が使うか）
アクターとは、システムを利用する「人」または「外部のシステム」のことで、ユースケース図では人型のアイコンで表現されます。
例えば「宿泊予約システム」であれば、「宿泊客」「ホテルスタッフ」「決済システム」などがアクターになります。アクターは必ずしも人間だけではなく、外部の決済サービスや他のシステムも登場することがあります。図を見たら、まず「自社の関係者が漏れなく描かれているか」を確認してください。
ユースケースとは？（何をするか）
ユースケースは、システムが行う機能・処理を表す要素で、楕円形（だ円形）で表現されます。各アクターとの間に線が引かれ、「この機能はこのアクターが使う」という関係を表します。
「宿泊客は予約を検索する」「ホテルスタッフは予約を確認する」といった内容が、楕円の中に書かれます。発注者は「自分が伝えたかったやりたいことが、すべて楕円になっているか」を見れば十分です。
システム境界とは？（どこまでがシステムか）
システム境界は、大きな長方形の枠で表現され、その枠の内側がシステムで担う機能の範囲を示します。枠の外側にいるアクターが、枠の内側の機能を利用する、という構造です。
「このシステムが何をするのか・しないのか」の範囲を視覚的に示すために使われます。ステップ3で決めた「範囲外」が枠の外になっているかを確認すると、スコープのズレを早い段階で発見できます。
なお、ベンダーがこうした図を作る際には、draw.ioのようなブラウザ上で使えるGUIツールや、テキストから図を生成するPlantUMLといったツールがよく使われます（NotePM「無料オープンソースのUMLエディタおすすめ12選」）。あくまでベンダー側の作図ツールであり、発注者がこれらを覚える必要はありません。ツール名が出てきても「ベンダーが作図に使うもの」と理解しておけば大丈夫です。
要件定義でユースケースを使う目的は？
要件定義でユースケースを使う目的は、「誰が何をできるシステムか」をベンダーと発注者で共通言語化し、機能の漏れとスコープのズレを防ぐことです。発注者の立場でもこの効果を理解しておくと、なぜ3つの情報を準備するのかが腑に落ちます。
ユースケースを使う主な効果は次の3つです。
- 認識のズレ防止：「誰が何をできるシステムか」をベンダーと発注者で共通言語化できる
- 機能の漏れ防止：アクターを洗い出すことで、利用者や機能の見落としを防げる
- スコープの明確化：システムの範囲内・外を明示することで、追加費用の発生を抑えられる
逆に言えば、ここを曖昧にしたまま開発に進むと、「想定していた人が使えない」「思っていた機能がなかった」「追加で費用がかかった」というトラブルにつながります。発注者が3つの情報を整理する作業は、こうしたリスクを未然に防ぐための準備でもあるのです。
ユースケース図が必要なプロジェクトは？
ユースケース図が特に役立つのは、利用者の役割が複数あり、機能や権限が複雑なプロジェクトです。すべてのシステム開発で必要なわけではありません。以下を参考に、ベンダーと相談してみてください。
ユースケース図が特に役立つプロジェクト
- 複数の役割（管理者・一般ユーザー・外部ユーザーなど）が存在するシステム
- 画面数が多く、権限による機能制御が複雑なシステム
- ステークホルダーが多く、認識のズレが起きやすいプロジェクト
- 複数の部署や外部システムが絡み合うシステム
ユースケース図がそこまで必要ではないプロジェクト
- 利用者が1種類でシンプルな機能のシステム（LP・簡易な申し込みフォームなど）
- 既存システムの小規模な機能追加・改修
- プロトタイプ・MVP開発など、素早く試すことを優先するフェーズ
「ユースケース図が必要かどうか」はプロジェクトの規模や複雑さによって変わります。判断に迷った場合は、ベンダーに率直に確認するのが最善です。秋霜堂株式会社でも、要件定義の初期段階でどのドキュメントが必要かを一緒に整理するサポートを行っています。
まとめ：発注者は図ではなく「3つの情報」を準備する
この記事のポイントを3点でまとめます。
- ユースケースとは「システムを誰がどう使うかを整理した利用シナリオ」。IT・システム開発の文脈では、「誰がシステムを使って何をするか」を整理した記述または図を指します。
- 発注者はユースケース図を自分で描く必要はない。作図はベンダーが行います。発注者の役割は「誰が・何をしたいか・何は対象外か」の情報を整理してベンダーに伝えることです。
- テキスト形式の簡易ユースケース記述で十分。図ツールは不要です。「[アクター]は[ゴール]したい。[制約]」というシンプルな形式で書いたものをベンダーに渡すだけで、要件確認が大きく前進します。
次の打ち合わせまでに、まずはシステムを使う人のリストと「この人は何をしたいか」を書き出してみてください。それだけでも、ベンダーとの対話がぐっとスムーズになるはずです。
業務別の具体的な書き出し例やそのまま使えるテンプレートが欲しい方はユースケースの書き方｜発注者向けに業務別の例とテンプレートで解説を、要件定義の全体的な進め方については要件定義の進め方ガイドも合わせてご覧ください。
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 発注者はユースケース図を自分で描く必要がありますか？
必要ありません。作図はベンダーの仕事です。発注者が準備するのは「誰が・何をしたいか・何は対象外か」というテキスト情報のみで、特別な作図ツールも不要です。この3つの情報を伝えるだけで、ベンダーが図に変換してくれます。
- 「ユースケース記述」と「ユースケース図」、発注者はどちらを用意すればいいですか？
テキスト形式の「ユースケース記述」を用意すれば十分です。メモ帳やWordで「誰が・何をしたいか」を箇条書きするだけで足り、図への変換はベンダー側で行います。図を描くための専門的なツールやスキルは一切不要で、次の打ち合わせにはこの箇条書きを持参するだけで準備が整います。
- アクターには外部システムや取引先も含めますか？
含めます。アクターは人だけでなく、決済システムなどの外部システムも対象です。システムを利用する可能性がある関係者・システムを漏れなく洗い出すことが、後からの追加費用を防ぐポイントです。社内の担当者だけでなく、外部の顧客や取引先システムまで視野を広げてリストアップしましょう。
- 既存の業務フロー図があれば、ユースケース記述を新たに作らなくても大丈夫ですか？
業務フロー図だけでは不十分です。業務フロー図は人の作業手順、ユースケースはシステムが提供する機能を示すもので役割が異なります。業務フロー図は補足資料としてそのまま渡し、別途ユースケース記述も準備してください。
- ユースケース図が不要と判断してよいプロジェクトの目安はありますか？
利用者の役割が1種類でシンプルな機能のシステム、既存システムの小規模な改修、MVP開発などは不要と判断できる場合が多いです。判断に迷う場合はベンダーに率直に確認するのが最善です。一方、複数の役割や部署が絡む複雑なシステムでは、認識のズレを防ぐためユースケース図が役立ちます。
