「ユースケースを書いて（整理して）ほしい」とベンダーから依頼され、意味は調べて分かったものの、いざ書こうとするとパソコンの前で手が止まってしまう。次の打ち合わせまでに実物を用意しなければならないのに、白紙のドキュメントだけが残っている。そんな状況に置かれている方は少なくありません。
手が止まる原因は、あなたが業務を理解していないからではありません。むしろ業務を知りすぎているからこそ、「どこまで細かく書けばいいのか」「何個書けば足りるのか」「業務のどこを書いてどこを省くのか」という粒度と分量の判断ができず、着手できないのです。これは初めてユースケースを書く発注者なら誰もがぶつかる壁です。
ただ、安心してください。ユースケースは「[誰が][何をしたいか]」を一文で書くだけのシンプルな整理です。お手本（具体例）と、そのまま埋められる型さえあれば、業務を知っているあなたなら数本書き出すのはそれほど難しくありません。しかも、UMLの図を描く必要はありません。文章と表だけで、ベンダーに渡せる形が作れます。
本記事では、発注者がそのまま使えるよう、作図不要のユースケースの書き方を4ステップで解説します。さらに、受注管理・勤怠・予約といった業務システム別の記述例と、Excelやスプレッドシートに転記してすぐ埋められる表形式テンプレートを掲載しました。読み終えたときには、自社業務に当てはめてユースケースを書き出せる状態になっているはずです。
なお、「ユースケースとは何か」「ユースケース図の読み方」をまず押さえたい方は、ユースケースとは？発注者が要件定義で知るべき意味と図の読み方を先にご覧いただくと、本記事の内容がよりスムーズに頭に入ります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ユースケースの書き方を始める前に押さえる3要素
書き方に入る前に、ユースケースを書くときに「何を埋めるのか」だけ確認しておきましょう。難しい定義は不要です。書く側の視点で必要なのは、次の3つの要素だけです。
「誰が・何をしたいか」を1セットで書くのが基本
ユースケースは、次の3要素を埋めていく作業だと考えてください。
- アクター（誰が）: そのシステムを使う人や立場のことです。「営業担当」「経理」「店舗スタッフ」「顧客」など、役割の単位で考えます。個人名ではなく役割で書くのがポイントです。
- ユースケース（何をしたいか）: そのアクターがシステムを使って実現したいことです。「見積書を作成したい」「勤怠を申請したい」「予約を確認したい」のように、ゴール（やりたいこと）の単位で書きます。
- システム境界（対象範囲）: 今回作る（または改修する）システムが扱う範囲のことです。たとえば受注管理システムなら「見積・受注は対象だが、請求書発行は別システム」というように、どこまでがこのシステムの仕事かを決めておきます。
この3つのうち、書き方の中心になるのは「アクター（誰が）」と「ユースケース（何をしたいか）」です。この2つを組み合わせて「[アクター]は[ゴール]したい」という一文を作る——これがユースケースを書くということの正体です。システム境界は、書き終えたあとに「どこまでがこのシステムの範囲か」を補足する役割と考えてください。
ユースケースの意味をもう少し詳しく知りたい場合
「アクターやシステム境界という言葉自体がまだピンとこない」「ユースケース図がどんなものか先に見ておきたい」という場合は、意味と図の読み方を解説したユースケースとは？発注者が要件定義で知るべき意味と図の読み方を先に読んでおくと、本記事の手順がより理解しやすくなります。本記事は「意味は分かったので、実際に書きたい」という段階の方に向けて、手を動かす部分に絞って解説していきます。
ユースケースの書き方4ステップ（発注者向け・作図不要）
ここからが本記事の中心です。作図ツールは使わず、文章と箇条書き、最後に表だけで書く方法を4ステップで紹介します。Excelやスプレッドシート、あるいはメモ帳でも進められます。
ステップ1 使う人（アクター）を洗い出す
最初に、これから作る（改修する）システムを「誰が使うか」を書き出します。役職や役割の単位で、思いつくままに箇条書きにしてください。
たとえば受注管理システムなら、次のようになります。
- 営業担当
- 営業マネージャー
- 経理担当
ここで完璧を目指す必要はありません。あとから「そういえば管理者も使う」と気づいたら追加すればよいだけです。まずは主要な使い手を3〜5人ほど挙げられれば十分です。個人名ではなく「役割」で書くこと、これだけ意識しておきましょう。
ステップ2 アクターごとに「やりたいこと」を箇条書きにする
次に、洗い出したアクターそれぞれについて、「このシステムで何をしたいか」を箇条書きにします。普段の業務でそのシステムを操作する場面を思い浮かべながら書くと進めやすくなります。
営業担当を例にすると、次のような具合です。
- 見積書を作りたい
- 受注を登録したい
- 自分の案件の進捗を確認したい
この段階では文章を整える必要はありません。「〜したい」のメモ書きで十分です。業務を知っているあなたにとっては、ここが一番書き出しやすいパートのはずです。アクターの数だけ、このリストを作っていきます。
ステップ3 一文の形に整える
ステップ2で出した「やりたいこと」を、「[アクター]は[ゴール]したい」という一文の形に整えます。誰がやることなのかを先頭に付けるだけです。
ステップ2のメモ | ステップ3で整えた一文 |
|---|---|
見積書を作りたい | 営業担当は、見積書を作成したい |
受注を登録したい | 営業担当は、受注を登録したい |
案件の進捗を確認したい | 営業担当は、自分の案件の進捗を確認したい |
このとき意識したいのは、「画面操作」ではなく「やりたいこと（業務上のゴール）」を書くことです。たとえば「保存ボタンを押す」「検索窓に入力する」のような操作の手順ではなく、「受注を登録したい」というゴールで書きます。操作の細かい部分はベンダーが設計する領域なので、発注者は「何を実現したいか」を書けば十分です。
ステップ4 前提・対象外を添える
最後に、誤解を防ぐための補足を1〜2行だけ添えます。具体的には、次の2点です。
- 前提条件: 「ログイン済みの社員が使う」「承認権限を持つ人だけが承認できる」など、そのユースケースが成り立つ条件があれば書きます。
- 対象外（システム境界）: 「請求書の発行はこのシステムでは行わない」「在庫管理は既存システムを使う」など、今回のシステムが扱わない範囲を書いておきます。
対象外を明記しておくと、ベンダーが「どこまで作るのか」を取り違えるのを防げます。ここはあとから埋めても構いませんが、思いついた時点でメモしておくと、見積もりや認識合わせのときに役立ちます。
以上の4ステップで、ユースケースの骨格はできあがります。次の章では、業務システムごとの具体的な記述例を見ていきましょう。
【業務システム別】ユースケースの書き方の例
ここでは、代表的な業務システムごとに記述例を並べます。自社の業務に近いものを見つけて、アクター名ややりたいことを置き換えるだけで、たたき台が作れます。各例は「アクター」「ユースケース一覧（一文形式）」「対象外」をセットで掲載しました。
受注・案件管理システムの例
営業が見積から受注までを管理し、経理が売上を把握するシステムを想定した例です。
アクター: 営業担当 / 営業マネージャー / 経理担当
ユースケース一覧
- 営業担当は、見積書を作成したい
- 営業担当は、受注を登録したい
- 営業担当は、自分の案件の進捗を確認したい
- 営業マネージャーは、チーム全体の案件状況を一覧で確認したい
- 営業マネージャーは、見積内容を承認したい
- 経理担当は、受注済みの案件の売上見込みを確認したい
対象外（システム境界）
- 請求書の発行・入金管理は既存の会計システムで行う
- 顧客への自動メール送信は今回の対象外とする
勤怠・申請管理システムの例
一般社員が勤怠を打刻・申請し、上長が承認、人事が集計するシステムを想定した例です。
アクター: 一般社員 / 承認者（上長） / 人事担当
ユースケース一覧
- 一般社員は、出退勤を打刻したい
- 一般社員は、残業申請を提出したい
- 一般社員は、有給休暇を申請したい
- 承認者は、部下の申請内容を確認して承認したい
- 承認者は、未承認の申請を一覧で確認したい
- 人事担当は、月次の勤怠データを集計・出力したい
対象外（システム境界）
- 給与計算は既存の給与システムで行う
- 交通費精算は別の経費精算システムを使う
予約管理システムの例
顧客がオンラインで予約し、店舗スタッフが対応、管理者が全体を見るシステムを想定した例です。
アクター: 顧客 / 店舗スタッフ / 管理者
ユースケース一覧
- 顧客は、空き状況を確認して予約したい
- 顧客は、自分の予約内容を変更・キャンセルしたい
- 店舗スタッフは、当日の予約一覧を確認したい
- 店舗スタッフは、来店時に予約状況を更新したい
- 管理者は、店舗ごとの予約状況を集計して確認したい
- 管理者は、予約枠の設定（営業時間・定員）を変更したい
対象外（システム境界）
- 決済処理は外部の決済サービスを利用する
- ポイント管理は今回の対象外とする
これらはあくまで一例です。自社の業務にぴったり一致しなくても、「アクター」と「やりたいこと」の組み合わせ方を真似するだけで、自社版のユースケースを書き出せます。
そのまま使えるユースケース記述テンプレート（表形式）
ここまでの内容を、コピーしてそのまま埋められる表形式のテンプレートにまとめました。Excelやスプレッドシートに転記して使うことを想定しています。図を描く必要はありません。
アクター | やりたいこと（ユースケース） | 前提・対象外 | 優先度 |
|---|---|---|---|
営業担当 | 見積書を作成したい | ログイン済みの社員が使う | 高 |
営業担当 | 受注を登録したい | — | 高 |
営業マネージャー | チーム全体の案件状況を一覧で確認したい | — | 中 |
経理担当 | 受注済み案件の売上見込みを確認したい | 請求書発行は対象外 | 低 |
（ここに役割を書く） | （〜したい、と書く） | （あれば書く） | （高・中・低） |
このテンプレートを基に、各列を自社の業務に置き換えていけば、ベンダーに渡せるユースケース一覧ができあがります。
テンプレートの各列の意味
- アクター: そのユースケースを実行する人や立場です。「営業担当」「顧客」など役割で書きます。
- やりたいこと（ユースケース）: 「〜したい」の形で、業務上のゴールを書きます。1行に1つのゴールを書くのが原則です。
- 前提・対象外: そのユースケースが成り立つ条件や、対象に含めない範囲があれば書きます。なければ空欄で構いません。
- 優先度: 「これは絶対に必要」「あれば便利」といった重要度を、高・中・低の3段階で付けます。
記入のコツ（優先度・空欄の扱い）
- 優先度は「必須かどうか」で付ける: 厳密なルールは不要です。「これがないと業務が回らない」ものを「高」、「あると便利だが後回しでもよい」ものを「低」と考えれば十分です。優先度を付けておくと、予算や納期の都合で機能を絞る必要が出たときに、ベンダーとの相談がスムーズになります。
- 前提・対象外の列は空欄で構わない: すべての行を埋める必要はありません。特に補足がない行は空欄のままで問題ありません。気づいた行にだけ書けば十分です。
- 1行に複数のゴールを詰め込まない: 「見積書を作成して送付したい」のように2つの動作が混ざる場合は、「作成したい」「送付したい」と行を分けると、後工程でベンダーが扱いやすくなります。
ユースケースを書くときに迷いやすいポイント（粒度・分量）
お手本やテンプレートがあっても、実際に書き始めると「これで合っているのか」という不安が出てきます。ここでは、書き方の例だけでは伝わりにくい判断軸を、よくある疑問に答える形で整理します。
どのくらい細かく書けばいい？（粒度の目安）
粒度の目安は、「業務上のひとまとまりのゴール」で1つと考えてください。
たとえば「見積書を作成したい」は1つのユースケースで十分です。これを「品番を入力する」「金額を計算する」「PDFで出力する」と画面操作レベルまで分解する必要はありません。操作の細部はベンダーが設計するので、発注者は「何を実現したいか」のレベルで止めて問題ありません。
逆に、「業務を管理したい」のような大きすぎる粒度も避けます。これだと何をするのか分からないため、「案件を登録したい」「進捗を確認したい」のように、具体的なゴール単位に分けましょう。「一言で言えるやりたいこと」が1つの目安です。
何本書けば足りる？（分量の目安）
結論から言うと、全機能を網羅する必要はありません。
最初から完璧な一覧を作ろうとすると手が止まります。まずは主要なアクターごとに、業務でよく使う操作を3〜5本ずつ書き出してみてください。アクターが3人なら、合計で10〜15本程度が最初の目安になります。
要件定義は、発注者が出したたたき台をベンダーと一緒に磨いていくプロセスです。抜け漏れは打ち合わせの中で「この場合はどうしますか?」と質問されながら埋まっていきます。最初から全部を書き切ろうとせず、「思いつく主要なものを出す」ことを目標にしましょう。
ユースケースとシナリオ（記述）の違いは?
「ユースケースとシナリオは同じものですか?」という疑問はよく聞かれます。両者は関連していますが、粒度が異なります。
- ユースケース: 「営業担当は、見積書を作成したい」という、やりたいこと（ゴール）の見出しにあたるものです。本記事で書いてきたのはこちらです。
- シナリオ（ユースケース記述）: そのユースケースを「どういう流れで実現するか」を手順として詳しく書いたものです。「①顧客を選択する ②品番を入力する ③金額を確認する ④保存する」といった具体的な操作の流れを指します。
発注者がまず用意すべきは、前者の「ユースケース一覧」です。シナリオ（詳細な手順）は、必要に応じてベンダーと一緒に作り込んでいくことが多いため、最初から細かい流れまで書き切る必要はありません。
業務フロー図とどう使い分ける?
業務フロー図とユースケースは、見ている角度が違います。
- 業務フロー図: 「業務がどういう順番で流れるか」を時系列で表したものです。複数の人や部署をまたぐ業務の流れ全体を俯瞰するのに向いています。
- ユースケース: 「誰がシステムを使って何をしたいか」を、機能の単位で列挙したものです。
すでに業務フロー図を持っているなら、その図に登場する各作業のうち「システムで行うこと」を抜き出すと、ユースケースの素材になります。逆に、まだ何もない場合は、本記事の4ステップでユースケースから書き始めるほうが手早く進みます。
ぜんぶ書ききれない場合はどうする?
書ききれなくても問題ありません。先述のとおり、ユースケース一覧は発注者とベンダーが一緒に完成させる前提のたたき台です。
「ここまでは書けたが、この先は判断に迷う」という状態でも、その時点でベンダーに共有して構いません。むしろ、迷っている箇所を共有することで、ベンダー側から「こういうケースもありますね」と提案を引き出せます。完璧な状態で渡すことよりも、早めに素材を出して対話を始めることのほうが、結果的に良い要件定義につながります。
まとめ：完璧でなくてよい、たたき台で十分
ユースケースの書き方を、発注者向けに4ステップと業務別の例、テンプレートで解説してきました。最後に要点を3つに整理します。
- 「[誰が]は[何を]したい」を一文で書く。アクター（役割）とやりたいこと（ゴール）を組み合わせるだけで、ユースケースの骨格はできあがります。画面操作の細部までは書かず、業務上のゴールの単位で止めて構いません。
- 業務別の例を真似して埋める。受注管理・勤怠・予約などの記述例から自社業務に近いものを選び、アクター名とやりたいことを置き換えれば、たたき台が作れます。表形式テンプレートに転記すれば、図を描かなくてもベンダーに渡せる形になります。
- 粒度・分量は完璧を目指さず、たたき台でよい。全機能を網羅する必要はなく、主要なものを書き出せば十分です。抜け漏れはベンダーとの打ち合わせで埋めていきます。
発注者の役割は、業務を知る当事者として「何をしたいか」という素材を出すことです。磨き込みや、シナリオ（詳細な手順）への落とし込みは、ベンダーと対話しながら進めればよい部分です。白紙のドキュメントを前に「完璧に書けないと渡せない」と身構える必要はありません。本記事のテンプレートに数本書き出すことから、まず始めてみてください。
ユースケースそのものの意味や、ユースケース図の読み方をあらためて確認したい場合は、ユースケースとは？発注者が要件定義で知るべき意味と図の読み方も参考にしてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
