2026.09.09 26 人が閲覧（直近 30 日）アーキテクチャ

ユースケースとは？ビジネスとUMLで異なる意味・記述の書き方とテスト連携を解説

「ユースケース」という言葉は、同じ会議の中で二つの別物を指していることがあります。事業側が口にするユースケースは「その仕組みをどんな場面で使うか」という利用事例です。一方、要件定義やUMLで言うユースケースは、利用者と対象システムのやり取りを完了単位で切り出した振る舞いの仕様を指します。この記事では、OMGのUML 2.5.1が定める定義文と完了条件、ユースケース記述に書く7項目、記述をGherkinの受け入れテストへ落とす手順、ユーザーストーリーや業務フローとの線引きまでを実装者向けにまとめました。図そのものの書き方は別記事に分けてあります。

まとめ：ユースケースの二つの意味と、記述からテストまでの落とし込み

ユースケースは、使われる文脈によって意味が異なる言葉です。事業寄りの会話では「導入事例」「使いどころ」に近い意味になり、要件定義とUMLでは「アクターが対象システムを使って観測可能な結果を得るまでの一連の振る舞い」という厳密な意味を持ちます。前者は数を挙げるもの、後者は完了条件まで書き切るものだと押さえておけば、要件のヒアリングで話が噛み合わない場面を減らせます。

実装側が扱うのは後者です。UML 2.5.1の定義には図が一切登場せず、ユースケースは文章の表（記述）だけでも成立します。図はそれを俯瞰する一手段にすぎません。記述が7項目そろっていれば、主シナリオはGherkinのGiven-When-Then、条件の値だけが違う代替コースはScenario Outlineの例示表へほぼ機械的に移せます。逆に「受注管理機能」のように名詞で切った一覧しかない状態では、テストへ落とす段で必ず情報が足りなくなります。書く価値が出る案件と書かずに済ませる案件の線引きは、記事の後半で条件付きで示しました。

ビジネス文脈とIT文脈で食い違うユースケースの意味と使い分けの基準

語義を分けないまま議論を始めると、要件定義の初日で認識がずれます。まず二つの用法を切り分けましょう。

ビジネス側が言うユースケースが指す導入事例・利用場面という用法

製品紹介やSaaSの営業資料に出てくるユースケースは、ほぼ「利用事例」「想定される使いどころ」の意味です。列挙されるのは「小売の在庫照会」「コールセンターの応対要約」といった業務シーンで、粒度もそろっていません。網羅性も完了条件も求められません。数を挙げて読者に自分の業務を重ねてもらうことが目的だからです。

この意味のユースケースは、要件定義の入力としては使えます。ただしそのまま設計へ渡すと破綻します。「在庫照会」という1行には、誰が照会するのか、どの単位で在庫を見るのか、在庫が0のときにどう応答するのかが含まれていません。事業側の一覧は対象業務を決める材料であって機能仕様ではない、と割り切るところから始めましょう。

要件定義とUMLで言う振る舞いの仕様という用法と、見分ける二つの質問

もう一方は、対象システムと利用者のやり取りを目的単位で切り出した仕様です。UML 2.5.1の18章は、ユースケースをシステムの要求（システムが何をすることになっているか）を捉える手段だと位置づけ、鍵となる概念をアクター・ユースケース・対象（subject）の三つに整理しています。アクターは人間に限らず、対象と相互作用する他システムもその範囲に含む概念です。この用法では「受注伝票を登録する」のように動詞で終わる目的単位が1本になり、中規模の業務システムなら数十本から百数十本の桁になります。

どちらの意味で使われているかは、二つの質問で判別できます。第一に「そのユースケースは、誰が始めますか」。答えが出てこなければ事業側の用法です。第二に「どこまで進んだら、そのユースケースは終わりですか」。終わりを言えることが、仕様として扱えるかどうかの判断基準です。この二問は記述の必須項目（主アクターと事後条件）にそのまま対応するため、議事録に書き留めておけば後の記述作成でヒアリングをやり直す手間が消えます。なお図の記法そのものはユースケース図とは何かを4要素と関係の使い分けから整理した解説に分けてあり、図をコードで版管理する記法はPlantUML公式のユースケース図ページに一覧があります。

UML 2.5.1が定めるユースケースの定義と完了条件・仕様上の制約

厳密な定義はOMGが公開しているUML仕様に書かれています。現行の正式版は2017年12月公開のUML 2.5.1（文書番号 formal/17-12-05）で、ユースケースは18章にまとまっています。

UML 2.5.1の定義文が示すアクター・ユースケース・対象の3概念

18.2.5.1の定義文は、ユースケースを「対象（subjects）が実行する一連のアクションを規定し、その結果は一つ以上のアクター、または各対象の他の利害関係者にとって価値を持つ観測可能な結果をもたらすもの」と述べています。アクターの定義は18.2.1.1で「対象と相互作用する利用者、または他システムが演じる役割」です。役割と書かれているため、実在の担当者名ではなく「受注担当者」のような役割名を置きます。

対象（subject）はシステムに限らず、振る舞いを持つコンポーネントやクラスでもよいと18.1.3.1に明記されています。マイクロサービス単位でユースケースを切る書き方が仕様上許されるのは、この一文が根拠です。

ユースケースが完了したと判定できる状態と、仕様が定める終了条件

実務で効くのは完了条件の規定です。18.1.3.1は「その機能はユースケースが完了するために常に完了していなければならない」とし、完了とみなせる状態を二つ挙げています。実行後に対象が、それ以上の入力や操作を期待されない状態になって同じユースケースを再度開始できるようになったとき、あるいはエラー状態になったときです。

この規定は粒度を決める道具になります。「商品を検索する」は、それだけでは対象が落ち着く状態に到達しません。検索は「受注伝票を登録する」の途中の一手にすぎないからです。切り出しに迷ったら、終わった直後にもう一度同じことを始められるかを当ててみてください。

includeとextendの仕様上の制約と、自己参照が禁止される理由

仕様には制約（Constraints）が明文化されており、モデルの破綻を機械的に防げます。18.2.5.6には、ユースケースが直接または間接に自分自身を含むinclude関係を持てないこと（cannot_include_self）、同じ対象を規定するユースケース同士を関連で結べないこと（no_association_to_use_case）、関連は2端のみであること（binary_associations）、名前が空であってはならないこと（must_have_name）が並びます。

自己参照が禁じられる理由は、includeが含まれる側の振る舞いを取り込んで完成する関係であり、循環すると完了条件が定義できなくなる点にあります。extend側は、拡張点に条件が付いていない場合は無条件で挿入されると18.1.3.1に書かれています。条件を書き忘れたextendは「常に起きる分岐」として解釈される関係です。関係の使い分けを手法として運用する話はICONIXの4工程とロバストネス分析を軸にしたユースケース駆動開発の解説にまとめました。

ユースケース記述に書く項目と主シナリオ・代替コースの粒度基準

UML 2.5.1の18.1.3.1は、ユースケースの振る舞いをInteractionやActivity、StateMachineだけでなく、事前条件・事後条件と自然言語のテキストでも記述してよいと述べています。表形式のユースケース記述が仕様の枠内にある根拠は、この一文です。

ユースケース記述に必ず入れる7項目と、IPAガイドが示す合意の段階

書式は仕様が固定していないため現場ごとに揺れます。実装へ渡すために最低限そろえたいのは、ユースケース名（動詞で終える）・主アクター・対象システム・事前条件・事後条件・主シナリオ・代替コースの7項目です。この7つが埋まっていれば、設計とテストの両方を起こせます。

発注者と開発者の合意という観点では、IPAの機能要件の合意形成ガイド ver.1.0（2010年3月31日公開・分冊1概要編）が参考になります。同ガイドは合意の成熟度を仕掛レベル・充実レベル・完成レベルの3段階に分け、コツを「言い切る／聞き切る」「図表に書く」「もれ／矛盾をチェックする」「一緒にレビューする」の4作業へ整理しました。技術領域はシステム振舞い・画面・データモデル・外部インタフェース・バッチ・帳票の6領域で、ユースケースが対応するのはシステム振舞いです。段階を分ける考え方を借りると、初回は主シナリオだけの仕掛レベルで合意を取り、代替コースを次の回で足す進め方が取れます。

主シナリオと代替コースを分けて書く手順と、書式のテンプレート

主シナリオは、事前条件が満たされた状態から事後条件に到達する成功経路だけを番号付きで並べます。分岐や例外は本文へ混ぜず、代替コースに切り出してください。分岐先の番号を主シナリオの手順番号へ紐づけると（手順3の分岐なら3a）、実装とテストの対応が追いやすくなります。次のテンプレートは受注登録を例に7項目を構造化したもので、表計算に置くよりテキストで持つほうが差分レビューに向きます。

usecase: 受注伝票を登録する
primary_actor: 受注担当者
subject: 受注管理システム
precondition:
  - 受注担当者が受注管理システムにログイン済み
  - 対象の取引先が与信審査を通過している
postcondition:
  - 受注伝票が受注番号付きで保存されている
  - 対象商品の在庫引当数が更新されている
main_scenario:
  - 1. 担当者が受注登録画面を開く
  - 2. システムが取引先候補を一覧表示する
  - 3. 担当者が取引先・商品・数量を入力する
  - 4. システムが在庫数と与信枠を検証する
  - 5. システムが受注番号を発行し伝票を保存する
alternative:
  - id: 3a
    when: 入力した取引先が候補に存在しない
    then: システムが新規取引先の申請画面へ誘導する
  - id: 4a
    when: 在庫数が要求数量に足りない
    then: システムが引当不足を警告し担当者が数量を修正する
  - id: 4b
    when: 与信枠を超過している
    then: システムが保存を中断し承認待ちとして保留する

この形式のまま版管理に載せると、代替コースが増えた差分だけをレビューできます。図として俯瞰したい場合は、同じ内容からPlantUMLの記法と.puml拡張子の扱いに沿って図を生成する運用へ寄せられます。

1本のユースケースの粒度をそろえる基準と、細分化しすぎる失敗

粒度の基準は前述の完了条件です。「同じことをもう一度始められる状態に戻るか」で切ると、1本あたりの主シナリオは5手順から9手順あたりに収まります。手順が3つを下回るユースケースが並び始めたら切りすぎのサインで、「ログインする」「検索する」「一覧を表示する」が独立して並ぶ記述は、画面遷移をユースケース名に置き換えただけの状態です。

逆方向の失敗もあります。「受注業務を行う」のような業務名を1本にすると、代替コースが20を超えて記述が読めなくなります。目安として、代替コースが10を超えたら複数の目的を含んでいると考えて分割してください。1本の記述をA4で1枚に収めるという運用上の上限を先に決めておくと、判断が早くなります。

ユースケース記述をGherkinの受け入れテストへ落とす手順とコード例

記述が7項目そろっていれば、受け入れテストは書き起こしに近い作業になります。Gherkinの公式リファレンスによれば、シナリオは初期文脈をGivenで、イベントをWhenで、期待される結果をThenで記述する形を取ります。

ユースケース記述の主シナリオとGherkinのGiven-When-Thenの対応

対応の付け方は単純です。事前条件はGiven、主シナリオでアクターが起こす操作はWhen、事後条件はThenへ移します。システム側の応答は期待結果なのでThenかAndに置いてください。共通の事前条件が複数シナリオに現れるならBackgroundへ抜き出せます。

Gherkinのキーワードは、Feature、Rule（Gherkin 6以降）、Example（別名Scenario）、Given／When／Then／And／But、アスタリスク、Background、Scenario Outline（別名Scenario Template）、Examples（別名Scenarios）です。70を超える言語に翻訳されているため、ファイル先頭に言語指定コメントを置けば日本語キーワードでも書けます。

代替コースをScenario Outlineの例示表へ移す書き方と実行の手順

代替コースのうち条件の値だけが違うものは、Scenario Outlineにまとめて記述してください。公式リファレンスは、ステップの中で山括弧で囲んだパラメータがExamples表のヘッダを参照すると説明しています。先ほどのテンプレートの4aと4bは、在庫数と要求数量の組み合わせが違うだけなので1本のOutlineへ畳めます。

Feature: 受注伝票の登録

  Rule: 在庫と与信を満たす受注だけを確定できる

    Background:
      Given 受注担当者がログインしている
      And 取引先「甲社」が与信審査を通過している

    Example: 在庫と与信を満たす受注を確定する
      Given 商品「A-100」の在庫が 50 個ある
      When 担当者が取引先「甲社」へ商品「A-100」を 10 個で登録する
      Then 受注番号が発行される
      And 商品「A-100」の在庫引当数が 10 個になる

    Scenario Outline: 在庫が足りない受注を差し戻す
      Given 商品「A-100」の在庫が <stock> 個ある
      When 担当者が商品「A-100」を <order> 個で登録する
      Then 画面に「<message>」が表示される
      And 受注番号は発行されない

      Examples:
        | stock | order | message  |
        |     5 |    10 | 引当不足 |
        |     0 |     1 | 引当不足 |

この.featureファイルを実行環境に置き、各ステップに対応するステップ定義を書けば受け入れテストとして回せます。JavaでCucumberを走らせる手順とステップ定義の書き方はCucumberによるテスト自動化とGherkin記法の実例にまとめました。記述の代替コースがテストに1本も現れていない場合、その代替コースは誰も検証していない要件だと分かります。

ユーザーストーリー・業務フロー・テストケースとの違いと使う場面

ユースケースは似た成果物と混同されます。混同の実害は「同じことを二重に書く」か「どちらも書かれない」のどちらかです。主語と粒度で並べると線引きがはっきりします。

近い三つの成果物との違いを、記述の主語と粒度と完了条件で比較

次の表は、4つの成果物を主語・粒度・完了の定義で比べたものです。

成果物	主語	粒度	完了の定義
ユースケース記述	アクターと対象システム	目的1つ・手順5〜9	事後条件への到達
ユーザーストーリー	利用者の役割	価値1つ・数文	受入条件の充足
業務フロー	複数部門の担当者	業務プロセス全体	業務の終端まで
テストケース	テスト実行者	入力と期待値1組	期待値との一致

ユーザーストーリーとユースケースは代替関係ではありません。ストーリーは「誰に何の価値があるか」を短く保つ書式で、システムの応答や分岐は受入条件へ逃がします。分岐が多い基幹業務では記述のほうが情報の置き場が足りるため、ストーリーで着手して複雑な箇所だけ記述へ書き下ろす併用が現実的でしょう。反復型での要件の進め方はアジャイル開発の要件定義を5ステップで整理した解説を参照してください。

機能一覧や画面一覧では要求が抜ける理由と、ユースケースで補う点

機能一覧は名詞の集合です。「受注登録」「与信照会」「在庫引当」と並べても、どの順で起き、途中で止まったらどうなるかは書かれていません。抜けるのは主に3種類で、開始のきっかけ、失敗時の振る舞い、そして完了の判定です。障害復旧やリトライの仕様が結合テストの直前に出てくる案件は、この3つが一覧から落ちたまま進んでいます。

ユースケース記述はこの3つを構造として持つため、抜けが空欄として見えます。事前条件が書けないユースケースは、開始のきっかけを誰も決めていないという指摘に変わります。要件定義工程の全体像と成果物の位置づけは要件定義の目的・進め方と失敗を防ぐ観点で発注者目線から整理しました。

ユースケースを書くべき案件の条件と、書かずに済ませる判断の線引き

ユースケース記述は無料ではありません。100本の記述を書けば、作成とレビューで数週間の工数が消えます。書く価値が出る条件と、書かないほうが速い条件を分けて示します。

ユースケースを書く価値が出る案件の3条件と、受託開発での進め方

次の3条件のうち2つ以上が当てはまるなら、記述を書いたほうが後の手戻りは小さくなります。第一に、1つの操作に対して条件分岐が5本以上あること。第二に、発注側と開発側が別組織で、仕様の合意を文書で残す必要があること。第三に、既存業務の置き換えで、現行の例外処理を洗い出さなければならないことです。

この条件に当たる案件では、記述を書く順番を決めておくと進行が安定します。業務の主要導線から先に3本だけ記述を作り、書式と粒度の合意を取ってから残りへ展開してください。最初から全数を書き始めると、粒度がずれた記述を後で全部直す作業が必要になるためです。業務要求をこの形で仕様へ落として構築する進め方は業務用・Webアプリ開発の相談時に前提として扱っています。要求と要件の責任分界は要求定義と要件定義の違いと成果物の分かれ目が判断材料になります。

ユースケースを書かずに済ませて良い案件と、形式だけ作る失敗例

書かない判断をはっきり示します。分岐がほぼ無い参照系の画面だけで構成される案件、社内の少人数チームが自分たちで作って自分たちで使うツール、そして数週間で捨てる検証用のプロトタイプでは、ユースケース記述は過剰です。この3つでは画面のワイヤーフレームと受入条件の箇条書きで足ります。読み手が書き手と同一なら、記述を書いても情報は増えません。

採用してはいけない使い方もあります。既に固まった画面仕様書から逆算して、体裁だけのユースケース記述を後付けで作る作業です。この場合、代替コースは画面のバリデーション一覧の写しになり、業務上の例外は最後まで出てきません。成果物は増えても要求は1つも増えないため、工数だけが積み上がります。納品物の一覧にユースケース記述があるからという理由で書き起こすなら、代替コースを業務担当者に確認する工程が入っているかを先に確かめてください。確認工程が無いのであれば、その記述は作らないほうが良い成果物です。

よくある質問

ユースケースの語義と記述の書き方について、検索でよく確認されている疑問に答えます。

ビジネスで言うユースケースとIT用語のユースケースは同じ意味ですか？

別物として扱ってください。事業側の会話に出るユースケースは「導入事例」「使いどころ」に近く、粒度も完了条件もそろっていません。UML 2.5.1が定めるユースケースは、対象システムが実行する一連のアクションを規定し、アクターにとって観測可能な結果をもたらす振る舞いの仕様です。前者は対象業務を決める材料、後者は設計とテストの入力になります。「誰が始めますか」「どこで終わりますか」の二問で、どちらの意味かを確認できます。

ユースケース記述は誰が書くのですか？

開発側が下書きし、業務側が代替コースを埋める分担が現実的です。主シナリオは業務ヒアリングの結果を開発側が構造化できますが、例外処理は現場の担当者しか知りません。IPAの機能要件の合意形成ガイドは合意を仕掛・充実・完成の3レベルに分けており、初回は主シナリオだけの状態で合意を取り、代替コースを次の回で足す進め方が取れます。レビューの場に業務担当者が入らない体制では、記述の代替コースは埋まりません。

ユースケースとユーザーストーリーは併用できますか？

併用できます。ユーザーストーリーで対象範囲と優先順位を決め、条件分岐が多い箇所だけをユースケース記述へ書き下ろす進め方が扱いやすい形です。ストーリーは「誰に何の価値か」を短く保つ書式のため、分岐や失敗時の振る舞いを書く場所が受入条件しかありません。分岐が5本を超えたあたりから受入条件が読めなくなるので、そこが書き下ろしの目安になります。両方を全件そろえる運用は二重管理になるため避けてください。

ユースケースは何本くらい洗い出せばよいですか？

本数を目標にしないでください。完了条件（実行後に同じことをもう一度始められる状態へ戻るか）で切った結果が本数になります。目安として、中規模の業務システムで収まる本数は数十本から百数十本の桁です。ここから大きく外れる場合は粒度がずれています。手順3つ未満の記述が並ぶなら画面遷移を名前に置き換えただけの切りすぎ、代替コースが10を超える記述があるなら複数の目的が混ざった切り足りずです。

ユースケース記述のテンプレートに決まった標準はありますか？

UML仕様は書式を固定していません。UML 2.5.1は、ユースケースの振る舞いをInteractionやActivity、StateMachineに加えて、事前条件・事後条件と自然言語のテキストでも記述してよいと述べているだけです。書式をどのように定めるかは、組織ごとに判断する事項です。実装とテストへ渡すには、ユースケース名・主アクター・対象システム・事前条件・事後条件・主シナリオ・代替コースの7項目がそろっていれば足ります。テキスト形式で版管理に載せると、代替コースの追加を差分で追えます。