この記事はこんな人におすすめ
- OOUI（Object Oriented User Interface）の基本を理解したいデザイナー・エンジニア
- UI設計を“画面ベース”ではなく“オブジェクトベース”で考えたい人
- UX改善やプロダクト設計に体系的な思考を取り入れたい人
- MVC、Atomic Design、DDD（ドメイン駆動設計）との関係を整理したい人
記事の概要
OOUI（Object-Oriented User Interface：オブジェクト指向ユーザーインターフェース）は、
「ユーザーが操作する対象（オブジェクト）」を中心にUIを設計するアプローチです。
従来の“画面中心のUI設計”から脱却し、ユーザーの意図と現実世界の構造を一致させる設計手法として注目されています。
この記事では、OOUIの定義・背景・メリット・設計プロセス・具体例・他手法との違いを解説します。
この記事を読むと変わること（Before / After）
| Before | After |
|---|---|
| OOUIという言葉を聞いたことはあるが理解できていない | OOUIの基本概念と設計手順が明確になる |
| 画面単位でしかUIを考えられない | オブジェクト単位で、より柔軟で再利用性の高い設計ができる |
| 既存のUI設計手法との違いが曖昧 | MVC・Atomic Designとの関係が理解できる |
OOUIとは？（定義）
OOUI（Object Oriented User Interface）とは、「ユーザーが操作する対象＝オブジェクト」 を中心に構造化するUI設計手法です。
オブジェクトとは、ユーザーが使おうとしている目当てのもの。
従来のUI設計（画面中心）は「どんな画面をつくるか？」を起点に考えますが、
OOUIは「ユーザーが操作したい“もの”や“概念”は何か？」を出発点に設計します。
OOUIが注目される背景
- モバイルアプリやSaaSなど、複雑な操作対象を持つプロダクトが増加
- 画面ベース設計では、機能追加・スケール時にUIが破綻しやすい
- ドメイン駆動設計（DDD）やオブジェクト指向プログラミングと親和性が高い
OOUIの基本構造
OOUIは、UIを「オブジェクト（Object）」と「操作（Action）」で整理します。
| 要素 | 説明 | 例 |
|---|---|---|
| オブジェクト | ユーザーが扱う対象 | 顧客、商品、タスク、レポート など |
| 操作 | オブジェクトに対して行う行為 | 作成、編集、削除、共有 など |
つまりUIは、
「このオブジェクトに、どんな操作を提供するか？」という視点で設計します。
オブジェクト指向UIの原則
上野学さんの本では下記4つの原則が記載されています。
・オブジェクトを知覚でき直接的に働きかけられる
・オブジェクトは自身の性質と状態を体現する
・オブジェクト選択→アクション選択の操作順序
・すべてのオブジェクトが互いに協調しながらUIを構成する上野学さんの著書「オブジェクト指向UIデザイン 使いやすいソフトウェアの原理」
OOUI設計のプロセス（手順）
Step 1. オブジェクトの抽出
ユーザーが操作する実体（名詞）を洗い出す。
例：「顧客」「契約」「請求書」「タスク」など。
Step 2. 関係性を整理
オブジェクト同士の構造（親子・依存関係）を明確化。
例：「顧客」→「契約」→「請求書」
Step 3. 操作を定義
各オブジェクトに紐づく操作（動詞）を定義。
例：「請求書」→ 作成する・送信する・キャンセルする
Step 4. 表現とナビゲーション設計
ユーザーが自然にオブジェクトへアクセスできるようUIを配置。
タブ構造・カード構造などで直感的に行き来できるようにする。
OOUIのメリット
| メリット | 内容 |
|---|---|
| 一貫した体験 | 同じ種類のオブジェクトに一貫した操作体系を適用できる |
| 拡張性 | 新しいオブジェクトを追加してもUI構造を保てる |
| 再利用性 | UIパターンを部品化しやすくなる |
| 認知負荷の軽減 | ユーザーが「何を操作しているのか」が明確になる |
OOUIと他設計手法の比較
| 手法 | 中心概念 | 強み | 弱み |
|---|---|---|---|
| タスク指向UI（TUUI） | ユーザーの行動 | ワークフロー理解に強い | 対象構造が複雑になる |
| OOUI（本手法） | 対象（オブジェクト） | 構造化・一貫性に強い | 初期設計に時間がかかる |
| Atomic Design | コンポーネント構造 | UI部品の管理・再利用 | 機能と体験の関連が弱い |
タスク＝ユーザーが行いたい事
オブジェクト＝ユーザーが使おうとしている目当てのもの
OOUIとドメイン駆動設計（DDD）の関係
OOUIはDDD（Domain Driven Design）の考え方と非常に近く、
「現実世界の概念（ドメインオブジェクト）」をUIに反映する発想です。
- DDD：コードレベルでドメインをモデリング
- OOUI：UIレベルでドメインをモデリング
両者を組み合わせることで、ビジネスロジックとUIの整合性が高まります。
OOUI設計時の注意点
- オブジェクト抽出を曖昧にすると、構造が崩れる
- 操作を多くしすぎるとUIが複雑化
- ユーザー視点を失うと「技術的オブジェクト設計」になりやすい
🏠 不動産システムにおけるUI設計の2つの考え方
| 視点 | タスク指向UI（TUUI） | オブジェクト指向UI（OOUI） |
|---|---|---|
| 発想の起点 | 「ユーザーがやりたい作業」 | 「ユーザーが扱う対象（オブジェクト）」 |
| 設計の中心 | タスクフロー（To-Do） | オブジェクト構造（Entity） |
| 情報構造 | ワークフローに従って階層化 | 対象と関係性に基づいて階層化 |
| 特徴 | 一連の業務を手順通りに進める | どの対象からでも必要な操作にアクセスできる |
| 長所 | 業務効率化・教育しやすい | 拡張性・再利用性・一貫性が高い |
| 短所 | 機能追加で構造が複雑化 | 初期設計に時間がかかる |
🔧 具体例：「物件登録・契約・顧客管理」システムの場合
① タスク指向UIの設計例
ユーザーの操作フロー：
- 「物件を登録する」ボタンを押す
- 入力フォームを開いて登録
- 契約者を追加する
- 契約書を作成して送信
画面構造のイメージ：
ホーム
├── 物件登録
├── 契約作成
├── 顧客登録
└── 請求書発行
特徴：
- 各「操作（タスク）」がトップレベルで並ぶ。
- 新しい業務（例：退去手続き）を追加するたびに、メニューが増加。
- 操作導線が「業務単位」になっているため、構造が縦割り化しやすい。
日本の家電にみられる機能追加は、タスク指向UIが原因です。
新機能を追加するたびにボタンが増えることになります。
② OOUIの設計例
ユーザーの操作フロー：
- 「物件（オブジェクト）」一覧を開く
- 任意の物件を選択 → 関連する契約・顧客情報が表示
- 物件ページ内で「契約を作成」「顧客を追加」などの操作を行う
画面構造のイメージ：
オブジェクト中心構造
├── 物件（Property）
│ ├── 契約一覧
│ ├── 契約を追加
│ └── 関連顧客
├── 顧客（Customer）
│ ├── 契約履歴
│ ├── 請求書一覧
│ └── メモ
└── 契約（Contract）
├── 契約書PDF
├── 支払履歴
└── 更新処理
特徴：
- 「物件」「顧客」「契約」といった現実世界の実体（オブジェクト）を中心に設計。
- ユーザーは自分の興味対象（＝操作したいオブジェクト）から行動を始める。
- 「どの画面に行けばいいか」よりも、「どの対象を扱うか」で思考できる。
👀 UI体験の違い（例：賃貸契約を作成する場合）
| 項目 | タスク指向UI | OOUI |
|---|---|---|
| 行動の起点 | メニューの「契約作成」から始める | 「物件ページ」内で「新規契約」を押す |
| ユーザーの思考モデル | 「作業を始める」 | 「対象に対して操作する」 |
| 導線の数 | メニュー→フォーム→一覧（3ステップ） | オブジェクト→操作（1〜2ステップ） |
| 認知の焦点 | タスク（何をするか） | 対象（どれを扱うか） |
| 新機能追加時の影響 | メニュー構成が崩れる | 各オブジェクトに操作を追加するだけで済む |
💡 直感的に理解するポイント
OOUIでは「対象が主語」。タスクUIでは「動作が主語」。
💬 例：
タスク型：「契約を作成する」
OOUI型：「この物件に契約を追加する」
つまり、OOUIはユーザーの自然な思考プロセス（対象→行動）に沿う形で、現実世界の構造をそのままUIに投影するということです。
補足：UI設計観点の対比図
| 観点 | タスク指向UI | OOUI |
|---|---|---|
| 設計単位 | 操作・画面 | 対象・関係 |
| ユーザーの行動心理 | 手順思考 | 対象思考 |
| 情報設計 | ワークフロー中心 | オブジェクト中心 |
| 拡張性 | 低い（新タスク追加で構造崩壊） | 高い（オブジェクト追加で拡張可能） |
| 一貫性 | 機能ごとにバラバラになりやすい | オブジェクト単位で統一可能 |
まとめ
| 要点 | 内容 |
|---|---|
| OOUIとは | オブジェクト中心に設計するUI手法 |
| 狙い | 一貫性・拡張性・再利用性を高める |
| 実践ステップ | オブジェクト抽出 → 関係整理 → 操作定義 → UI設計 |
| 成果 | ユーザーが「何を操作しているのか」が明確で、自然な体験を作れる |
FAQ
Q1. OOUIはどんなプロジェクトに向いている？
A. SaaSや業務システムなど、データ構造が複雑で長期運用されるプロダクトに最適です。
Q2. OOUIはデザイナー向け？エンジニア向け？
A. 両方です。デザイナーは情報構造設計、エンジニアはドメイン構造設計に応用できます。
Q3. OOUIの学習におすすめの資料は？
A. 『Object-Oriented UX（Sophia Prater著）』、および国内ではGoodpatchやnote上の実践記事が参考になります。
コメント