ユースケース図とユースケース記述の実践 – システム機能を漏れなく定義する

「要件定義で『機能の漏れ』を指摘されて、夜中まで修正作業…」

そんな経験、ありませんか?

45歳のあなたが20年間培ってきたプログラマ経験は、確かに貴重な資産です。しかし、上流工程では「実装できる」だけでなく、「システムに必要な機能を漏れなく洗い出せる」能力が求められます。

「ユースケース図って、若手の頃に聞いたことはあるけど、実際には使ったことがない…」「UMLは難しそうで、今さら学ぶ意味があるのか?」——その不安、よくわかります。

でも、安心してください。ユースケース図は、あなたが持つ「ユーザー視点で考える力」を形にする、最もシンプルで強力なツールです。プログラマとしての経験があるからこそ、「このアクターがこの機能を使う」という構造を、若手より深く理解できるのです。

この記事では、通勤時間30分+夜の30分=1日1時間で、2週間後にはユースケース図を使った機能定義ができるようになる、実践的なステップをお伝えします。完璧なUML記法を覚える必要はありません。まずは「機能漏れをなくす」という目的に集中しましょう。

---

ユースケース図が上流工程で必須スキルになった理由

結論

ユースケース図は、顧客とエンジニアをつなぐ「共通言語」として、上流工程で不可欠なツールです。

理由

現代のシステム開発では、顧客の要望が複雑化・多様化しています。「こんな機能が欲しい」という漠然とした要求から、システムに必要な機能を漏れなく、重複なく洗い出す能力が、上流工程のエンジニアに求められています。

ユースケース図を使えば、以下の3つが可能になります:

1. 誰が(アクター)、何を(ユースケース)するのかを可視化できる
2. 機能の抜け漏れを顧客と一緒にチェックできる
3. 開発優先順位を決める際の判断材料になる

特に、要件定義からシステム設計まで担当するポジションでは、「ユースケース図を描いて、顧客と合意を取る」スキルが、年収650万円以上のオファーを得る分岐点になります。

具体例

46歳でSIerからWeb系企業のシステムアナリストに転職したHさんは、こう語ります。

「面接で『ECサイトのユースケース図を描いてください』と言われました。ホワイトボードに『購入者』『管理者』『決済システム』をアクターとして描き、『商品検索』『カート追加』『決済処理』といったユースケースを洗い出したところ、『実装経験があるからこそ、現実的な機能分割ができている』と評価されました。年収は520万円から670万円に上がりました」

ユースケース図を描けることは、単なる図の知識ではなく、システム全体を俯瞰して設計できる力の証明なのです。

まとめ

ユースケース図は、上流工程への扉を開く最初の鍵です。今日から学習を始めることで、2週間後には顧客との要件確認で自信を持って使えるようになります。

---

ユースケース図の基本構成要素を理解する

結論

ユースケース図は、たった3つの要素で構成されています。複雑に見えても、本質はシンプルです。

理由

多くの人が「UMLは難しい」と感じるのは、完璧な記法を覚えようとするからです。しかし、実務では「伝わる図」が描ければ十分です。

ユースケース図の構成要素は以下の3つだけ:

1. アクター(Actor):システムを利用する人や外部システム
2. ユースケース(Use Case):アクターが実行する機能や処理
3. 関連(Association):アクターとユースケースを結ぶ線

この3つを理解すれば、今日からユースケース図が描けます。

具体例

ECサイトの基本的なユースケース図

[アクター:購入者] ---- (商品を検索する)
[アクター:購入者] ---- (商品をカートに追加する)
[アクター:購入者] ---- (注文を確定する)
[アクター:管理者] ---- (商品を登録する)
[アクター:管理者] ---- (在庫を管理する)

このように、棒人間(アクター)と楕円(ユースケース)を線で結ぶだけです。

3つの要素の詳細

1. アクター(Actor)

• 人間だけでなく、外部システムもアクターになる
• 例:「購入者」「管理者」「決済システム」「在庫管理システム」

2. ユースケース(Use Case)

• アクターの視点で「〜する」という動詞で表現
• 例:「商品を検索する」「注文を確定する」

3. 関連(Association)

• アクターとユースケースを結ぶ単純な線
• 矢印は不要(双方向の関係だから)

まとめ

ユースケース図の基本は、アクター、ユースケース、関連の3つです。まずはこの3つだけを使って、簡単な図を描いてみましょう。

---

システムの境界を定義する – スコープを明確にする技法

結論

システムの境界を明確にすることで、「どこまで作るか」を顧客と合意できます。

理由

要件定義の失敗の多くは、「システムの範囲」が曖昧なまま進んでしまうことが原因です。

ユースケース図では、システム境界を四角い枠で囲むことで、「このシステムが提供する機能」と「外部システムに任せる機能」を明確に区別できます。

これにより、以下のメリットがあります:

1. スコープの拡大を防げる(追加要望を整理できる)
2. 外部システムとの連携ポイントが明確になる
3. 開発工数の見積もり精度が上がる

具体例

システム境界の描き方

┌─────────────────────────┐
│   ECサイトシステム          │
│                           │
│  (商品を検索する)           │
│  (商品をカートに追加する)    │
│  (注文を確定する)           │
│  (在庫を確認する)           │
│                           │
└─────────────────────────┘
     ↑                  ↑
  [購入者]          [決済システム]

この図を見れば、「ECサイトシステムは注文確定までを担当し、決済は外部システムに委ねる」ことが一目で分かります。

境界を明確にする質問例

顧客との要件確認で、以下の質問をしてください:

• 「この機能は、このシステムで実装しますか? それとも既存システムを使いますか?」
• 「外部システムとの連携は、どのタイミングで発生しますか?」
• 「この処理は、システム内で完結しますか? それとも人手での確認が入りますか?」

まとめ

システム境界を定義することで、「何を作るか」だけでなく「何を作らないか」も明確になります。これが、上流工程で求められる「スコープ管理能力」です。

---

ユースケース記述で機能の詳細を定義する

結論

ユースケース図だけでは不十分です。各ユースケースの詳細を「ユースケース記述」で文書化しましょう。

理由

ユースケース図は「何があるか」を示すだけで、「どう動くか」は分かりません。開発チームが実装するには、以下の情報が必要です:

1. 事前条件:このユースケースが実行される前提
2. 基本フロー:正常系の処理手順
3. 代替フロー:エラー時や例外時の処理
4. 事後条件:このユースケースが完了した後の状態

これらを「ユースケース記述」として文書化することで、開発者が迷わず実装できる仕様書になります。

具体例

ユースケース記述の例:「商品をカートに追加する」

ユースケース名:商品をカートに追加する

アクター:購入者

事前条件:

• 購入者がログインしている
• 商品詳細ページを表示している

基本フロー:

1. 購入者が「カートに追加」ボタンをクリックする
2. システムは在庫を確認する
3. 在庫がある場合、カートに商品を追加する
4. システムは「カートに追加しました」というメッセージを表示する

代替フロー:

• 3-a. 在庫がない場合
  • 3-a-1. システムは「在庫切れです」というメッセージを表示する
  • 3-a-2. ユースケース終了

事後条件:

• カートに商品が追加された状態になる
• カートの商品数が1つ増える

ユースケース記述の書き方のコツ

• 主語を明確にする:「購入者が〜する」「システムが〜する」
• 曖昧な表現を避ける:「適切に」「うまく」といった言葉は使わない
• 代替フローは具体的に:「エラーが発生した場合」ではなく「在庫がない場合」

まとめ

ユースケース記述は、図だけでは伝わらない「処理の詳細」を明確にします。これにより、開発者が迷わず実装でき、テスト設計もスムーズになります。

---

include関係とextend関係を使った機能の整理

結論

複雑なシステムでは、ユースケース同士の関係を整理することで、図の可読性が向上します。

理由

実務のシステムでは、ユースケースが10個、20個と増えていきます。すべてを並列に描くと、図が複雑になり、かえって分かりにくくなります。

そこで、以下の2つの関係を使って、ユースケースを整理します:

1. include関係:必ず実行される共通処理
2. extend関係:条件によって実行される追加処理

具体例

include関係:「注文を確定する」→「ログイン認証」

(注文を確定する) --<<include>>--> (ログイン認証)

「注文を確定する」ユースケースは、必ず「ログイン認証」を含みます。これをinclude関係で表現することで、「ログイン認証」の記述を1箇所にまとめられます。

extend関係:「商品を検索する」←「詳細検索」

(商品を検索する) <<--extend-- (詳細検索を使う)

「商品を検索する」ユースケースは、通常はキーワード検索ですが、条件によっては「詳細検索」が追加されます。これをextend関係で表現します。

include vs extend の使い分け

関係	意味	例
include	必ず実行される共通処理	「注文」→「ログイン認証」
extend	条件によって実行される追加処理	「検索」←「詳細検索」

まとめ

include/extend関係を使うことで、ユースケース図がシンプルになり、保守性が向上します。ただし、使いすぎると逆に複雑になるので、本当に必要な箇所だけに限定しましょう。

---

実践演習:会員管理システムのユースケース図を描く

結論

実際に手を動かして描くことで、初めてユースケース図が「使える」スキルになります。

理由

多くの学習者が陥る罠は「理解したつもり」で終わることです。ユースケース図は、実際に描いてみないと、細かな判断ポイントが分かりません。

特に、以下の3つは描いてみて初めて気づきます:

1. アクターの粒度:「ユーザー」で良いのか、「一般会員」「プレミアム会員」と分けるべきか
2. ユースケースの粒度:「会員登録」で良いのか、「仮登録」「本登録」と分けるべきか
3. 境界の引き方:メール送信は自システムか、外部システムか

具体例

演習課題:会員管理システム

以下の要件から、ユースケース図とユースケース記述を作成してください。

要件:

• 会員は、Webサイトから会員登録ができる
• 会員は、ログインして自分のプロフィールを編集できる
• 管理者は、会員情報を検索・閲覧できる
• 管理者は、不適切な会員を削除できる
• 会員登録時には、メールで認証コードが送信される

解答例(一部)

アクター:

• 会員(一般ユーザー)
• 管理者
• メール送信システム(外部)

ユースケース:

• 会員登録をする
• ログインする
• プロフィールを編集する
• 会員を検索する
• 会員を削除する

ユースケース記述例:「会員登録をする」

事前条件:会員は未登録の状態

基本フロー:

1. 会員がメールアドレスとパスワードを入力する
2. システムは入力をチェックする
3. システムはメール送信システムに認証コードを送信する
4. 会員が認証コードを入力する
5. システムは認証コードを確認し、会員登録を完了する

代替フロー:

• 2-a. メールアドレスが既に登録されている場合
  • 2-a-1. システムは「既に登録されています」と表示
  • 2-a-2. ユースケース終了

学習のポイント

描いてみると、以下のような疑問が湧いてきます:

• 「ログイン」はユースケースとして独立させるべき?
• 「メール送信」は内部処理? それとも外部システム?
• 「会員」と「管理者」は別のアクターにすべき?

**これらの疑問こそが、あなたの設計力を高めます。**正解は1つではありません。顧客やチームと議論しながら、最適な粒度を見つける経験が重要です。

まとめ

理論を学んだら、必ず自分で描いてください。小さなシステムでも構いません。「描く→疑問が出る→調べる→また描く」のサイクルが、実務レベルのスキルを作ります。

【おすすめ学習ツール】

• draw.io:無料で使えるオンライン作図ツール。ユースケース図のテンプレートあり
• Notion:ユースケース記述を整理・管理するのに最適。無料プランでも十分使えます

---

ユースケース図から基本設計へつなぐ方法

結論

ユースケース図は、要件定義だけでなく、基本設計(外部設計)の出発点にもなります。

理由

多くの人が誤解しているのは、「ユースケース図は要件定義で終わり」という思い込みです。実際には、ユースケースから画面設計、データ設計、インターフェース設計へと自然につながります。

以下のように展開できます:

1. ユースケース → 画面設計:各ユースケースに対応する画面を設計
2. ユースケース → データ設計:ユースケースで扱うデータを洗い出し、ERダイアグラムに展開
3. ユースケース → API設計:ユースケースを実現するためのAPI仕様を定義

具体例

ユースケース「商品をカートに追加する」からの展開

1. 画面設計への展開

• 商品詳細画面に「カートに追加」ボタンを配置
• カート一覧画面で、追加した商品を表示

2. データ設計への展開

• 必要なテーブル:
  • 商品マスタ(product)
  • カート(cart)
  • カート明細(cart_item)

3. API設計への展開

• API:POST /api/cart/items
• リクエスト:{ "product_id": 123, "quantity": 1 }
• レスポンス:{ "cart_id": 456, "total_items": 3 }

このように、ユースケースを起点にすることで、設計の一貫性が保たれます。

まとめ

ユースケース図は、要件定義から基本設計へのブリッジです。この流れを理解することで、上流工程全体を見通せるようになります。

---

実務でよくある失敗パターンと対策

結論

ユースケース図の失敗パターンを知ることで、同じ過ちを避けられます。

理由

初心者が陥りがちな失敗は、以下の3つです:

1. 粒度が細かすぎる/粗すぎる
2. アクターの設定ミス
3. 境界の曖昧さ

これらを事前に知っておくことで、最初から質の高い図が描けます。

具体例

失敗パターン1:粒度が細かすぎる

悪い例:

• (メールアドレスを入力する)
• (パスワードを入力する)
• (登録ボタンをクリックする)

良い例:

• (会員登録をする)

対策:ユースケースは「アクターにとって価値がある単位」で切る。細かすぎる操作は、ユースケース記述の基本フローに書く。

失敗パターン2:アクターの設定ミス

悪い例:

• アクター:「データベース」「サーバー」

良い例:

• アクター:「購入者」「管理者」「決済システム」

対策:アクターは「システムの外部にいる存在」。内部のコンポーネント(DB、サーバー)はアクターではない。

失敗パターン3:境界が曖昧

悪い例:

• システム境界を描かずに、すべてのユースケースを並べる

良い例:

• システム境界を四角で囲み、外部システムは境界の外に配置

対策:最初に境界を明確にし、「このシステムが提供する機能」と「外部に任せる機能」を区別する。

まとめ

失敗パターンを知ることで、最初から質の高いユースケース図が描けます。特に「粒度」の判断は経験が必要ですが、「アクターにとって価値があるか?」を基準にすると迷いません。

---

学習を継続するための「3つの実践ステップ」

結論

ユースケース図は、実務で使い続けることで初めて「自分のスキル」になります。

理由

多くの学習者が、「理解した」で満足してしまいます。しかし、上流工程で求められるのは、**「顧客の前で、ホワイトボードに即座にユースケース図を描ける力」**です。

そのためには、以下の3つの実践ステップを継続してください。

具体例

ステップ1:既存システムを分析する(毎週30分)

• 普段使っているWebサービス(Amazon、楽天、メルカリ等)のユースケース図を描いてみる
• 「このサービスのアクターは誰か?」「どんなユースケースがあるか?」を洗い出す

ステップ2:業務システムの要件をユースケースで整理する(月1回)

• 現在の業務で「こんなシステムがあったらいいな」と思う機能を、ユースケース図で描いてみる
• 同僚に見せて、「機能の漏れがないか」をレビューしてもらう

ステップ3:ポートフォリオに追加する(3ヶ月に1回)

• 作成したユースケース図とユースケース記述を、GitHubやNotionにまとめる
• 転職活動で「要件定義の経験」として提示できる資料にする

まとめ

ユースケース図は、「描く→フィードバックをもらう→改善する」のサイクルで上達します。小さくても良いので、毎週1つずつ描き続けましょう。

【学習管理におすすめ】

• Notion:ユースケース記述をテンプレート化して管理できます
• Udemy – UML実践講座:ユースケース図だけでなく、クラス図、シーケンス図も体系的に学べます

---

今日から始める3つの行動

結論

この記事を読んだ「今」が、上流工程エンジニアへの第一歩を踏み出す最後のチャンスです。

理由

ユースケース図という武器を手に入れることで、あなたの市場価値は確実に上がります。しかし、「いつかやろう」では、何も変わりません。

以下の3つの小さな行動から、今日始めてください。

具体例

ステップ1:無料作図ツールを試す(所要時間:10分)

**draw.io**にアクセスし、ユースケース図のテンプレートを開いてください。簡単なログイン機能のユースケース図を、5分で描いてみましょう。

ステップ2:Udemy講座を1つ購入する(所要時間:10分)

「いつか買おう」ではなく、今すぐ購入してください。セールなら1,200円程度です。購入した瞬間、あなたの学習は「本気」に変わります。

おすすめ:Udemy – UML実践講座
ユースケース図、クラス図、シーケンス図を体系的に学べます。

ステップ3:今の業務を1つ、ユースケース図で描く(所要時間:30分)

今夜、現在の業務(または過去のプロジェクト)を1つ選び、ユースケース図を描いてください。完璧でなくて構いません。「誰が」「何をする」を洗い出すだけで、要件定義の視点が身につきます。

まとめ

この3つのステップは、それぞれ1日で完了できます。つまり、3日あればユースケース図の基礎が身につき、上流工程への扉が開くのです。

【今すぐ始める学習セット】

• Udemy – UML/ユースケース図講座:セール時なら1,200円〜。実践的な演習が豊富
• Kindle Unlimited:30日間無料体験。UML関連の技術書が通勤時間に読めます
• Notion:ユースケース記述をテンプレート化して管理。無料プランで十分使えます

---

まとめ

ユースケース図習得ロードマップの全体像

第1週:基本要素の理解
→アクター、ユースケース、関連を理解し、簡単な図を描く

第2週:ユースケース記述の作成
→基本フロー、代替フローを文書化する練習

第3週:実践演習
→既存システムや業務をユースケース図で表現してみる

第4週:基本設計への展開
→ユースケースから画面設計、データ設計へつなぐ

2ヶ月後:ポートフォリオ作成
→オリジナルのユースケース図と記述を、転職活動で提示できる形にまとめる

最後に:45歳のあなたへ

「要件定義は若手がやるもの」——その思い込みは、今日で捨ててください。

あなたには20年の開発経験があります。その経験こそが、「このユースケースを実装するのに、どんな処理が必要か」を深く理解する武器になります。若手が図を描いている間に、あなたは「なぜこの粒度で切るのか」を説明でき、顧客の信頼を得られるのです。

行動しなければ、何も変わりません。

でも、今日draw.ioで1つ図を描き、今夜30分だけユースケース記述を書けば、明日のあなたは「昨日より上流工程に近づいたエンジニア」になっています。

2週間後、あなたは「ユースケース図で要件を整理できるエンジニア」として、年収650万円以上のオファーを手にしているはずです。

その第一歩を、今日、踏み出しましょう。

【今日から始める学習セット – 最後のご案内】

• Udemy講座:セール中なら1,200円〜。ユースケース図から上流スキルまで幅広くカバー
• Kindle Unlimited:30日間無料体験。UML関連の技術書が通勤時間に読めます
• Notion:学習ログと進捗管理に最適。無料プランでも十分使えます
• Lucidchart:ユースケース図作成に特化したツール。チームでの共同編集も可能

関連記事

クラス図とシーケンス図の実践 – UMLで表現するオブジェクト設計
ユースケースを理解したら、次は詳細設計のUMLを学びましょう。

処理フロー設計とアルゴリズム仕様化 – フローチャートから擬似コードまで
ユースケース記述から、さらに詳細な処理フローへ展開する方法を学べます。

---