要件定義の入り口でよく出てくるのが「ユースケース」です。ただ、言葉だけが先に歩いていて、「図をきれいに描くこと」が目的になってしまっている現場を、けっこう見ます。
先に、この記事でいちばん言いたいことを書いてしまいます。
ユースケース図は、きれいに描くための道具ではありません。「誰の・どの目的を・漏れなく」掴むための道具です。
目的は、図の完成ではなく、要求の把握。だから、記法のルールを覚えることより、洗い出しの視点と、そもそも作らなくていい場面の見極めの方が、実務では効きます。順番に書いていきます。
① ユースケースとは何か — 「目的」の単位で捉える
ユースケースとは、利用者がシステムを使って達成したい「目的」を、ひとつの単位として書き出したものです。
ポイントは、操作ではなく目的で捉えることです。
→ ✕「ボタンを押す」「ログインする」「検索する」——これは操作。
→ ○「宿を予約する」「月次レポートを受け取る」「返品を申請する」——これが目的（＝ユースケース）。
操作の単位まで割ってしまうと、数が爆発して、全体を見渡せなくなります。ユースケースは「利用者にとって意味のある達成」の粒度でそろえる。ここがずれると、以降の洗い出しが全部ぶれます。
そして、ユースケース図は、この目的たち（ユースケース）と、それを使う人（アクター）の関係を、1枚に俯瞰した図です。文章で書くのが「ユースケース記述」、関係を絵にするのが「ユースケース図」。まず箇条書きで目的を出し、全体像を掴むために図にする——この順番が自然です。
- アクター：システムを使う人や外部システム（例：一般ユーザー、管理者、決済サービス）。
- ユースケース：そのアクターが達成したい目的（例：予約する、承認する、通知を受け取る）。
② ユースケースの洗い出し方 — アクター起点と目的起点
洗い出しは、2つの入り口を両方使うと、抜け漏れが減ります。
（A）アクター起点 — まず「誰が使うか」を全部挙げる。そのアクターごとに「このシステムで何を達成したいか」を、目的の単位で書き出していく。利用者の種類を先に固定するので、「あの立場の人の目的を丸ごと忘れていた」という事故が減ります。
（B）目的起点（業務の流れから） — 実際の業務や利用シーンを頭から追いかけ、「ここで何をしたいか」を拾っていく。アクター起点だと出てこない、例外時・イレギュラー時の目的（キャンセル、問い合わせ、エラー時の復旧など）を拾いやすい。
この2つは、片方でもう片方を検算するために使います。アクター起点で出したリストを、業務の流れでなぞって「これで足りているか」を確認する。逆もやる。すると、どちらか一方では気づけない穴が浮かびます。
洗い出しのコツを、現場の言葉で3つ:
→ 粒度をそろえる。「予約する」と「予約ボタンを押す」を同じリストに混ぜない。目的の粒度に統一する。
→ 例外を1階層だけ足す。正常系（予約する）に対して、代表的な異常系（予約を変更する／取り消す）を必ずセットで考える。全部は要らないが、代表は要る。
→ 「誰も使わない目的」を疑う。アクターに紐づかない目的が出てきたら、それは想像で足した機能かもしれません。誰の目的かを言えないものは、いったん外す。
③ ユースケース図の書き方 — 基本ルールと記述例
図の記法は、覚えることは多くありません。要素は4つだけです。
- アクター（棒人間）：利用者や外部システム。
- ユースケース（楕円）：達成したい目的。
- 関連線：アクターとユースケースを結ぶ線。「この人がこの目的を使う」を表す。
- システム境界（囲みの四角）：どこからどこまでが今回作る対象か。ここが曖昧だと、話が発散します。
書くときの基本ルール:
→ ユースケース（楕円）の中は、動詞＋目的語で書く（「予約する」「承認する」）。名詞だけ（「予約」）にしない。名詞にすると、目的なのか画面なのか機能なのか曖昧になります。
→ システム境界を先に引く。今回の対象外（外部サービスや別システムがやること）を境界の外に置くと、スコープの合意が一気に進みます。
→ include / extend を乱用しない。「共通処理をくくり出す（include）」「例外的に拡張する（extend）」の記法は、便利ですが、図を読めなくする最大の原因でもあります。関係が複雑になってきたら、まず「本当にこの矢印は要るか」を疑う。図の価値は、非エンジニアが一目で読めることにあります。
記述例（宿泊予約サービスの一部）
- アクター：宿泊者 / 施設管理者 / 決済サービス（外部）
- 宿泊者のユースケース：宿を検索する、宿を予約する、予約を変更する、予約を取り消す、レビューを書く
- 施設管理者のユースケース：予約を確認する、料金を設定する、レビューに返信する
- 決済サービス（外部）：決済を実行する（※システム境界の外）
この粒度で並べると、「宿泊者は予約できるのに、施設管理者はキャンセルに対応できないぞ？」といった関係者間の抜けが、図の上で見えてきます。これがユースケース図の本当の効き所です。
④ ツールの選び方 — 目的に対して過剰にしない
ツールは、「目的に対して過剰にしない」が唯一のコツです。ユースケース図の目的は要求の把握なので、ツールの高機能さは本質ではありません。選ぶ観点は4つで十分です。
- 予算：無料で始められるか。最初から有償ツールを買う必要はほぼありません。
- 機能：UML記法にどこまで厳密に対応する必要があるか。多くの現場では、厳密なUMLより「読める図」の方が価値があります。
- 利用者のスキル：非エンジニアも編集・閲覧するか。するなら、学習コストの低いものを。
- 共同編集・クラウド：複数人で同時に触るか、レビューで共有するか。ここが要るかどうかで、選択肢が大きく変わります。
図を描くツールに凝るより、「この図で誰と何を合意したいか」を先に決める。ツールは、その合意を助ける範囲で選べば十分です。
⑤ ユースケース図が「いらない」ケース — 作ること自体を目的化しない
最後に、いちばん実務で効く話をします。ユースケース図は、作らなくていい場面があります。
目的は「要求を漏れなく掴む」ことなので、それが別の手段で果たせているなら、図を描く手間は見合いません。作らない方がいい代表的なケース:
→ 関係者が少なく、認識がそろっている。2〜3人で全員が同じ絵を頭に持っているなら、図にするより手を動かした方が速い。
→ 機能が単純。アクターも目的も明らかで、抜け漏れの心配が薄いなら、箇条書きで足りる。
→ すでに別の形で全体像を共有できている。画面遷移図やユーザーストーリー、既存システムの実物があるなら、そちらで代替できることが多い。
逆に、ユースケース図が効くのは「アクターが多い」「関係者の認識がバラバラ」「スコープの線引きで揉めている」ときです。つまり、抜け漏れと認識ズレのリスクが高いときほど、図の価値が上がる。リスクが低いのに律儀に描くのは、ただのコストです。
作ること自体を目的にしない。これが、ユースケース図といちばん上手に付き合うコツだと思っています。
まとめ — 図の完成ではなく、要求の把握
もう一度だけ、順番で言い切ります。
→ ユースケースは、操作ではなく目的の単位で捉える。
→ 洗い出しは、アクター起点と目的起点の両方で相互に検算する。
→ 図は、要素4つ・システム境界を先に・include/extendは乱用しない。非エンジニアが一目で読めることが価値。
→ ツールは目的に対して過剰にしない。
→ そして、目的が果たせるなら、作らなくていい。
ユースケース図は、上手な絵のコンテストではありません。誰の・どの目的を・漏れなく掴めているか。その一点に効くから使うのであって、効かない場面で律儀に描くものではない、と考えています。
よくある質問（と僕の答え）
Q. ユースケースとユースケース図は何が違うのですか？
ユースケースは「利用者がシステムを使って達成する目的」を1つの単位として書き出したもの、ユースケース図はそれらとアクター（利用者）の関係を1枚に俯瞰した図です。文章で書くのがユースケース記述、関係を絵にするのが図、と分けて考えると混乱しません。実務では、まず目的を箇条書きで洗い出し、全体像を掴むために図にする、という順番が自然です。
Q. ユースケースの洗い出しは、どこから始めればいいですか？
アクター（誰が使うか）を先に挙げ、そのアクターごとに「このシステムで何を達成したいか」を目的の単位で書き出すのが基本です。目的の粒度は「ログインする」のような操作ではなく、「予約する」「レポートを受け取る」のような、利用者にとって意味のある達成にそろえます。操作単位まで割ると数が爆発し、抜け漏れの確認ができなくなります。
Q. ユースケース図は必ず作らないといけませんか？
いいえ。ユースケース図の目的は要求を漏れなく掴むことなので、目的が果たせるなら作らなくても構いません。関係者が少なく認識がそろっているとき、機能が単純なとき、すでに別の形で全体像を共有できているときは、図にする手間が見合わないことがあります。作ること自体を目的化しないのが、いちばん大事なコツです。
要件定義でユースケースの洗い出しに詰まったら、たいていは「粒度がそろっていない」か「アクターを1種類見落としている」かのどちらかです。まずそこを疑ってみてください。
以上です。
HirokiKumazawa
アプリ戦略大学
Yutaro
