ユースケース（Use Case）とは

意味

ユースケースとは、利用者が製品やサービスを使って目的を達成する、具体的な状況や筋道を記したものである。「誰が」「何のために」「どう使うか」を一連の流れとして描き、抽象的な機能ではなく実際の使われ方から対象を捉え直す。

機能を並べる発想と対をなし、ユースケースは目的の側から設計を照らす。同じ機能でも、想定する状況が違えば求められる形は変わるため、どの場面を主に据えるかが設計の輪郭を決める。

構造の視点では、ユースケースは要求を具体の物語に翻訳する装置になる。関係者が同じ場面を思い描けることで、議論が抽象論に流れず、判断の基準が共有されやすくなる。

ユースケースは、ソフトウェア工学者イヴァー・ヤコブソン（Ivar Jacobson）がシステム開発の手法として体系化した概念に由来する。利用者とシステムのやり取りを記述する枠組みとして広まり、製品企画などにも応用されている。

ジョブ理論は、利用者が片づけたい用事という目的の側を、手段を問わずに捉える。ユースケースは、その用事が特定の製品との一連のやり取りとしてどう進むかを描く。抽象度が一段違うため、同じ用事から複数のユースケースが書けることになる。

判別は、記述に自社の機能名が出てくるかで付く。用事は製品が存在しなくても成立するが、ユースケースは製品を前提にしないと書けない。手段を入れ替えたときに書き直しが必要になるのはユースケースの側で、用事のほうは残る。

カスタマージャーニーは、知る前から使った後までの長い時間を横断して捉える。ユースケースは、その途中の一場面を切り出し、目的を達成する筋道として描く。扱う時間の幅が違い、通常はジャーニーが複数のユースケースを含む形になる。

使い分けの目安は、問題が現れている位置にある。迷いや離脱が接点をまたいで起きているならジャーニーの側で見るほかないが、特定の場面で完了できないなら、その場面をユースケースとして切り出したほうが早い。原因の所在で、持ち出す道具が変わる。

「主要なユースケースを洗い出す」といった形で、想定される使われ方を具体化する場面で用いられる。機能の一覧ではなく、実際の状況から必要を導く際の起点となる。

機能の一覧を場面らしい言い回しに置き換えただけで、書けたことにしてしまう例が多い。誰がどんな状態で始め、何が揃えば終わったと言えるのかが書かれていなければ、設計上の判断は何も変わらない。名前を変えると整理された感覚は得られるが、判断材料の量は増えていない。

うまく進む筋道だけを書く偏りもよく起きる。実務で手間がかかるのは例外の側で、途中で中断した、必要な条件が揃っていなかった、複数人で操作した、といった分岐が抜けたまま作ると、後から作り直す範囲が広がる。書かれていない分岐は、存在しないのではなく検討されていないだけになる。

数の目安より、優先順位を付けられる数に収めるほうが実務は動く。並べたときに主たる場面がどれか言えなくなったら、書きすぎの側に入っている。細かく分けるほど網羅した感覚は得られるが、どれを犠牲にしてよいかが判断できなくなり、設計の輪郭は逆にぼやける。

シナリオは特定の人物が特定の状況で辿る一つの筋書きで、ユースケースは同じ目的に対する筋道をまとめた形になる。前者は具体を伝える力が強く、後者は分岐や条件を漏れなく扱える。関係者に情景を共有したいときと、抜けを潰したいときで使い分ける。

有効だが、操作する人と目的を持つ人が別であることが多い点を織り込む必要がある。入力する担当者にとっての完了と、決裁する側にとっての完了は別の地点にある。誰の目的で終わりを定義しているかを書き分けないと、どちらにとっても中途半端な設計になりやすい。