OOUI
Object-Oriented User Interface
OOUI（オブジェクト指向UI）とは、ユーザーが操作する「対象（オブジェクト＝名詞）」を起点にして画面や機能を設計するUIデザインの考え方です。この言葉は、GUIが実用化されはじめたころ（1980年代中頃？）に登場したと記憶しています。当時はまだPCもCUIで、インターネットもブラウザもありませんでしたが、プログラミングのパラダイムとしてのオブジェクト指向は、その後の Macintosh や Windows のアプリケーション開発に必須の概念となりました。
OOUIの基本概念
- 名詞から動詞へ：
「オブジェクト（対象）を選んでから何をするか（操作）を選ぶ」という順序（名詞→動詞）で操作します。
- タスク指向UIとの違い：
従来のタスク指向UIが「何をするか（操作）を選んでからオブジェクト（対象）を選ぶ」（動詞→名詞）のに対し、OOUIは「何を」操作したいのかが最初に明確になります。
- 具体例：
メッセージアプリで友人（オブジェクト）を選んでから「送信」や「削除（アクション）」を選ぶ仕組みです。
OOUIの原則
- オブジェクトを知覚することができ、直接それを操作することができる
- オブジェクトは自身のプロパティ（属性・状態情報）をもって知覚される
例えば、今選択されいてるファイル（オブジェクト）が強調表示される・・など
- オブジェクトは自身に対するメソッド（操作機能）をもつ
- 接触の順序は、オブジェクトの選択 ＞ 操作の選択
- すべてのオブジェクトが自律分散的に協調する仕組みをもつ
OOUIを取り入れるメリット
- 操作が直感的：
日常の行動フローに近いため、マニュアルなしでも直感的に使える
- 作業効率の向上:：
画面の行き来や画面数が減り、目的に素早く到達できる
- 開発側のコスト削減：
オブジェクト単位で情報や機能が整理されるため、プログラムや画面構成がシンプルになります。
オブジェクト指向UIは、タスク指向UIという概念と比較することで、より理解しやすくなります。簡単な事例で紹介しましょう。
オブジェクト指向とタスク指向の簡単な比較
- オブジェクト指向（名詞→動詞：操作する対象からスタート）
- 商品を選ぶ ＞ お金を入れる / ICカードをタッチ ＞ ・・（新自販機）
キャンセルの場合、そのまま立ち去ればよい。
- 連絡したい相手を選ぶ ＞ 電話する / メールする ＞
- 画面上のファイルを右クリック ＞ コンテキストメニューから操作 ＞
パソコン・スマホの GUI は、基本的にオブジェクト指向です。
- タスク指向（動詞→名詞：操作対象は事後に登場）
- お金を入れる ＞ 商品を選ぶ ＞ ・・（旧自販機）
キャンセルの場合、「返却」操作をする必要がある。
- 受話器を取る ＞ 連絡したい相手の電話番号をプッシュする
- ログインする ＞ 必要項目を入力する ＞「次へ」を押して進む
オブジェクト指向
ユーザーに対して対象（オブジェクト）が開示されています。ユーザーはその全体を眺め（プロパティを確認し）、動かして（メソッドを確認し）、「ああすればこうなる」という因果関係を見出すことができます。
アナログの道具の大半は基本このタイプで、見て触ってみれば、何をどうすればいいのかが、体験的にわかります。危険な部分は見ればわかるので、事故のリスクも小さいと言えます。
タスク指向
ユーザーに対して対象は開示されておらず、システムがどんなプロパティ（設定情報）を持っていて、どんなメソッド（操作）が可能なのか・・その全体を事前に把握することができません。ユーザーは、入口（許可を要するケースもあり）から入ると、その後決められた手順に沿って候補の選択作業をすることになります。システムの全体が見えないので、自分がどこにいるのかもわからず、ただシステムに従うしかありません。
デジタル家電の多くが、このタイプに陥っています。ボタンの先に何があるかわからないまま、とりあえず押さないと先へ進めないし、むやみにあちこち触ると設定が変わって戻せなくなる・・。これが「使いにくい」の最大の理由です。また、何が危険かもわからないので、大事故につながるリスクがあります。
見た目の良し悪しの問題ではなく、根本的な設計思想の問題
使いにくい製品・・の最大の理由は、ユーザー視点ではなく、メーカー視点（いかに収益につなげるか）でインターフェイスが設計されているからです。その違いは、オブジェクト指向とタスク指向の違いとして説明することもできます。
プロプライエタリなものは、メーカー視点で設計されたタスク指向的なものが多いので、ブラックボックスの中を誘導に従って進むしかない。ユーザーにとっては、理解しにくく、使いにくいものとなります。
その点、オープンソースはユーザー視点で設計されたオブジェクト指向的なものが多く、ホワイトボックス化されているので、使いやすいものが多くなる・・これは当然の結果と言えます。
比較事例１｜パソコンとテレビ
CUIからGUIへの転換をしたパソコンがこれほど普及したのは、人間の「物に触れてから何かをする」という自然な振る舞いに近いオブジェクト指向を採用したからだと言えます。一方で、「まず必要な機能を呼び出すためのボタンを探す（タスク指向）」というテレビの操作系は、多くの機能を詰め込みすぎた結果、ユーザーの認知負荷を高めています。
テレビやレコーダーという家電製品は、GUIではなく、リモコンで逐次制御することを前提に設計されています。操作はリモコンから「見る / 録画する・・」といった機能（タスク）を先に選んで、その後で番組（オブジェクト）を探すという手順になっていて、この逐次操作（タスク指向）は非常にイライラするものとなります（ちなみにテレビのリモコンには「CTRL+Z」（ひとつ前の操作に戻る）もありません）。
最近のものでは「番組コンテンツ」というオブジェクトとして選んでから「見る / 録画する / 移動する / 削除する」などの操作もできるケースもありますが、それができることに気づきにくい・・。一方で、最近のスマートテレビのUI（NetflixやYouTubeのアプリなど）は、PCやスマホに近く、オブジェクト指向へとシフトしています。
- サムネイルの並び：
まず見たい「作品（オブジェクト）」が並び、それを選んでから「再生」「詳細を見る」といったアクションを選ぶ形式です。
- ポインティングリモコン：
LGのマジックリモコンのように、画面を直接指せるデバイスの登場により、家電でも「オブジェクト指向」的な操作が可能になりつつあります。
比較事例２｜Google Workspace と Teams
Google Workspace：オブジェクト指向（名詞 → 動詞）
Google Workspaceは、元々独立したウェブアプリケーション（Drive, Docs, Gmail, Calendar）を相互にハイパーリンクで結びつけた構造からスタートしています。
- 操作の軸
- 「どの情報（オブジェクト）を」（ドキュメント、スプレッドシート、予定） → 「どうするか / 誰と共有するか」（編集、コメント、Chatへ送信）。
- UIの特徴
- すべてのファイルやデータが「固有のURLを持つ独立したオブジェクト」として存在している。
- ドキュメントを開いたまま、サイドパネルでChatやCalendar、Keepなどの別オブジェクトを呼び出して操作できる。
- なぜオブジェクト指向に感じるか:
- 「まずGoogleドライブでファイル（名詞）を開く」→「そこでコメントや共同編集をする（動詞）」、あるいは「URLをコピーしてどこかに貼る」というように、オブジェクトを中心に人が集まる設計になっているためです。
Microsoft Teams：タスク・文脈指向（コンテキスト → アクション）
Teamsは「まずプロジェクトやチームという文脈（コンテキスト）に入り、そこで発生する会話やタスクを処理する」という構造になっています。
- 操作の軸
- 「誰と / どのプロジェクトで」（チャネル） → 「何をするか」（会話、ファイル共有、Plannerでのタスク管理）。
- UIの特徴
- チャネルという「部屋」の中に、会話・ファイル・Wiki・各種アプリがタブとして組み込まれている。
- ファイルは独立したオブジェクトというよりも、「チャネル内の議論に伴う添付資料」としての側面が強い（実体はバックグラウンドのSharePointに紐付く）。
- なぜタスク・文脈指向に感じるか:
- ユーザーは常に「今どのチャネル（文脈）にいるか」というステータス（モード）を意識して操作するためです。リモコンの例で挙げられた「モードの存在」に近い構造を持っています。
両者の設計思想の比較
| 比較項目 | Google Workspace | Microsoft Teams |
| 中心にあるもの | 実体・データ（Document / URL） | 場所・文脈（Team / Channel） |
| メンタルモデル | 〇〇の書類を開いて作業をする | 〇〇プロジェクトの部屋に行って仕事をする |
| 情報の集約方法 | URLで相互に「結びつける」ハイパーリンク） | チャネルの中にツールを「引き込む」（タブ追加） |
| UIの指向性 | オブジェクト指向（自立・分散型） | タスク・文脈指向（モード依存型） |
なぜこの違いが生まれたのか？
- Googleの出自
検索エンジン発祥のGoogleは、すべての情報を「フラットなデータ（URL）」として捉えます。場所（フォルダやチャネル）に縛られず、検索やリンク一本で目的のオブジェクトに到達し、その場でアクションを起こす「オブジェクト指向」が根底にあります。
- Teamsの出自
Microsoftはかつて「Outlook（メール）」と「SharePoint（ファイル保管）」と「Skype（会話）」で分かれていた体験を、「Teamsという一つの操作画面（ハブ）にまとめる」というタスク統合のアプローチをとりました。結果として、アプリや機能の切り替えを意識させる「階層的・タスク指向」のUIになっています。
それぞれのツールを使ったときに感じる「Googleはシンプルだがファイル単体が独立していて散らかりやすい」「Teamsは多機能だが目的の場所に辿り着くのにモードを意識させられる」という感覚は、まさにこの設計思想の違いから来ています。
比較事例３｜Wiki と Blog
Wiki：オブジェクト指向（名詞・概念中心）
Wikiは、「概念（ページというオブジェクト）がまず存在し、それが相互にリンク（ネットワーク）で結びつく」という完全なオブジェクト指向のUI/構造を持っています。
- 中心軸: 「トピック / 概念（名詞）」
- 構造: ネットワーク型（グラフ構造）
- UI/UXの特徴:
- 主役は「記事内容」: 誰が・いつ書いたか（時間や執筆者）は背景に隠れ、「その言葉・概念が何であるか」というオブジェクトそのものの定義が前面に出ます。
- 非時系列・永続的更新: 情報は時間の経過で流れ去るのではなく、同じオブジェクトに対して上書き・リファクタリングされ続けます。
- Wikiリンク（内部リンク）: オブジェクトとオブジェクトを双方向に結びつけるメタファそのものです。
Blog：ログ/イベント指向（時間・動詞中心）
Blog（Web-log）は、「誰が・いつ・何を発言/作業したか」という時系列（ストリーム）を記録する構造を持っています。
- 中心軸: 「時間・出来事（タイムライン）」
- 構造: 時系列リスト型（リニア・ストリーム構造）
- UI/UXの特徴:
- 主役は「文脈と時間」: 「今何が起きたか」「筆者がその時どう考えたか」という時間の経過（イベント）が最優先されます。
- ストリーム型（フロー情報）: 記事は投稿された瞬間が最も価値が高く、新しい記事が入ると古い記事は奥底へ押し流されます。
- ストックの難しさ: 同じテーマについて後から追加情報が出た場合、既存ページを書き換えるのではなく「続編」という新しい時系列の動詞（投稿）を重ねる傾向があります。
APPENDIX
関連ページ
