ユースケースとは？意味・書き方と要件定義での使い方

ユースケースとは

ユースケースとは、利用者がシステムを使って達成したい目的と、その目的を達成するまでの利用者とシステムのやり取りの流れを整理したものです。

平たく言えば、「誰が、何のために、どのようにシステムを使うか」を具体的な場面として書き出したものです。機能の一覧ではなく、利用者の目的を起点に考えることで、本当に必要な機能や抜けている機能を見つけやすくなります。

英語の use case（使用事例）がそのまま使われています。ソフトウェア開発の分野で要件を整理する手法として広まり、その後ビジネスの場面でも「この技術のユースケース（活用場面）」のように、使い道という意味で広く使われるようになりました。

書き方の要素

システム開発で使うユースケースは、次の要素で構成するのが一般的です。

ユースケースを図で表したものをユースケース図と呼びます。アクターを人型の記号、ユースケースを楕円で描き、誰がどの目的でシステムを使うかを一枚で俯瞰できます。全体像はユースケース図で、個々の流れは文章で記述する、という使い分けが一般的です。

良いユースケースの条件

• 利用者の目的が一つにまとまっている（「予約して、精算して、報告する」のように欲張らない）
• 画面の細かな操作ではなく、目的に沿ったやり取りの流れで書かれている
• 例外の流れが書かれている（入力ミス、在庫切れ、権限がないなど）
• 業務の担当者が読んで、実際の業務と合っているか判断できる言葉で書かれている

実務での使い方・具体例

ユースケースは、発注者と開発者が要件をすり合わせる場面で特に役立ちます。機能の一覧だけでやり取りすると、「予約機能」という言葉の中身を互いに違うものと想像したまま開発が進んでしまうことがあります。ユースケースで流れを書くと、こうした認識のずれを早く見つけられます。

架空の例として、工務店向けの見積もり管理システムを作る場合の進め方を示します。

1. アクターを洗い出す：営業担当、現場監督、事務担当、経営者、顧客
2. アクターごとの目的を書き出す：営業担当は「見積もりを作成する」「過去の見積もりを複製する」など
3. 重要度の高いユースケースから基本フローを書く
4. 業務の担当者と読み合わせ、実際の業務との違いを修正する
5. 代替フローを追加する：単価が未登録の場合、承認者が不在の場合など
6. ユースケースから必要な画面と機能を導き出し、機能一覧を作る

ユースケースは、テストの観点づくりにも使えます。基本フローと代替フローは、そのまま受け入れテストのシナリオになります。「見積もりを作成する」の基本フローが最後まで通るか、「単価が未登録の場合」に想定どおりの案内が出るかを確認すれば、要件どおりにできているかを発注者自身が判断できます。要件定義の段階でユースケースを書いておくと、納品時の確認作業も楽になります。

MVP開発では、すべてのユースケースを作るのではなく、検証に必要なユースケースだけを選びます。主要なアクターの、主要な目的の、基本フローだけをまず作り、例外の多くは運用で対応する、という割り切りも有効です。

よくある誤解と注意点

• 画面操作の手順書になってしまう：「ボタンを押す」「プルダウンを選ぶ」といった細かな操作まで書くと、画面設計の段階で変更が必要になります。
• 基本フローだけで終わる：実際の開発で問題になるのは例外の流れです。主要な例外は必ず書きます。
• アクターの漏れ：管理者や外部システムなど、目立たないアクターの見落としに注意します。
• 作りすぎて読まれない：細かく書きすぎると関係者が読まなくなります。重要なものから書き、必要に応じて追加します。
• 業務の担当者を巻き込まない：開発者だけで書くと、実際の業務と合わないユースケースになります。

関連用語

• MoSCoW分析：ユースケースから導いた機能に優先順位をつける手法
• 業務フロー図：業務全体の流れを図にしたもの。ユースケースの前提になる
• 画面遷移図：ユースケースの流れを画面のつながりとして表したもの
• 基本設計（外部設計）：ユースケースをもとに画面や機能の仕様を決める工程

実践記事：要件定義書の書き方、MVPの軽量な仕様書

Otsumuに相談できること

ユースケースを整理すると、作るべき機能と作らなくてよい機能が見えてきます。利用者の目的から逆算して必要な機能に絞り、短期間で形にする進め方を新規事業の爆速MVPシステム開発で提供しています。業務システムの要件整理から相談したい場合は、業務システム開発もご覧ください。

まずは30分の無料相談で、作りたいシステムの利用場面をお聞かせください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01