ユースケース記述の書き方 記載項目とサンプル・粒度の決め方と活用先を解説

要件定義の場で「利用者が何をしたいのか」を整理しようとすると、話が画面の話に流れてしまう。機能の一覧は作ったものの、それが業務のどの場面で使われるのかが誰にも説明できない。こうした状況は、利用の流れが文章として残されていないことが原因であることがほとんどです。

ユースケース記述は、アクターがシステムを使って目的を達成するまでの流れを、決まった項目に沿って文章化したものです。図ではなく文章なので、専門知識のない業務担当者でも読めますし、書く過程で仕様の抜けが見つかります。

本記事では、ユースケース記述の役割と図との違いから、記載する項目、具体的なサンプル、粒度の決め方、つまずきやすい点、そして作った記述を後工程へ活かす方法までを順番に整理します。

確認したいポイント	結論	詳細
ユースケース記述とは何ですか？	利用の流れを文章化した文書	アクターがシステムを使って目的を達成するまでを、定型の項目に沿って記述します。
ユースケース図との違いは？	図は一覧、記述は中身	図はアクターとユースケースの関係を示し、記述は各ユースケースの手順と条件を書きます。
何を書けばいい？	条件とフローが中心	名称、アクター、事前条件、事後条件、基本フロー、代替・例外フローが基本の構成です。
粒度はどう決める？	目的が1つ完結する単位	画面上の操作単位まで細かくすると手順書になります。目的が達成される範囲で切ります。

無料サービス資料

AIコンサル・AX伴走支援サービス
ご紹介資料

• 
• 
• 

少数精鋭で高利益率な「筋肉質企業」への変革を実現するための考え方や支援内容をまとめた資料です。

こんな方におすすめ

• AI導入を検討している
• 業務改善の進め方を知りたい
• 導入事例を確認したい

サービス資料をダウンロードする

目次

この記事でわかること

• ユースケース記述の役割と、ユースケース図との使い分け
• 記述に含める項目と、それぞれに書くべき内容
• 購入、承認という2つのサンプルに見る具体的な書き方
• 大きすぎず小さすぎない粒度の決め方
• 書いた記述を設計やテスト設計へつなげる方法

▼ 要件定義や設計の進め方を整理したい方へ 業務の棚卸しからシステム化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

ユースケース記述とは何を書く文書か

まず役割を整理します。図と記述は役割が分かれており、どちらか一方だけでは要件を表現しきれません。

利用の流れを文章で表したもの

ユースケース記述とは、アクターがシステムを使って目的を達成するまでのやり取りを、定型の項目に沿って書き起こした文書です。UMLの考え方をもとにしており、ユースケース図と組み合わせて使われます。

最大の目的は、システムが何をすべきかを、開発者、顧客、テスト担当者の間で齟齬なく共有することです。図だけでは伝わらない手順や条件を、文章として明示します。

文章で書くため、専門用語を知らない業務担当者でもレビューできます。この読みやすさが、要件の合意形成で効いてきます。

ユースケース図との違い

ユースケース図は、アクターとユースケースの関係を一覧として示す図です。誰がどの機能を使うのかという全体像は分かりますが、中で何が起きるかは表現されません。

対して記述は、1つのユースケースの中身を詳細に書きます。図が目次、記述が本文という関係だと考えると分かりやすくなります。

実務では、図を描く前に文章で記述するほうが、抜け漏れに気づきやすいという利点もあります。図にすると見た目が整ってしまい、中身の不足が見えにくくなるためです。

なお、記述と図は必ずセットで作る必要はありません。規模が小さければ記述だけで足りますし、全体像の共有が目的なら図だけでも成立します。目的から決めてください。

概要記述と詳細記述

記述には2つの粒度があります。概要記述は目的と主要な流れだけをまとめた簡潔な形式、詳細記述は事前条件や代替フローまで細かく書き起こした形式です。

検討の初期は概要記述で全体を押さえ、仕様を固める段階で重要なものだけ詳細記述に展開する、という進め方が現実的です。すべてを詳細に書くと作成が終わりません。

どちらの形式を使うかは、そのユースケースの重要度と複雑さで決めます。基幹となる業務や、分岐の多い処理ほど詳細に書く価値があります。

何のために作るのか

目的は3つです。1つ目が認識の共有。開発者とエンドユーザーが同じ文書を見ることで、システムのイメージを揃えられます。

2つ目がスコープの明確化です。記述を並べると、何を作って何を作らないかが決まります。3つ目が進捗の管理で、ユースケース1つひとつを実装の単位として扱えば、進み具合を測る目安になります。

工程全体での位置づけを整理したい場合は、IPAの共通フレームが参考になります。企画から要件定義、開発、運用までの作業項目と役割が体系的にまとめられており、用語をそろえる土台として使えます（出典：IPA「共通フレーム2013」）。

ユースケース記述に含める項目

ここからは中身です。書式に厳密な決まりはありませんが、実務で使われる項目はほぼ共通しています。

ID・名称・概要

一意のIDを振り、内容が一目で分かる名称を付けます。「UC-010 会員が商品を購入する」のように、アクターと目的が含まれた名称にしてください。

名称は動詞で終わる形にします。「購入画面」のような名詞だけでは、何をするユースケースなのかが伝わりません。

概要は数行で、このユースケースが何を成し遂げるのかを書きます。詳細を読まなくても位置づけが分かる状態にしておくと、一覧として眺めるときに役立ちます。

アクター

このユースケースを利用する主体を記載します。ユースケース図のアクター名と対応させてください。

主アクターと関連アクターを分けて書くと、より正確になります。主アクターは目的を持ってシステムを使う側、関連アクターは処理の途中で関わる外部システムや他の利用者です。

決済サービスや在庫管理システムのような外部システムも、アクターとして扱います。人だけがアクターではないという点は押さえておいてください。

アクターは役割で書いてください。個人名や部署名ではなく、「申請者」「承認者」「管理者」といった役割で表すことで、組織変更があっても記述が古くなりません。

事前条件と事後条件

事前条件は、このユースケースを開始する前に満たされていなければならない条件です。「会員がログイン済みであること」「カートに1点以上の商品が存在すること」といった形で書きます。

事後条件は、終了した時点で満たされているべき状態です。「注文データが作成され、在庫が引き当てられ、確認メールが送信されていること」のように、システムが保証する状態を書きます。

事後条件は、成功した場合と失敗した場合を分けて書くとより実用的になります。失敗時に「注文データは作成されず、在庫とカートの状態は変更されないこと」と書いておけば、実装もテストも迷いません。

条件に入りそうで入らないものもあります。「利用者が操作方法を理解した」のような、システムが保証できない内容は事後条件に含めないでください。

基本フロー

目的を達成するために最も頻繁に実行される流れを、番号付きの手順で書きます。アクターの行動とシステムの応答を交互に並べる形が一般的です。

1ステップには1つの動作だけを書いてください。複数の処理を1行にまとめると、代替フローの分岐点を指し示せなくなります。

主語を省略しないことも重要です。「確認画面を表示する」だけでは、誰が何をするのか曖昧になります。「システムは確認画面を表示する」と書いてください。

ステップ数の目安は、おおむね10前後です。これを大きく超えるようなら、粒度が粗すぎるか、複数の目的が混ざっている可能性があります。

代替フローと例外フロー

基本フロー以外の流れを記載します。代替フローは、異なる手順をたどるものの最終的に基本フローと同じ事後条件に至るものを指します。

例外フローは、手順だけでなく事後条件も基本フローと異なるものです。エラーで処理が中断する場合などが該当します。なお、両者を区別せず代替フローとしてまとめる現場もあります。

書き方としては、基本フローのどのステップから分岐するのかを明示します。「基本フロー3で在庫が不足していた場合」のように、分岐点を番号で指定してください。

▼ 要件定義の進め方からご相談いただけます ドキュメントの型化、粒度の決め方、社内での合意形成まで含めて、実務目線でご一緒に整理します。 ＞ 相談予約はこちら

サンプルで見る書き方

実際の形を2つの例で確認します。項目の並べ方より、それぞれに何を書くかが要点です。

サンプル1：会員が商品を購入する

IDはUC-010、名称は「会員が商品を購入する」。主アクターは会員、関連アクターは決済代行サービスと在庫管理システムです。概要は「カート内の商品を確定し、決済を完了させて注文を成立させる」。

事前条件は「会員がログイン済みであり、カートに1点以上の商品が存在すること」。事後条件（成功）は「注文データが作成され、在庫が引き当てられ、購入完了メールが送信されていること」。事後条件（失敗）は「注文データは作成されず、在庫およびカートの状態は変更されないこと」です。

基本フローは、会員がカートの内容を確認する、システムが配送先と支払方法の入力を求める、会員が入力して確定する、システムが在庫を確認する、システムが決済代行サービスへ決済を依頼する、システムが注文を確定して完了メールを送る、という流れになります。

例外フローとして、在庫確認で不足していた場合、決済が拒否された場合をそれぞれ書きます。分岐点を基本フローのステップ番号で示し、そのときの事後条件も明記してください。

関連アクターに外部システムが登場する場合は、その連携が失敗したときの流れも忘れずに書いてください。自社で制御できない部分ほど、記述に残す価値があります。

サンプル2：上長が申請を承認する

主アクターは上長、関連アクターは申請者と通知サービス。事前条件は「承認待ちの申請が1件以上存在し、上長が当該申請の承認権限を持っていること」です。

基本フローは、上長が承認待ち一覧を開く、システムが対象の申請を表示する、上長が内容を確認して承認を選択する、システムが状態を承認済みに更新する、システムが申請者へ通知する、という流れになります。

代替フローとして「差し戻しを選択した場合」を置きます。手順は異なりますが、申請が処理されて申請者へ通知が届くという点では同じ結果に至るため、代替フローとして扱えます。

例外フローには「承認権限がない場合」「処理中に他の承認者が先に処理していた場合」を書きます。後者は実際によく起こり、書いておかないと実装で漏れる典型です。

サンプルから読み取るポイント

2つのサンプルに共通するのは、画面名や操作の詳細が出てこない点です。「購入ボタンを押す」ではなく「注文を確定する」と書きます。画面の設計は後工程の仕事だからです。

もう1つが、例外フローを書く過程で仕様の抜けが見つかるという点です。在庫不足のとき、決済失敗のとき、他の人が先に処理していたとき。これらを書こうとして初めて「どうするのか決まっていない」ことに気づきます。

粒度の決め方

ユースケース記述で最も難しいのが粒度です。大きすぎても小さすぎても使えません。判断の基準を整理します。

大きすぎる例と小さすぎる例

大きすぎる例は「受注管理を行う」のような、業務全体をひとまとめにしたものです。中身が膨大になり、フローを書き切れません。

小さすぎる例は「検索ボタンを押す」のような、画面上の操作単位です。これは操作手順であってユースケースではありません。数が膨大になり、一覧としての価値もなくなります。

もう1つの見分け方は、名称にしたときに自然かどうかです。「〜する」で終わる文にして違和感があるなら、粒度がずれている可能性があります。

「目的が1つ達成される単位」で切る

基準は明確です。アクターがシステムを使う目的が1つ完結する範囲で切ってください。「商品を購入する」「申請を承認する」「月次レポートを出力する」といった単位です。

判断に迷ったら、「アクターはこれを終えたら席を立てるか」と考えてみてください。途中で止まって次の作業が必要なら、まだ完結していない可能性があります。

逆に、その中に複数の目的が混ざっているようなら分割の候補です。「商品を購入して、レビューも投稿する」は2つのユースケースです。

登録・更新・削除をまとめない

よくある悩みが、登録、参照、更新、削除をどう扱うかです。目的も事前条件も事後条件も異なるため、原則としては分けて書くほうが正確になります。

ただし、マスタの保守のように利用者が同じで流れも似ている場合は、1つにまとめて代替フローで分岐させる書き方も実務では使われます。プロジェクト内で方針を決めておいてください。

数の目安

明確な正解はありませんが、中規模のシステムで数十本程度に収まるのが一般的な感覚です。100を大きく超えるようなら、粒度が細かすぎる可能性があります。

逆に10本に満たない場合は、粒度が粗すぎるか、対象範囲が狭いかのどちらかです。一覧を眺めて違和感があれば、その時点で見直してください。

▼ 粒度や進め方の判断もご相談いただけます 「この単位で切ってよいか」「どこまで書くべきか」といった設計段階の判断も含めて、実務目線でご相談を承っています。 ＞ 相談予約はこちら

書くときのつまずきと対処

実際に書き始めると、いくつかの点で手が止まります。原因はパターン化できるので、先に知っておくと早く進みます。

画面操作の手順書になってしまう

最も多い失敗です。「ログイン画面でIDとパスワードを入力し、ログインボタンを押す」という記述は、ユースケースではなく操作手順になっています。

対処は、画面名やボタン名を使わずに書いてみることです。「システムに認証を要求する」のように抽象度を上げると、ユースケースの粒度に近づきます。

画面の詳細は、この後の画面設計で決めるべき内容です。要件の段階で画面に踏み込むと、実現方法の選択肢を狭めてしまうという問題もあります。

あわせて、実現手段にも踏み込みすぎないでください。「バーコードで読み取る」と書くと、その方式を前提にした設計しか選べなくなります。

事後条件が曖昧になる

「処理が完了していること」のような書き方では、何をもって完了とするのかが分かりません。システムが保証する状態を、具体的に列挙してください。

データが作成されているのか、状態が更新されているのか、通知が送られているのか。これらを書き出すと、実装者もテスト担当者も判断に迷わなくなります。

代替と例外の区別で迷う

前述のとおり、事後条件が基本フローと同じなら代替、異なるなら例外という区別が基本です。とはいえ、判断に時間をかけるほどの価値はありません。

迷うなら、両者を区別せずまとめて代替フローとする運用でも構いません。重要なのは分類ではなく、その流れが漏れなく書かれていることです。

主語が抜けて誰の動作か分からない

「確認画面に遷移する」という書き方では、利用者が遷移させたのかシステムが表示したのかが不明です。すべてのステップに主語を書くルールにしてください。

この習慣があるだけで、レビューでの指摘が減ります。書く側も、システムの責任範囲を意識しながら書けるようになります。

作った記述を後工程で活かす

ユースケース記述は、書いて終わりではありません。後工程の入力として使えるからこそ、書く価値があります。

画面設計や業務フローへつなげる

基本フローの各ステップは、そのまま画面遷移を検討する材料になります。どの手順でどの画面が必要かを洗い出し、画面の一覧と遷移図に展開していきます。

代替フローと例外フローは、エラー画面や確認ダイアログの必要性を示します。正常系だけの画面遷移図にならないのは、この記述があるおかげです。

記述の段階で「この画面はどこから来るのか」が整理されるため、画面遷移図を描く作業も短時間で終わります。文章が先、図が後という順序が効いてきます。

テスト設計へ展開する

効果が大きいのがこちらです。ユースケース記述はそのままテストシナリオの土台になります。事前条件をセットし、基本フローを順に実行し、途中で代替や例外に分岐させる、という形でシナリオを組み立てられます。

テストの体系の中でも、ユースケースからテストケースを導き出す方法が技法の1つとして位置づけられています（出典：JSTQB「テスト技術者資格制度 Foundation Level シラバス」）。

実際の利用の流れに沿ったテストになるため、単体テストでは見つからない、つながりの部分の不具合を検出しやすくなります。結合テストや受入テストのシナリオ作成に向いています。

見積もりと進捗の管理に使う

ユースケースを実装の単位として扱えば、進捗を測る目安になります。全部で40本のうち何本が実装済みか、という形で状況を共有できます。

見積もりでも、ユースケースごとに難易度を判定して積み上げる方法が使えます。機能一覧だけで見積もるより、実際の処理量を反映しやすくなります。

変更時に更新する

仕様が変わったら記述も更新してください。実態と合っていない記述は、テスト設計や改修の判断を誤らせます。変更管理の手順に、記述の更新を組み込んでおいてください。

あわせて、版数と更新日、承認者を残します。いつ時点の合意なのかが分かる状態にしておくことが、後の議論を助けます。

▼ 設計からテストまで一貫した進め方をご提案します ドキュメントの標準化、テスト設計への展開、AI活用による効率化まで含めてご相談いただけます。 ＞ 相談予約はこちら

組織で使えるようにする

個人の技能で終わらせず、組織として書ける状態を作る方法を整理します。

テンプレートを標準化する

項目の並び、書き方の例、粒度の目安をまとめたひな形を1つ用意しておきます。案件ごとに形式が違うと、レビューする側の負担が増えます。

最初から項目を詰め込みすぎないことも大切です。最小限の構成から始め、実際に使ってみて足りなかった項目だけを追加していくほうが定着します。

記述の管理場所も決めておいてください。個人のフォルダに散らばると、最新版がどれか分からなくなります。関係者が誰でも参照できる場所に置きます。

レビューの観点を決める

レビューで見る点を事前に決めておくと、質が安定します。粒度が適切か、主語が書かれているか、事後条件が具体的か、例外が漏れていないかの4点をチェックリストにしておけば十分です。

レビューには業務部門にも参加してもらってください。文章で書かれているからこそ、専門知識がなくても内容の妥当性を判断できます。

生成AIを下書きに使う

近年は、ヒアリングのメモから記述の下書きを生成AIに作らせ、人が取捨選択するという使い方も増えています。特に例外フローの候補出しでは、抜けの発見に役立ちます。

ただし、出力をそのまま採用するのは避けてください。書かれていない前提を補って生成することがあり、実態と異なる流れが混ざります。叩き台として扱い、確認は人が行う運用にしてください。

書ける人を増やす

記述を書けるのが特定の1人だけという状態は、組織として脆弱です。レビューを通じて複数人が書き方を共有しておけば、経験の差は徐々に埋まっていきます。

新しく参加したメンバーには、既存の記述を1本読ませてから書いてもらうのが効率的です。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。育て方の考え方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

ユースケース記述は、アクターがシステムを使って目的を達成するまでの流れを、定型の項目に沿って文章化したものです。全体像を示すユースケース図に対して、記述は各ユースケースの中身を担います。

記載する項目は、ID・名称・概要、アクター、事前条件と事後条件、基本フロー、代替フローと例外フローです。事後条件は成功時と失敗時を分けて具体的に書くと、実装にもテストにもそのまま使えます。

粒度は「アクターの目的が1つ完結する範囲」で切ります。画面上の操作単位まで細かくすると、それは手順書であってユースケースではありません。中規模のシステムなら数十本程度が目安になります。

そして、書いた記述を画面設計とテスト設計へつなげること。例外フローを書く過程で仕様の抜けが見つかり、その記述がそのままテストシナリオの土台になる。この循環まで設計できれば、要件定義の質は大きく変わります。

▼ 要件定義から設計・テストまで、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しから要件の整理、ドキュメント運用の設計、AI活用と社内への定着支援までを一貫してご支援しています。まずはお気軽にご相談ください。 ＞ 相談予約はこちら