ユースケース駆動開発とは？ICONIXの4工程とロバストネス分析・DDDとの違いを解説

ユースケース駆動開発は、利用者がシステムで達成したい目的を1本ずつ文章に書き下ろし、その文章から設計・コード・テストまでを一直線に導く開発の進め方です。日本では『ユースケース駆動開発実践ガイド』（翔泳社、2007年10月16日、512ページ）で紹介された ICONIX プロセスがほぼ同義語として使われます。

この記事では、ICONIX の4工程と3つのレビュー関門、その中核にあるロバストネス分析の描き方を原著の記述に沿って整理し、ドメイン駆動設計（DDD）やクリーンアーキテクチャ、AI の仕様駆動開発（SDD）との関係まで扱います。

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

先に結論を並べます。

• ユースケース（英語では use case）は、アクターとシステムのやり取りを「利用者が達成したい目的1つ」の単位で書いた文章です。図ではなく文章が本体です。
• ユースケース駆動開発＝ICONIX プロセスは、ドメインモデル・ユースケース図・ロバストネス図・シーケンス図の4種類だけで、ユースケース記述からコードまで到達させます。
• 出発点はユースケースではなくドメインモデルです。原著は第2章にドメインモデリングを置き、「なぜユースケースではなくドメインモデルから始めるのか」を節タイトルにしています。
• 中核はロバストネス分析です。ユースケース記述を「オブジェクトの絵」に描き直し、その過程で記述そのものを書き直して曖昧さを削ります。
• DDD とは競合しません。ICONIX は1本のユースケースをコードへ落とすまでの手順、DDD は肥大化するモデルを分割し続けるための指針で、担当する時間軸が違います。

以下、各工程で実際に何を書くのかを順に見ていきます。

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

ユースケースが指すもの：目的単位で書かれた振る舞いの記述

ユースケースは、アクター（利用者や外部システム）がシステムを使って達成する目的を1つ選び、その目的が達成されるまでのやり取りを文章にしたものです。「顧客を新規登録する」「書籍の詳細を表示する」といった粒度で切ります。

ここで取り違えが起きやすいのが、ユースケース図との関係です。図はユースケースの一覧とアクターとの結びつきを俯瞰するための地図であり、設計を駆動するのは図ではなく記述の方です。作図の記法そのものはユースケース図とは？UMLの書き方・アクターと関係・要件定義での使い方を解説で扱っています。

記述には基本コース（成功したときの流れ）と代替コース（入力不備や重複など、うまくいかないときの流れ）を必ず両方書きます。この経路1本1本がシナリオです。「ユースケース＝目的、シナリオ＝その目的を達成する具体的な1経路」という関係で、1つのユースケースは基本コース1本と代替コース数本のシナリオを持ちます。

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）にまとまりました。OOSE は商用プロセス Objectory の簡略版という位置づけです。

この考え方を、実務で回せる最小限の手順に絞り込んだのが 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）、邦訳が『ユースケース駆動開発実践ガイド』（翔泳社、2007年10月16日、512ページ、ISBN 9784798114453、訳＝佐藤竜一・三河淳一・船木健児）です。

ICONIX が図を4種類に絞った理由

原著の Introduction には、ICONIX を採用した顧客の声を並べた「トップ10」が載っています。10位から1位へ数え上げる形式で、リストの冒頭に置かれた第10位が「The process uses a core subset of UML.（We’d rather learn 4 diagrams than 14 . . .）」——14個の図を覚えるより4個で済ませたい、という一言です。

実際に使う図は次の4種類に限られます。

4つに絞れるのは、それぞれが別々の問いに答えているからです。同じ問いに答える図は重ねて描きません。

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

要求定義：ドメインモデル先行とユースケース初稿の書き起こし

最初に描くのはユースケースではありません。原著は第2章をドメインモデリングに充て、その節タイトルに「Why Start with the Domain Model Instead of Use Cases?」を掲げています。第3章のユースケースモデリングでも冒頭で「Do an Initial Domain Model Before You Write the Use Cases」と念を押しています。

順序を逆にすると何が起きるでしょうか。ユースケース記述に出てくる語が人によってばらつき、「顧客」「ユーザー」「アカウント」が同じものを指しているのか判別できなくなります。先に業務のモノを洗い出して名前を固定しておけば、記述は最初からその語彙で書けます。

この工程では、画面の簡易プロトタイプ（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枚

シーケンス図はユースケース1本につき1枚描きます。原著はこの図の主目的を「The primary function of sequence diagramming is to allocate behavior to your classes」と明言しています。処理の流れを美しく描くことではなく、どのクラスにどの操作を持たせるかを決めることが目的です。

描きながらドメインモデルに操作を追加していくと、ドメインモデルは静的モデル、すなわち詳細設計としてのクラス図へ変わっていきます。ここを整理して通すのがマイルストーン3「クリティカル設計レビュー（CDR）」です。記法の詳細はシーケンス図とは？UMLの書き方・ライフラインやメッセージ・複合フラグメントを解説にまとめています。

実装とテスト：代替コース起点のテストケース設計

実装工程では、コーディングと単体テストを進めたうえで、結合テストとシナリオテストをユースケースに紐づけます。ここで効くのが代替コースです。基本コースだけを試験対象にすると例外系の実装漏れが残るため、代替コースのシナリオを1本ずつテストケースに落とします。最後にコードレビューとモデル更新を行い、次のバッチへ進みます。

ICONIX がアジャイルと相性が良いとされるのは、この一巡をユースケース数本という小さな束で回すからです。全ユースケースの設計を終えてから実装に入る、という進め方は前提にしていません。

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

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

ロバストネス図に登場するオブジェクトは3種類だけです。Rosenberg・Stephens・Collins-Cope が Methods & Tools 誌（2005年春号）で示した定義は次のとおりです。

この3分類は ICONIX の発明ではなく、Jacobson の OOSE（1992年）に由来する ECB パターンです。当初の名称は entity-interface-control で、interface が後に boundary へ置き換わりました。

コントロールについて、Kendall Scott と Doug 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, but controllers usually serve as placeholders to assure that you don’t forget any functionality and system behavior required by your use cases」。コントロールが実際のクラスとして残るのは2割程度で、残りは機能の抜けを防ぐための置き場だという整理です。ロバストネス図をそのまま実装構造だと受け取ると、この点で読み違えます。

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

ロバストネス図が設計レビューとして機能するのは、線の引き方に制約があるからです。前掲の Scott・Rosenberg 記事は「Four basic rules apply」として次の4つを挙げています。

覚え方も同記事が示しています。「Nouns can’t talk to other nouns, but verbs can talk to either nouns or verbs」——名詞同士は繋げず、動詞は名詞にも動詞にも繋げる。バウンダリとエンティティはどちらも名詞なので直結できず、間に必ずコントロールが入ります。画面が直接テーブルを読み書きする設計は、そもそも線が引けません。

エンティティ同士も名詞なので、ロバストネス図では線を引けません。ドメインモデル（クラス図）でエンティティ間に関連を描くのは正当なので、この2つの図を混同しないでください。なお同記事は、基本コースと全ての代替コースが1枚の図に収まるはずだ、とも述べています。収まらないなら、ユースケースの粒度が大きすぎるという合図です。

ユースケース記述が曖昧になる典型パターン

原著の Preface に、ICONIX の存在理由がそのまま書かれています。「if you hand a programmer an abstract, technology-free, implementation-independent, “essential” use case, that programmer will find the use case to be vague, ambiguous, incomplete, and therefore incorrect」——抽象的で技術非依存、実装非依存の「本質的な」ユースケースをプログラマに渡すと、プログラマにはそれが曖昧で不完全で誤ったものに見える、という指摘です。

原著はここから、ICONIX がプログラマに受け入れられる理由を「it actually forces the use cases into concrete, tangible, and specific statements of required system behavior」——ユースケースを具体的で手に取れる、システムの振る舞いの明確な記述へと強制するからだ、と説明し、そのうえで「If there’s a secret to all of this, that’s it.」と締めています。秘訣とされているのは、曖昧さの指摘そのものではなく記述を具体へ強制する仕掛けの方です。

ですから ICONIX 流のユースケース記述は、意図的に画面名まで踏み込みます。Methods & Tools 記事に載っている「新規顧客の作成」の記述はこの形です。

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

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

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

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

「顧客詳細ページ」「顧客一覧ページ」がバウンダリ、「顧客」がエンティティ、「検証する」「追加する」がコントロールに対応します。記述の語がそのまま図の要素になるため、図が描けない箇所は記述が足りていない箇所です。

ドメイン駆動設計（DDD）との違いと併用の判断基準

「出発点が違う」という通説の誤り

「ユースケース駆動はユースケースから、DDD はドメインモデルから始める」という説明をよく見かけますが、前述のとおり ICONIX もドメインモデルを先に描きます。両者の差は着手順ではなく、ドメインモデルに何を期待し、どれだけの期間維持するかにあります。

ICONIX のドメインモデルは、ユースケース記述で使う語彙を固定するための道具として始まり、シーケンス図を描く過程で操作が加わり、最終的に詳細設計のクラス図へ育ちます。設計を進めるための足場であり、ユースケース数本のバッチを一巡させるたびに更新されて、成果物はコードに着地します。

対して Eric Evans の『Domain-Driven Design: Tackling Complexity in the Heart of Software』（Addison-Wesley、2003年8月、版元表記560ページ）が扱うドメインモデルは、業務の複雑さそのものを表現し、業務側と共有する言語（ユビキタス言語）として維持され続ける対象です。境界づけられたコンテキストを単位に年単位で育てるもので、1回のリリースで終わる話ではありません。用語やパターンの詳細はドメイン駆動設計（DDD）とは？意味・基本用語・実装と採用判断をわかりやすく解説にまとめています。

併用するときの分担

この2つは競合しません。ICONIX に「1本のユースケースを設計してコードに落とすまでの手順」を、DDD に「増え続けるモデルをどこで分割するか」を担わせます。切り替えの目安は、Evans 本が第14章「Maintaining Model Integrity」で扱う境界づけられたコンテキストの分割が要る規模、つまり同じ語が部署によって別の意味を持ち始めた時点です。

逆に、両方の語彙を1つのモデル図に混ぜるのは避けるべきです。ロバストネス図のコントロールと DDD のドメインサービスは、名前が似ていても粒度が違います。コントロールはユースケース1本のための処理、ドメインサービスは複数のユースケースが共有する業務ルールです。

クリーンアーキテクチャのUseCase層への落とし込み

同心円4層とロバストネス図3要素の対応

Robert C. Martin が2012年8月13日に公開した「The Clean Architecture」の同心円は、内側から Entities、Use Cases、Interface Adapters、Frameworks and Drivers の順です。Use Cases 層について同記事は「The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system.」と説明しています。依存の向きを定める依存性のルールは「This rule says that source code dependencies can only point inwards.」——外から内への一方向だけです。

ロバストネス図の3要素はこの同心円に対応させられます。エンティティは Entities 層、コントロールは Use Cases 層、バウンダリは Interface Adapters 層です。ロバストネス図で引けない線（バウンダリからエンティティへの直結）が、クリーンアーキテクチャでも層飛ばしとして禁止される点も一致します。

ひとつ注意が要ります。同記事は Interface Adapters 層について「The Presenters, Views, and Controllers all belong in here.」と書いており、ここでいう Controller はロバストネス図のコントロールとは別物です。前者は入力を受け取って変換する係、後者はユースケースの業務ロジックそのものを指します。同じ発想を採るヘキサゴナルアーキテクチャとは？ポートアンドアダプターの仕組みとクリーン・オニオンとの違いでは、バウンダリが外側のアダプタ層にあたります。

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

実装で迷いやすいのが、UseCase クラスと Service クラスの線引きです。判断基準は単純で、利用者が達成したい目的1つに対応するなら UseCase、複数のユースケースから呼ばれる部品なら Service です。UseCase クラスは入口を1つ（execute など）に絞り、基本コースと代替コースを戻り値の型で列挙します。

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

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

// ドメインサービス: 複数のユースケースが再利用する業務ルール
class CustomerNamePolicy {
  static readonly MAX_LENGTH = 40;
  isValid(name: string): boolean {
    return name.trim().length > 0 && name.length <= CustomerNamePolicy.MAX_LENGTH;
  }
}

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

// ロバストネス図のコントロールに対応する。ユースケース1本を1クラスで表す
class RegisterCustomerUseCase {
  constructor(
    private readonly repository: CustomerRepository,
    private readonly namePolicy: CustomerNamePolicy,
  ) {}

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

// 動作確認用のインメモリ実装
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); }
}

async function main(): Promise<void> {
  const useCase = new RegisterCustomerUseCase(
    new InMemoryCustomerRepository(),
    new CustomerNamePolicy(),
  );
  console.log(await useCase.execute("issoh", "[email protected]"));
  console.log(await useCase.execute("issoh", "[email protected]"));
  console.log(await useCase.execute("   ", "[email protected]"));
}

main();

TypeScript 7.0.2 の tsc --strict で型検査を通し、Node.js v26.5.0 で実行すると、次の3行が出力されます。

{ kind: 'created', name: 'issoh' }
{ kind: 'duplicated', name: 'issoh' }
{ kind: 'invalidName' }

戻り値を RegisterResult の直和型にしている点が肝です。先ほどのユースケース記述にあった代替コース2本が、そのまま invalidName と duplicated という値になっています。例外を投げる実装にすると、記述との対応が型に現れず、代替コースの実装漏れがコンパイル時に検出できません。Java や PHP でのサービスクラスの書き分けはサービスクラスとは？Javaでの役割・書き方とコントローラーとの違いで扱っています。

AI仕様駆動開発（SDD）との対応関係と曖昧さ解消工程の位置づけ

2025年以降に広がった仕様駆動開発（SDD）は、チャット履歴ではなく書かれた仕様を正とし、AI エージェントにコードを書かせる進め方です。代表的なツールキットである GitHub Spec Kit は、2025年9月2日に GitHub 公式ブログで公開が告知されました。最新リリースは v0.16.2（2026年8月10日）、スターは126,370です（2026年8月12日時点、GitHub API で取得）。

v0.16.2 の README が Core Commands として並べるのは、/speckit.constitution（プロジェクトの原則を定める）、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement ほかです。この並びは ICONIX の4工程とほぼ同じ位置に立っています。

注目すべきは Optional 欄です。曖昧さを詰める /speckit.clarify（「Clarify underspecified areas」、/speckit.plan の前に推奨）も、成果物間の整合とカバレッジを検証する /speckit.analyze（/speckit.tasks の後、/speckit.implement の前）も、ツールとしては実在します。

差は2点に絞られます。第一に、ICONIX でこれらに相当する工程はマイルストーンとして必須ですが、Spec Kit では Optional に置かれ、飛ばしても流れが成立します。第二に、/speckit.clarify は仕様テキストの中で質疑して追記する形式で、ICONIX のように設計側の図に描き起こして上流の記述を書き直す往復にはなりません。図に描けない箇所が記述の穴として現れる、という検出のしかたが SDD 側には無いわけです。

ここは実務判断が分かれる点なので、立場を明示します。Optional のまま運用するのは勧めません。抽象的な仕様を渡されたプログラマが「曖昧で不完全」と感じるという2007年の指摘は、読み手が LLM に替わっても成り立ちます。むしろ LLM は曖昧な箇所を質問せずに埋めてしまうため、実害は大きくなります。/speckit.specify の直後に代替コースを列挙し、画面名と業務オブジェクト名まで書き下ろしてください。図を描かないとしても、この確認だけは必須工程として運用に組み込む価値があります。SDD 側の全体像は仕様駆動開発（SDD／Spec-Driven Development）とは？従来手法との違いとAI時代に注目される理由で整理しています。

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

採用を見送るべき3つの条件

次に当てはまる場合、ICONIX を丸ごと持ち込む効果は小さいと判断してよいと考えます。

最も多いのが、画面をほとんど持たないバッチ処理やデータパイプラインです。ロバストネス図に描けるバウンダリが起動トリガー1つ、あとはエンティティとコントロールだけ、という図になります。この形の図から出てくる発見は、シーケンス図を直接描いた場合とほぼ変わりません。ICONIX の価値は「画面での操作と業務ルールの間にある食い違いを炙り出すこと」に集中しているため、画面が無い領域では効き目が薄いわけです。ETL 処理やバッチ集計であれば、ユースケース記述と単体テストだけ残して図の工程は落として構いません。

次に、ユースケースが1〜2本しかない小規模ツール。要求レビュー・予備設計レビュー・クリティカル設計レビューという3つの関門を通すコストが、発見できる不整合の量に見合いません。

3つ目は、何を作るかを探ること自体が目的のプロトタイプです。ユースケース記述を確定させてから設計へ進む、という前提が最初から崩れています。

効果が出やすい条件

反対に効くのは、画面と業務ルールがどちらも多い基幹系、とりわけ既存システムの再構築です。原著の要求分析の図には「再構築対象のレガシーシステムの情報を集める」という作業が明示されており、画面とデータベース表という具体物から出発できる場面を想定しています。

既存の画面一覧がそのままユースケースの初稿になり、既存のテーブル定義がドメインモデルの土台になります。この2つが手元にある案件なら、要求定義の工程は短く終えられます。

よくある質問

1つのユースケースはどの粒度で切ればよいですか？

「1画面＝1ユースケース」ではありません。基準は、アクターがそれ単独で価値のある目的を達成し終えるかどうかです。「顧客を新規登録する」は達成しますが、「顧客名を検証する」は単独では何も終わらないので、独立したユースケースにはしません。判定の目安として、Scott と Rosenberg は基本コースと全ての代替コースが1枚のロバストネス図に収まるはずだと述べています。収まらないなら大きすぎ、他のユースケースから常に呼ばれる断片なら小さすぎます。

ユースケース駆動開発とドメイン駆動設計はどちらを選ぶべきですか？

択一の関係ではありません。1本のユースケースを設計からコードまで落とす手順が欲しいなら ICONIX、モデルが肥大化したときの分割方針と業務側との共通言語が欲しいなら DDD です。基幹系の再構築では、序盤を ICONIX で回し、同じ語が部署によって別の意味を持ち始めた段階で DDD の境界づけられたコンテキストによる分割を持ち込む進め方が現実的です。両者はドメインモデルを先に描く点でも一致しており、着手順で対立するものではありません。

UseCaseクラスとServiceクラスはどう使い分けますか？

利用者が達成したい目的1つに対応するクラスが UseCase、複数のユースケースから呼ばれる業務ルールの置き場が Service です。判断に迷ったら、呼び出し元の数を数えてください。呼び出し元が画面（バウンダリ）1種類なら UseCase、複数の UseCase から呼ばれるなら Service に切り出します。UseCase は入口のメソッドを1つに絞り、代替コースを例外ではなく戻り値の型で表すと、ユースケース記述との対応が型検査で保たれます。

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

ICONIX では、まずドメインモデルを描き、次にユースケースを洗い出して図に置き、そのうえで記述の初稿を書きます。図が先ですが、これは一覧を作って抜けを防ぐためで、設計を駆動するのは記述の方です。原著が第2章のタイトルに「Why Start with the Domain Model Instead of Use Cases?」を掲げているとおり、図と記述のどちらよりも先に来るのはドメインモデルだという点に注意してください。

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

業務フローは人の作業も含めた業務全体の流れを描くのに対し、ユースケースはシステムの境界の内側で起きるやり取りに限定します。境界の外にある作業（紙の書類を運ぶ、電話で確認する）はユースケースには書かず、アクターの振る舞いとして扱います。業務フローを先に描いてシステムに載せる範囲を決め、その範囲内をユースケースへ分割する、という順で使うと二重管理になりません。

関連記事

• ユースケース図とは？UMLの書き方・アクターと関係・要件定義での使い方を解説
• ドメイン駆動設計（DDD）とは？意味・基本用語・実装と採用判断をわかりやすく解説
• シーケンス図とは？UMLの書き方・ライフラインやメッセージ・複合フラグメントを解説
• ヘキサゴナルアーキテクチャとは？ポートアンドアダプターの仕組みとクリーン・オニオンとの違い
• サービスクラスとは？Javaでの役割・書き方とコントローラーとの違い