私は普段、家の脱衣所で仕事をしているのだが、デスクの隣にある縦型洗濯機がちょうどいい高さということもあり、そこにいつも仕事中に参照する本を積んでいる。洗濯機の蓋もまさか、漬物石みたいに本が置かれることになるなんて思ってもみなかっただろう。それらの本は主に、その時々の仕事に関係するものとか、読みかけのものだったりするから、頻繁に入れ替わっていくのだけど、ずっと置いているお気に入りが、いくつかある。そのうちの一つが、OOUI 本こと『オブジェクト指向 UI デザイン　使いやすいソフトウェアの原理』- ソシオメディア株式会社、上野 学、藤井 幸多（著） 上野 学（監修）だ。

出版されてから 3 年以上たっても、私は時折この本をふと、開いてみてはいつの間にか没頭し、そういえば私は仕事をしていたんだっけな、みたいになってしまう。端的に言って大好きだ。この 3 年間で読書会も 2 度主催したことがあるし、仕事で知り合った人が「『オブジェクト指向 UI デザイン』読みました」なんて言うのを聞いた時には、もう一緒に飲みに行って 2 時間くらい感想を語り合いたいという衝動に駆られたりもする。迷惑だろうから誘ったりしないけど。もしかして私は、いやたぶんもしかしなくても、著者よりもたくさんの時間、これを読んでいるのではないかと思う。

そして喜ばしいことに（いや、別に私が書いた本でも何でもないのに喜ぶのはとても変かもしれないけれど、でも本当にそうだからそうとしか言えないが）、この本は多くのデザイナーやエンジニア、なぜか哲学者にまでも愛読されていて、その感想や分析、実践してみた様子などを書いた記事がインターネット上に数多く存在する。私はそういった、感動や発見を読むのも好きだ。できることなら一人一人話しかけたいくらいに。そんなことされた怖いだろうからやらないけど。※ 1

しかし本というものはテキストの性質上、誤配がつきものだ。私にしたって、読み違いの一つや二つあるだろう。ある人が書いたテキストの特定のニュアンスが、それを読んだ人によって強調されて別のテキストとなる。さらにそれを読んだ人がそこにまた違ったニュアンスを読みとって別のテキストを書く。そんな風にして最初に書かれたものとは全然違ったものが、さも最初から書かれているかのように世界を闊歩していってしまう。

何らかの学問を志して研究した事のある人はその初学者の頃「孫引きはおやめなさい、どんな時も必ず本文にあたること」と指導者に口を酸っぱくして言われるから、学術論文において元のテキストとあまりに乖離した解釈というのはそれほど起こらないものだが、皆が自由に、好き勝手に書く感想では、丁寧な文献調査みたいなものは行われないし、またそういった手軽さが良いところでもあるからして、時間と共にどうしても誰が言い始めたのか判然としない説が、まるで最初のテキストに書かれているように人々に伝わっていくのだ。

「最近の若者は」とプラトンが言ったとか、「変化に対応できたものが生き残る」とダーウィンが言ったとか、「遠くに行くにはみんなで」とアフリカの諺にあるとか、古今東西その枚挙に暇がない。ていうか、プラトンのテキストで喋ってんのソクラテスじゃん。

ともあれ、そういった従前の例に同じく、実は『オブジェクト指向 UI デザイン』について書かれたテキストにも「いやそんな事、本に書いてないけどな」というものが数多く見受けられる。そして、年月を重ねるにつれておかしな説が次々に台頭していく様子を見ていると、この本が格別に好きな私としては、書いてないことはやはり、書いて無いですよと主張した方がいいのではないかと思うようになってきた。だから私はここで『オブジェクト指向 UI デザイン』には書かれていないオブジェクト指向 UI についての通説に関して、著者を差し置いて、勝手に一刀両断することを試みようと思う。

もちろん、本にもその歴史について詳しく記載されているように、オブジェクト指向 UI 自体は GUI の歴史とともに誕生した古いものであるし、『オブジェクト指向 UI デザイン』に書かれていることが全てとは言えないだろう。
そしてこれが、いや俺は別に書籍『オブジェクト指向 UI デザイン』の話ではなく、OOUI 一般、つまり Dave Collins や Mark Van Harmelen とか、Theo Mandel の文献について言ってるんだけど？みたいに「あなたの論考ではなくてあなたの論考の元ネタを援用してるんですよ」的なアクロバット弁明もできてしまう微妙なものであるということは承知してる。当たり前だが、OOUI について書くことと、書籍『オブジェクト指向 UI デザイン』について書くことはイコールではないから。
また、オブジェクト指向 UI についての自由闊達な批評や実践を阻害するつもりもないし、書いてないことを書いている人、言ってないことを言っちゃってる人個人を攻撃する意図も全然ない。そもそもそんな権利は私にはないし。

ただ、本を引用したブログなどに、本に書いていない事がそう断りなく書いてあったら、本に書かれているように読めてしまうから、それを防ぐために書いてないことについて、書いてないのでは？と主張する、それだけである。
とはいえ、わざわざ主張するからにはそこに批判的意味を多少なりとも含むことにはなるだろう。その点については私も、何も取り繕うことはしない。

というわけで、前置きはこれくらいにして、私が特に気になった 5 つの言説について順に取り上げていこう。

1. オブジェクト指向 UI  とは UX の 5 段階モデルにおける「構造」と「骨格」部分である

なんか、もうこの一文だけでお腹いっぱいで初っ端から挫けそうになってきたが、気を取り直して言及する。

まず、UX の 5 段階モデルというのはもちろん Jesse James Garrett の、あの有名な図のことだ。

Jesse James Garrett の著書『 The Elements of User Experience ~5段階モデルで考えるUXデザイン』には UX の構成要素として「戦略」「要件」「構造」「骨格」「表層」という5 段階のモデルが登場する。この「構造」と「骨格」を形成するのが、オブジェクト指向 UI という主張だ。

ところで Garrett の図もまた、典型的な誤配をたどったものといえるだろう。特に日本語版は、去年復刻されるまで長らく絶版になっていたこともあり、本は読んだことはないけど図は知っているという人が多かった。その様な人たちによって伝言ゲームのように繰り返し描き写されていった中でこの図は、UX の要素というよりは、制作フローのステップだったり、分業におけるロールの区分としての意味が強調されていった。そもそも、UX というのはユーザーの体験のことだから、その要素に制作者の「戦略」とか、制作者が定義した「要件」なんてものがあること自体おかしいという所が、そのような誤配を誘導していった一因かもしれない。

『オブジェクト指向 UI デザイン』では、ソフトウェアデザインのレイヤーとして

• モデル … ユーザーの関心対象の模式

• インタラクション … 構造と機能（フィール）

• プレゼンテーション … スタイルやレイアウト（ルック）

の 3 つを挙げており、それぞれを「2. オブジェクト指向 UI 設計のプロセス」において解説している。5 段階モデルを構成する要素の、その妥当性はともかく、少なくともオブジェクト指向 UI が、「構造」や「骨格」といった、UX の要素とかワークフローとか、ましてソフトウェアデザインの断片についての話ではないことは明白だし、そんなことはどこにも書いていない。部分ではない、全部だ。部分であり全部だというべきか。

ちなみに「戦略」「要件」「構造」「骨格」「表層」というレイヤーの名称について漢字 2 字で統一された美しい訳語をあてたのは『オブジェクト指向 UI デザイン』の著者の一人である上野 学氏だ。豆知識です。この人マジなんでもやってるよな。そうそう、上野さんは復刻版のまえがきも素晴らしいので未読の方はぜひ！

2. 初心者や高齢者などリテラシーの低いユーザーにはオブジェクト指向 UI よりもタスク指向 UI の方が使いやすい

よく見られる言説だが本にそのような記述はないし、何よりいつもオブジェクト指向 UI デザインについて実践している立場からも全くそんなことはないと言える。どちらかといえば、むしろリテラシーが高い人の方が、タスク指向 UI をうまく使える。だからといって、リテラシーが高い人はタスク指向 UI の方が使いやすいかというと、そういうわけでもないが。考えてみたらいい。パソコン初心者が、iPhone と CLI のどちらが使いやすいのか。iPhone は赤ん坊でも、子猿にだって操作できる。パソコンやソフトウェアについてのリテラシーが低い場合、ユーザーインターフェースのイディオムを学習出来ていなかったりするから、その点については注意が必要だが、それを言い訳にタスクを並べて、お前のような初心者にはこれで十分だとするのはあまりに意地悪だ。ユーザーはいつまでも初心者でいたがったりはしないと、クーパーさんもいってるじゃないか。

ただ、何か予め設定したタスクを完了できるかについて調査するようなユーザビリティーテストを行った場合、タスク指向 UI の方が成功率が高いということはあると思う。

「ユーザーをプロジェクトメンバーから削除する」というタスクに対して「ユーザーをプロジェクトメンバーから削除する」というボタンがあれば、おそらく初見でも間違えずに使えるだろう。ユーザーの一覧に「編集」というボタンがあるだけでは、少し迷うかもしれない。しかしそうはいっても、「ユーザーをプロジェクトメンバーから削除する」「ユーザー情報を登録する」「ユーザーを追加する」といったタスクをボタンにしていたのでは、ユーザビリティテストでのタスク成功率は高いがゴミみたいに使いにくいものが出来上がってしまう。

また、タスク指向 UI はユーザーの操作を予め決めてリニアライズするものであるという観点から、タスク指向 UI の方がアクセシビリティが高いのでは？という結論を出すのもちょっと待ってほしい。決してそんなことはないので。これについては『オブジェクト指向 UI デザイン』と同じ「WEB+DB PRESS Plus」シリーズの書籍『Webアプリケーションアクセシビリティ』伊原 力也、小林 大輔、桝田 草一、山本 伶（著）に詳しいのでご一読を。私は自分の目が見えなくなってもランダムアクセスがしたい。

ちなみに、いきなりオブジェクトを見せられても、初心者は何ができるか分からないから、タスクを見せた方がいい、という言説も全くの筋違いだと思う。そのように考える人は「3-6 タスクをどう扱うか」に、タスクの性質について詳しく書かれているので、ぜひ読んでほしい。だいたい、タスク指向で考える人のタスクの数は極端に少ない。 1 つのオブジェクトに対するアクションで表現できることが、タスクにしたら 200 になるなんてことはザラにある。もしそのソフトウェアにメニュー化されたタスクが 5 つしかないなら、195 のタスクを行う自由を、あなたはユーザーから奪っているのだ。

3. オブジェクト指向 UI のデザインは、モデル、インタラクション、プレゼンテーション、の順番にやる。

確かに本では、先に述べたソフトウェアデザインのレイヤーである、モデル、インタラクション、プレゼンテーション、という 3 つのステップで、その設計プロセスが紹介されている。しかし、それはテキストというリニアなメディアの特性上、順に説明するしかないという制約のためにその様になっているだけで、別にどこから始めてもいいし、作業の順序を変えてもいい、それぞれのステップをいきつ戻りつしながらやるのだと「3-1 オブジェクト指向 UI の設計ステップ」にちゃんと書かれている。ここまでハッキリ書いているのに、なぜみんな順番にやると思うのか。一体どこをどう読んだらそんな読み違いをするのか、とても不思議なことだが、おそらく本を要約したブログに書いていなかったので、要約だけ読んで本を読んでいない人が思い違いをしているだけなのだろうと思う。

「モデルより先に絵を描かないこと、まずはモデルから！」という人もいるが、もちろん個人的な実践としてその様にした方がやりやすいのであれば、それでも構わないけど、そうでないとオブジェクト指向 UI にならないというわけではない。ちなみに私はいきなり絵を描いて、モデルで整理して、また絵を描く、みたいにすることが多い。頭の中でやることも随分あるから、厳密に何が先で何が後とかいうのが難しいところではあるけど。私のまわりを見渡した感じでは、いきなり絵です、って人が多い気がする。

そもそも、ランダムアクセス性が重要な要素としてあるオブジェクト指向 UI の設計プロセスに、決められた順序などあるはずがないし、あってはならないのだ。

4. オブジェクト指向 UI のオブジェクトとはコンテンツのことである

本ではオブジェクトについて、その語源まで遡って解説されているが、要するにコンテンツの事だ、などとは書いていない。これについては、いくつかその様に書かれたブログなどを読んでみたものの、コンテンツというのが何を指しているのか、なぜわざわざ言い換えるのかについては、正直よく分からなかった。ここで言われているのはおそらく、コンテンツはメディアで、メディアはメッセージみたいな話ではなく、単に音楽プレイヤーにおける曲、電子書籍アプリにおける本、日記アプリにおける日記的なものを言っているのだと思う。ソフトウェアというよりは、ウェブサイトの設計の様なイメージがあるのかもしれない ※2 。それでいうと、確かにそれらはユーザーの関心の対象であり、主要なオブジェクトに違いないだろう。しかし、その様な理解でいると思い至らないものがあると思う。

オブジェクトはプレイリストであり、オブジェクトは時計のアラーム設定であり、オブジェクトは Photoshop のアクションであり、オブジェクトは Google Docs の変更履歴であり、オブジェクトは可変のカテゴリである。

これらは「コンテンツ」という言葉でイメージするものとは随分異なると思わないだろうか。しかし、UI デザインにおいて人々の活動の中からデザイナーが見立てるオブジェクトとは、曲や日記や本みたいなものよりも、例に挙げたようなものの方が多い。ソフトウェアは物理的制約がないので、何でもオブジェクトとしてユーザーの前に現す事ができる。そこが UI デザインの一番面白い所でもある。

コンテンツというのはデータだ、という所まで抽象度を上げれば、まあ、オブジェクトとはデータのことである、とも言えなくはないが、しかしそれではソフトウェアで扱う言葉としては、オブジェクトよりもスコープが広がってしまい、言い換える意味がない。だから「オブジェクトとは、例えばコンテンツのことである」とか「ここでいうコンテンツというのはオブジェクト指向 UI でいうオブジェクトのことだ」ということはあり得るが、「オブジェクト指向 UI のオブジェクトとはコンテンツである」というのは妥当な言い換えではないと私は思う。

思うのだけど、まあその辺は別に分かりやすいように、好きにしたらいいじゃんという気もする。しかしオブジェクトとして現すものについて、曲とか本とか日記みたいに、あまりに物として素朴で分かりやすいイメージをもっていると、「出張申請書」みたいな現状紙ベースで存在しているものに囚われて、出張申請書で人々が行なっていることは一体何なのか、そういった事を考える余地を失ってしまう恐れがあり、私はその点について懸念している。コンテンツは、オブジェクト指向 UI によってドキュメントとか、音楽データみたいなものから解放されてしまう、それくらいのパワーがあるから。「出張申請」が、オブジェクト指向 UI によってどのようにリフレームされ得るのか、一度考えてみてほしい。そして考えたら、出張申請のオブジェクト指向 UI に関する著者のアイデアを読んでみるといい。それは出張申請は申請書というコンテンツの一つ、という考え方では辿り着けないデザインなのではないか。オブジェクトはコンテンツでもいいけど、そこについてはぜひ意識されたい。

5. タスク指向 UI が向いている場合もある。使い分けが重要である。

本では、タスク指向のシステムには UI はなく、そこにあるのは一方的な徴用性だけだ、とまで言ってるので、当然そんなことは書いていない。だいいち、オブジェクト指向 UI 、つまり OOUI は GUI だし GUI とは OOUI なのだから、OOUI でない GUI など、その存在自体が倒錯しているじゃないか。

ソフトウェア制作において、オブジェクト指向 UI にする事が叶わないケースは当然あると思うが、オブジェクト指向 UI にできる状況で、あえてタスク指向 UI を選択した方がいいケースなんてない。「納期」「お金」「技術」のいずれか、またはその複数が要因となって、涙をのんでそうせざるを得ない事が現実問題としてあるというだけだ。納期に間に合わないから、資金がないから、実現する技術がないから。それも広い意味においては「タスク指向 UI が向いている」ということになるかもしれないが、一般的にそのような状態を「使い分ける」とは言わないだろう。

もしかしたら、ユーザーを操ったり、ユーザーの行動を制限したりするために意図的にタスク指向 UI を採用する酷い人達もいるのかもしれないが、実のところそんなケースは稀であるように思う。オブジェクト指向 UI を体現した　Apple 製品が多くの人々に愛されるということはあっても、タスク指向 UI によって大儲けした、みたいな話を、私は聞いたことがないからだ。

オブジェクト指向 UI でデザインされたシステムであっても、例えば初回起動時のセットアップでウィザードを使用したり、決済フローでどうしても操作に厳密な順序性を持たせる必要が出てくる場合もあるかもしれない。その様なケースにおいては、部分的にタスク指向 UI 的なモードを採用することは当然考えられるだろう。だとしてもやはり、それも「向いている」とか「使い分ける」というよりは、仕方なくそうするといった類いのものだ。

時間やお金がないにしろ、自分のスキル不足にしろ、ユーザーとは関係ない、単なる制作者の都合によってタスク指向 UI にしたものを、もっともらしくあえてそうデザインしたと言わんばかりに「使い分け」と表現してしまってはいないだろうか。決まった手順でしか操作できないなら、そもそもそれは人間のやる事ではないのだろう。ならばタスクを見せてユーザーに選択させるまでもなく、自動的に完了しているべきだ。

また、ATM などを例として対象オブジェクトが単一の場合にはタスク指向 UI も機能する、と考えるのも早とちりすぎるのではないかと思う。確かに ATM の例は本に書かれているが、それはすでに「口座」が選択された状態から始まるので、便宜上タスクが最初に現れるというだけの話だ。何らかの合目的性のためにユーザーの行動を制限する様な時には許容されうるにしても、ユーザーによる生産性への工夫、能動的な創造性、自由な消費行動をあえて制限することに合目的性を持ったソフトウェア作る機会など、かなり稀であると思う。そもそもパーソナルコンピューターとは、そういったものからユーザーを解放する、カウンターカルチャーなのだから。

300 ページ以上ある本のたった 5 行しか書かれていないタスク指向 UI が許容され得るケースの説明が、他の全てを費やして書かれているオブジェクト指向 UI についての説明と同等に併記されていることが多いのは、何か特定の考えを一方的に書くこと事を嫌う、両論併記的な風潮によるものと考えられる。しかし内容についてよく考察することなく、ポーズとして安易に両者を同等のように挙げる態度は、あまりに雑すぎるのではないか。余談になってしまうが、両論併記の問題については『ヘイトスピーチと対抗報道』角南 圭祐　著に詳しいので、両論を併記して中立的な立場を取ることの何がいけないのか、と思った方は読んでみてほしい。

そして、この議論において最も重要なのは、現場のデザイナーが「これはちょっと特殊だから、オブジェクト指向 UI にはできない」とか「タスク指向になるとしてもウィザードでないと無理だろう」と思ってしまう様な状況にあっても、実は別の切り口からオブジェクト指向 UI に出来たり、必要だと思ったウィザードを無くしてしまえる世界線が存在しているにも関わらず、単にそれに気づいていないだけだったりすることがよくあるということだ。
個別の事情を知っているわけではないので一概には言えないものの「タスク指向 UI の方がいい場合もある」と言われているものの多くが、実はタスクの解体に失敗しているだけなのではないかと私は疑っている。

私は以前、少し複雑な設定について、説明的なウィザードを使ってステップ式にそれを実行するものを作ったことがある。その設定自体は必ずしも順序性のあるものではなかったが、順を経ないと理解が難しいと私は考えたからだ。ところが、それを見た私の上司 — この文脈上いくぶん特殊な上司ではあるが ※3、ともかく彼はこう言ったのだ。

「それで、分かりやすくなっていますか？」

ウィザードはステップ式に、言われるままに設定を行うものだから、その通りにやれば設定自体は完了するだろう。しかし何をやらされているのか理解するのは困難だ。懇切丁寧な説明テキストを追加すればなんとか理解はできるかもしれないが、そういう問題ではない。分かりやすくするために私は、ウィザードを採用したのではなかったか。

こういうのはどうですか?
どのみち分からないのだから、その理解を助けるための手がかりを UI 上に表現した上で、順序性なくその設定を可能にしましょう。当然、初見では使えないでしょう。けれど一度分かったなら自分の好きな順序で、自由なタイミングでそれを行える。そういったものなら、毎日使うツールとして合理的です。

そうして、私が作ったタスク指向なウィザードは瞬く間に解体され、ユーザーにとって意味のない手続きは消え、ユーザーが好きな順序で操作を組み立てて行うことができる GUI が、そこに姿を現したのだった。

それは一度見たら、なぜ自分はウィザードしかないと思ったのだろうと不思議になくらいに、初めからそのままそこにあったかの様だった。どうして自分はこれを思いつくことができなかったのか。自分の未熟さや技量のなさはもちろんのこと、何よりもオブジェクト指向 UI にする、モードレスであるために別の可能性を模索し続ける圧倒的な質と量の違いだと思った。質量というよりも熱量か。
最初から上手に、賢く「使い分け」しようなどと考えていては、そこに到達することはできないだろう。

本には「名詞」→「動詞」の順序にすればいい、なんて、誠に明快にあっけなく書かれているし、それは本当に全くその通りではあるが、オブジェクト指向 UI にするのは、実は結構難しい。少なくとも私には。いや、オブジェクト指向 UI にするのが、というより、制作の中にあってそのモードレス性を保ち続け、より良いデザインをする事が、といった方が正確だろうか。いずれにせよ、特に業務アプリケーションの制作のように、複雑で生産的で創意工夫にあふれた活動をソフトウェアとしてデザインする場合、自然にやったらオブジェクト指向 UI に勝手になるなんてことは全然ない。
そんな風に奥が深くて、なかなか容易なものではないから、これはオブジェクト指向 UI にはできないのだと諦めてしまったり、タスク指向 UI が向いているものなのだと思い込んでしまう気持ちは私にもよくわかる。

オブジェクト指向 UI の、使いやすいソフトウェアの原理はとても、とてもシンプルだけど、そこには既存の手続きやタクスを解体して、別の新しいメンタルモデルをユーザーに提案する、そう、「発明」と呼ばるような、パラダイムの転換がいつも共にある。ラリー・テスラーのカット＆ペーストや、iPhone の UITableView みたいに。

GUI の、ソフトウェアのデザインにおいては、コンセプトに関わる大きなものも、操作性に影響する細かいものも、それぞれに、フラクタルに「発明」が起こっていて、それらが全体としてその形作っている。そしてこれは一度 UI 上に現されてしまったら、もう当たり前の事として皆に受け入れられてしまうから、当事者であってもなかなかその転換を上手く捉えることができない。本の後半、応用編にあるのはまさに、この「発明」について抽象化されたものではあるのだけど。そのようにメソッドになるまで概念化すると、シンプルな原理になってしまい、具体化すると個別すぎる。かといって、出来た物を見てもそうとしか思えないからリバースエンジニアリングも出来ない。「あの時の、あれ」みたいにしか表現できないもの。

それについては本には書かれていない。
それは自転車に乗る時の、身体の動かし方みたいなものだから。

本には、『オブジェクト指向 UI デザイン』 には書かれていないものがある。

いや、違うか。書かれているのに、それを読み取れる状態に自分がなくて受け取れない。上手くいえないけど。

私達 UI デザイナーは、使いやすいソフトウェアの原理を携えて自らを支えつつ、作ることを繰り返す中で歩みを運び、それを体得していくしかないのだろう。私にはそんな気がしている。たぶん、そういうものなのだと思う。

＊　＊　＊

※ 1
しかしながら、そういったブログ記事の中でも、本の内容そのままだったり、微妙に変えつつもほぼ丸写しだったりするものや、さらにその上で本について一切言及のないものについては、一体どういう意図があってやっているのかよく分からない。そういえばこの本に限らず、デザイナーやエンジニアが丸写しスタイルのブログや動画を量産しているのをよく見かける。今回のテーマからは逸れるのでこれについては追求はしないが、IT 業界で議論を深めるべき課題と思う。
絵を写して描く、ファンアートみたいなノリで、ようするに対象の本が好きのかな、と私は思うけれど、それならせめて出典は明記するべきだろう。そして、出典の記載があれば丸写しして良いのかというとそれも微妙な所だ。
読者にはシンプルで単純な内容に思えたとしても、それを形にするまでには膨大な試行錯誤があっただろう事は想像に難くないのだから、そこへの敬意はあって然るべきだと思う。『オブジェクト指向 UI デザイン』にあるものも、20 年かけてまとめ上げられた大切なメソッドなのだから。
個人的な学びの記録ならともかく、そんな丸写しが、少なくとも会社や書き手個人の PR になるとは思えない。

※2
コンテンツ・ファーストでいうと、この本が良書と思う。おすすめです。本の内容としては CMS とかウェブサイトよりの話が多いかな。もちろん、その射程は広いものの。

※3
特殊な上司とは『オブジェクト指向 UI デザイン』の著者の一人、上野 学 氏のことである。わお！
めっちゃ優しいでしょ。本当にめっちゃ優しくてカッコいいから！