ユースケース駆動開発とは？ICONIXの4工程とユースケース記述の書き方・ロバストネス分析を解説

ユースケース駆動開発は、利用者がシステムで達成したい目的を1本ずつ文章に書き、その文章から設計・コード・テストまでを導く開発の進め方です。本記事では、『ユースケース駆動開発実践ガイド』（翔泳社、2007年）で紹介された ICONIX プロセスを中心に扱います。

この記事では、ICONIX の4工程、ユースケース記述で避ける誤り、ロバストネス図の接続ルールを原典に沿って整理し、代替コースをテストへ落とす実装例と Spec Kit との対応まで扱います。

まとめ：ユースケース駆動開発の要点

• ICONIX プロセスは、ドメインモデル・ユースケース図・ロバストネス図・シーケンス図の4種類の図だけで、ユースケース記述からコードまで到達させます。
• 出発点はドメインモデルです。原著は第2章の節タイトルに「なぜユースケースではなくドメインモデルから始めるのか」を掲げています。
• ユースケース記述は具体的に書きます。画面名を出し、利用者の操作とシステムの応答を能動態で対にし、見出しは基本コースと代替コースの2つだけにします。
• 中核はロバストネス分析です。記述を1文ずつ「バウンダリ・コントロール・エンティティ」の図に描き直し、描けない箇所を記述の穴として書き直します。
• 代替コースはそのままテストケースになります。DDD とは担当範囲が違うため併用でき、Spec Kit を使う場合は曖昧さを詰める工程を任意のまま放置しないことが要点です。

ユースケース駆動開発とICONIXプロセスの定義

ユースケースの定義と1本の大きさ

ユースケースは、アクター（利用者や外部システム）がシステムを使って達成する目的を1つ選び、達成までのやり取りを文章にしたものです。「顧客を新規登録する」「書籍を検索する」といった単位で切ります。ビジネス用語としての「ユースケース（活用事例）」との違いや、記述項目の一般的なテンプレートはユースケースとは？ビジネスとUMLで異なる意味・記述の書き方とテスト連携を解説にまとめています。

ICONIX が想定する1本は小さく、原著第1章は数本の束を設計から単体テストまで一巡させる説明の中で「each use case is only a couple of paragraphs」（1本は2〜3段落ほど）と書いています。設計を駆動するのは図ではなく記述です。図の記法はユースケース図とは？UMLの書き方・アクターと関係・要件定義での使い方を解説で扱っています。

Jacobson の OOSE から ICONIX への流れ

ユースケースという概念は Ivar Jacobson が1987年の OOPSLA 論文「Object-Oriented Development in an Industrial Environment」で発表し、1992年刊行の OOSE（Object-Oriented Software Engineering: A Use Case Driven Approach）で体系化しました。これを最小限の手順に絞ったのが Doug Rosenberg の ICONIX プロセスです。

現在の定本は Doug Rosenberg と Matt Stephens の “Use Case Driven Object Modeling with UML: Theory and Practice”（Apress、2007年、ISBN-13 978-1-59059-774-3）で、目次と第1章は版元提供の試し読みPDFで読めます。邦訳が『ユースケース駆動開発実践ガイド』（翔泳社、2007年10月16日、512ページ）です。題材のインターネット書店を、ユースケースから Spring Framework の Java 実装と JUnit のテストまで1本の例で通しています。

図を4種類に絞る理由

原著 Introduction の「ICONIX の好きなところ トップ10」の第10位は「The process uses a core subset of UML.（We’d rather learn 4 diagrams than 14 . . .）」です。使う図は次の4種類で、それぞれが別の問いに答えます。

ICONIXプロセスの4工程と3つのレビュー関門

要求定義：ドメインモデル先行とユースケース初稿

最初に描くのはユースケースではなくドメインモデルです。原著は第3章でも「Do an Initial Domain Model Before You Write the Use Cases」と念を押しています。先に業務のモノの名前を固定しておけば、「顧客」「ユーザー」「アカウント」が同じものかで記述が揺れずに済みます。ただし完成させる必要はなく、原著のドメインモデリングの指針は初回を「a couple of hours」に抑えるよう勧めています。足りないクラスは後のロバストネス分析で足します。

並行して画面の簡易プロトタイプ（GUI ストーリーボード）を作り、実装するユースケースを洗い出して初稿を書きます。ここでマイルストーン1「要求レビュー」を通し、記述が顧客の期待と一致しているかを確かめます。原著はこのレビューを、設計に入る直前の小さな束ごとに行ってよいとしています。

分析・予備設計：ロバストネス分析による記述の書き直し

束の中のユースケース1本ごとにロバストネス図を描きます。原著の表現は「Draw a robustness diagram (an “object picture” of the steps in a use case), rewriting the use case text as you go」で、図を描きながら記述の方を書き直すのがこの工程の実体です。

同時に、ドメインモデルに漏れていたクラスを足し、属性（書籍ならタイトル・著者・あらすじ）を書き加え、ユースケースの成立に必要な処理（コントローラ）すべてに名前を付けます。ここでマイルストーン2「予備設計レビュー（PDR）」です。

詳細設計：シーケンス図による振る舞いの割り当て

シーケンス図はユースケース1本につき1枚です。原著は「The primary function of sequence diagramming is to allocate behavior to your classes」と書いており、目的は処理の流れを描くことではなくどのクラスにどの操作を持たせるかを決めることです。操作を書き足すにつれてドメインモデルは詳細設計のクラス図へ変わります。整理してマイルストーン3「クリティカル設計レビュー（CDR）」を通します。記法はシーケンス図とは？UMLの書き方とライフライン・複合フラグメント・Mermaid実装を解説を参照してください。

実装：単体テスト・シナリオテスト・モデル更新

コードと単体テストを書き（原著は先にテストを書いてもよいと注記し、第12章で「Design-Driven Testing」として扱う）、結合テストとシナリオテストを基本コースと代替コースの両方に紐づけ、最後に「Code Review and Model Update」でコードとモデルの食い違いを直して次の束へ進みます。

ユースケース記述の書き方：原著が挙げる10のガイドライン

原著第3章は記述のガイドラインを10項目にまとめ、さらに「describe system usage in the context of the object model」（オブジェクトモデルの文脈でシステムの使い方を書く）の一文に要約しています。一覧は著者によるThe Register の書籍抜粋（2007年11月23日）で読めます。

同じ考え方を誤りの側から並べたのが、Rosenberg と Kendall Scott が Software Development 誌2001年2月号に書いた「Top Ten Use Case Mistakes」です。「use case driven」を「Write the user manual, then write the code」と要約し、機能要求（〜しなければならない）を書く、属性やメソッドを書く、受動態で書く、といった10の誤りを挙げています。以下ではこの2つの一覧から、とくに効く3点を取り上げます。

画面名・対話の両側・能動態による具体的な記述

中心は「抽象的に書かない」ことです。2001年の記事は、記述はシステム境界の内側で起きること（オブジェクトの生成、入力の検証、エラーメッセージの生成）まで捉えるべきだとし、「your use case text describes both sides of the dialog between the user and the system」と書いています。画面名を早めに書くのは、次の工程のロバストネス分析でその画面（バウンダリ）の振る舞いを調べるからです。

原著の Preface も、抽象的で実装非依存のユースケースはプログラマには「vague, ambiguous, incomplete, and therefore incorrect」に見えると書いています。Methods & Tools 誌に掲載された Rosenberg・Stephens・Collins-Cope の記事に載っている「新規顧客の作成」は、この書き方の見本です。

ユースケース: 新規顧客の作成

基本コース:
  システムは既定値をいくつか埋めた状態で顧客詳細ページを表示する。
  利用者が詳細を入力し、作成ボタンを押す。
  システムは必須項目がすべて埋まっていることを検証する。
  システムは顧客名が一意であることを検証し、新しい顧客をデータベースに追加する。
  システムは利用者を顧客一覧ページへ戻す。

代替コース: 必須項目が埋まっていない
  システムはその旨を利用者に伝え、
  埋まっていない項目を赤で強調した顧客詳細フォームを再表示する。

代替コース: 同名の顧客が既に存在する
  システムはその旨を利用者に伝え、
  顧客詳細を編集するかキャンセルするかを選ばせる。

設計前の代替コースの洗い出し

2001年の記事は、重要な代替コースがコーディングやデバッグの段階まで見つからないと、担当プログラマが自分に都合のよい扱い方をしがちだと指摘しています。代替コースの洗い出しには「should take up the majority of the time」とも書いており、記述作業の大半を代替コースに使う前提です。別の例として、パスワード照合のあるログインなら「メールアドレスが見つからない」「パスワードが一致しない」の2本が最低限必要になります。

事前条件・事後条件の欄を省くICONIXのテンプレート

Alistair Cockburn や Larry Constantine のテンプレートは事前条件・事後条件などの欄を持ちます。2001年の記事はこれを米国の確定申告書になぞらえて「1040 long form」と呼び、ICONIX は見出しが基本コースと代替コースの2つだけの「1040EZ」型を勧めるとしています。ユースケース名が目的を表し、基本コースの中身が事前・事後条件を兼ねるという考え方です。

共通部分の切り出しも、UML の include と extend、OML の invoke と precede のどれでもよく、1つに決めて使い続けることが求められます。誤りの第1位は「Don’t spend a month deciding whether to use includes or extends.」です。要件定義の成果物を Cockburn 型のテンプレートで統一している組織では、ICONIX を持ち込む前にどちらの書式に寄せるかを先に決めてください。2つの書式が混在すると、記述の粒度がそろわずロバストネス分析が進みません。

ロバストネス図の3要素と接続ルール

バウンダリ・コントロール・エンティティの役割

ロバストネス図に登場するオブジェクトは3種類です。定義は前掲の Methods & Tools 記事によります。同記事はロバストネス図を、ユースケースを絵にしたもので分析と設計の「halfway」に位置すると説明しています。

この3分類は Jacobson の OOSE に由来し、当初は entity-interface-control と呼ばれていました。コントロールについて Scott と Rosenberg は Software Development 誌2001年3月号の「Successful Robustness Analysis」で「Once in a while (perhaps 20 percent of the time), controllers are “real objects” in a design」と書いています。2割は著者の概算で規則ではありませんが、コントロールが設計上のオブジェクトになるのは一部で、多くは機能の抜けを防ぐ置き場だという整理です。図をそのまま実装構造と読まないことが前提です。

接続してよい相手と禁止される組み合わせ

同じ「Successful Robustness Analysis」は「Four basic rules apply」として次の4規則を挙げ、覚え方を「Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs」と示しています。

バウンダリとエンティティはどちらも名詞なので直結できず、間に必ずコントロールが入ります。画面が直接テーブルを読み書きする設計は、そもそも線が引けません。エンティティ同士も同じ理由でつなげませんが、これはロバストネス図の規則で、ドメインモデルのクラス図にエンティティ間の関連を描くのは正当です。同記事によれば基本コースと全代替コースは1枚に収まるはずで、収まらなければユースケースが大きすぎます。

記述の1文を図の要素へ写す手順

作業は、記述を1文ずつ読み、名詞をバウンダリかエンティティ、動詞をコントロールに割り振ることです。「新規顧客の作成」の基本コースを写すと次のようになります。

この表を作る途中で「既定値」の中身が記述のどこにも無いと気づけば、たとえば「既定値として登録日と担当者を埋める」のように記述へ書き足します。図に写せない文、たとえば「適切に処理する」のような動詞は、どのコントロールにも割り当てられません。そこが書き直す箇所です。

線のつなぎ方は4規則どおりになります。アクターは顧客詳細ページ（バウンダリ）にだけつなぎ、顧客詳細ページから「必須項目を検証」へ、そこから「一意性を検証」へ進みます。「一意性を検証」と「顧客を保存」は顧客（エンティティ）につなぎ、保存のあとは「一覧を表示」を経て顧客一覧ページへ出ます。代替コースは、2つの検証コントロールから顧客詳細ページへ戻る線として同じ図に描き足します。

代替コースからテストを起こす：UseCaseクラスの実装例

UseCaseクラスとServiceクラスの使い分け

実装で迷いやすいのが UseCase クラスと Service クラスの線引きです。本記事の例では、利用者が達成したい目的1つを1つの UseCase クラスにし、1件のエンティティでは判定できない業務ルールをドメインサービスに置く方針で分けます。Evans がまとめたDDD Reference（2015年版）は、ドメインサービスを「a significant process or transformation in the domain is not a natural responsibility of an entity or value object」のときに置くものと定義しており、呼び出し元の数で決まるものではありません。アプリケーションサービスがユースケースを実装する設計もあり、UseCase クラスはその「1ユースケース1クラス」版です。Java・Spring でのサービスクラスの書き方はサービスクラスとは？Java・Springでの役割と書き方、コントローラーとの違いで扱っています。

// usecase.ts
// ドメイン層のエンティティ
export class Customer {
  constructor(readonly name: string, readonly email: string) {}
}

// ユースケースが依存する抽象（ポート）
export interface CustomerRepository {
  existsByName(name: string): Promise<boolean>;
  save(customer: Customer): Promise<void>;
}

// ドメインサービス: 顧客名の一意性は1件の Customer だけでは判定できないため、エンティティの外に置く
export class CustomerUniquenessChecker {
  constructor(private readonly repository: CustomerRepository) {}
  isDuplicated(name: string): Promise<boolean> {
    return this.repository.existsByName(name);
  }
}

export type RegisterResult =
  | { kind: "created"; name: string }
  | { kind: "missingFields" }
  | { kind: "duplicated"; name: string };

// ロバストネス図のコントロール群をまとめた、ユースケース1本＝1クラスの入口
export class RegisterCustomerUseCase {
  constructor(
    private readonly repository: CustomerRepository,
    private readonly uniqueness: CustomerUniquenessChecker,
  ) {}

  // 基本コースと代替コースを戻り値の型で列挙する
  async execute(name: string, email: string): Promise<RegisterResult> {
    if (name.trim() === "" || email.trim() === "") return { kind: "missingFields" };
    if (await this.uniqueness.isDuplicated(name)) return { kind: "duplicated", name };
    await this.repository.save(new Customer(name, email));
    return { kind: "created", name };
  }
}

// 動作確認用のインメモリ実装（同名の同時登録は防げない）
export class InMemoryCustomerRepository implements CustomerRepository {
  private readonly rows: Customer[] = [];
  async existsByName(name: string) { return this.rows.some((c) => c.name === name); }
  async save(customer: Customer) { this.rows.push(customer); }
}

UseCase は入口を1つ（execute）に絞り、記述の代替コース2本をそのまま missingFields と duplicated という値で返します。例外を投げる実装にすると記述との対応が型に現れず、呼び出し側で代替コースの処理漏れを switch の網羅性検査で拾えません。インメモリ実装は確認用で、同名の同時登録は防げません。本番では永続化先の一意制約で弾き、その違反を duplicated に変換します。

代替コースとテストケースの対応づけ

以下は記述のコース名をそのままテスト名にした、ユースケース層の単体テストです。画面の再表示、未入力項目の赤色表示、編集かキャンセルかの選択は対象外で、UI のテストで別に確かめます。コース1本につきテストが1本で足りるとは限らず、境界値や入力の組み合わせがあれば1つのコースに複数の確認を入れます（下の「必須項目」のテストは2通りを確かめています）。Node.js 組み込みのテストランナー node:test で書くと次のとおりです。

// usecase.test.ts
import { test } from "node:test";
import assert from "node:assert/strict";
import { RegisterCustomerUseCase, InMemoryCustomerRepository, CustomerUniquenessChecker } from "./usecase.js";

const newUseCase = () => {
  const repository = new InMemoryCustomerRepository();
  return new RegisterCustomerUseCase(repository, new CustomerUniquenessChecker(repository));
};

test("基本コース: 新しい顧客を登録できる", async () => {
  assert.deepEqual(await newUseCase().execute("issoh", "[email protected]"), { kind: "created", name: "issoh" });
});

test("代替コース: 必須項目が埋まっていない", async () => {
  assert.deepEqual(await newUseCase().execute("   ", "[email protected]"), { kind: "missingFields" });
  assert.deepEqual(await newUseCase().execute("issoh", ""), { kind: "missingFields" });
});

test("代替コース: 同名の顧客が既に存在する", async () => {
  const useCase = newUseCase();
  await useCase.execute("issoh", "[email protected]");
  assert.deepEqual(await useCase.execute("issoh", "[email protected]"), { kind: "duplicated", name: "issoh" });
});

TypeScript 7.0.2 と型定義パッケージ @types/node を開発依存に入れ、strict を有効にして tsc でコンパイルし（module は nodenext）、Node.js v26.5.0 で node --test dist/usecase.test.js を実行すると、3件とも通ります。

✔ 基本コース: 新しい顧客を登録できる (2.799291ms)
✔ 代替コース: 必須項目が埋まっていない (0.214835ms)
✔ 代替コース: 同名の顧客が既に存在する (0.228363ms)
ℹ tests 3
ℹ pass 3
ℹ fail 0

代替コースを1本足したら、戻り値の型に1つ、テストに1つ足す。この3点を同時に動かせば、記述にある代替コースの実装漏れはテストで見つかります。逆に、記述に無い仕様（実装者が独断で足した入力制限など）はテストが通っても残るので、コードレビューで記述と突き合わせる工程は省けません。テストを先に書く進め方そのものはTDD（テスト駆動開発）とは？Red・Green・Refactorの手順をpytestとJUnit 6の実行例で解説で扱っています。

DDD・クリーンアーキテクチャとの関係

DDDとの違い：ドメインモデルの役割と分割の単位

「ユースケース駆動はユースケースから、DDD はドメインモデルから始める」という説明は誤りで、ICONIX もドメインモデルを先に描きます。差はドメインモデルに担わせる役割と分け方です。ICONIX のモデルは記述の語彙を固定する足場として始まり、ユースケースの束を回すたびに直されて詳細設計のクラス図へ育ちます。Eric Evans の『Domain-Driven Design』（2003年）は、モデルを業務側と共有するユビキタス言語そのものとして扱い、境界づけられたコンテキストごとに分けて継続的に改善します。

したがって併用できます。ICONIX に「1本のユースケースをコードへ落とす手順」を、DDD に「増えるモデルをどこで分割するか」を担わせ、同じ語が部署ごとに別の意味を持ち始めたら DDD の分割を持ち込みます。ロバストネス図のコントロールは記述の動詞を写した分析上の置き場で、DDD のドメインサービスとは定義が違います。コントロールをそのままドメインサービスとして実装しないでください。DDD 側の用語と採用判断はドメイン駆動設計（DDD）とは？意味・提唱者・基本用語から進め方と採用判断まで解説にまとめています。

クリーンアーキテクチャのUse Cases層との対応

Robert C. Martin の「The Clean Architecture」（2012年8月13日）は、同心円の内側から Entities、Use Cases、Interface Adapters、Frameworks and Drivers を置き、Use Cases 層を「It encapsulates and implements all of the use cases of the system.」と説明しています。ロバストネス図の3要素は、エンティティを Entities 層、コントロールの多くを Use Cases 層、バウンダリを Interface Adapters 層の側に寄せて読むと整理しやすくなります。ただし一対一の対応ではありません。原典の Entities 層は「enterprise wide business rules」を持つ層で、ロバストネス図のエンティティ（データオブジェクト）と同じものではないからです。

また同記事は Interface Adapters 層について「The Presenters, Views, and Controllers all belong in here.」と書いており、この Controller は入力を変換する係で、ロバストネス図のコントロールとは別物です。層の読み方はクリーンアーキテクチャとは？4層・依存性ルール・図の読み方を原典で解説｜いらない場面の判断基準、ポートとアダプターの考え方はヘキサゴナルアーキテクチャとは？ポートアンドアダプターの仕組み・メリットとクリーン・オニオンとの違いで扱っています。

仕様駆動開発（Spec Kit v1.2）との対応と欠けやすい工程

仕様駆動開発（SDD）は、書かれた仕様を正として AI エージェントにコードを書かせる進め方です。代表的なツールの GitHub Spec Kit は、2026年11月2日に v1.2.6 を公開しました。v1.2.6 の README が示す最小の流れは constitution、specify、plan、tasks、implement、converge の6段で、implement と converge を「Converged」と報告されるまで繰り返します。

公式のコマンドリファレンスは「only /speckit.specify is strictly required before /speckit.plan」とし、clarify・checklist・analyze を曖昧さのある案件に足す品質ゲートと位置づけています。ICONIX で必須のレビュー関門にあたる工程が、Spec Kit では任意です。

中身にも差があります。clarify のテンプレートは仕様を分類ごとに点検し、回答を仕様へ書き戻しますが、質問は1回のセッションにつき最大5問（「Maximum of 5 total questions across the whole session」）です。analyze は「STRICTLY READ-ONLY」の点検役で、公式リファレンスは analyze で要求の穴が見つかれば clarify か specify に戻って直すよう案内しています。converge は実装と仕様を突き合わせ、未完了の作業を tasks.md に追記するだけで、仕様は書き換えません。上流へ戻る流れはあるものの、ICONIX のように記述の全文を図へ写し、写せない文から穴を見つける検出のしかたは、どのコマンドにもありません。

立場を明示すると、clarify を任意のまま運用するのは勧めません。抽象的な仕様が「曖昧で不完全」に見えるという2007年の指摘は、読み手が AI エージェントに替わっても成り立ちます。エージェントは質問の上限を超えた曖昧さを推測で埋めて実装を進めることがあります。そこで /speckit.specify の直後に、代替コース・画面名・業務オブジェクト名を人が書き足してから clarify に渡してください。書き足しても洗い出しの完了は保証されないので、未解決の分岐が残れば人のレビューか clarify の再実行で詰めます。Spec Kit の導入手順はSpec Kit（GitHub）とは？使い方・インストール・コマンド一覧をv1.2で解説【2026年10月】、SDD の全体像は仕様駆動開発（SDD／Spec-Driven Development）とは？TDDとの違い・3つの段階とSpec Kitで試す手順【2026年10月】にあります。

ユースケース駆動開発が向かないプロジェクトと効く条件

図の工程の省略や不採用で足りる案件の条件

典型は、画面をほとんど持たず、外部システムとの連携や例外の分岐も少ないバッチ処理やデータパイプラインです。バウンダリが起動トリガー1つになり、図から得られる発見はシーケンス図を直接描く場合と変わらないため、記述と単体テストだけ残して図の工程は省いて構いません。外部連携の失敗や再実行の分岐が多いバッチは、画面が無くても代替コースが多いので、この条件には入りません。ユースケースが1〜2本で、業務ルールや例外分岐も少ない小規模ツールでは、3つのレビュー関門を個別に設けず、記述とコードをまとめて確認する運用で足ります。何を作るかを探るプロトタイプも、目的や操作の仮説が固まるまでは図やレビューの工程を省いてよい段階です。ICONIX 自体は分析を通じて記述とモデルを直す反復を前提にしているので、仮説が固まった時点から持ち込めます。

画面と業務ルールが多い既存システム再構築での効果

効くのは、画面と業務ルールがどちらも多い基幹系、とくに既存システムの再構築です。「Top Ten Use Case Mistakes」は、レガシーシステムの再構築ならユーザーマニュアルから逆算すればよいと書いており、既存の画面一覧がユースケースの初稿に、テーブル定義がドメインモデルの土台になります。要件定義の段階で画面・業務ルール・データの対応表を作れずに設計が止まっている案件は、要件定義・RFP作成・PMO支援のように上流工程を外部と組んで進める選択肢もあります。

よくある質問

ユースケースとシナリオの違いは何ですか？

ユースケースは「顧客を新規登録する」という目的の単位で、シナリオはその目的に至る具体的な1本の経路です。1つのユースケースは、基本コース1本と代替コース数本のシナリオを持ちます。ICONIX では両方を同じ記述に書き、各コースからテストケースを導きます。境界値や入力条件によっては、1つのコースに複数のテストケースが要ります。

『ユースケース駆動開発実践ガイド』は今読んでも役に立ちますか？

手順の部分はそのまま使えます。2007年の本で UML 2.0 に対応し、実装例は Spring Framework と JUnit の Java コードです。ライブラリの版は古いので、第3章（ユースケースモデリング）・第5章（ロバストネス分析）・第12章（Design-Driven Testing）を中心に読むのが効率的です。翔泳社から電子書籍版も出ています。

DDDでは、ユースケースをどの層に置きますか？

一般にはアプリケーション層に、ユースケース1本につき1つのクラスやメソッドとして置き、業務ルールそのものはドメイン層のエンティティやドメインサービスへ寄せます。本記事の実装例でいえば、RegisterCustomerUseCase がアプリケーション層、Customer と CustomerUniquenessChecker がドメイン層です。

ユースケース記述とユースケース図はどちらを先に書きますか？

ICONIX では、まずドメインモデルを描き、次にユースケースを洗い出して図に置き、そのうえで記述の初稿を書きます。図が先なのは一覧を作って抜けを防ぐためで、設計を駆動するのは記述の方です。

ユースケースと業務フローはどう違いますか？

業務フローは人の作業も含めた業務全体の流れを描き、ユースケースはシステム境界の内側で起きるやり取りに限ります。紙の書類を運ぶ、電話で確認するといった境界の外の作業はユースケースには書きません。業務フローでシステムに載せる範囲を決め、その範囲をユースケースに分ける順で使うと二重管理になりません。

関連記事

• ユースケースとは？ビジネスとUMLで異なる意味・記述の書き方とテスト連携を解説
• ユースケース図とは？UMLの書き方・アクターと関係・要件定義での使い方を解説
• シーケンス図とは？UMLの書き方とライフライン・複合フラグメント・Mermaid実装を解説
• ドメイン駆動設計（DDD）とは？意味・提唱者・基本用語から進め方と採用判断まで解説
• 仕様駆動開発（SDD／Spec-Driven Development）とは？TDDとの違い・3つの段階とSpec Kitで試す手順【2026年10月】