ユースケースで要件定義を整理する
ユースケースは「誰が・何のためにシステムを使うか」を整理する手法です。機能の列挙だけでは漏れやすい「業務の流れ」を捉えるために有効で、技術的な知識がなくても活用できます。
ユースケースとは
ユースケース（use case）とは、「あるユーザーがシステムを使って特定の目的を達成するまでの一連の流れ」を記述したものです。
「機能の一覧」が「システムが何をできるか」を列挙するのに対して、ユースケースは「誰が・何をしたくて・どう使うか」という目的と流れを記述します。
例を挙げると、在庫管理システムにおける「発注担当者が在庫切れを確認して発注を行う」という業務の流れがひとつのユースケースです。
ユースケースを使う理由
機能の一覧だけで要件定義を進めると、「機能は揃っているが、業務の流れに合っていない」という問題が起きやすくなります。
個々の機能がどのような文脈で使われるか、誰が使うか、どんな前後の流れがあるかを考えずに機能を並べると、「この操作をした後、どこに移動するかわからない」「この機能、誰が何のために使うのか不明」といった設計の漏れが出てきます。
ユースケースは「業務の目的から逆算して機能を考える」アプローチであるため、こうした漏れを防ぐことができます。
ユースケースの基本的な書き方
ユースケースは複雑な図で表現することもできますが、発注者が使う場合はシンプルな文章形式で十分です。
アクター（actor）：システムを使う人・組織・外部システムのことです。「営業担当者」「倉庫スタッフ」「経営者」のように、使う立場を名前で表現します。
目的（goal）：アクターがシステムを通じて何を達成したいかです。「受注情報を登録したい」「在庫数を確認したい」のように「〜したい」で表現します。
基本的な流れ（main flow）：目的を達成するための一般的な手順を箇条書きで書きます。
例外の流れ（alternative flow）：基本の流れから外れる場合（エラー・例外・権限がない場合など）の対処を書きます。
ユースケース例：在庫確認と発注申請
アクター：発注担当者
目的：在庫数が基準値を下回った商品を確認し、発注申請を行う
基本的な流れ：
- 発注担当者がシステムにログインする
- 在庫一覧画面を開き、基準値以下の商品を絞り込む
- 発注する商品を選択し、発注数量を入力する
- 発注申請を送信する
- 上長に承認通知が届く
例外の流れ：
- 同じ商品をすでに誰かが発注済みの場合、警告を表示する
- 発注数量が最小発注単位を下回る場合、エラーを出して入力を促す
このような形式で主要な業務ごとにユースケースを書くと、機能の過不足が見えやすくなります。
ユースケースで「アクター」を意識する効果
ユースケースを書く過程で「誰がこのシステムを使うか」を明確にすることは、要件定義で見落としやすい観点を補います。
同じ「受注管理システム」でも、営業担当者・倉庫スタッフ・経営者では使い方が異なります。それぞれの立場でユースケースを書くことで、「この役割には何の機能が必要で、何は不要か」が整理でき、画面設計や権限設計の方針も自然に見えてきます。
ユースケースと機能一覧の組み合わせ
ユースケースは機能一覧の代わりではなく、組み合わせて使うものです。
まずユースケースを書いて「業務の流れ」を捉え、そこから「この流れを実現するためにどんな機能が必要か」を抽出して機能一覧に落とし込むという手順が、実際には使いやすいアプローチです。
ユースケースが先にあることで、機能一覧の各項目が「何のためにある機能か」と紐づくため、ベンダーへの説明もわかりやすくなります。
発注者がユースケースを書くメリット
ユースケースは本来、開発者や設計者が書く手法ですが、発注者が書くことにも大きな価値があります。
「誰がどう使うか」は業務を知っている発注者のほうが正確に書けます。ベンダーは技術的な実装を考えますが、業務の文脈は発注者にしかわかりません。発注者がユースケースを書いてベンダーに渡すことで、ヒアリングの効率が上がり、認識のズレを早期に発見できます。
完璧なユースケースを書く必要はありません。「主要な業務ごとに、誰が何をしてどうなるか」を箇条書きでまとめるだけでも、要件定義の議論を大きく前進させることができます。
まとめ
ユースケースは「誰が・何のためにシステムを使うか」を整理する手法です。機能の列挙だけでは漏れがちな「業務の流れ」や「使う人の目的」を捉えるために有効です。発注者が主要業務ごとにシンプルなユースケースを書いてベンダーと共有することで、要件定義の精度が上がり、後からの手戻りを減らすことができます。