A ユースケース図 は、 における基本的なモデル化ツールである要件工学 は、 間の相互作用を可視化するために使用されるアクター (ユーザーまたは外部システム)と システム (またはその機能)。これはステークホルダーがシステムが機能的に何をしなければならないかを理解するのを助け、技術チームとビジネスユーザーの間のコミュニケーションの橋渡しとなる。
シンプルさにもかかわらず、ユースケース図は よく誤用される アクターの特定が不十分、ユースケースが曖昧、または関係性が誤っているためである。このガイドは、 を明確にし、重要な概念、 を提供し、ステップバイステップの手法、そして を強調する一般的な落とし穴を回避するためである。
| 概念 | 説明 |
|---|---|
| アクター | システムとやり取りする人間のユーザー、組織、または外部システム。システムの文脈における「ユーザー」として機能する。例:学生、教師、管理者、決済ゲートウェイ。 |
| ユースケース | アクターのためにシステムが実行する特定の目標や機能の記述。 何 システムが行うことを定義するが、 どのように. 例: 「コースに登録する」、「成績を提出する」、「レポートを生成する」。 |
| システム境界 | システムと外部のアクターおよびシステムを分ける境界。境界内にあるすべてのものはシステムの一部である。 |
| 関連 | アクターとユースケースを結ぶ線で、そのアクターがそのユースケースを実行できることを示す。 |
| 一般化 | あるアクターが別のアクターの振る舞いを継承する関係(例: 「学生」は「ユーザー」の一種である)。 |
| 依存関係 | あるユースケースが別のユースケースに依存することを示す関係(e |
| 例: 「レポートを生成する」は「学生データを取得する」に依存する)。 | |
| 包含 | 実行される必要があるユースケース(例: 「成績を提出する」は「学生IDを検証する」を含む)。必須もう一方の実行に必要である(例: 「成績を提出する」は「学生IDを検証する」を含む)。 |
| 拡張 | 条件付きで機能を追加するユースケース(例: 「通知を送信する」は成績が閾値を下回る場合に「成績を提出する」を拡張する)。条件付きで機能を追加する(例: 「通知を送信する」は成績が閾値を下回る場合に「成績を提出する」を拡張する)。 |
⚠️ 重要な注意点: ユースケースは機能についてのものではなく、ユーザーのニーズを満たす機能—— それらは機能的目標ユーザーのニーズを満たすものである。
すべての関連するアクターを特定するために、以下の核心的な質問に答えてください:
| 質問 | なぜ重要なのか |
|---|---|
| 主要なユースケースを使用するのは誰ですか? | 主要なユーザーを特定する(例:学生、教授)。 |
| 日常業務のサポートが必要なのは誰ですか? | サポート役割を特定する(例:人事スタッフ、ITサポート)。 |
| システム管理の責任を負うのは誰ですか? | 管理者役割を特定する(例:システムマネージャー、データベース管理者)。 |
| システムが外部デバイスやソフトウェアシステムとやり取りするのはどのようなものか? | 外部システムを特定する(例:メール、決済ゲートウェイ、ERP)。 |
| システムの成果に関心を持つのは誰ですか? | ステークホルダーを特定する(例:保護者、取締役)。 |
📌 ヒント:まず 最も重要なユーザー から始め、外側へと広げていく。実際のシナリオやインタビューを使って、アクターの特定を検証する。
💡 例: 大学の学生管理システムでは、アクターには以下が含まれる可能性がある:
学生
教員
学業アドバイザー
事務職員
決済ゲートウェイ
ERPシステム
アクターが特定されたら、それぞれのアクターについて以下の質問を行う。
| 質問 | 目的 |
|---|---|
| アクターが実行しなければならない主なタスクは何ですか? | 機能的目標を特定する(例:登録、受講、成績の閲覧)。 |
| アクターはシステム内のデータを照会または変更したいですか? | 読み取り/書き込み操作を示します(例:レコードの閲覧、プロフィールの編集)。 |
| アクターは他のシステムでの変更をシステムに通知したいですか? | イベント駆動型のトリガーを示します(例:コースが追加されたときにシステムに通知)。 |
| アクターは予期せぬイベントについて通知されるべきですか? | 通知のユースケースを示します(例:「アラート:授業の過剰検出」)。 |
📌 使用するシンプルで目標志向の言語技術用語を避ける。
✅ 良いユースケース:「授業に登録する」
❌ 悪いユースケース:「検証付きの登録フォームを提出する」→ 技術的になりすぎます。
ユースケースは異なるレベルでモデル化できます:
| レベル | 説明 |
|---|---|
| 上位レベルのユースケース | ビジネス目標を反映する広範な機能的目標(例:「学生記録の管理」)。 |
| 洗練されたユースケース | 上位レベルの目標から導き出された詳細な行動。 |
🔁 反復的開発アプローチ:
高レベルのビジネス目標から始めます。
それらをサブゴールに分解します。
各ユースケースを明確で実行可能な状態になるまで洗練します。
📌 例の分解:
上位レベル:「学生管理を支援する」
洗練:
学生は登録できます
学生は授業に登録できます
システムは成績を保存します
システムは登録確認を送信します
これにより、システムが満たすことを保証しますビジネス目標ながらも実用的でテスト可能であることを保ちます実用的でテスト可能.
次に、アクターとユースケースを図に配置し、適切に接続してください。
[アクター] --> [ユースケース]
↑
[包含] [拡張]
↓
[依存]
アクターはシステムの境界外に配置してください(通常は左・右・上側)。
ユースケースはシステムの境界内に配置してください(中央または下部)。
使用する実線関連性に使用します。
使用する破線依存関係に使用します。
使用する包含矢印(→)に対して包含関係を表します。
使用する拡張矢印(→)に対してextend関係。
重複するユースケースを避ける;図を明確で読みやすく保つ。
📌 ビジュアル例(テキストベース):
+------------------+
| 学生 | --> コースに登録
+------------------+
|
v
+------------------+
| システム | --> コース登録情報を保存
| (境界) |
+------------------+
^
|
+------------------+
| 支払いゲートウェイ| --> 手数料支払いを処理
+------------------+
🚨 一般的なミス:アクターをシステム境界内に描くこと — これはアクターがシステムの一部であると誤解を招くため、実際にはそうではない。

この図はVisual Paradigm AIチャットボットによって生成されました:

| 落とし穴 | なぜ間違っているのか | どう修正するか |
|---|---|---|
| 🚫 アクターの複雑化 | 役割をグループ化せずに、多すぎるアクター(例:「ジョン・ドー」、「サラ・スミス」)を作成すること | 類似した役割をグループ化する(例:「学生」、「教職員」) |
| 🚫 曖昧なユースケースの使用 | 「データを管理する」、「何らかの処理を行う」などの表現 | 具体的で目的指向の表現に置き換える(例:「コース登録を提出する」) |
| 🚫 依存関係の欠落 | 一つのユースケースが別のユースケースに依存していることを示さないこと | 追加するincludeまたはextend必要に応じて関係を追加 |
| 🚫 ‘extend’の誤用 | 使用する拡張する通常のワークフロー用 |
使用する含める必須手順用;使用する拡張するオプションや条件付きのものにのみ |
| 🚫 外部システムを無視する | 決済ゲートウェイ、メールなどは含まない | すべての外部システムを特定し、それらの相互作用を示す |
| 🚫 1つのアクターのみを使用する | システムを使用するのは1人のユーザーであると仮定する | すべてのステークホルダーとそのニーズを特定する |
| 🚫 技術用語を使用する | 例:「データベースを更新する」、「APIを呼び出す」 | 機能的な動作に留まる——「リクエストを送信する」の方が良い |
| 実践 | 説明 |
|---|---|
| ✅ ビジネス目標から始める | 上から下へモデル化する——戦略的目標と一致させる |
| ✅ ステークホルダーを早期に参加させる | ユースケースを検証するために、最終ユーザーまたはドメイン専門家にインタビューする |
| ✅ ユースケースを独立させ続ける | 各ユースケースは、単一で明確な目標を表すべきである |
| ✅ 実際のシナリオを使用する | ユースケースを実際のユーザーの行動に基づく(例:学生が授業に登録する) |
| ✅ チームと検証する | 開発者、テスト担当者、ビジネスアナリストと図をレビューする。 |
| ✅ 反復的に更新する | 要件が進化するにつれて、図を小さなサイクルで改善する。 |
| ✅ 使用ケースを詳細に文書化する | 事前条件、事後条件、成功/失敗基準を別ドキュメントに含める。 |
[30] 要件工学 – 使用ケースモデリングに関する基盤的なテキスト。
[27] ソフトウェア要件における使用ケースの特定 – エイクターから使用ケースを導出するための実用的手法。
[16, 40] – 要件工学およびシステム設計に関する包括的な文献。
IEEE/ISO規格: ISO/IEC 29148 – 使用ケース仕様のガイドライン。
おすすめの書籍:
ソフトウェア要件:最初から正しくする イアン・スプロール著
統合ソフトウェア開発プロセス(RUP) – UMLにおける使用ケースモデリングを紹介
会員
図書館員
管理者
オンラインカタログシステム
決済ゲートウェイ
会員:
本を借りる
本を返す
本を検索する
会員状態を確認する
図書館員:
本を貸し出す
本を返却する
本の記録を更新する
延滞リストを生成する
管理者:
新規本を追加する
ユーザーアカウントを管理する
年次レポートを生成する
オンラインカタログシステム:
本を検索する
会員に新入荷を通知する
決済ゲートウェイ:
罰金を処理する
更新料を処理する
会員 → 借りる → 含む → 返却
図書館員 → 貸し出し → 更新 → 逾期時にお知らせを送信
管理者 → 本を追加 → 含む → カタログを更新
この図は、誰が何をし、何ができるか、そしてシステムがどのように相互作用するかを明確に示しています。
✅ 関連するすべてのアクターを特定しましたか?
✅ ユースケースは記述的で目的志向になっていますか?
✅ すべてのアクターが少なくとも1つのユースケースに接続されていますか?
✅ 依存関係(include/extend)が正しくモデル化されていますか?
✅ キャラクターやユースケースが欠けていないか確認しましたか?
✅ 図は読みやすく、理解しやすいですか?
✅ ステークホルダーと確認しましたか?
作成するにはユースケース図単なる線とボックスを描くこと以上です——それは戦略的なプロセスが必要とされるユーザーのニーズに対する深い理解, 言語の明確さ、および細部への注意.
図はシンプルに見えるかもしれませんが、キャラクターおよびユースケースの誤用システム設計の質の低下、要件の漏れ、ユーザーの不満を引き起こします。このガイドの手順に従うことで——現実世界の質問を通じてキャラクターを特定し、キャラクターのニーズからユースケースを導出し、一般的な落とし穴を避ける——正確で実行可能でステークホルダーと整合性のあるユースケース図を作成できます。
✅ 忘れないで:良いユースケース図は物語を語る——ユーザーがシステムとどのようにやり取りして目標を達成するかという物語です。