【聴講】オブジェクト指向インターフェースデザイン講義【4/5】

今回のテーマは「オブジェクト指向デザイン１」ということで、講義としては本題に入っていく。繰り返しで恐縮だが、一連の記事は９割くらいは私の妄想で占められており、講義の正確な理解ではないことにご留意いただければと思う。

まず、この一連の講義において、「オブジェクト指向ユーザーインターフェース」は GUI の原理としての位置づけが与えられていることを確認しておく。すなわち、「オブジェクト（関心の対象）を手がかりに操作設計された UI」という位置づけである。あとで斜めから見て検討するが、投射されたものと素朴に捉えることができるがゆえに、逆に概念としては難解になっている。実際のところ、この「オブジェクト」の概念には三重の意味があると考えられ、これらの意味が疑いを挟む余地なくひとつの「見せかけ」に統合されて表に出てきている。

私以外にこの講義を聴講している大学院生から聞いた話だが、はじめて「オブジェクト指向」を学ぶ学部の学生は「オブジェクト」という概念の理解が難しかったようである。もちろん、素朴な「モノ」や「関心の対象」としては理解しているのだろうが、「クラス」などの話が出てきた途端につまずいてしまうものと思われる。前提として、C言語のような手続型の形式言語を取り扱った経験がない点が大きいかもしれないと個人的には思っている。

ここで、15年前、私がはじめてプログラミング言語に触れた時代の話をしよう。当時はインターネットもたいして発達しておらず、プログラミングのための書籍も今日ほどなかった。数少ない入門書のひとつには「猫でもわかる」と書いてあった気もするが、読んでもわからない私は猫未満なのかと憤った記憶がある（残念ながら、いまも猫にさえなれていない。）。あまり多くない人が初期のガラケーを使い、Yahoo!ジオシティーズ（※現在は廃村になり現存しない。）でウェブサイトを作成する、そんな時代である。まだ JavaScript は前面に出てきていない。現在、大学院で私が履修しているほかの科目では Arduino や 3D CAD を使っているが、かつては PIC C 一択で 3D プリンタも存在しなかった。この調子でいくと、そのうち部屋に設置できるタイプの小型の工場が出てくるんじゃないだろうか。ちなみに、MIT でそういう研究があったと思うので、そこまで根拠のない話はしていない。そうした中で、わりと多くの人が Java や C++ を使っていたと思う。いずれもオブジェクト指向の言語である。ハードウェアとソフトウェアの境界も未分離で、フロントエンドやサーバーサイドの区別もたいしてなかった。もちろんクラウドの観念はない。私がこうした世界から離れて10年後にスタートアップの世界に来た時には状況は様変わりしていた。まったく、とんだ浦島太郎である。やれやれだ。最近では「フレームワーク芸人」という存在もあると聞くが、どうも表層の人材が厚くなっているようである。

もともとエンジニアリングの世界（と呼んでいなかったと思うが）では、仕様変更、機能追加、保守、再利用といった事項に対応するため、ソースコード（ゼロイチ連鎖の機械語を人間が読んで容易に扱えるようにしたもの）は、部品としての独立性という観点が極めて重視される。つまり、設計方法として、全体から個別へとブレイクダウンするのではなく、個別の積み上げないしは連鎖によって全体をつくろうとする。こうすることにより、（全体は部分の総和ではないという欠陥に目をつぶったとしても、なおあまりあるメリットとして）突発的な仕様変更があったとしても修正範囲を最小限に食い止めることができる。これは根本的には、機械は人間と異なり柔軟な変化ができないことに起因している。そして、形式言語の世界における「オブジェクト指向」の考え方 (OOP: Object-Oriented Programming) も、手続型の言語と比較して、部品としての独立性の考え方を重視していることは疑いようがない。

こうしてみれば明らかであるように、OOP における「オブジェクト」の第一次的な意味は「モノ」ではなく関係性が予定された「部品」である。それも、形式的な論理的規則の束（記号学的な表現を用いればシニフィアンだけの束）であり、ここに想像的なイメージや実体は一切伴わない。すぐれて象徴的な次元の産物なのである。

しかし、人間は部品としての論理的規則の束を取り扱うことは認知的な次元において著しく困難である（ちなみにプログラミングだけではなく法律実務もそうだと思う。）。そこで、アナロジーないしメタファーという方法が採用される。つまり、機械世界にしかない論理的規則の束に現実世界のモノや実体のイメージ（記号学的な表現を使えばシニフィエ）を付与するのである。これが第二の意味である。結果的に、第二の想像的意味は第一の象徴的意味から離れて、つまりソースコードの話から離れて、上流にのぼっていき、要件定義以前の水準でさえそうした考え方が用いられるようになる。ここでは、もはや「オブジェクト」は部品（論理的規則の束）ではなく純粋なモノの認識として受け取られることになる。しかし、第一次的な象徴的な意味との関係が切断されたわけではない。逆に、こうしたモノの認識をどのようにして部品の仕様として落とし込むかという話になっていく。いや、さらに進んでモノの認識の仕方の話になっていく。そういうわけで、「オブジェクト」には、論理的規則の束という意味と想像的なモノないし実体という意味が二重に与えられることになるのだ。

ここからさらに、想像的な実体は哲学的に受け取られる。特に現象学との結びつきを強めることになる。すなわち、現象学の「事象そのものへ」という考え方ないし志向性から、認識（現象学では「知覚」という、より生物学的な表現が用いられるが）の対象は常に現実性を構成する想像的代理物となり、それを呼び出す掴みえぬ空虚な〈対象〉こそ〈現実的なもの〉であると論が進められる。ここにいう〈現実的なもの〉は到達不可能な純粋な実在的空無であり、いわばイメージないし概念に対して重力が働く場所である。これが第三の意味である。言い換えれば、現実性を構成する想像的な意味は、恣意的に決定されるが、何者かによって任意に決定されるわけではなく、常に〈現実的なもの〉から呼び出され、時間軸に対して後ろ向きに投影される。この〈現実的なもの〉についてはここで記述できるほど簡易な概念ではないため、というよりも記述しようとすると常にそうでなくなるため、いったんは世界にはそういう謎めいた対象があると思っておいてほしい。ふわふわした概念やメタな存在を許さない「くらやみ」（by 物語シリーズ）のようなものだと思ってくれていい。

以上のとおり、オブジェクトには、第一に論理的規則の束という意味があり、第二にモノのイメージという実体の意味があり、第三に第一の意味と第二の意味を「本来の」位置に変更してしまう〈なにものか〉の意味があり、これらの意味が重なり合っている。そして、これがデザインの世界における OOUI の話となったとき、通常の説明の際には第二の意味が前景化される。これは第二の意味だけがわかりやすいビジュアルによって表現することができるからである。したがって、第二の意味でのイメージを見せた後に第一の意味の話をすると、初学者にとってはあたかも関係のなさそうな話に聞こえ、理解が追いつかなくなるというわけだ。

（執筆：平塚翔太）