要件定義アプローチとアーキテクチャの選択: ビジネスルール vs ユーザー体験 🔄

Posted at 2025-04-09

はじめに 👋

システム開発において、要件定義は成功の鍵を握る重要なプロセスです。しかし、その進め方については「ビジネスルールから始めるべきか」「ユーザー体験から入るべきか」という根本的な問いがあります。この選択はプロジェクトの方向性を大きく左右し、後のアーキテクチャ設計にも密接に関わってきます。

本記事では、ソフトウェアアーキテクチャの代表的なパターンである「オニオンアーキテクチャ」と「クリーンアーキテクチャ」の視点から、両アプローチの特徴、適用シーンを比較し、効果的な要件定義戦略について考察します。

二つの要件定義アプローチ 🔍

要件定義の進め方は、大きく分けて「ビジネスルール起点」と「ユーザー体験起点」の二つのアプローチがあります。

ビジネスルールを起点とするアプローチ 🏢

ビジネスルールを先に定義し、その後にユースケースや画面設計へと進む方法は、オニオンアーキテクチャと親和性の高いアプローチです。

メリット ✅

🎯 ビジネスの本質を最優先に捉えられる
🏗️ 安定した要件の基盤を構築できる
🧩 ドメイン駆動設計(DDD)の考え方と整合する
🔄 システム全体の一貫性を確保しやすい
🛡️ 技術的制約に影響されない純粋なビジネス要件を定義できる
🗣️ プロジェクト関係者間の共通言語が早期に確立される

デメリット ❌

👤 実際のユーザー体験から乖離するリスクがある
🎨 ユーザー中心設計の観点が弱くなりがち
🔍 過度に複雑なルール体系になる可能性がある
🔙 ユースケース検討段階での手戻りコストが高くなることがある
📊 抽象的な概念だけでは関係者間の合意形成が難しい場合がある

ユーザー体験を起点とするアプローチ 👥

画面設計から始め、ユースケースを経てドメインモデルへと進む方法は、クリーンアーキテクチャと親和性の高いアプローチです。

メリット ✅

🙋‍♀️ ユーザー視点を優先したシステム設計ができる
🧠 具体から抽象への自然な思考の流れに沿っている
📝 ステークホルダーから早期にフィードバックを得られる
💡 必要なドメインルールが自然と浮かび上がる
🔄 アジャイル開発との親和性が高い
⚙️ 技術的実現性を早期に確認できる

デメリット ❌

🏢 ビジネスの本質的な部分が見落とされるリスクがある
🔄 UI/UX変更によって要件が揺らぎやすくなる
📈 長期的な視点でのシステム設計が難しい場合がある
🧩 ドメインモデルの一貫性を保つのが難しくなる可能性がある

アーキテクチャの特徴 🏗️

オニオンアーキテクチャ 🧅

🧩 中心にドメインモデルとビジネスルールを配置
💼 ビジネスロジックを最優先に考える
🏢 「ビジネスありき」の考え方と親和性が高い
📝 複雑なビジネスルールを持つ業務システムに適している

オニオンアーキテクチャでは、ドメインモデルを中心に据え、外側に向かってアプリケーションサービス、インフラストラクチャと層を重ねていきます。各層は次のような構成になっています：

ドメイン層（中心） 🎯：ビジネスエンティティとビジネスルール
ドメインサービス層 🔄：複数のエンティティにまたがるビジネスロジック
アプリケーションサービス層 📋：ユースケースの実装
インフラストラクチャ層（外側） ⚙️：データベース、UI、外部APIなどの技術的実装

この構造により、ビジネスロジックが技術的な実装の詳細から分離され、ビジネスの本質に焦点を当てた設計が可能になります。依存関係は常に外側から内側へ向かい、内側の層は外側の層を知りません。これにより、技術的な変更がビジネスロジックに影響を与えにくい設計が実現します。

クリーンアーキテクチャ 🧹

📋 ユースケース（インタラクター）を中心とした構造
👥 ユーザーインタラクションを重視する
✨ 「体験ありき」の考え方と親和性が高い
🚀 新規サービスやユーザー体験が重要な領域に適している

クリーンアーキテクチャは、Robert C. Martinによって提唱されたアーキテクチャパターンで、次の同心円層から構成されています：

エンティティ（中心） 🧩：ビジネスオブジェクトとルール
ユースケース 📋：アプリケーション固有のビジネスルールと操作フロー
インターフェースアダプター 🔌：コントローラー、ゲートウェイ、プレゼンターなど
フレームワークと外部インターフェース（外側） 🖥️：UIフレームワーク、データベース、外部APIなど

この構造では、ユースケースが設計の中心となり、それを実現するためのエンティティ（ドメインオブジェクト）とインターフェースアダプターを組み合わせて設計します。依存性はすべて内側に向かうため、外部の変更が内部のビジネスロジックに影響しにくくなります。

アーキテクチャの比較 🔍

以下の表は、オニオンアーキテクチャとクリーンアーキテクチャの主な特徴を比較したものです。

比較ポイント	オニオンアーキテクチャ 🧅	クリーンアーキテクチャ 🧹
設計の中心	🧩 ドメインモデル・ビジネスルール	📋 ユースケース（インタラクター）
設計の起点	🏢 ビジネスルールから始まる	👥 ユーザーの行動・体験から始まる
依存関係	⬅️ 外から内への一方向のみ	⬅️ 外から内への一方向のみ
得意な領域	💼 複雑なビジネスルールを持つ業務システム	✨ ユーザー体験が重要な新規サービス
適したプロジェクト	🏦 銀行システム、基幹業務システムなど	🛒 ECサイト、SNS、コンシューマーアプリなど
開発アプローチとの親和性	📚 ドメイン駆動設計（DDD）	🔄 アジャイル開発、UI駆動開発

DDD vs クリーンアーキテクチャ：根本的な方向性の違い 🧭

ドメイン駆動設計（DDD）とクリーンアーキテクチャは、同じ目標（良質なソフトウェアの設計）を目指しながらも、根本的に異なる方向性を持っています。この違いは要件定義アプローチの選択にも大きく影響します。

観点	DDD（ドメイン駆動設計）	クリーンアーキテクチャ
主な関心事	📊 何を実現するか（ビジネス価値）	👥 どんな体験を提供するか（ユーザー価値）
出発点	💼 ビジネスドメインの理解	🖥️ ユーザーとシステムの相互作用
核となる概念	🧩 ドメインモデル	📋 ユースケース（インタラクター）
共通言語	🗣️ ビジネス用語	🔄 ユーザーアクション用語
設計の流れ	🔍 ドメイン → ユースケース → UI	🎨 UI → ユースケース → ドメイン
プロセス	🏗️ 分析的・計画的	🧪 実験的・反復的
チーム構成との相性	👔 ドメインエキスパートとの協働	🎭 デザイナーとの協働

DDDの本質：「システムは何を実現すべきか」 🎯

DDDはビジネスドメインの複雑さを理解し、モデル化することに重点を置きます：

🔍 ドメイン探求：ビジネスの本質的な課題と解決策を探る
🗣️ ユビキタス言語：ビジネス関係者との共通言語を構築
📊 境界づけられたコンテキスト：複雑なドメインを管理可能な単位に分割
🧩 知識の表現：ビジネスルールやポリシーをコードで明示的に表現

クリーンアーキテクチャの本質：「どんな体験をもたらすか」 ✨

クリーンアーキテクチャはユーザーとシステムのインタラクションを中心に据えます：

👥 ユーザー中心：ユーザーが達成したい目標を最優先に考える
📋 ユースケース駆動：システムの機能をユーザーの行動として定義
🔄 依存関係の制御：変更に強い柔軟な設計を実現
🧪 テスト容易性：ビジネスロジックを簡単にテストできる構造

優先度と整合性：両アプローチの本質 🔄

両アプローチとも最終的には同じ要素（ユーザー体験とビジネスルール）を含むことになりますが、優先度と出発点が異なることが重要な違いです。

優先順位の特性 🔄

各アーキテクチャの特性をより深く見ると、それぞれが優先するものが見えてきます：

アーキテクチャ	最初に優先するもの	後から整合させるもの
オニオンアーキテクチャ 🧅	🧩 ビジネスルール/ドメインモデル	👥 ユーザー体験/インターフェース
クリーンアーキテクチャ 🧹	👥 ユーザー体験/ユースケース	🧩 ビジネスルール/エンティティ

どちらのアプローチも、最終的には両方の要素を整合させる必要があります。違いは単に「どこから始めるか」「何を優先するか」という点だけです。

整合性を取るプロセス ⚖️

オニオンアーキテクチャの場合 🧅

ドメインモデル/ビジネスルールを定義 🧩
アプリケーションサービス層でユースケースを実装 📋
UI/UXを設計・実装（ビジネスルールに準拠） 👥
ユーザーフィードバックを得て必要に応じてドメインモデルを修正 🔄

クリーンアーキテクチャの場合 🧹

ユーザー体験/ユースケースを定義 👥
必要なエンティティとビジネスルールを抽出 🧩
インターフェースアダプターでつなぐ 🔌
実装・テストを通じて必要に応じてビジネスルールを強化 🔄

クリーンアーキテクチャとデザイン思考 🎨

クリーンアーキテクチャを採用したユーザー体験起点のアプローチは、デザイン思考のプロセスと非常に親和性が高いです。デザイン思考とは、人間中心のイノベーションアプローチであり、以下のステップを含んでいます：

共感（Empathize） 👂: ユーザーのニーズや問題を理解する
定義（Define） 🔍: 問題を明確に定義する
発想（Ideate） 💡: アイデアを創出する
プロトタイプ（Prototype） 🛠️: アイデアを形にする
テスト（Test） 🧪: プロトタイプを検証する

これをシステム開発のプロセスに当てはめると、以下のようなフローになります：

デザイン思考に基づくクリーンアーキテクチャのアプローチ

共感・定義フェーズ 👂🔍
- ユーザーリサーチ（インタビュー、観察、アンケート）
- ペルソナの作成
- ユーザージャーニーマップの作成
- 問題点・ニーズの明確化
発想・プロトタイプフェーズ 💡🛠️
- UI/UXデザインの作成
- ワイヤーフレーム・モックアップの制作
- インタラクティブプロトタイプの作成
- ユーザビリティテスト
ユースケース抽出フェーズ 📋
- プロトタイプから必要な機能を抽出
- ユーザーストーリーの作成
- ユースケース図の作成
- 画面遷移図の作成
ドメインモデル定義フェーズ 🧩
- ユースケースから必要なエンティティを特定
- 事後的にドメインルールを定義
- データモデルの設計
- ビジネスルールの文書化

このアプローチの特徴は、「外から内」に向かって設計を進めていくことです。まずユーザーインターフェース（最も外側の層）を検討し、次にユーザーストーリーやユースケース（ユースケース層）を定義し、最後にそれらを実現するためのドメインモデルやエンティティ（最も内側の層）を抽出・定義します。

「あとづけ」ドメインモデリングの特徴 🔄

ユーザー体験起点のアプローチでは、ドメインモデルが「あとづけ」で定義される特徴があります：

ユーザー視点優先 👁️
- ユーザーが何を求めているかを最優先に考える
- ビジネスルールはユーザーニーズを満たすための手段として位置づけられる
実用主義的アプローチ 🛠️
- 実際に必要なドメインルールだけを抽出する
- 過度に理論的・網羅的なモデリングを避ける
イテレーティブな洗練 🔄
- 初期のドメインモデルは簡素で、必要最小限
- 開発が進むにつれて徐々に洗練される
- ユーザーフィードバックを基にモデルを調整する
ドメインの発見的プロセス 🔍
- ドメインの知識がなくても、ユーザー体験から必要な概念を発見できる
- 暗黙知を形式知化するプロセスとなる

プロジェクト規模と開発スピードによる選択 ⏱️

アーキテクチャ選択は、プロジェクトの規模とスピード感によっても大きく影響を受けます。

クリーンアーキテクチャ：小規模・高速開発に適合 🚀

🧪 プロトタイピングとの親和性：初期のUIプロトタイプから始め、徐々にビジネスルールを整理できる
⚡ 素早いフィードバックサイクル：ユーザーに見せられるものを早期に作れる
🔍 発見的アプローチ：開発しながらシステムやプロダクトイメージを形成できる
👥 チーム構成：少人数チームや、ビジネスドメインがシンプルな場合に有効
🛠️ 適している開発：スタートアップ、MVPの構築、新規サービスの検証フェーズ

DDD/オニオンアーキテクチャ：大規模・複雑なプロジェクトに適合 🏗️

🏢 ビジネス要件の担保：複雑なビジネスルールを確実に実装できる
📊 一貫性の確保：大規模システムでも一貫したドメイン理解を維持できる
⚠️ 課題：スピード感：初期段階での見える成果が出にくい
👥 チーム構成：複数チーム、多人数での開発に有効
🛠️ 適している開発：金融システム、基幹業務システム、ミッションクリティカルなシステム

要件定義ドキュメント例：レストラン予約システム 📄

同じ「レストラン予約システム」を例に、ビジネスルール起点とユーザー体験起点の両方の要件定義アプローチを比較してみましょう。

ビジネスルール起点の要件定義ドキュメント例 📊

# レストラン予約システム 要件定義書
Version: 1.0
Date: 2025/4/10

## 1. ドメインモデル定義

### 1.1 コアエンティティ
- **店舗（Restaurant）**
  - 属性: ID, 名称, 住所, 営業時間, 座席数, 予約可能期間, 予約間隔, キャンセルポリシー
  - ビジネスルール: 
    - 営業時間外は予約を受け付けない
    - 座席数以上の予約は受け付けない
    - 特定日の予約可否を設定できる

- **予約（Reservation）**
  - 属性: ID, 店舗ID, 顧客ID, 日時, 人数, ステータス, 作成日時, 更新日時
  - ビジネスルール:
    - 予約は店舗の予約可能期間内である必要がある
    - 予約は店舗の予約間隔に従う必要がある
    - キャンセルポリシーに基づきキャンセル料が発生する

- **顧客（Customer）**
  - 属性: ID, 名前, 電話番号, メールアドレス, 予約履歴, ポイント
  - ビジネスルール:
    - 予約完了時にポイントを付与する
    - キャンセル回数が一定数を超えると予約制限がかかる

### 1.2 ドメインサービス
- **予約管理サービス**
  - 予約可能時間枠の計算
  - 予約の重複チェック
  - キャンセル料の計算

- **顧客管理サービス**
  - 顧客のランク付け
  - 予約履歴の管理
  - ポイント計算

## 2. ユースケース定義

### 2.1 店舗管理者のユースケース
- UC-01: 予約可能枠の登録・管理
- UC-02: 予約の確認・変更
- UC-03: キャンセルポリシーの設定

### 2.2 顧客のユースケース
- UC-04: 店舗検索
- UC-05: 予約の作成
- UC-06: 予約の変更・キャンセル
- UC-07: 予約履歴の確認

## 3. 技術要件

### 3.1 非機能要件
- パフォーマンス要件: 同時予約処理数100件以上
- セキュリティ要件: 個人情報保護法に準拠
- 可用性要件: 稼働率99.9%以上

### 3.2 外部システム連携
- 決済システム連携
- メール通知システム
- SMS通知システム

## 4. 画面設計（概要レベル）

### 4.1 管理者向け画面
- 予約管理画面
- 店舗情報設定画面
- 営業カレンダー管理画面

### 4.2 顧客向け画面
- 店舗検索・閲覧画面
- 予約作成画面
- マイページ（予約履歴）

ユーザー体験起点の要件定義ドキュメント例 👥

# レストラン予約システム 要件定義書
Version: 1.0
Date: 2025/4/10

## 1. ユーザージャーニーマップ

### 1.1 顧客のジャーニー
1. **認知フェーズ**: SNSや検索で予約システムを知る
   - タッチポイント: Google検索、Instagram、口コミサイト
   - ユーザーの感情: 興味・期待
   - ペインポイント: 良いレストランを見つけるのが難しい

2. **探索フェーズ**: システムにアクセスして店舗を探す
   - タッチポイント: トップページ、検索機能、フィルター機能
   - ユーザーの感情: 好奇心・比較検討
   - ペインポイント: 検索条件が複雑すぎると離脱する

3. **予約フェーズ**: 日時と人数を選択して予約する
   - タッチポイント: 空き状況カレンダー、予約フォーム
   - ユーザーの感情: 期待・不安
   - ペインポイント: 予約プロセスが長いと諦める

4. **事前準備フェーズ**: 予約の確認と変更
   - タッチポイント: 予約確認メール、マイページ
   - ユーザーの感情: 安心・期待
   - ペインポイント: 急な予定変更に対応できるか不安

5. **体験フェーズ**: 実際に来店して食事をする
   - タッチポイント: 来店確認システム、決済
   - ユーザーの感情: 満足・楽しみ
   - ペインポイント: 予約した通りの体験が得られるか

6. **事後フェーズ**: 体験を評価・共有する
   - タッチポイント: レビュー機能、SNS連携
   - ユーザーの感情: 満足・共有したい
   - ペインポイント: レビュー入力が面倒

### 1.2 店舗スタッフのジャーニー
1. 予約の確認と準備
2. 顧客対応と受け入れ
3. サービス提供
4. フィードバック受領

## 2. ユーザーインターフェース設計

### 2.1 顧客向けUI
- **ホーム画面**
  - 人気店舗のカルーセル表示
  - 位置情報ベースのおすすめ店舗
  - 簡易検索バー

- **検索結果画面**
  - フィルター機能（料理ジャンル、価格帯、評価など）
  - 地図表示切り替え
  - 検索結果のソート機能

- **店舗詳細画面**
  - 写真ギャラリー
  - 基本情報（営業時間、住所、電話番号）
  - 予約カレンダー
  - レビュー・評価
  - おすすめメニュー

- **予約フォーム**
  - 日付選択（カレンダー形式）
  - 時間選択（空き状況表示）
  - 人数選択
  - 特別リクエスト入力

- **予約確認画面**
  - 予約内容サマリー
  - キャンセルポリシー表示
  - 変更・キャンセルボタン

### 2.2 店舗管理者向けUI
- ダッシュボード
- 予約カレンダー管理
- 顧客情報管理

## 3. 機能要件

### 3.1 顧客向け機能
- 店舗検索機能
- 予約作成機能
- 予約管理機能
- レビュー投稿機能
- アカウント管理機能

### 3.2 店舗管理者向け機能
- 予約管理機能
- 営業設定機能
- 顧客管理機能
- 分析・レポート機能

## 4. ドメインモデル（抽出）

### 4.1 主要エンティティ
- 店舗
- 予約
- 顧客
- 営業時間
- レビュー

### 4.2 主要ビジネスルール
- 予約可能時間の計算ルール
- キャンセルポリシー
- 顧客ランク付けルール

要件定義アプローチの比較分析 📊

上記の2つの要件定義例から、両アプローチの特徴と違いを分析してみましょう。

出発点の違い 🚀

ビジネスルール起点 🏢	ユーザー体験起点 👥
🧩 ドメインモデルから始まる	🗺️ ユーザージャーニーから始まる
🎯 システムの「中心」から設計を始める	🖥️ システムの「外側」から設計を始める
📝 「何を」「どのように」処理するかに注目	🤔 「誰が」「なぜ」「どのように」使うかに注目
📊 データとその関係性を重視	❤️ 感情や体験を重視

ドキュメント構造の違い 📑

ビジネスルール起点 🏢	ユーザー体験起点 👥
📝 エンティティとビジネスルールの詳細定義が先頭に来る	🗺️ ユーザージャーニーと感情の流れが先頭に来る
⚙️ 技術的な仕様が詳細に記述される	🎨 UI設計が詳細に記述される
🖥️ 画面設計は最後に概要レベルで記述される	🧩 ドメインモデルは最後に抽出結果として記述される

想定読者の違い 👁️

ビジネスルール起点 🏢	ユーザー体験起点 👥
👨‍💻 主にエンジニアやアーキテクトが理解しやすい	👨‍🎨 デザイナーやマーケターも理解しやすい
💼 ビジネス部門との共通言語としてのドメインモデルを重視	👥 エンドユーザーの視点を重視
⚙️ 技術的な実装に直結する情報が多い	❤️ 感情や体験に関する情報が多い

アプローチの適合性 🎯

ビジネスルール起点が適している状況 🏢	ユーザー体験起点が適している状況 👥
📝 業務プロセスが複雑なシステム	🛍️ 顧客体験が競争優位性となるシステム
⚖️ 法令順守が重要なシステム	🚀 新規サービス開発
🔄 既存システムのリプレイス	📱 ユーザーインターフェースが複雑なシステム
⚙️ 技術的制約が多いプロジェクト	🔄 アジャイル開発を採用するプロジェクト

システム例：ECサイトの場合 🛒

ECサイトの要件定義を例に、両アプローチの具体的な適用方法を見てみましょう。

ビジネスルール起点でのECサイト設計 🏢

ドメインモデルの定義 🧩
- 商品（Product）：ID, 名称, 価格, 在庫数, カテゴリ, 属性
- 顧客（Customer）：ID, 名前, メールアドレス, 住所, 購入履歴
- 注文（Order）：ID, 顧客ID, 商品リスト, 金額, ステータス, 配送先
- 支払い（Payment）：ID, 注文ID, 金額, 支払い方法, 状態
ビジネスルール定義 📝
- 在庫管理ルール：注文確定時に在庫を減らす
- 価格計算ルール：数量割引、クーポン、送料計算
- 会員ランク制度：購入金額に応じたランク付け
ユースケース定義 📋
- 顧客が商品を検索・閲覧する
- 顧客が商品をカートに追加する
- 顧客が注文を確定する
- 管理者が在庫を管理する
UI設計 🖥️
- 商品一覧画面
- 商品詳細画面
- カート画面
- 注文確認画面

ユーザー体験起点でのECサイト設計 👥

ユーザージャーニーマップ作成 🗺️
- 認知（SNS広告から訪問）
- 探索（商品カテゴリ閲覧、検索）
- 検討（商品詳細確認、レビュー確認）
- 購入（カート追加、注文手続き）
- アフターフォロー（配送状況確認、問い合わせ）
UI/UXプロトタイピング 🎨
- ホーム画面のワイヤーフレーム
- 商品検索・フィルタリング機能
- 商品詳細ページのレイアウト
- カート・レジ体験のフロー
ユースケース抽出 📋
- ユーザーがカテゴリから商品を探す
- ユーザーが検索で商品を探す
- ユーザーが商品を比較検討する
- ユーザーが購入手続きを完了する
ドメインモデル抽出 🧩
- 商品モデル
- 顧客モデル
- 注文モデル
- 支払いモデル

結論 🎯

要件定義アプローチの選択は、プロジェクトの成功に直結する重要な決断です。オニオンアーキテクチャとクリーンアーキテクチャは、それぞれに強みがあり、状況に応じて使い分けるべきものです。

重要なのは、どちらか一方に固執せず、プロジェクトの特性に応じて柔軟に採用することです。 🔄

🏦 既存の業務システムの再構築や複雑なビジネスルールを持つシステムでは、ビジネスルールを起点としたアプローチが有効でしょう。
🛍️ 新規サービスや消費者向けアプリケーションでは、ユーザー体験を起点としたアプローチが効果的かもしれません。
🔄 多くの実プロジェクトでは、両アプローチを組み合わせたハイブリッドな方法が最適解となります。

理想的には、「ビジネスの本質を大切にしながらも、優れたユーザー体験を提供する」という両面を満たすシステム設計を目指すべきです。そのためには、要件定義の早い段階からプロトタイピングを活用し、ビジネスサイドとユーザーサイドの双方からフィードバックを得ながら、イテレーティブに要件を洗練させていくプロセスが効果的でしょう。

システム開発の成功は、技術選択だけでなく、プロジェクトの本質を見極め、適切な要件定義アプローチを選択することから始まります。アーキテクチャは目的ではなく手段であることを忘れず、プロジェクトの真の価値を実現するための最適な道筋を選びましょう。

参考リソース 📚

書籍：『Domain-Driven Design』by Eric Evans
書籍：『Clean Architecture』by Robert C. Martin
書籍：『実践ドメイン駆動設計』by Vaughn Vernon
The Onion Architecture by Jeffrey Palermo
The Clean Architecture by Robert C. Martin

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up