OOUI の目当て

OOUI の目当てについて考えたいと思います。

私はここで「目当て」という言葉を「オブジェクト」の訳語として使っています。このタイトル自体に同語反復的な響きを持たせてみたのです。

OOUI は「オブジェクト指向ユーザーインターフェース」のことですから、OOUI について考える上ではオブジェクト指向とは何かということについて考える必要があります。するとさらにオブジェクトとは何かというところまで遡って、このコンセプトの本質を見ていく必要があるのです。

そこで、O（object）、O（oriented）、OO（object-oriented）、U（user）、I（interface）、UI（user interface）、OOUI（object-oriented user interface）という風に言葉を分解して、それぞれの意味を確認しながら、OOUI の目当てを探っていきます。

オブジェクト指向が一時的な流行語ではなく、ソフトウェア開発の世界に自然に浸透していったのはそれが人間の自然本来の考え方であり、根源的なものであり、普遍性がある考え方だからなのです。

Object

まず「Object」について見てみましょう。

オブジェクトというのは日本語にするのがとても難しい言葉です。英和辞典を見ると、物体、対象、目的、目標、客観、客体、異議を唱える、といった意味が載っています。日本語ではこのように色々な言葉になってしまいますが、オブジェクトにはこれらすべてがひとつにまとまっているのです。

オブジェクトの語源を調べると、「ob-」と「-ject」に分けられるようです。「ob-」というのは「toward, to, on, over, against」とった意味合いで、「その方へ」といったニュアンスになります。「-ject」というのは「thrown」で、「投げられた」といったニュアンスです。

つまり「object」の語源的なニュアンスは「その方へ投げる」となります。この図のように、私がいて、その前に何かが投げかけられている感じかと思います。映画などの裁判のシーンで「オブジェクション（異議あり）」と言うのも、ある主張に対して客体としての異議を投げ込んでいるという構図になるのでしょう。

オブジェクトは日本語にしづらいですから、この先に「オブジェクト」という言葉が出てきたら、頭の中で日本語にしようとせず、この図の感じを思い浮かべてください。この白い丸が、オブジェクトです。

オブジェクトという言葉を聞いて、英文法の基本構文のひとつである「SVO」を思い浮かべる人もいるでしょう。Object は、「S-主語」「V-動詞」「O-目的語」のうちの「目的語」にあたります。この三つの要素を使って、私が持っている「オブジェクト」というもののイメージを描いてみたのがこれです。

まず下に並んでいる人間が、我々であり、「Subject」です。サブジェクトという言葉にも「-ject」が含まれていることに注目してください。「sub-」というのは「下に」という意味合いですから、サブジェクトというのは、語源的には「下に投げる」という感じのニュアンスになります。

サブジェクトは「サブ」ですから、主ではなく「副」なのですが、日本語では「主体」「主語」「主観」のように訳されます。これは、オブジェクトが対象として「見られるもの、知られるもの」であるのに対し、サブジェクトが「見るもの、知るもの」という視点の主（ぬし）であるということから、そう訳されるわけです。このことが、日本人にとって、西洋的な世界観におけるオブジェクトとサブジェクトの関係をわかりにくくしているように思います。

サブジェクトは我々一般の人々のことであり、それのニュアンスは、君主によって支配される臣下のことなのです。そのような「下々」の立場と視点、世俗、日常、話題、といったものが、オブジェクトのような高尚な存在に対する、移ろいやすく感覚的な者たちの様子として表されるのです。

一方、Verb は「動詞」ですが、これには「言葉」という意味もあります。その語源には「主張」や「指令」といったニュアンスがあり、つまり君主的な立場から臣下に対して一方的に投げ下ろされる命令なのです。この「言葉」によって、我々サブジェクトが統率されたり、その中での日常的な話題の交換をしているのです。

これら Subject と Verb とは一線を画して、その天上にある、観念的、客体的、理想的な場所に、オブジェクトが掲げられています。オブジェクトは我々の生活的な会話や利己的な駆け引きとは別なレイヤーで、確固として、真善美の普遍妥当な価値を保持しています。

このような Subject – Verb – Object の構図をイメージしていて、私は、有名な「洞窟の比喩」を思い出しました。

洞窟の比喩とは、古代ギリシャの哲学者プラトンがイデア論を説明するために用いたものです。それは、我々が住んでいる世界は洞窟の中であり、そこから出ることはできない、というものです。洞窟の外には真実の世界（イデアの世界）があるが、我々はそれを直接見ることはできず、我々が見ているものは全てイデアの影に過ぎない、というのです。

イデアとはもちろん、「アイデア」のことです。

プラトンのこのような世界認識は実在論と呼ばれます。全てのものにはまず本来の姿 ＝ イデアがあり、そこから個別のものが生じているという考え方です。一般（観念、抽象、型、真理、本質、類）から、個別（個体、具象、物質、感覚、現象、様態）が現れるという方向性です。

実は西洋哲学の源流にあるこのようなものの捉え方が、オブジェクト指向に関係してくるのです。

Oriented

次に「Oriented」について見てみましょう。

オリエントというのは「東方の」「東洋の」という意味ですが、語源的には「日が昇る方」というニュアンスのようです。そこから、「本来の方向」「方角」「方針」「方向を定める」「意識を向ける」「指向する」といった意味になりました。

ここで面白いのは、オブジェクトという言葉にも「その方へ投げる」というベクトル性があり、オリエントにも「方向」というベクトル性があるところです。「Object-Oriented（オブジェクト指向）」と言った場合、同語反復的な再帰性が生じているのです。

Object-Oriented

ではその「Object-Oriented」について見てみます。

Object-Oriented ＝ オブジェクト指向は、1960年代にソフトウェア開発の分野で考案されたプログラミング技術です。

最初のオブジェクト指向プログラミング言語は1962年に作られた Simula というものでしたが、「オブジェクト指向」という言葉を最初に使ったのは、1970年代に Xerox のパロアルト研究所でパーソナルコンピュータの原型を作ったアラン・ケイだと言われています。

1972年の Smalltalk、1979年の C++ などによってオブジェクト指向プログラミングは発展していき、現在では、メジャーなプログラミング言語のほとんどがオブジェクト指向の考え方を取り入れています。

オブジェクト指向プログラミング（OOP）は、データとコードを基本要素にしてそれらの相互作用によって処理を行うものです。これは、複雑化するソフトウェア開発を効率化するために考えられた仕組みで、生物の細胞をヒントにしたものだと言われています。

オブジェクト指向とは、オブジェクト自身が自分が何をできるのか知っているという意味である。

オブジェクト自身が自分が何をできるのか知っているというのは、データと動作がパッケージになっているということです。これにより、処理に必要なデータと動作を別々に管理したり呼び出す必要がなくなります。このパッケージを、オブジェクトと呼びます。オブジェクト指向のプログラムでは、沢山の小さなオブジェクトの集まりによる相互作用によって、大きな構造体を動かしていくのです。

オブジェクト指向プログラミングでは一般的に、オブジェクトの型を「クラス」と呼びます。クラスはオブジェクトの元となる概念的な存在です。このクラスから、実体的なオブジェクトである「インスタンス」を生成していきます。

例えば、プログラムの中に「犬」オブジェクトを登場させたければ、まずその型となる「犬クラス」を作ります。犬という概念には、名前、色、声といった属性があるでしょう。これらを「犬」のプロパティと呼びます。また「犬」には、走ったり、鳴いたり、食べたりするという一般的な振る舞いが想定されるでしょう。これらが「犬」の動作になります。

プログラムの中で実際に犬を動かすには、「犬クラス」からその実体である「犬インスタンス」を生成します。その際に、各プロパティについて「名前＝ポチ」「色＝茶色」「声＝ワン」と言った具体的な値（データ）を付与します。

ひとつのクラスから、値の異なる複数のインスタンスを作ることができますが、その動作は共通しているものと考えます。

生成された「名前＝ポチ」のインスタンスは、すべての犬に共通の動作として「鳴く」ことができます。ポチが持っている「鳴く」という動作を呼び出せば、ポチはその声である「ワン」を使って鳴くというわけです。

この「クラス → インスタンス」の生成順序は、先に紹介したプラトンの実在論とそっくりなのです。まず一般としてのクラスを作り、そこから個別としてのインスタンスを作る。この考え方で、オブジェクト指向プログラミングでは、複雑なソフトウェア世界の構成要素を効率的に組み立てるのです。

クラスとインスタンスの関係が GUI の画面にどのように反映されるのか、簡単な例を見てみます。

例えば「Document」という概念があり、クラスとして存在しているとします。Document には、Title、Content、Date といったプロパティがあります。また Close、Save、Print といった動作があります。

Document クラスからインスタンスを生成すると、それが書類のウィンドウとして画面上に現れます。そしてそこには具体的な「Title = Test Note」「Content = Hello world.」「Date = Feb 23, 2019」といった属性の値が付与されています。

そしてメニューを開くと、Document クラスが持っている Close、Save、Print といった動作が見えるというわけです。

オブジェクト指向で作られたアプリケーションは、何百何千というオブジェクトの集まりでできています。例えば iOS アプリにおけるボタンを見てみます。

iOS でボタンを作るには UIButton というクラスを使います。UIButton クラスからインスタンスを生成すると、具体的なひとつのボタンになります。そのボタンの構成要素を細かく見てみると、背景色には UIColor というクラスが使われていますし、アイコンの部分には UIImage というクラスが使われています。またラベルの部分には UILabel というクラスが使われていて、それをさらに分解すると、文字列を扱う NSString クラス、フォントを扱う UIFont クラス、色を扱う UIColor クラスなどが使われています。

このように、アプリケーション世界の全てが、大小のオブジェクトの集まりとして組み立てられているのです。

次にプログラミングの記述法についてみて見ます。

手続き型プログラミングの構文では、Verb（動作）→ Object（対象物）の順に記述するのが普通です。例えば PHP で「hello という文字列を大文字にする」という命令を手続き型に記述すると、次のようになります。

strtoupper( 'hello' )

ここでは、まず strtoupper（大文字にする）という関数名を先に書き、その後に ‘hello’ という対象物を書いています。

一方、オブジェクト指向プログラミングの構文では、Object（対象物）→ Verb（動作）という記述順序になります。例えば JavaScript で同様に「hello という文字列を大文字にする」という処理を記述すると、次のようになります。

'hello'.toUpperCase()

ここでは、まず ‘hello’ という対象を書き、その文字列オブジェクトが持っている toUpperCase（大文字にする）という動作を後に書きます。

この Object → Verb という順序性が、オブジェクト指向における重要なポイントになります。まず対象としてのオブジェクトを定めて、次にそのオブジェクトが持っている動作を指示するということです。

ところで、哲学の分野では昨今、オブジェクト指向存在論（Object-Oriented Ontology）というものが注目されています。これは、オブジェクト指向プログラミングのような観点で、存在論という哲学的テーマを展開するものです。

その第一人者であるグレアム・ハーマンは、オブジェクトについてこのように言っています。

オブジェクトはただそれらの自立的な実在性だけによって定義される。

存在論としてオブジェクトを捉えようとする上ではまず、ハイデガーの有名な道具分析について見てみるのが良いでしょう。ハイデガーは「ものが在るとはどういうことか」を説明する中で、道具というものの本質について深く考えています。

例えば我々がペンを使って何かを書いているとします。ペンには、白い色だとか、つるつるした表面だとか、ちょうど良い重さといった、その物の物質的な特徴があります。これを手前存在（事物的存在）と呼びます。

そしてそのペンが思い通りに使えている時には、それらの感覚的な性質は我々の意識から失われ、ペンの存在は隠れたものになっていきます。そして我々の意識はペンではなく、書いている内容そのものの方へ向けられます。そのような状態を、手元存在（道具的存在）と呼びます。

そしてひとたびペンのインクが切れたりしてうまく機能しなくなると、隠れていたペンの性質が意識にのぼり、それはまた事物的存在になるのです。

このように、道具が本当にうまく機能している時というのは、それは道具的存在になって消えてしまう。物にはそういう隠れた本質の姿 ＝ 実在性があるのです。

そのような考え方を、ハーマンはさらに発展させます。道具のように手にとって扱うものだけでなく、世の中のあらゆる物、空想上のものや概念的なもの、我々の意識において対象となるすべてのものについて、ハーマンはそれらを「オブジェクト」と呼び、オブジェクトを手がかりとした世界の見方を提起しています。

例えばこれはハーマンによる「四方界」の図です。あらゆるものには、このように「実在的対象」「実在的性質」「感覚的対象」「感覚的性質」という4つの存在性があるのだと言います。

これらひとつひとつの意味についてハーマンは著書の中で詳しく説明していますが、いずれも抽象度の高い観念的な表現になっていて、なかなか簡単には理解できません。

そこで私は、ハーマンの四方界を我々が親しんでいるオブジェクト指向プログラミングの言葉で言い換えてみました。それが次の図です。

実在的対象を「プログラムとしてのクラス」、実在的性質を「プログラムとしてのインスタンス」、感覚的対象を「UIとしてのクラス」、感覚的性質を「UIとしてのインスタンス」、という具合に言い換えてみました。

こうしてみると、それぞれの意味合いと関係性がすっきりしてきます。この解釈でハーマンの説明を読むと、随分わかりやすくなるのです。

私の解釈をもう少し具体的にすると、この図のようになります。

まず右下の「UIとしてのインスタンス」について。これは一件のツイートのキャプチャです。そこには特定のユーザー名やアイコン、内容の文字列、特定の色や形などが見えています。つまりUIとして我々が知覚できる性質がそこにあります。

このようなひとかたまりのUIを見ながら我々は、ツイートという概念を認識しています。それが左下の「UIとしてのクラス」です。ツイートというものには、ユーザー名、アイコン、内容といった共通した属性があるという認識です。

しかし同時に我々は、今見ているツイートと、その前後にあるツイートは「別のツイートである」ということも知っています。それはなぜかといえば、ツイートはひとつひとつが別のインスタンスであるということを暗黙的に理解しているからです。それが右上の「プログラムとしてのインスタンス」です。一般的なユーザーがなんとなく認識しているのはこのレベルまででしょう。

そしてプログラマーやデザイナーであれば、そのプログラムとしてのインスタンスの元になっている型として、左上の「プログラムとしてのクラス」を認識することができるでしょう。これは一般的なユーザーの視点からはアクセスできないものです。けれど我々は、ツイートの具体をアプリケーション世界の中に生み出す「イデア」として、これが確かに存在していることを知っているのです。

このようなオブジェクトの実在性について考える時、私はアレグザンダーの『パタン・ランゲージ』を思い出します。

クリストファー・アレグザンダーは、都市や建築のデザインの周囲に生じている、ある種の名状し難い良い感じ ＝「無名の質」を集め、それらをデザインパターンと呼んでまとめています。

そのパターンのひとつに「柱のある場所」というものがあります。

柱というのは通常、屋根や建物を支えるために作られますが、その存在には、もっと多くの意味性があるというのです。例えば柱には、それを中心にひとつの空間を作り出すという性質があります。そして人々がその空間に集い、テーブルを置いたり、寄りかかっておしゃべりをしたりするのです。

そのような空間をより良く作るためには、柱にはある程度の太さが必要となります。技術の進歩によって、もっと細い柱で同じだけの強度を出せるとしても、細い柱に対して人々はそれを避けて動く傾向があることから、有意義な空間が失われてしまうのだといいます。

つまり物には、それを作った人の意図とは無関係に、環境との融即から生じてくる実在があるのです。その物がいったい何であるかというのは、それを作る人には決めることができないのです。

ですから、要求とデザインの適合というものは、そこへ向かっていかなければ現れてこないものなのでしょう。あらかじめ適合があるというよりも、進みながら適合を作っていくのです。全体の状態から部分を定め直し、部分の状態から全体を定め直す。この繰り返しです。

道具を作るというのは、自分の一部でありながら自分ではないもの、自分の一部と環境の一部が結晶した特殊な存在者を生み出す行為だと言えます。この存在者は人と環境の間から現れ、我々の社会を変化させ、我々を変化させます。

アレグザンダーは、デザインという行為にまつわる「何が問題か」と「どのように解決するか」という二つの事柄の両方ともが、「的確に表し得ない」ものだと言っています。そのため良いデザインのためには、まず世界においてどのような「無名の質」があるのかというパターンを見出すこと、そして、物を作る意図だけでなく、その物自体の存在性についてデザイナーはよく考えるべきなのです。

デザインの視点を制作者の文脈から物自体の存在へ移すということについて、興味深い例があります。オブジェクト指向プログラミング言語の Smalltalk では、慣習的に、開発者がオブジェクトのプログラム内容に関してコメントを書く際、そのオブジェクトの立場になって、オブジェクトから見た一人称で記述するそうです。

例えばこのキャプチャでは、カーソルのプログラムに関するコメントで、開発者はカーソルというオブジェクト自身になったつもりで「I am a 16 x 16 dot matrix…」 というふうにコメントを書いています。

オブジェクト指向においては、主体（サブジェクト）と客体（オブジェクト）の視点が転回し、「客体が主体的に扱われる」のです。これを私は「構文論的転回（Syntactic Turn）」と呼んでいます。

世界の捉え方についての構文論的転回こそが、オブジェクト指向がもたらしたパラダイムシフトなのです。

User

次に、「User」について考えてみます。

ユーザー中心設計（UCD）やデザイン思考などのアプローチが注目されて随分経ちます。そこでよく言われるのは、デザイナーはユーザーの視点に立って、ユーザーに共感することで、プロダクトの実際的な利用文脈や問題点を知ることができる、ということです。

これはユーザーのニーズや潜在的な課題を見つけようとする姿勢として重要なことですが、一方で、それだけでは良いデザインを発想することはできないだろうと考えます。もしデザイナーが本当にユーザーの感覚に同調し、単にユーザーの要求に応じるだけであったら、あるいはユーザーが置かれた状況の中に完全に同化してしまったら、デザイナーはユーザー以上の視点を持ち得ず、アイディエーション（イデアを作る）のためのバイアス破壊ができなくなってしまうからです。

問題の本質を見極めてその核心に対してアプローチするには、デザイナーはユーザーに同化するのではなく、ユーザーとその状況をプロの視点から解釈し、「ユーザーが理解していることを理解する」必要があるのです。これを「二次的理解」と言います。

ユーザーを中心として、ユーザーがプロダクトを利用する文脈的環境の全体像 ＝ プロダクト環境というものを客体として主体的に捉え直すこと。そうすることで見えてくる本質についてデザイン的なアプローチをとること。これが本当の「ユーザー中心設計」なのだと私は考えます。

ここでもやはり、「客体を主体的に捉える」というオブジェクト指向的なパースペクティブが重要になるのです。

デザイナーの役割は、ユーザーの問題解決を肩代わりすることではないし、またそうすることもできないのです。できると考えているならそれは驕りでしょう。デザイナーの役割は、新しい意味を見出す余地を与えることです。道具を作りユーザーに提供するということは、つまり、ユーザーが「自分でやり方をデザインできるようにする」ということなのです。

Interface

では次に「Interface」に話を移しましょう。

人間の歴史とは人工物の歴史であり、まるで地球が巨大なデザインスタジオであるかのようだ。人工物はインターフェースであり、人間と世界が違ったかたちで関わり合えるようにする。

人間の歴史は道具の歴史です。人間は道具を作り、使うことで、環境との関わり方をアップデートし続けてきました。その意味で、人工物というものは全て、我々人間と環境との間のインターフェースなのです。

そしてその人工物によって我々自身の視点が変更され、環境が違った形で我々に関わってくるという意味で、人、人工物、環境、の三者ははっきり区別できるものではなく、一体の相互作用として、我々の世界認識を作り上げているのです。

技術は人間によって発明されたのではない。むしろその逆である。

この写真は、330万年前の石器で、現在見つかっている中で最も古いものです。330万年前というと、ホモ・サピエンスが登場するよりも前、まだ猿人の時代です。つまり、道具の歴史というのは、我々現生人類の歴史よりもずっと古いのです。

よく言われることですが、人の知能が発達したことで道具が作られるようになったのではなく、道具を作ることで人の知能は発達したのです。人間が道具を作ったのではなく、道具が人間を作ったのです。

道具をうまく操り、それが自分の身体の一部のようになっている時、その自己帰属感と身体拡張感は道具の手元存在性を強めます。そして身体をコントロールすることと環境をコントロールすることが同質化していきます。この状態をオブジェクト指向的に主客統合した観点で捉えると、自分の拡張として道具が帰属するのではなく、むしろ道具のインターフェースとして自分が接続されるのだと言えるでしょう。

道具というものが、世界との関わり方、世界というものに対する我々の認識を鏡のように反映するなら、そのインターフェースこそが、我々にとっての世界であり、同時に我々自身の投影なのです。

顧客の立場から見る限り、インタフェースが製品そのものなのです。

ソフトウェアにおいて考えれば、ユーザーは常に、インタフェースを通じて製品を利用します。インターフェースを通じてしか、ユーザーは製品とインタラクトすることができません。ユーザーはインターフェースからその製品を知覚し、その性質や意味を捉えます。

その意味で、ユーザーから見る限り、インターフェースが製品そのものなのです。

User Interface

ということで、「User Interface」です。

現在のユーザーインターフェースという概念が生まれる前、機械化時代においてはまず、産業機械などを人が遠隔的に運転するための操作盤として「マン – マシン インターフェース」という概念が生まれました。それはこの図のように、人がその操作盤を使って一方的に機械を動かすという構図でした。

やがて技術が進歩し、コンピュータのようなインタラクティブな装置が現れると、人（ユーザー）とコンピュータの間でその相互作用を媒介する面として、それは「ユーザーインターフェース」という概念に変化してきました。

特に1980年代後半からパーソナルコンピュータとGUIが普及すると、ユーザーインターフェースは仮想的な作業空間として捉えられるようになってきました。

ブレンダ・ローレルは、ユーザーインターフェースを単なる面ではなく、人とコンピュータの特性的な差異を吸収しながら作業の全体像を演出する存在として、この図のように空間的な概念として表しました。

この10年のスマートフォンの普及、そしてそのアプリを介した様々なサービスの隆盛は、我々の生活、仕事、遊びなどのあり方をますますソフトウェアのインターフェースに反映させています。今、我々は一日の多くの時間をソフトウェアの中で過ごしています。

例えばスマートフォンやパソコンを使って何かをしている時、我々はもはや、ユーザーインターフェースを媒介にしてその向こうにあるコンピュータやネットワークを遠隔的に操作しているという意識をほとんど持ちません。掌の中に見えているフレンドの存在にはリアリティがありますし、スクリーンに並ぶ書類のアイコンは仕事の対象である書類そのものなのです。

そこで私はブレンダ・ローレルの図をアップデートし、ユーザーインターフェースというものを、ユーザーとその関心の対象（オブジェクト）を直接接着しているものとして描いてみたいと思います。我々にとって今やインターフェースはオブジェクトそのものとして知覚され、身体性の一環として我々の世界認識に結合しているのです。

ハーマンが言うように、あらゆるものはオブジェクトとして考えることができます。それは、あらゆるものがデザイン可能であることを意味します。実際、あらゆるものはデザインされているのです。たとえそれが人工物ですらなくても、たとえば宇宙も、デザインされているのです。

つまりデザインとは、我々が何かを対象化した時に見出している形相のことでなのです。我々が何かにそれ自体の実在（リアル）を感じた時、それはデザインされるのです。デザインの対象が広がるということは、自分のリアルが広がるということなのです。

OOUI

それではいよいよ、「Object-Oriented User Interface」について考えていきます。

本題である「OOUIの目当て」は、ここまでの話で明らかになっているでしょう。

近代化以降のデザインの多くは、サブジェクティブなベクトルで発達してきたと言えます。それはつまり、デザインというものを、顕在化した課題に対する即物的な解決策として狭く捉えること。システム全体のインテグリティを軽視して部分最適化を偏重すること。テクノロジーによって人々の射幸心を狡猾に刺激し、その行動を支配して盲目的な消費欲を増幅させること。権力者の要求に合わせてその他の人々を一方的なタスクに従属させること。

そのようなゴールを動機とした「サブジェクト指向」のデザインは、人と道具の相互発展的なスパイラルを分断し、仕事から創造性を奪い、我々を搾取構造のバブルに閉じ込めてしまうのです。

OOUI によるオブジェクティブなデザインの目当ては、その構造を脱することです。

ユーザーインターフェースという言葉には、コンピュータスクリーンという意味は含まれていません。使う人とその対象を繋ぐものはすべてUIです。対象には色々なものがあるでしょうが、そもそも扱うべき対象 ＝ オブジェクトが「在る」という前提そのものが、ユーザーインターフェースの概念なのです。UIははじめから存在論的であり、オブジェクト指向なのです。

だから極端に言えば、サブジェクティブ ＝ 従属的に行動するだけのシステムに、ユーザーインターフェースはないのです。そこにあるのはタスクだけです。

オブジェクティブなデザインとは、ユーザーが対象へ直接的にアプローチできるようにするものです。それはつまり、人々をそれぞれの目当てに接続すること。ユーザーが自分なりの方法で目的に向かっていけること。行動の可能性を解放し、その道具を使うことで仕事や遊びに対する自身の意味空間を創造できるようにすること。思弁性をもって潜在的な課題に取り組み、道理をわきまえ、異なる視点を得られるようにすること。

OOUI の実装は、2000年もの昔から繰り返されてきた実在論という思考実験を次の段階に進めることを意味します。そんなことは不可能と思われるかもしれませんが、ソフトウェアの世界ではそれが可能なのです。ここまで見てきたように、オブジェクト指向のパラダイムにおいて、ソフトウェアデザイナーはイデアをデザインする能力を持つのです。そしてその実在的対象をもってユーザーの掌に感覚的性質を表象することができるのです。

OOUI は我々の仕事を捉え直すものとなります。多くの仕事には決められた手順がありますが、手順をなぞることが仕事なのではありません。OOUI のデザイナーは、仕事の本質を見極め、作業に別の意味を与えるのです。業務の形骸を暴き、それを創造の場へとリフレームするのです。

そのような意味で、我々の生活時間がさらにソフトウェアに結合していくこれからの時代、デザイナーは、OOUI のパースペクティブから新しい世界認識を提起していく役割を担っているのです。

このイラストでは、オブジェクトベース（オブジェクティブ）のUIと、タスクベース（サブジェクティブ）のUIとの対比がわかりやすく示されています。

オブジェクトベースのUIでは、ユーザーに対してオブジェクトを直接開示します。ユーザーはそれらを手にし、眺め、動かしてみて、そこから自分なりの意味性を取り出します。そこでは、システムはユーザーの側に属していて、手元存在として目的（オブジェクト）の前に透明になっています。

仕事の対象がそこに見えていて、それに対して行えるアクションが見えていて、その結果の状態が常に見えるようになっていれば、ユーザーはその道具を使ってできること、その道具の役割を自ら発見し、妥当性を感じながら仕事を組み立てることができます。そのような仕事は楽しいものです。

一方タスクベースのUIでは、入口でまず謎の人格が立ちはだかります。ユーザーはその人格に、オブジェクトにアクセスするための許可を求めなければいけません。システムは事業者や権力者という人格に属しており、ユーザーは、その人格が企図した形でしかそれを使うことを許されません。タスクベースのUIは、そうしたある種の傲慢さを常に纏っています。

タスクベースのUIでは、ユーザーが一番に意識しなければならないのは決められたタスクのことであり、システムは手前存在として目的を覆う障害物になってしまうのです。

GUI の特徴は、オブジェクト（物）ベースであることです。スクリーンを二次元空間として扱って、そこに視覚的な対象を配置し、ユーザーがそれらを直接的に操作できるようにしたものです。

一方、コマンドラインのUIはタスク（やること）ベースであり、スクリーンを一次元的なリストとして扱って、そこに、入力したコマンド文と出力結果を表示していくものです。

GUIの歴史は、1963年にアイバン・サザランドが開発した「Sketchpad」から始まります。これは画面に表示されたグラフィック要素をライトペンで直接的に指し示してCADのような操作ができるもので、GUIのアイデアの起源と言われています。

その後 Sketchpad に影響を受けるかたちでダグラス・エンゲルバートの研究チームが開発したNLSは、より洗練されたビットマップディスプレイとマウスを備えており、スクリーンを仕事空間に見立てて、そこに表示された様々な情報オブジェクトにランダムにアクセスしながら作業を進めていくという操作体系を作り上げました。

1970年代になると、Xerox PARC でアラン・ケイを中心に Smalltalk が開発されます。オブジェクト指向プログラミング環境およびGUIベースのOSというアーキテクチャが明確になり、パーソナルコンピュータの最初の完成形となりました。

Smalltalk では、オーバーラッピングウィンドウ（複数の作業をウィンドウという重なり合う矩形で現す）による仕事空間の表現や、カット＆ペースト、およびアンドゥによるモードレスな操作性が生まれ、後の Macinotsh や Windows などのUIに大きな影響を与えました。

UIの振る舞いがモードレスであるということは、それまで一般的であったコマンドベースのものに対する、GUIの大きな特徴となりました。例えば「カット＆ペースト」は、文字列を移動するための操作からモードを無くすために発明されました。それまでコマンド式のエディタで用いられていた、「移動コマンド → 文字列選択 → 移動先指定 → 確定」という固定的な操作手順を分解し、「文字列選択 → 削除」と「挿入箇所指定 → 前回削除した文字列の挿入」というふたつの独立した即時的アクションとして捉え直したのです。

モードレスなUIは操作を効率化しますが、アクションを選択すると同時に処理が実行されてしまうので、ユーザーが間違ったアクションを選択した場合にリスクがあります。そこでアンドゥ機能が作られました。アンドゥは、失敗しないための仕組みではなく、失敗してもよい仕組みとして作られたのです。アンドゥがあれば全ての操作は学習や試行錯誤の一環として肯定されます。アンドゥは単なる機能ではなく、作業というものに対する新しい意味づけとなったのです。

UIの操作における順序性について見てみると、プログラミングの記述構文と同じことが起きています。すなわち、コマンドラインのUIにおいては「Verb → Object」であり、オブジェクト指向のUIにおいては「Object → Verb」になっているのです。

例えばコマンドラインで「helloworld.txt」という名称のテキストファイルを開く場合、次のように入力します。

$ more helloworld.txt

ここでは、まず more というコマンドを入力し（動作の指示）、その後に helloworld.txt という対象ファイル名を入力（対象の指示）しています。

これに対して、GUIで同様なことをする場合は次のようになります。

まず helloworld というファイルを選択し（対象の指示）、メニューから「Open」を選ぶ（動作の指示）

GUIにおける「Object → Verb」の構文は、システムの操作からモードを取り除く効果がありますが、そもそもスクリーン上に提示されている要素を任意のタイミングで指し示せるということがGUIの基本イディオムですから、UIの表現が空間的なマッピングを利用したオブジェクトベースであることと、操作が非順序的でモードレスであることの間には、相互に強い蓋然性があるのです。

プログラミングとUIのどちらの場合でも、オブジェクトが先であり、やりたいことがその次となっている。これは具体的なものと抽象的なものとを高い次元で統合している。

アラン・ケイは Smalltalk のオブジェクト指向性について、プログラムの記述構文とUIの操作構文が一致していることを強調しています。実際、オブジェクト指向における「Object → Verb」の構文は、パーソナルコンピュータがもたらす新しい世界認識の統一的なアナロジーとなったのです。

さらに言えば、オブジェクト指向の構文論的転回は、単に操作の順序が Object → Verb に変わったというよりも、システムの操作設計から利用パスという固定観念を取り除き、ユーザーが好きな方法で、自分なりの工夫で目的を探索できるような「モードレスネス」をもたらしたということなのです。

つまり OOUI とは、作業段階における推論過程を我々の直観的思考パターンに同期させ、主体と客体、サブジェクトとオブジェクトが包摂的に作用し合う、中動態的な道具存在性の原理なのです。

釘を打ち込む時、ハンマーを振り下ろす動作と、打ち込まれた釘の姿は、一体化したイメージとして目当ての妥当をつくっています。オブジェクト指向的な捉え方では、道具とその対象は非人称的に交わります。GUI上のアイコンが、操作の道具でもあり、処理の対象でもあるように。

対象に対する我々の意識が、我々とその物との交わりであるなら、この世界には、道具的存在性をもたないものは無いと言えます。アフォーダンスが物の性質でも人の知覚でもない、あるいはそのどちらでもあるように、アラン・ケイはおそらく全てのオブジェクトを道具として捉えていたのです。要するに、GUIを構成するすべては、我々とインタラクトする対象として存在していなければならないのです。

GUIの設計のよりどころはオブジェクト同士の決定論的な関係性であって、文脈的なものではありません。だから想定された作業フローのようなものからは設計し得ませんし、そのような考え方はそもそもGUIの発想と次元が合っていないのです。手順的なものから考える限り、GUIを設計することはできません。

ユーザーが「する事」ではなく、ユーザーが「得る物」を先に考えるのが OOUI です。それを最初から示すか、できるだけすぐに探せるようにしておけば、ユーザーは自分でそれを獲得するでしょう。

OOUI のデザインにおいて、サブジェクトはオブジェクティブに観察され、またオブジェクトはサブジェクティブに記述されます。そこでは、ユーザー要求を満たす形などという表現は意味を失うのです。形は、人と道具が作り作られる流れそのものだからです。

このような認識は人と道具の関係をそのまま反映しています。OOUI を前に我々は、使うことと作ることは同じなのだという、シンプルな道理に浸るのです。

現在、スマートフォンやパソコンの操作体系としてGUIが広く採用されています。OOUI とは言わばGUIのことですから、そのコンセプトやパターンはにもう半世紀近くの歴史があるのです。しかしGUIのオブジェクト指向性やデザイン理論について正面から解説した文献はとても少なく、デザイン系の学校でもほとんど教えていないでしょう。

ユーザーインターフェースのデザインに関する方法論としては、ISO 9241-210 人間中心設計活動プロセスなど、「利用状況の把握〜ユーザー要求の特定」といった前段、「デザイン試作〜デザイン評価」といった後段からなる、反復性を持ったプロジェクト進行が有効であるとされています。ところが、このようなデザインプロセスの解説をいろいろと見ても、前段と後段をつなげるロジック、つまり特定されたユーザー要求を実際のUIでどう扱うべきなのかという部分のセオリーが、どこにも説明されていないのです。

言ってみれば、デザインの方法論がリサーチと品質保証のみの視点から議論されていて、文脈的な要求事項から原理的な道具計画を止揚する「デザイナーの視点」が抜け落ちているのです。

そのような中で、実質的に、GUIをデザインする上での構造力学的な設計理論は、「オブジェクトベースのモデリング」つまり「OOUI」の方法論しか無いのです。そしてこのことは、オブジェクト指向こそがGUIの発生原理であることから証明できるのです。

そこであらためて、オブジェクト指向ユーザーインターフェースの基本的な特性を確認しましょう。

まず OOUI においては、アプリケーションが扱う主要なオブジェクトの一覧を早い段階で見せます。

主要なオブジェクトとは、ドメイン（ユーザーの活動領域）における概念物で、エンティティとも呼ばれます。それらがスクリーンに見えていることで、ユーザーはそのアプリケーションの用途や作業範囲を把握することができます。そしてそこに見えているオブジェクトにマウスやタッチで直接働きかけることによって、操作を開始できるのです。また、オブジェクトの一覧がどのような形式で表現されているかによって、アプリケーションのおおよその操作イディオムが推測されてくるのです。

次に、オブジェクト選択 → アクション選択という操作構文をできるだけアプリケーション全体で踏襲します。これがGUIにおける基本的な操作のリズムであり、これにより、操作フローの中から「対象選択待ちモード」を取り除くことができます。

またモードレスな操作性を徹底するために、アクションは、選択されると同時に追加入力なしで即時的に実行されるべきです。またその結果をリアルタイムにユーザーにフィードバックしなければいけません。

そして、オブジェクトのプロパティおよび関連オブジェクトは、モードレスに表示したり変更したりできるようにします。

例えばナビゲーションは、今見ているオブジェクトに関連する／付随する別なオブジェクトの一覧を呼び出すものとして考えます。するとナビゲーション項目は名詞形の表現になり、オブジェクトベースの操作構文に沿ったものになります。

また、現在選択しているオブジェクトのプロパティはモードレスに変更できることが望ましく、そのために、実装として双方向データバインディング（同じオブジェクトの値がスクリーン上で同時に複数見えている時、システムが値の変化を監視し、常に相互に同期させること）されていることが望まれます。

できるだけ早くユーザーにオブジェクトを見せるというのは、例えばEメールクライアントであれば、それを起動した直後に、ユーザーの関心の対象である「メール」オブジェクトの一覧をまず表示するということです。

オブジェクト選択 → アクション選択という操作構文の例としては、例えば写真アプリで、ユーザーがまず対象の写真を選択し、次にその写真に対するアクションを選択するといった流れが挙げられます。

プロパティのモードレスな変更とは、例えばあるファイルがスクリーン上に見えている時、そのファイル名をその場で（モーダルダイアログなどを表示せずに）変更できること。またそのファイルがスクリーン上で同時にふたつ見えている時、片方のファイル名を変更するとリアルタイムにもう片方のファイル名も変更されることです。そうすれば、ユーザーはそれらが同じオブジェクトであり、自分が直接コントロールできる対象そのものであると認識し、メンタルモデルから操作手続きという余計な間接性を取り除くことができます。

では OOUI をモデリングしていくための、基本ステップを見てみます。

OOUI のモデリングではまず、ドメインからオブジェクトを抽出します。

次に、オブジェクトを表示するためのビューの種類を決めます。ビューの種類は、大きく「コレクション」と「シングル」に分けることができ、そのどちらをどのようなまとまりで用いるのか、ユーザーが情報を探索したりドリルダウンしたりする流れを考えながら決めていきます。

そして、ビューの状態やユーザーからの操作をハンドリングするための、コントローラーの役割を検討します。

モデリングの例として、Eメールクライアントを考えてみます。

一般的なEメールクライアントでは、基本的なオブジェクトとして、「受信箱」と「メール」があるでしょう。その他にもいくつか考えられますが、ここではそのふたつに絞って考えます。

受信箱とメールはそれぞれ関係しています。ひとつの受信箱の中に、複数のメールが入っているという関係です。

受信箱とメールという2種類のオブジェクトを具体的なビュー（ユーザーが実際に画面上で目にするひとまとまりの情報表示領域）に対応させて考えます。アプリケーションの中では、あるオブジェクトがいくつかの異なるビューとして現れてくるのが普通です。

受信箱もメールも複数件が存在し得るので、それぞれに一覧を表示するための「コレクション」ビューが必要でしょう。また情報の階層として、受信箱のコレクションからメールのコレクションが呼び出されるようになっているのが普通でしょう。そしてメールのコレクションで一件のメールを選択すれば、その「シングル」ビューが呼び出され、メールの本文が表示されるでしょう。

OOUI を少し実装寄りに考えると、ビューの状態を変更したりユーザーの操作を受け取って処理を実行するための「コントローラー」を意識する必要があります。このモデリング図は実装仕様と言えるほど厳密なものではありませんが、それぞれのビューに動作を与える、いわゆるビューコントローラーの存在を表しています。

例えばコレクションのビューには、オブジェクトの一覧上で選択状態を調べたり、DBからの抽出条件を特定したりする役割があります。またユーザーのクリック／タップを受け取って次のビューを呼び出したり、データの追加や削除といった処理を実行する役割も持ちます。

OOUI においては、ユーザーの関心の対象であるオブジェクトをビューが表象し、それらの振る舞いをコントローラーが司るのです。

OOUI のモデリングを実際の画面レイアウトに当てはめてみるとこのようになります。これはデスクトップ向けのEメールクライアントとして、ひとつのウィンドウに「受信箱のコレクション」「メールのコレクション」「メールのシングル」を隣り合ったペインとして並べた形です。

スマートフォンの小さなスクリーンであればこのように、「受信箱のコレクション」「メールのコレクション」「メールのシングル」はそれぞれ別の画面となり、画面遷移しながらドリルダウンしていく形になるでしょう。

このように、同じモデリングからビュー同士の配置関係を変えることで、異なるスクリーンに対応したUIが作れるのです。

複雑な業務を扱うようなシステムでは、モデリングの最初にオブジェクトを抽出する際、ドメイン分析を行う必要があります。

例えばこの図では、事業組織内のある部門が扱っている業務上の概念物と、それらが既存業務システムにどのように関係しているか、また外部のシステムとどのように連携しているかを簡単に示しています。このような図を描きながら、ドメインの理解を深めていきます。

多くのシステムでは、例えば顧客管理システムであれば「顧客」、プロジェクト管理システムであれば「プロジェクト」など、主要なオブジェクトは自明的に抽出されます。一方で、比較的単純なシステムであっても、ユーザー要求が特定のタスクに強く依存している場合、オブジェクトが暗黙的になっていて抽出しづらいことがあります。

例えばこれは為替レート計算のための簡単なアプリケーションですが、ドルを円に換算するといった特定タスクのみを実行するものとして手順化された表現になっているため、オブジェクトが表象されていません。

このようなUIは、操作を穴埋め式のミニウィザードと実行ボタンで線型化する、モーダルな表現であるため、もっとGUIらしく改善することができそうです。

タスクベースの既存UIから暗黙的になっているオブジェクトを抽出するひとつの方法は、その手順の中の入出力情報に着目することです。

為替レート計算の例では、入出力される情報として、「1. 計算元通貨の金額」「2. 計算元通貨の種類」「3. 計算先通貨の金額」「4. 計算先通貨の種類」があります。

「1. 計算元通貨の金額」「2. 計算元通貨の種類」「3. 計算先通貨の金額」「4. 計算先通貨の種類」という入出力情報の共通項を見ていくと、1 と 2 には「計算元通貨」という概念があり、3 と 4 には「計算先通貨」という概念があることがわかります。

また、「計算元通貨」と「計算先通貨」はどちらも「通貨」という概念として汎化できます。

そこで、OOUI としての為替レート計算アプリをデザインするために、まず「通貨」というオブジェクトを立ててみましょう。

既存のUIを見てわかるとおり、通貨には「種類」や「金額」というプロパティが必要になりそうです。

通貨オブジェクトは、既存UIを参考にすると、少なくとも「計算元」と「計算先」というふたつのビューとして同時に見えているのがよいでしょう。そしてそれぞれの「種類」と「金額」というプロパティが見えているべきでしょう。

ふたつの「通貨」ビューは、なんらかの形で関係しているはずですが、それはどのような関係性でしょうか。

ある通貨を別の通貨に換算するということは、両者の間に為替レートが特定されている必要があります。そしてその為替レートを使って、計算元と計算先の通貨が等価になるように金額が更新されることになります。

すると、片方のビューに対して行われた操作をトリガーとして、もう片方のプロパティを変更するという、両者をつなぐコントローラーの役割が見えてきます。

モデリングを反映すると、実際のUIはこのウィジェット（Mac）のようになるのです。

このUIでは、ふたつの「通貨」オブジェクトのビューが左右に配置されています。そしてそのどちらかの「種類」もしくは「金額」に変更が加わると、左右が等価になるように、もう片方の値が変更されます。

このUIには線型的な入力手順や実行ボタンはもうありません。ユーザーは通貨換算タスクという手続きを意識することなく、単に等価になろうとするふたつの通貨オブジェクトを直接的に操作すればよいのです。

前述したとおり、ビューの種類には大きく「コレクション」と「シングル」があります。

コレクションは、同種のオブジェクトを複数並べて表示するものです。シングルは、オブジェクト一件分のプロパティを詳しく見せるものです。

通常、コレクションビューの中でユーザーがひとつのオブジェクトを選ぶと、その内容を表示するシングルビューが表示されるという振る舞いになります。これは Master-Detail パターンとも呼ばれます。

アプリケーションの性格を特徴づけるのは、コレクションの形式です。コレクションがどのような表現でオブジェクトの一覧を提示するのかが、ユーザーにとってのアプリケーションの妥当性を決定します。

コレクションの形式には、例えば、カレンダー式、マップ式、一次元リスト式、タイル式などがあります。

ユーザーはコレクションを見て、すでに知っているイディオムとの類似性から、そのアプリケーションの世界観を把握します。また初めてみる形式であれば、ユーザーはその表現からアプリケーションの意図を汲み取ろうとします。

OOUI では、コレクションとシングルの組み合わせによってオブジェクト同士の関係と情報粒度を定義しますが、オブジェクトの性質をアプリケーション固有の表現として反映するのは、コレクションのフォーマットなのです。

ここでもうひとつ、OOUI モデリングの例を見てみます。

これはある契約管理システムの改善前のデザインです。左側のメニューには、「新規申請」「変更申請」「解約申請」「承認」「契約照会」という項目が並んでいます。これらはいずれも「やること」を動詞的な文言で表していますので、このUIがタスクベースで設計されていることがわかります。

メニュー項目はそれぞれが決まったタスクを行うためのウィザードの入口になっており、このように、全体では12画面にもなっていました。

タスクベースの業務アプリケーションによくあることとして、タスク同士の間では、似たような検索や一覧が登場します。ユーザーは今自分が何のタスクにいるのか（どの入口から入ってきたのか）を意識しながら、対象物の選択と確定を行うことになります。このようなモーダルな流れでは、ユーザーは仕事の対象自体ではなく、強要された手続きの方に注意を払う必要があるため、ストレスフルなものになります。

メニュー項目には「承認」というタスクがあります。これは、申請された契約の内容を上長が承認するためのもので、その権限を持つユーザーのみに表示されます。

また、メニューには「契約照会」という項目があります。これは、利用ケースとしてユーザーが特定の契約の内容を単に参照するだけ（変更等はしない）の場合が多いためです。

このシステムを OOUI としてモデリングしてみます。

まず、このシステムにおける主要なオブジェクトは「契約」です。それは、「新規申請」「変更申請」「解約申請」「承認」「照会」といったタスクがいずれも「契約」という概念に対して行うものであることからわかります。

OOUI のセオリーとして、主要オブジェクトの一覧が必要です。この場合、契約オブジェクトのコレクションビューです。そしてそこからユーザーが一件を選択して見ることができる、契約オブジェクトのシングルビューも必要でしょう。

このシステムでは、特定の契約の内容をただ確認するだけの場合と、内容を変更したり新規に作成して上長に申請する場合があります。そのため、契約オブジェクトのシングルビューは、「参照用」と「編集用」のふたつが必要になりそうです。それらはユーザーの編集意思によって切り替えられるようになっているとよいでしょう。

編集機能を持ったシングルビューは、一般的に、オブジェクトの新規作成画面としても流用することができます。そのため、契約オブジェクトの編集用シングルビューは、新規契約申請のためのビューとしても使うことにします。

承認権限のある上長は、契約一覧の中で「承認待ち」のものを知る必要があるため、コレクションビューには要承認フラグのようなものがあると良さそうです。また、改善前の承認用画面にあったとおり、参照用シングルビューには、承認権限のある上長が見た時のみ、承認者コメント欄を表示するようにします。

次にコントローラーの働きを考えてみます。

コレクションビューにはユーザーが目的の契約を探せるように検索機能があるべきなので、コントローラーにはその条件を特定するための「抽出条件」、および一覧における項目の「選択状態」をプロパティとして持つことになります。また一覧に対するアクションとして、契約の「追加」および「削除」ができるようにします。

参照用のシングルビューのコントローラーには、ユーザーの承認権限の有無によって表示内容を変更するために、「承認可能性」プロパティを持たせます。またアクションとしては、編集画面に切り替えるための「編集画面を開く」、解約を申請するための「解約申請」、そして上長向けの「承認／非承認決定」の機能を持たせます。

編集用のシングルビューでは、内容を変更した契約を申請するための「申請」機能が必要です。また改善前のUIにならって、ここには「一時保存」の機能も持たせることにします。

モデリング結果を具体的な画面レイアウトに当てはめてみたのがこの図です。ここでは一覧と詳細を左右に並べる Master-Detail のパターンを用いて、ユーザーが次々と内容を確認しながら目的の契約を探せるようにしました。

ユーザーが契約の「変更」ボタンを押した時、あるいは一覧の上にある「新規」ボタンを押した時には、シングルビュー部分のペインが編集用のフォームに変わるようにします。

このように、「契約」オブジェクトの一覧を最初から見せ、そこで選んだものを隣のペインに表示させるようにすることで、改善前に12画面もあったシステムが、合理的に作業の全体を把握できるシングルページアプリケーションになったのです。

The Object of OOUI

では最後にもう一度おさらいすると、OOUI は、我々「サブジェクト」を、その実在的対象である「オブジェクト」に接続する試みということになります。

オブジェクトとは我々の前に投げられた目当てであり、それは普段は物事の感覚的性質のうしろに退隠しています。そして探求の手がかりは、数百万年の時間とともに我々を作ってきた道具存在 ＝ 無名の質の中にあるのです。

OOUI は、単にナビゲーションのラベルを「名詞」にしたり、操作順序を「対象選択 → アクション」にするといった表現上のスタイルのことではなく、ユーザーの前に対象の実在をストレートに表象するということです。ユーザーに手順を提供するのではなく、そのものを差し出す態度なのです。そして我々は、その表象がやがてユーザーとその環境を変え、新たな無名の質に育っていくことを想うのです。

主体から客体を見るという膠着したパースペクティブを転回し、統合的な「主体である客体」の視点を持つことは、これまでの物理世界では困難でした。しかしソフトウェアからのフィードバックによって我々の認識が脱近代されていくこれからの世界では、各々がクラス ＝ 真存在の制作者になれるのです。

ユーザーを洞窟から解放し、それぞれの創意によって本質に向かっていけるようにすること。人々が自身のやり方で意味空間を思索し、愛智者として日常を汲んでいけるようにすること。誰もが自らにとってのデザイナーとなり、世界を新たな方法で見たり感じたりできるようにすること－

それが、OOUI の目当てなのです。