ユースケースとは？要件定義での意味・書き方・ユースケース図の作成手順を完全解説

ユースケースとは、ユーザー（または外部システム）がシステムを使って特定の目的を達成するまでの相互作用を構造化して記述した設計書です。

要件定義の打ち合わせで「ユースケースを整理しておいて」と言われ、白紙のドキュメントを前に固まっている場面を想定して構成しました。読み終えたときに、アクターの洗い出し→記述書テンプレートへの落とし込み→ユースケース図の作図までを自力で進められる状態を目指します。

本記事は、システム開発の要件定義支援に携わる編集部メンバー（要件定義・業務フロー設計の実務経験者）が、OMGのUML仕様およびIPA（独立行政法人情報処理推進機構）が公開する要件定義関連ガイドラインを参照しつつ、実際の案件で使っているフォーマットをもとに構成しました。記法の細部は標準規格の版により差が生じるため、厳密な仕様はOMG公式のUML Specifications、非機能要件の整理はIPA公式サイトの最新資料で確認してください。

ユースケースとは？ITとビジネスでの意味の違い

IT領域では「システムに必要な機能を洗い出すための記述」、ビジネス領域では「顧客がサービスで得る価値を可視化するための記述」として扱われます。同じ言葉でも、目標がシステム機能の定義なのか提案資料の価値定義なのかで記述スタイルが変わります。

ITシステム開発におけるユースケースの役割

IT領域のユースケースは、アクター（利用者や外部システム）とシステムの相互作用を単位に切り出します。「会員が商品を購入する」「経理担当者が申請を承認する」のように、アクターにとって意味のある目的が完了する単位で1本にまとめるのが原則です。

• 要件定義：機能の抜け漏れを防ぐチェックリストとして機能する
• 画面設計：フローの各ステップがそのまま画面遷移や操作手順の下敷きになる
• テスト設計：基本フロー＝正常系テスト、代替フロー＝異常系テストに対応する
• 見積り：ユースケースの件数と難易度が開発規模を算出する基準になる

編集部メンバーが過去に要件定義に関与したWebシステム開発プロジェクト10件を振り返ると、ユースケース記述書を正確に作成した案件では、作成しなかった案件と比較して設計工程以降の仕様変更や手戻り工数が抑えられる傾向が見られました。プロジェクト規模や体制の違いを含む社内での観察結果であり、一般的な統計値ではありません。

ビジネス領域におけるユースケースの意味と活用シーン

ビジネス側で「このプロダクトのユースケースは？」と問われた場合、求められているのは「どんな顧客が、どんな課題を、この製品でどう解決するか」という具体的な利用シーンです。SaaSプロダクトのWebサイトにある「活用事例」がこれに該当します。ビジネスユースケースはUMLの厳密な記法を使わず、箇条書きやプレゼンテーション形式で表現される傾向があります。

ユースケースと類似用語（シナリオ・ケーススタディ・ユーザーストーリー）の違い

シナリオは「1本の具体的な操作の流れ」、ユースケースは「分岐や例外も含めた機能全体」、ケーススタディは「過去に起きた事実の分析」、ユーザーストーリーは「開発に着手する小さな単位」を指します。包含関係としては、ユースケースが複数のシナリオを束ねる位置づけです。

「ユースケース」と「シナリオ」の違い

ログイン機能を例に挙げると整理しやすくなります。シナリオは「正しいIDとパスワードを入力してログインし、マイページが表示される」という1本の経緯です。対してユースケースは、それに加えて「パスワード誤り3回でアカウントロック」「未登録メールアドレス入力」「二要素認証の要求」といった例外や分岐をすべて包含した集合体を指します。

「ケーススタディ」や「事例」との違い

ケーススタディは過去の事実を扱い、ユースケースはこれから構築するシステムの仕様を扱います。「システム導入で作業時間が○％削減された」はケーススタディであり、「経理担当者が月次レポートを出力する」はユースケースです。両者を混同すると要件定義書の記述が曖昧になります。

アジャイル開発での「ユーザーストーリー」との使い分け

アジャイル開発（スクラムなど）では「購入者として、過去の注文履歴を検索したい。素早く再注文するため」という形式で要求を記述します。ユースケースと競合するものではなく、ユースケースでシステム全体の構造を把握し、そこから切り出したストーリーをスプリントに投入する併用方法が実用的です。

• 全体の網羅性確認・関係者合意 → ユースケース図が適している
• 優先順位付け・見積り・スプリント計画 → ユーザーストーリーが適している
• 1つのユースケースを複数のストーリーへ分解して運用する手法が一般的

ユースケース図の書き方と構成要素｜UMLの基礎知識とテキスト描画ツール

基本となる表記記号は、棒人間（アクター）、楕円（ユースケース）、枠線（システム境界）、直線/矢印（関係）の4種類です。UMLはOMG（Object Management Group）が定めた標準規格であり、詳細な記法規約はOMG公式の仕様書に記載されています。

1. アクター（主体）：人間・外部システムの定義

アクターはシステムの外側に位置し、システムとやり取りを行う対象です。操作する人間だけでなく、外部の決済代行サービスや基幹システム、自動起動するタイマーバッチなども含まれます。

• 主アクター：目的を達成しようとする主体（例：会員、申請者）
• 副アクター：処理の完了を補助・承認する側（例：承認者、管理者）
• システムアクター：外部の連携システム（例：クレジットカード決済API、会計システム）

「営業課長」のような特定の役職名ではなく、「承認者」といった抽象化された役割名で定義すると、組織改編による図の陳腐化を防げます。

2. ユースケース（機能）：楕円で表すシステムの振る舞い

楕円の内部には「動詞＋目的語」の形式で記述します。「商品を購入する」「経費を申請する」が適切な例です。「購入処理」「マスタ管理」といった名詞形式では、アクターの達成したい目的が不明瞭になります。

3. システム境界：システムの対象範囲を明確にする枠

楕円群を囲む長方形の枠がシステム境界です。枠の内側が今回開発・変更する範囲、枠の外側が開発対象外を示します。明確な枠線を引くことで、「その機能も含まれていると思っていた」という認識ズレを未然に防ぎます。紙での手運用や既存システム側に任せる範囲も、境界外に明記しておくと親切です。

4. 関係性：include（包含）とextend（拡張）の使い分け

includeは常に実行される共通処理、extendは特定の条件下でのみ実行される追加処理を表します。「この処理を行わなくても本来の目的は達成できるか？」を基準にし、達成可能であればextendとして整理します。

作図作業を効率化するテキストベース作図ツール（PlantUML / Mermaid）

従来のようにドローソフトで図を手作業配置するほか、エンジニア現場では**PlantUML**や**Mermaid**といったテキスト記述から図を自動生成するコードベースのツールの利用が増えています。

テキスト形式で管理することで、Gitによる変更履歴の追跡やコードレビュー（diff確認）が容易になり、生成系AIとの連携による作図自動化もスムーズに行えます。業務効率化を目指す場合は、手動描画ツールだけでなくこうしたテキスト描画環境の導入や、要件定義・設計作業を効率化する開発ツールの選定を検討するのが効果的です。

【テンプレート付き】実務で失敗しないユースケース記述の作成5ステップ

アクター洗い出し→目的抽出→事前・事後条件の設定→基本フローと代替フローの記述→スコープ外の明記、という順序で整理するとスムーズに作成できます。図を描く前に文章形式で記述するほうが、ロジックの抜け漏れに気付きやすいメリットがあります。

ステップ1：システムを利用する「アクター」を網羅的に洗い出す

関係者で集まり短時間で付箋出しを行う手法が有効です。特に以下の存在は見落とされやすいため注意が必要です。

• 運用・保守担当者（データマスタ登録、締め処理、障害対応を行う主体）
• カスタマーサポート（代理での照会やキャンセル操作を行う主体）
• 未ログイン状態の訪問者（ゲストユーザー）
• 外部連携システム・API・定期実行バッチ
• 監査者や最高管理者権限を持つユーザー

ステップ2：アクターごとの「目的・やりたいこと」を抽出する

「そのアクターがシステムを通じて達成したい目的」を動詞で記述します。画面のボタン名ではなく、利用者の目的の言葉で整理することが重要です。「検索ボタンを押す」ではなく「条件に合う物件を探す」と記述します。この抽出結果がそのまま機能一覧のベースになります。

ステップ3：「事前条件」と「事後条件」を明確化する

事前条件は処理が開始される前に満たされているべき状態、事後条件は処理が完了した際に保証される状態を意味します。正常完了時だけでなく、失敗時の事後条件（ロールバック後のデータ状態）を明記しておくことで、データ不整合に起因するトラブルを防げます。

ステップ4：基本フロー（メインシナリオ）と代替フロー（例外処理）を記述する

基本フローには、障害やエラーが発生せずスムーズに進行した際の手順のみを記載します。10ステップ前後に抑え、分岐や例外処理はすべて代替フローへ記述します。代替フロー側には「手順6でエラーが発生した場合」のように対応する基本フローの番号を明記します。

• 主語を明確にする（「利用者が〜する」「システムが〜する」を交互に配置）
• UI変更の影響を減らすため、具体的な画面デザインやボタン名の記載は最小限にとどめる
• タイムアウト、権限エラー、二重送信、通信切断の4パターンは代替フローの標準項目として検討する

ステップ5：システムの「範囲外（スコープ外）」を明記する

「今回の開発に含まない範囲」を書面に残すことで、開発終盤での不必要な仕様膨張を抑えられます。図ではシステム境界の外側に記述し、記述書では「スコープ外」項目として残します。

こうした要件定義ドキュメントの記述精度を高めるためには、生成AIツールを補助的に活用するアプローチも効果的です。ChatGPTを活用した要件定義ドキュメント作成法やChatGPTプロンプトテンプレートの活用ガイドを併用することで、ドキュメント作成にかかる時間を短縮できます。また、プロジェクト全体の設計手法を見直したい場合は、おすすめの要件定義自動化ツール比較も参照してください。

ECサイト・業務システムでのユースケース具体的な作成事例

正常系の処理だけでなく、代替フローや外部システムとの連携まで含めて記述した2つの実務例を紹介します。プロジェクトの状況に合わせて項目名を書き換えて活用できます。

事例1：ECサイトの「商品購入・決済」ユースケース

アクターは会員／ゲスト／決済代行サービス／在庫管理システムです。「注文する」ユースケースから「本人認証」へinclude線を引く構成をとります。

• 基本フロー：カート確認 → 配送先選択 → 決済方法指定 → 注文確認 → 確定操作 → 与信実行 → 在庫引き当て・完了メール送信
• 代替フロー：与信エラー時の再試行／在庫切れ発生／クーポン有効期限切れ／二重送信の防止／配送不可地域の検知
• 事後条件（失敗時）：注文レコードは作成せず、在庫・カート情報を維持する
• スコープ外：後払い決済処理、定期購入の自動更新、返品受付フロー

事例2：社内業務システムの「経費申請・承認」ユースケース

アクターは申請者／1次承認者／2次承認者／経理担当者／会計システムです。承認処理には「差し戻し」「代理承認」「金額閾値による分岐」が存在するため、代替フローの整理が中心となります。

要件定義でユースケースを作成する際の注意点とトラブル対策

作成時の失敗の多くは「粒度の不揃い」と「内部処理の書きすぎ」に起因します。アクターの目的が達成される単位を基準にし、システムの内部ロジックを排除することで記述の品質を保てます。

粒度が大きすぎる・細かすぎる問題の解決法

適切な粒度かどうかは、**「そのユースケースが完了した時点で、アクターがひとつの目的を達成できたと感じられるか」**で判断します。

• 大きすぎる例：「商品を管理する」 → 登録、変更、公開停止、在庫調整に分割が必要
• 細かすぎる例：「パスワードを入力する」 → 「ログインする」の中の一手順として集約する
• 適切な目安：基本フローが5〜9ステップ程度、説明に2〜3分程度を要する規模感

システム内部の処理（実装詳細）を書きすぎないコツ

「データベースにINSERT文を発行する」「キャッシュメモリを更新する」といった記述はシステム内部の実装構造であり、ユースケースに書くべき内容ではありません。**「外部から観測できるシステムの振る舞い」**のみを記述し、技術的な処理詳細は設計書へ切り分けます。

発注者と開発者の認識ズレを防ぐコミュニケーション術

発注側や業務部門の担当者が要件定義を進める際は、事前に以下の3要素を整理しておくと議論が円滑になります。

1. 登場人物一覧：システムに関わる人や部署、外部サービスを役割名で整理する
2. やりたいこと一覧：役割ごとに達成したい目的を「〜する」の形で列挙する
3. 対応しない範囲：既存の運用をそのまま残す範囲や、他システムで対応する範囲を明確にする

発注時の提案依頼書（RFP）にこれらの情報を記載しておくことで、開発ベンダーからの見積り前提が揃いやすくなります。また、セキュリティや処理性能などの非機能要件に抜け漏れがないか確認する際は、IPA（独立行政法人情報処理推進機構）が提供している非機能要件の整理ガイドラインなどを活用する方法があります。最新の基準や評価指標については、IPAの公式サイトで公開されている最新文書を参照してください。

IT領域での実務スキルを高めたい場合や、社内の開発体制を強化したい場合は、実務で役立つエンジニア向けスクール比較なども参考にしながら学習環境を整えるのが効果的です。

検索条件や抽出ロジックのような細かな業務ルールの定義方法については、要件定義やデータ抽出ロジックの整理手法で詳しく解説しています。

ユースケースに関するよくある質問（FAQ）

ユースケースの主な目的は何ですか？

ユーザー視点で「誰が・何を・どう達成するか」を明確にし、発注者と開発チーム間の認識不一致や仕様変更による手戻りを防ぐことです。整理した内容はテストケースの作成、機能一覧の定義、工数見積りの根拠として活用されます。

ユースケースとシナリオの違いは何ですか？

シナリオは1つの具体的な操作経路を指し、ユースケースは例外処理や分岐フローも含めた機能全体のまとまりを指します。「正しくログインして購入を完了する」のがシナリオであり、「購入処理（エラーや在庫切れの分岐を含む）」がユースケースとなります。

ユースケース図は発注側（非エンジニア）が作成する必要がありますか？

正式な図の作成は開発チームに任せる形でも問題ありません。発注側は「どのようなアクターが存在し、それぞれ何を行いたいか」という一覧情報を用意することで、要件定義の質を大きく向上させることができます。

ユースケース図のincludeとextendの違いは何ですか？

includeは常に呼び出される共通処理、extendは条件を満たした場合にのみ呼び出される拡張処理です。「注文時の本人確認」はinclude、「クーポン利用」はextendに分類されます。「その処理がなくても本来の目的が達成できるか」を判定基準とします。

作図ツールはPlantUMLやMermaidを使うべきですか？

プロジェクトの運用方法に合わせて選択するのが適切です。エンジニア中心のチームでGit管理や自動化を行いたい場合はPlantUMLやMermaidなどのテキストベースツールが優れています。非エンジニアとの共同作業が中心の場合は、一般的なドローツールやデザインツールが適しています。

ユースケースはプロジェクトで何本程度作成するのが一般的ですか？

システムの規模によりますが、中規模程度のシステムであれば20〜60本程度に収まるケースが多く見られます。100本を超える場合は粒度が細かすぎる可能性があり、逆に数が少なすぎる場合は検討不足の可能性があります。

ユースケース記述書は作成後にどう運用管理すべきですか？

仕様変更が発生するたびに更新を行い、変更履歴と版数を管理します。更新ルールをあらかじめ定めておかないとドキュメントが形骸化し、古い情報が残る原因となります。

まずは「アクター一覧」の整理から着手する

ユースケースは学習する記号が少なく、要件定義の精度向上に直結しやすい成果物です。最初に着手する際の実践ステップをまとめました。

• システムに関わる人間・外部システムを役割名で書き出す（アクターの整理）
• 各アクターの「達成したい目的」を「〜する」の形式で列挙する（機能の抽出）
• 核となる主要機能について、基本フローと代替フローをテンプレートに沿って記述する
• 対象外とする範囲（スコープ外）を明確にして関係者と共有する

これらの準備を行うことで、要件定義の打ち合わせを円滑に進められます。UML記法の厳密な定義についてはOMGの公式仕様書を、非機能要件やガイドラインについてはIPAの公式資料をそれぞれ確認しながら作業を進めてください。本記事は実務経験と公開情報をもとにまとめたものであり、プロジェクトの性質に応じて適切な調整を行ってご活用ください。