🎄要件定義で一番最初に描くべき図は“ユースケース図”だった話
こんにちは。12/12 担当の jun です。
普段は EC・業務システムの要件定義や、運用相談を担当しています。
システム開発において、
「言ってることは分かるんだけど、お互いの認識が合っていない気がする…」
という瞬間、ありませんか？
図がないとお互いイメージを掴みにくいし、ワークフローを考える上での見落としも発生しがちです。
一口に「図」と言ってもこの業界にはいろんな図があるので、今の自分にとって何が一番適切か調べてみました。
ユースケース図と言うのが、1から要件を考える上では使いやすそうでした。
この記事では、 ユースケース図をどう描けば要件漏れしにくいのか をまとめます。
🧭 システム開発で使う「図」ってこんなにある
実務で利用できそうな図はざっくり以下の通りです。
| 図 | 目的 | どのタイミングで使う？ |
|---|---|---|
| ユースケース図 | だれが何をしたいか | 初期ヒアリング・要件整理 |
| アクティビティ図 | 業務フローの整理 | 業務の把握、現状フローの確認 |
| シーケンス図 | イベント・API の時系列 | 仕様の詳細化、システム連携 |
| ER 図 | データ構造 | DB 設計 |
| 状態遷移図 | 注文や商品などの状態管理 | バグ防止、複雑業務の整理 |
| コンポーネント図 | システム構成 | インフラ・アプリ全体像共有 |
🎯 最初に描くべきはユースケース図
お客様と話すとき、いきなり
- API のシーケンス図
- データベースの ER 図
- 状態遷移図
…などは見せても理解されません。
お客様の関心は「誰が何をできるシステムになるの？」から始まります。
つまり思考順序は
誰が → 何をできるのか → それはどんな流れで動くのか
これに最もフィットするのが ユースケース図 です。
📘 ユースケース図の描き方（実務で使える最小構成）
Step 1. アクター（登場人物）を洗い出す
まずは「誰が使うか」。
- エンドユーザー
- 管理者
- 外部システム
- 営業担当
など、人物レベルで OKです。
Step 2. ユースケース（やりたいこと）を列挙する
付箋に「やりたいこと」をガンガン書き出すイメージ。
- 商品を検索する
- 商品を購入する
- 商品を登録する
- 在庫を更新する
画面ではなく“目的ベース”にするのがポイントです。
Step 3. 「誰が」「何をするか」を線で結ぶ
アクターとユースケースを線でつなぐだけです。
PlantUMLを使うと書きやすいです。
手書きの図だと、矢印や枠を用意するのにコストがかかるので、コードで書く方が書きやすいかもしれません。
📝 最小限のユースケース図の例（PlantUML）
@startuml
left to right direction
actor エンドユーザー as C
actor 管理者 as A
C --> (商品を検索)
C --> (商品を購入)
A --> (商品を登録)
A --> (在庫を更新)
@enduml
叩き台なので、最初はシンプルなところから書けたらいいと思います。
まとめ
図を使うとコミュニケーションがスムーズになり、自分の頭の整理にもなります。
いろんな図がありますが、お客様と1から要件定義を考える際は「ユースケース図」が使いやすそうです。
私もまだまだ使いこなせていませんが、要件定義で迷っている人の参考になれば嬉しいです。