ユースケース

📖 もうちょい詳しく

何が新しいの？

ユースケースは「利用者がシステムを使って何をしたいか」を、ひとつの場面として書き出したものです。新しい考え方というより、何を作るかをはっきりさせるために昔から使われてきた整理の道具です。「機能を並べる」のではなく「使う人の行動から見る」ところが特徴です。

どうやって動いてるの？

ふつうは「誰が（利用者）」「何をして」「どんな結果になるか」をひと続きの流れで書きます。たとえば〈買い物客がカートに商品を入れ、注文を確定し、注文番号を受け取る〉といった具合です。うまくいく場合だけでなく、在庫切れなどの「例外の場合」も一緒に書くことが多いです。

何ができるの？

ユースケースをそろえると、これから作るものの全体像が見えてきます。作る前に「この場面は誰が必要としているのか」を確認でき、抜けや認識のズレに早く気づけます。要件（何を作るかの取り決め）を洗い出すときの、土台になってくれます。

🌱 身近なたとえ

券売機の使い方の説明で例えると分かりやすいです。「お金を入れる→食券を選ぶ→ボタンを押す→食券が出る」という一連の流れが、ひとつのユースケースにあたります。利用者の目的（食券を買う）を出発点に、行動の順番をならべている点が似ています。

✅ まず覚えるポイント

• 「利用者が何をしたいか」を場面として書いたものです
• 「誰が」「何をして」「どうなるか」をひと続きで表します
• うまくいく流れだけでなく、例外の場面も書くことが多いです
• 機能の一覧ではなく、使う人の行動から見るのが特徴です
• 要件を洗い出すときの土台になります

🧭 よくある勘違い

ユースケースは機能一覧と同じもの？

似ているようで視点が違います。機能一覧は「システムが持つ働き」を並べたものですが、ユースケースは「利用者がその働きを使って何を達成するか」を場面で表します。同じ機能でも、誰が何のために使うかで意味が変わるため、行動から見る方が抜けに気づきやすいことが多いです。

きれいに1回で書き切らないといけない？

そんなことはありません。最初はざっくりした流れで構いません。話を進めながら例外の場面や細かい条件を足していき、少しずつ精度を上げていく書き方がふつうです。完璧さより、関係者の認識をそろえることが目的です。

🧩 関連して覚えると楽な言葉

• 要件定義: 何を作るかの取り決めを固める工程。ユースケースはその材料になります
• ユーザーストーリー: 利用者の要望を「〜したい」と短く書いた形。ユースケースより粒が小さいことが多いです
• KPI（重要業績評価指標）: 目標の達成度を測る数値。どの場面を重視するかの判断材料になります
• デザイン思考: 使う人の視点から発想する考え方。ユースケースの「利用者起点」と相性が良いです

🏁 ひとことでまとめ

ユースケースは、使う人の行動を場面として書き出して「何を作るか」を見えやすくする整理の道具です。