ユースケースとは何か ✨
はじめに
この記事では、ユースケース (Use Case) について詳しく解説していきます。ユースケースは、ユーザー（アクター）がシステムを使ってどのようなゴールを達成するかを整理する手法です。特に、複雑な業務フローを伴う業務アプリケーション開発において強力な武器となります。
1. ユースケースとは 🎯
ユースケース とは、次のような考え方を軸にした要件定義手法です。
- 誰（アクター） が
- 何を目的（ゴール） として
- システムを通じてどのようにやり取り（インタラクション） するのか
たとえば、ネット通販の例であれば、以下のようなユースケースが考えられます。
- 「商品を検索する」
- 「商品をカートに入れる」
- 「商品を購入する」
- 「問い合わせを行う」
機能を “単に作り込む” のではなく、ユーザーがどんな価値を得たいのか、どのような業務上の課題を解決したいのか にフォーカスすることで、本当に必要な機能を優先的に検討できるのがユースケースの最大の魅力です。
2. ユースケースと業務アプリケーションの相性 ⚙️
ユースケースは、以下のような理由で業務アプリケーションとの相性が良いとされています。
-
業務フローを可視化しやすい
- 業務プロセスごとに「誰が」「いつ」「何のデータを使って」「どの結果を得るのか」を整理できるため、システム要件と業務要件を同時に洗い出しやすい。
-
ステークホルダー間の共通言語になる
- 現場担当者は「業務の流れ」、開発者は「機能の仕組み」にそれぞれ精通しているが、ユースケースを仲立ちにすることで、双方の視点をスムーズにすり合わせやすい。
-
変更に強い
- 業務は時間の経過や外部環境の変化などにより、フローが変わることが多々あります。ユースケース単位で切り分けておくと、変更影響範囲を特定しやすく、柔軟に対応できます。
こうした理由から、業務プロセスを整理しながら要件定義を進めるビジネスアプリケーションにおいて、ユースケースは強力なフレームワークになり得ます。
3. ユースケースの進め方 🚀
ユースケースを用いた開発をスムーズに進めるために、以下の3ステップが重要です。
3-1. 現行業務 (AS-IS) の可視化 🔎
まずは、現在の業務プロセスを正確に把握することから始めます。ここでのポイントは、机上の空論ではなく、現場の担当者へのヒアリングや既存資料の確認を通じて実態を正しく捉えることです。
-
AS-IS の業務フロー図
どの部署が、いつ、何をして、どこにデータを入力しているのかをフローチャートや時系列で可視化します。ボトルネックや非効率な部分も明確になります。 -
AS-IS のユースケース図
現行システム（もし存在するなら）において、ユーザーがどの機能を使用しているかを大まかに洗い出します。既存の問題点（機能不足や使い勝手の悪さなど）もここで把握しやすくなります。
3-2. 目指す業務 (TO-BE) の可視化 🏆
次に、理想的な業務状態 (TO-BE) を考えます。ここでは「どのように改善すれば業務が効率化するのか」「ユーザーの利便性が高まるのか」を具体的に描きます。
-
TO-BE の業務フロー図
新システムの導入やプロセス改善を踏まえた“理想の流れ”を示します。要らないステップの削除や自動化を組み込み、業務負荷を下げるイメージを持ちやすくします。 -
TO-BE のユースケース図
新しい環境でユーザーとシステムがどのようにやり取りするかを整理します。現状では「メール対応」だったものを「チャットボット」に切り替えるなどの具体的なアイデアを、ユースケースとして描いていきます。
AS-IS / TO-BE 比較のメリット ✅
-
課題や改善ポイントが視覚的にわかる
2つの図を並べて比較することで、具体的にどこを変えれば良いのかが一目瞭然です。 -
ステークホルダーとの認識合わせがしやすい
図として見せることで、口頭だけでは共有しきれないイメージや認識を揃えやすくなります。
3-3. ユースケースフロー／ユースケース詳細の作成 ✏️
ユースケース図で概要を捉えたあとは、ユースケースフローやユースケース詳細と呼ばれるドキュメントを作成していきます。
-
ユースケースフロー (Use Case Flow)
1つのユースケースがどのような手順で進むかをステップバイステップで書き出す方法です。成功パターンだけでなく、エラーや例外、分岐も洗い出すことで漏れの少ない仕様を作ることができます。 -
ユースケース詳細 (Use Case Specification / Description)
前提条件、事後条件、入力・出力データの項目など、よりテキストベースで詳細化したものです。業務担当者とのすり合わせやシステム仕様書としても活用できます。
4. サンプル：ネット通販サイトのユースケースと業務フロー 🛒
ここからは具体例として、ネット通販サイトを題材にしたAS-IS / TO-BE の業務フローとユースケースのサンプルをご紹介します。現場イメージが湧きやすくなるよう、簡易的なフローを提示しますが、実際のプロジェクトではさらに細かい要件や例外パターンを検討してください。
4-1. AS-IS（現行）業務例 ❌
想定される課題
- 商品検索機能の精度が低く、ユーザーが商品を見つけにくい
- 在庫連携がリアルタイムでなく、注文後に在庫切れが判明するケースがある
- 購入後の問い合わせがメールベースで、サポート担当の対応が遅延しがち
AS-IS 業務フロー図 (Mermaid記法)
上記の流れでは、検索精度の低さや在庫確認の遅さなどがユーザー体験を損なっている点として挙げられます。また、サポート担当への問い合わせがメールに限定されているため、トラッキングや履歴管理が不十分で、担当者の工数もかさんでいる現状がうかがえます。
4-2. TO-BE（理想）業務例 ✅
改善案のポイント
- AI やサジェスト機能を活用して検索精度を高める
- 在庫システムとの連携をリアルタイム化し、在庫切れを防ぐ
- 購入後の問い合わせはマイページ経由やチャットボットなどを導入し、サポート体制を改善する
TO-BE 業務フロー図 (Mermaid記法)
このフローでは、ユーザーへの商品検索体験が格段に向上し、かつ在庫連携が自動かつリアルタイムで行われるため誤注文のリスクが大幅に減ります。また、問い合わせの窓口がメールだけでなくチャットボットやマイページ経由で行われるため、問い合わせ履歴や対応状況の管理が容易になり、サポート担当の負担も軽くなることが期待されます。
5. サンプルユースケース図 🔧
以下は、TO-BE を想定したネット通販サイトのユースケース図のサンプルです。
（Mermaid 記法を使った簡易図）
-
商品を検索する (UC1)
- ユーザーが検索エンジンを使って商品を探すシナリオ。AIサジェストやカテゴリ絞り込みなども含む。
-
商品を購入する (UC2)
- ユーザーがカートに入れた商品の決済を行い、在庫が更新されるプロセス。外部の決済サービスと連携する場合もある。
-
問い合わせを行う (UC3)
- ユーザーが購入後に質問やトラブル相談をする際のシナリオ。マイページ経由やチャットボットなど。
-
問い合わせを処理する (UC4)
- サポート担当が問い合わせ内容を受け取り、回答を行い、履歴を管理するフロー。
-
決済処理サービス (UC5)
- 外部決済サービスへのリクエスト送信や結果受信を行う。クレジットカードや電子マネー決済などを想定。
6. サンプルユースケースフロー（例：商品を購入する） 🛍️
ユースケース名：商品を購入する (UC2)
ここでは、利用者がスムーズに商品を購入できるための一連の動作をより具体的に示します。
- ユーザーがカート画面を開く。
- システムがカート内商品の数量や合計金額を表示。
- ユーザーが配送先情報や支払い方法などを入力。
-
システムが在庫システムへ連携し、在庫数が十分か確認。
- 在庫不足の場合：エラーメッセージを表示し、購入手続きを中断する。
- 在庫十分の場合：決済処理へ進む。
-
システムが外部決済サービスに決済情報を送信。
- 決済エラーの場合：ユーザーに再試行を促す。
- 決済成功の場合：注文IDを発行し、在庫数を更新。
- システムがユーザーに注文完了画面を表示し、メール通知などで完了報告。
- ユーザーは注文確定のメッセージを確認し、購入を完了する。
前提条件
- ユーザーがログイン済みであること。
- システムが在庫システムや決済サービスと正常に接続できる状態であること。
事後条件
- 注文データがDBに登録され、在庫数が減算される。
- ユーザーには購入完了通知が届く（メール、アプリ通知など）。
7. ユースケースドリブン型開発とは 🤝
ユースケースドリブン型開発 とは、開発全体をユースケースという“粒度”に沿って進めるアプローチを指します。具体的には下記のプロセスで進行します。
-
ユースケース定義
- どんなユースケース（機能単位）があるのか、アクターは誰で、ゴールは何かをまとめる。
-
ユースケースフロー/詳細の作成
- 前提条件や例外処理を含め、各ユースケースのシナリオを詳細に記述。
-
システム設計・画面設計
- ユースケースフローをもとに、必要な画面・データモデル・API連携などの設計を行う。
-
実装・テスト
- ユースケース単位で実装し、テストもユーザーの操作シナリオに近い形で行う。
ユースケースドリブン型開発のメリット ⭐️
-
要件が明確化しやすい
- “なぜ”その機能が必要なのか、どんなユーザー価値があるのかを常に問い続けられる。
-
機能の優先度を付けやすい
- ユースケースの重要度や緊急度に応じて開発の優先順位を決められる。
-
テストシナリオの作成が容易
- ユースケースフローがそのままテストケースに転用可能で、抜け漏れやダブりを減らせる。
8. まとめ 🎉
-
ユースケースは「ユーザーのゴール」から出発する要件定義の方法
- 機能単位の整理に留まらず、ユーザーの目的を最優先に設計を進めることができる。
-
AS-IS / TO-BE の業務フロー・ユースケース図で比較分析
- 現行業務の問題点と理想的なプロセスを対比させることで、改善ポイントが明確化される。
-
ユースケースフローやユースケース詳細で仕様を固める
- フロー図と詳細仕様を使い分けることで、漏れや重複を防ぎながら必要な情報を網羅できる。
-
ユースケースドリブン型開発でプロジェクトを推進
- ユースケースを軸にすることで、要件定義から実装・テストまで一貫した視点で進められ、変更にも強い設計が行いやすい。
最後に 💡
ユースケースを活用することで、利用者の視点とシステムの実装視点を橋渡ししながら、業務の本質に即したシステムを構築できます。特に業務アプリケーションのように多様なプロセスやステークホルダーが関わるプロジェクトでは、ユースケース分析をベースにすることで開発の方向性がブレにくくなり、結果的にプロジェクトの成功確率を高められます。
ぜひ、AS-IS / TO-BE の比較やユースケースドリブン型開発などを取り入れ、より効果的な業務アプリケーション開発を目指してみてください。
Discussion