Zenn
🙆‍♀️

ユースケースドリブン型要件定義プロセス ⚙️

2024/12/15に公開
ユースケース
システム開発
要件定義
tech

システム開発の要件定義フェーズでは、ユーザーがシステムをどのように使うかを明確化するためにユースケースドリブン型（Use Case Driven）アプローチが有効です。特に社内システムや業務アプリケーションのように、アクター（ユーザーの役割）が明確で、ビジネスプロセスに基づいた操作フローが重視されるプロジェクトとの相性が良いです。

🏷️ どんなときに採用される？

  1. 業務アプリケーション開発（BtoB、基幹システムなど）

    • 現場業務の手順や承認フローが複雑で、関係部署・ユーザー権限が明確に分かれている
    • 既存業務をシステム化する際に、一連の「業務フロー」を可視化しながら要件を固めたい

  2. 受託開発で顧客の要望を吸い上げる場合

    • ビジネス側から「こんな業務を効率化したい」「このプロセスをIT化したい」という要望を受け取り、それをユースケースに落とし込む

  3. 複数アクター（担当者 / 管理者 / マネージャーなど）が関わる複雑なシステム

    • ロール（役割）ごとに操作権限や閲覧範囲が違う
    • 個々のアクターが何をしたいかをユースケースとして定義することで、抜け漏れ・二重定義を防ぐ

業務アプリケーションでは、**エンドユーザー向け（個人消費者向け）**とは異なり、複数ロールの操作フローや承認プロセス、帳票出力、運用・保守観点などをより細かく定義する必要があります。ユースケースドリブン型は、こうした業務要件を整理するのに適しています。

🏁 全体フロー

以下のようなフェーズを経て、ユースケースドリブン型の要件定義を進めます。
各フェーズでアクター視点を常に意識し、最終的に画面要件、非機能要件、システム構成図まで一貫して落とし込みます。

ポイント:

  • アクターを明確化（担当者や管理者など、業務ロールを重視）
  • ユースケース間の共通処理は include、オプション処理は **extend**で表現
  • バッチ・帳票・非機能面まで抜け漏れなく定義

1️⃣ ユースケース一覧を作成 💡

目的
業務要件ヒアリングやビジネス企画書をもとに、どんな利用シナリオ（ユースケース）があるかを洗い出す。複数の業務ロール（例：営業担当、経理担当、管理者など）を正確に捉えるのがポイント。

活動内容

  • ユースケース名、アクター（ロール）、概要、優先度をまとめる
  • 内部ロジックやUIデザインはまだ考慮せず、「業務フロー」視点で必要な操作を網羅

成果物：ユースケース一覧表（例）

| ID     | ユースケース名       | アクター           | 概要                                            | 優先度 |
|:------:|:--------------------|:------------------|:----------------------------------------------|:------|
| UC-001 | ログイン             | 一般社員、管理者     | ユーザー認証を行い、システムにログインする                       | High   |
| UC-002 | 顧客マスタ登録       | 営業担当           | 新しい顧客情報をマスタに登録し、更新・削除も行う                  | High   |
| UC-003 | 受注登録             | 営業担当、管理者     | 商品を受注登録し、在庫を引き当てる                             | High   |
| UC-004 | 受注承認             | 管理者             | 受注情報を承認し、請求書発行フローへ進める                      | Medium |
| UC-005 | 請求書作成           | 経理担当           | 承認済み受注に対して請求書を作成し、PDFとして出力する              | Medium |
| UC-006 | 日次集計バッチ実行    | システム管理者       | 受注情報から売上集計を行うバッチを実行し、レポートを生成する         | Low    |

2️⃣ ユースケースフロー化 🔄

目的
アクター（ユーザー）がシステムをどのように利用し、ユースケース間での共通部分や条件付きの追加操作を整理することで、複雑な業務フローを視覚的に把握する。

include と extend の例（ユーザー目線）

  • include: 「ユーザーが行う共通操作」を別ユースケースとして抽出し、複数ユースケースで再利用

    • 例）「受注登録」でユーザーが行う「顧客情報選択UC」をinclude
      （「顧客情報選択UC」は他のユースケースでも利用可能）

  • extend: 「ユーザーの操作に応じて条件付きで発生する追加の操作」

    • 例）「受注登録UC」で、在庫不足が発生した場合にユーザーが実施する「在庫アラート確認UC」をextend
      （通常の受注登録操作に条件付きで追加）

活動内容

  • ユースケース図を描き、業務アプリ特有のアクター（営業、経理、管理者など）がどのようにシステムを操作するかを示す
  • ユーザーの視点からinclude（共通操作）やextend（条件付き追加操作）を整理
  • フローチャートやシーケンス図を合わせて作成し、詳細化する

ユースケース図（概略例）

  • UC-002a: 顧客情報選択 は、複数ユースケースで共通して実施される操作（include）
  • UC-003a: 在庫アラート確認 は「受注登録UC」の追加操作として定義（extend）

3️⃣ ユースケース詳細化（画面中心）📝

目的
ユースケース図（含むinclude / extend関係）で把握した処理の流れを、画面操作シナリオとして文章化。業務アプリでは権限や承認フローも加わるため、基本フローだけでなく例外パターンや承認ルートもきちんと定義する。

活動内容

  • ユースケースごとに「基本フロー」「例外フロー」「承認フロー」
  • 画面ID、入力項目、エラーメッセージ、承認状態の遷移などを詳述
  • includeユースケースはサブフローとして呼び出し手順を記載
  • extendユースケースは条件分岐として示す

成果物：ユースケース詳細仕様書

例：ユースケース詳細（UC-003 受注登録）

UC-003: 受注登録

アクター: 営業担当 (ROLE_SALES), 管理者 (ROLE_ADMIN)

【基本フロー】
1. 受注登録画面(SCR-ORDER)を開く
2. 顧客ID、商品ID、数量などを入力
3. 「登録」ボタン押下
4. [include] 権限チェック(UC-001a)を呼び出す
   - 営業担当 or 管理者ロール以外ならエラー
5. 在庫を引き当てる (PROC-ALLOCATE)
6. 受注情報をDB登録し、ステータスを「登録待ち」にする
7. 正常完了メッセージを表示

【extendフロー】
- 在庫不足の場合 → 「UC-003a: 在庫アラート表示」を実行
  - アラート画面(SCR-ALERT)に不足商品のリストを表示
  - 承認申請ボタン押下で承認フローへ進む

【画面ID】:
- SCR-ORDER（受注登録画面）
- SCR-ALERT（在庫アラート画面）

【終了条件】:
- 受注情報がDB登録 & ステータス更新
- extendフローが発生した場合、承認申請 or キャンセル

4️⃣ バッチ・帳票の整理 ⏲️📝

目的
オンライン操作以外で必要となる処理（バッチ）や、帳票（PDF、CSV等）を洗い出し、実行スケジュールやフォーマットを明確にする。基幹システムや社内業務アプリで重要な部分をカバー。

活動内容

  • バッチ一覧（ID、実行タイミング、概要）
  • 帳票一覧（ID、出力条件、フォーマット）
  • どのユースケースと関連するか（請求書作成UCなど）を紐づけ

成果物：バッチ一覧 / 帳票一覧

#### バッチ一覧
| バッチID | 名称                  | 実行タイミング     | 概要                                           |
|:-------:|:---------------------|:-----------------|:----------------------------------------------|
| BAT-001 | 日次売上集計バッチ     | 毎日深夜3時       | 受注承認UCで確定された受注情報を集計し、売上レポートを作成   |

#### 帳票一覧
| 帳票ID   | 帳票名                | 出力トリガー                        | フォーマット |
|:-------:|:---------------------|:-----------------------------------|:-----------|
| RPT-001 | 顧客リストCSV出力      | 顧客検索結果一覧画面で「CSV出力」ボタン | CSV        |
| RPT-002 | 受注請求書PDF         | 承認後の受注データ確定時に自動生成         | PDF        |

5️⃣ 画面要件定義 🖥️

目的
ユースケース詳細から抽出した各画面の入出力項目、権限制御、イベント処理を具体化。業務アプリの場合、ユーザー権限による表示制御が多いのが特徴。

活動内容

  • 画面ID、画面名、バリデーション、イベント
  • 権限（例：管理者のみアクセス可）
  • エラーメッセージ表示ルール

成果物：画面要件定義書

##### 画面要件（SCR-ORDER）
| 画面ID     | SCR-ORDER                |
|:---------:|:-------------------------|
| 画面名      | 受注登録画面               |
| 入力項目    | 顧客ID(必須), 商品ID(必須), 数量(必須), 備考(任意) |
| バリデーション | 数量 > 0, 文字数チェック(備考最大100文字)         |
| ボタン・イベント | 「登録」ボタン → PROC-ALLOCATE呼び出し → SCR-CONFIRMへ遷移 |
| 権限制御    | 営業担当 or 管理者のみ操作可        |
| エラー表示   | 在庫不足の場合はエラーコードとダイアログ表示      |

6️⃣ UIデザインの策定 🎨

目的
画面要件を踏まえ、業務効率や入力のしやすさを重視したUI/UXを設計する。BtoC向けアプリとは異なり、社内ユーザーが使いやすい配置・色合い・コンポーネントを優先。

活動内容

  • 画面レイアウト（テーブル表示、入力フォーム配置など）
  • スタイルガイド（カラー、フォント、アイコン）
  • モックアップ / プロトタイプ作成（Figma, XD等）

成果物

  • デザインモックアップ
  • スタイルガイド
  • 簡易プロトタイプ（操作検証用）

7️⃣ ビジネスロジックの処理定義 ⚙️

目的
画面やバッチが呼び出す内部処理（ビジネスロジック）を定義。業務アプリではマスタ登録・承認処理・在庫管理などの複雑なロジックが多いため、入念に整理する。

活動内容

  • 処理IDごとに入出力パラメータ、DBアクセス、外部API、例外ハンドリング
  • include / extendと連動するロジックも追記

成果物：処理定義書

##### 処理定義（PROC-ALLOCATE: 在庫引当処理）

| 処理ID         | PROC-ALLOCATE                      |
|:--------------:|:-----------------------------------|
| 呼び出し元       | SCR-ORDER画面「登録」ボタン              |
| 入力           | { orderId, itemId, quantity }      |
| 出力           | 更新後の在庫数 or エラーステータス         |
| ロジック概要     | 1. 入力パラメータを検証<br>2. 在庫テーブルを更新<br>3. 在庫不足時はエラー返却 |
| エラー制御       | DB障害時に例外スロー<br>在庫不足時に専用エラーコード |
| 関連ユースケース | UC-003(受注登録), extend: UC-003a(在庫アラート)      |

8️⃣ 非機能要件の策定 🛡️

目的
性能（レスポンスタイム、同時接続数）、セキュリティ（認証、暗号化）、可用性（稼働率、バックアップ）などを定義。業務アプリではログ管理や監査要件も重要。

活動内容

  • パフォーマンス要件（同時ログイン数、トランザクション量）
  • セキュリティ要件（LDAP/AD認証、HTTPS通信必須、WAF導入など）
  • 運用要件（障害発生時の連絡フロー、監査証跡、バックアップ頻度）

成果物：非機能要件定義書

##### 非機能要件の例

| 分類        | 要件                                           |
|:----------:|:----------------------------------------------|
| 性能        | 同時アクセス: 営業担当100人、管理者10人を想定。画面操作は3秒以内に応答  |
| セキュリティ | LDAP/AD認証必須、HTTPS通信必須、WAF導入検討                |
| 可用性      | 稼働率99.9%以上、フェイルオーバー構成、日次バックアップ           |
| 運用        | 操作ログをSYSLOGへ出力、監査要件に応じて6ヶ月保存              |

9️⃣ システム構成図 🗺️

目的
業務アプリのインフラ構成を確定。オンプレ / クラウド / ハイブリッドなどを検討し、関連システムやネットワーク、監視方法などを統合設計する。

活動内容

  • ネットワーク構成（VPN/専用線 / ゼロトラストなど）
  • サーバー群（アプリサーバ、DBサーバ、バッチサーバ）
  • ログ基盤、冗長化構成、バックアップ設計

成果物：システム構成図

🔟 要件定義完了 🎉

最終成果物一覧

  1. ユースケース関連

    • ユースケース一覧（include / extendを含むユースケース図）
    • ユースケースフロー図・シーケンス図
    • ユースケース詳細仕様書

  2. バッチ・帳票関連

    • バッチ一覧表
    • 帳票仕様書（出力タイミング、フォーマット）
    • 実行スケジュール定義

  3. 画面関連ドキュメント

    • 画面要件定義書
    • 画面遷移図 / 画面構成表
    • 入力項目定義書 / 権限制御一覧

  4. UIデザイン関連

    • デザインモックアップ
    • スタイルガイド
    • プロトタイプ

  5. 処理定義関連

    • ビジネスロジック仕様書（処理ID、入出力、DB・API連携）
    • DB設計書
    • API仕様書
    • エラー処理設計書

  6. 非機能要件関連

    • 性能要件定義書（スループット、レスポンスタイム、同時アクセス数）
    • セキュリティ要件定義書（認証 / 権限管理、監査ログ）
    • 可用性要件定義書（運用監視、バックアップ、DRサイト）
    • 運用・保守要件定義書

  7. システム構成関連

    • システム構成図（オンプレ / クラウド / ハイブリッド）
    • ネットワーク構成図（VPNなど）
    • 監視・バックアップ設計書
    • 環境定義書（ステージング・本番などの構成差分）

これらが整合性を持ち、全ステークホルダー（業務担当者・管理者・ITチームなど）の合意を得た時点で要件定義フェーズ完了となります。

✅ まとめ

ユースケースドリブン型の要件定義は、アクターを中心に業務プロセスを整理する方法として特に社内業務アプリやBtoBシステムに適しています。

  • include で共通処理を集約し、
  • extend で例外的または任意の処理を別ユースケースとして追加する
    ことで、開発初期から業務フローを抜け漏れなくカバーできます。

最終的に仕上がるドキュメントは、基本設計・詳細設計・テストシナリオへとスムーズに引き継がれ、プロジェクト全体の品質向上に寄与します。特に業務ロールや承認フローを事前に明確化しておくと、実装段階や運用段階での手戻りを最小限に抑えることができます。

ぜひ、あなたの業務アプリ開発プロジェクトにも取り入れてみてください。✍️✨

Discussion