2026年07月07日

非デザイナーでも知っておきたいOOUI（オブジェクト指向UI）の基本

UI/UX, システム開発, OOUI, フロントエンド

はじめに

「機能は満たしているのに、なぜか使いにくい」そんなアプリやシステムに触れたことはありませんか？

今回は、非デザイナーの方にこそ知ってほしいOOUI（オブジェクト指向UI）という設計思想についてお話しします。

私自身、普段は主にエンジニアとして活動する中で、OOUIを学んで良かったと感じることが多くあります。特に良かったことは、ソースコードだけでなく、システムやアプリケーション全体を「オブジェクト」という一貫した概念で捉えられるようになったことです。

以前、UI設計に携わった際に機能を詰め込むことに必死で、「どう設計すれば使いやすくなるのか」が分からず四苦八苦していました。その中で出会った書籍、『オブジェクト指向UIデザイン──使いやすいソフトウェアの原理』^[1]をベースに、非デザイナーでも実践できるUI設計の基本を解説します。

UIの設計思想

まずUIの設計思想についてです。UIの設計には、大きく分けて「タスク指向」と「オブジェクト指向（OOUI）」という2つのアプローチがあります。

タスク指向UIとは

タスク指向のUIは、ユーザーが行いたい「作業（タスク）」を起点に画面を設計するアプローチです。「自動精算機」や「ATM」のような一方通行の操作に向いた手法です。例えば、最初に以下のようなボタンが表示される写真管理アプリをイメージしてみてください。

「写真一覧」
「お気に入り登録」
「写真の編集」
「写真の削除」

「写真を削除」→「削除する写真を選ぶ」といったように、ユーザーはまず「やりたいこと」を選び、その後に対象となる写真データにたどり着きます。このように、「やること」を中心にUIを構成するのがタスク指向UIです。

タスク指向UIイメージ

オブジェクト指向UI（OOUI）とは

OOUI（Object-Oriented User Interface）は、ユーザーが関心を持つオブジェクト（モノ）を起点に設計するアプローチです。

例えば先ほどタスク指向UIの例で出した写真管理アプリをOOUIの設計にすると、最初に表示されるのは「写真一覧（オブジェクト）」です。

ユーザーはその中から写真を選び、

お気に入り登録
編集する
削除する

といった操作を行います。

つまり、「何をするか」ではなく、何に対して操作するかがUIの中心になります。

オブジェクト指向UIイメージ

著書では、

ほとんどの場合、UIはオブジェクト指向に設計されているべき

とされています。^[2]

多くのアプリケーションにおいて、ユーザーの関心は「何をするか」よりも「何に対して操作するか」にあり、オブジェクトを中心に据えたUIの方が、直感的で理解しやすいためです。^[3]

タスク指向UIとオブジェクト指向UIの比較

タスク指向のUI設計になる理由

今ではスマートフォンやパソコンのGUIをはじめ、誰もがOOUIのツールに触れています。それにもかかわらず、業務アプリケーションを中心に、タスク指向の使いにくいシステムが作られている現状があります。普段からOOUIに触れているにもかかわらず、いざ自分でツールのデザインを考えるとタスク指向のUIになってしまうのはなぜでしょうか？

理由として、開発プロセスそのものが、タスク指向UIが生まれる原因とされています。

システム開発ではまず、ユーザーの要求を整理するところから始まります。このとき定義するのが

「〇〇を登録したい」
「一覧を確認したい」
「検索したい」

といった「やること（タスク）」です。

さらに要件定義や設計では、これらをベースにユースケースや業務フローが作られていきます。つまり開発の初期段階から、システムは「タスクの集合」として捉えられやすい構造になっており、その結果、

「登録画面」
「一覧画面」
「検索画面」

といったように、UIもタスク単位で分割されがちになってしまいます。

開発プロセスの流れ

OOUIの設計ステップ

それでは、OOUIの設計プロセスを見ていきます。 OOUIを構築するための基本ステップは以下の通りです。

オブジェクトの抽出
ビューとナビゲーションの検討
レイアウトパターンの適用

設計ステップの実践

このステップに沿って、具体的な要件からOOUIを設計してみます。今回は、チームで使うタスク管理アプリを想定します。

要求は以下の通りです。

タスクを作成・編集・完了したい
タスクに担当者・期限・コメントを紐づけたい
プロジェクトごとにタスクを整理したい
メンバーごとの担当タスクを把握したい
タスクの状態（未着手・進行中・完了）を管理したい

1. オブジェクトの抽出

① 名詞の抽出

まず要求から名詞を抽出します。ここでは「操作（動詞）」ではなく「対象（名詞）」に注目することが重要です。

抽出した名詞：

タスク
プロジェクト
ユーザー（担当者・メンバー）
コメント
期限
状態

名詞の抽出

② 名詞と関係の整理、メインオブジェクトの特定

次に、それぞれの関係を整理します。

タスクはプロジェクトに属する
タスクはユーザーに割り当てられる
タスクには期限がある
コメントはタスクに紐づく
タスクは状態を持つ

ここで重要なのは、「ユーザーが操作したい・参照したい対象は何か？」という点を意識することです。この観点からUIの中心に配置するメインオブジェクトを特定します。

メインオブジェクト

タスク（最も頻繁に操作される）
プロジェクト（タスクのまとまり）
ユーザー（関係主体）

メインオブジェクトの特定

③ プロパティの設定

メインオブジェクトに付随する情報を、プロパティ（状態）として定義します。要求にはなくても、必要になるプロパティを想定して追加します。

プロジェクト

名前
タスク一覧
作成日
プロジェクト説明
ステータス

タスク

タイトル
説明
状態
期限
担当者
コメント一覧

ユーザー

名前
担当タスク一覧
メールアドレス
プロフィール
役割
登録日

プロパティ整理

2. ビューとナビゲーションの検討

① コレクションとシングルの定義

プロパティを定義してオブジェクト構造が固まったら、ビュー（画面）を設計します。

ビューは以下の2種類に分かれます：

コレクションビュー：複数のオブジェクトを一覧表示
シングルビュー：1つのオブジェクトの詳細表示

今回の例では以下のメインオブジェクトに対してのビューを設定します。

プロジェクト

コレクション：プロジェクト一覧
シングル：プロジェクト詳細

タスク

コレクション：タスク一覧
シングル：タスク詳細

ユーザー

コレクション：ユーザー一覧
シングル：ユーザー詳細

ここでビュー間の関係（遷移）を整理し、可視化すると理解しやすくなります。

ビューの整理

② ナビゲーションの設計

ナビゲーションには、ユーザーが頻繁にアクセスするオブジェクトのコレクションを配置します。

今回の例では：

プロジェクト一覧
タスク一覧
ユーザー一覧

となります。

3. レイアウトパターンの適用

最後に、各ビューを具体的なUIに落とし込みます。ここではゼロから画面を作るのではなく、世の中で一般的に使われている「UIデザインパターン」を、定義したオブジェクトの性質に合わせて選択・適用していく作業となります。代表的なパターンには、以下のようなものがあります。

リスト／カード：コレクションを表示する際の定番。
マスタ・詳細（分割ビュー）：左側に一覧、右側に詳細を表示する、PCの管理画面で多用される構成。
モーダル／ドロワー：コンテキストを維持したまま、特定のオブジェクトの編集や詳細表示を行う。

タスク

「コレクション」

上部：フィルタ（状態・担当者・期限）
中央：タスクカード一覧
- タイトル
- 状態
- プロジェクト
- 担当者
- 期限

「シングル」

メイン情報
- タイトル
- 状態（変更可能）
- 担当者
- 期限
サブ情報
- コメント一覧
アクション
- コメント投稿
- 状態変更

タスクUI

プロジェクト

「コレクション」

上部：検索窓
中央：プロジェクトカード一覧
- タイトル
- タスク数
- メンバー人数
- 進捗（タスク完了率）
- ステータス（プロジェクト単位）

「シングル」

メイン情報
- 名前
- プロジェクト説明
- ステータス（プロジェクト単位）
- メンバー人数
- タスク完了数
サブ情報
- タスク一覧
- プロジェクトメンバ一覧
アクション
- タスク追加
- プロジェクトメンバー追加

プロジェクトUI

ユーザー

「コレクション」

上部：検索窓
中央：ユーザーカード一覧
- 名前
- メールアドレス
- 役割
- 進行中のタスク数

「シングル」

メイン情報
- 名前
- 役割
- プロフィール
- 登録日
- 未完了のタスク
サブ情報
- 参画プロジェクト一覧
- 未完了のタスク一覧
アクション
- ユーザー情報の編集

ユーザーUI

以上のステップでUIの骨子が組み上がります。しかし、一度で完璧な設計にたどり着くことは少ないです。実際には、このプロセスを何度も行き来しブラッシュアップしていく必要があります。

ユーザーが「何をするか」を考える前に、目の前の「何をどうしたいか」を直感的に捉えられる形になるまで、オブジェクトの定義とレイアウトのパターンを練り上げていくことが大切です。

おわりに

OOUIは、「何をするか（タスク）」ではなく 「何を扱うか（オブジェクト）」を起点に設計する手法です。

今回例として挙げた要求はシンプルでしたが、実務ではもっと複雑な仕様が絡み合っていくことが多いです。

そこで、要求通りの「タスク」をただ画面に並べるのはなく、「オブジェクト」を掘り起こし、ユーザーが直感的に扱える形へと再定義することが必要です。

このOOUIの設計プロセスは、エンジニアにとってUIデザイン以上の価値を持つと考えています。DBやクラス設計で定義したモデルをUIに反映させることで、システム全体を一貫したオブジェクトの集合として捉えられるようになるからです。バックエンドから画面までが一本の線で繋がる感覚を持つことで、開発はよりロジカルで強固なものに変わると考えています。

『オブジェクト指向UIデザイン──使いやすいソフトウェアの原理』では、より細かい設計ステップや事例などが非デザイナーでも分かりやすいように紹介されていますので、興味のある方は是非手に取られてみてください。