Monthly Archives: October 2009

GUI とオブジェクト指向の間には強い繋がりがあると確信していた僕でしたが、その関係性をもっと直接説明した資料はないかと思って調べたところ、それほど多くはないものの、いくつかの文献に行き当たりました。 まず最も権威的なものとして、IBM が80年代に出版した「Object-Oriented Interface Design – IBM Common User Access Guidelines」というのがありました。これは IBM が OS/2 その他の GUI システム全般に適用するために策定したユーザーインターフェースデザインのための詳細なガイドラインなのですが、その前段部分で、「Object-Oriented User Interface（OOUI）」という言葉で GUI の思想を語っているのです。多少強引なところはあるものの、GUI はオブジェクト指向であるべきであるということを具体的な実装サンプルとともに説いているのです。ただ残念なことに、サンプルとして示されるデザインがあまりにもダサいので、Apple のガイドラインのような説得力がありません。理屈はよくても出来上がる画面がこれじゃなぁという感じなのです。OS/2 を思い出してください。あんな感じです。 IBM のこの OOUI メソッドは、後に「OVID（Object, View, and Interaction Design）」というメソッドに発展します。OVID については、「Designing for the User with OVID – … Continue reading →

「目的語 → 動詞」のシンタックスでインタラクションを設計することが GUI において重要であるということは、Apple のガイドラインをはじめ、多くの指南書で説かれていることです。目的語とは多くの場合、処理の対象物のことですから、「名詞 → 動詞」という書き方で同様のことを説明している場合もあります。 とはいえ、実際にパソコンを使っていると、基本的な操作の部分で、「動詞 → 目的語」のシンタックスが結構使われているのです。 まず前にも書いたとおり、アプリケーションの選択という操作はタスク指向です。アプリケーションを選ぶということは、これからやることを選ぶということです。例えばワープロソフトを起動するということは文書編集タスクを選ぶということですし、ウェブブラウザを起動するということはウェブ閲覧タスクを選ぶということです。これは別の言い方をすると、処理対象のデータ集合を選ぶということです。個々のデータオブジェクト（インスタンス）ではなく、データの種類（クラス）を選ぶところから作業を開始しているのです。例えばワープロであればワープロ書類、ウェブブラウザであればウェブページというクラスを選んだことになります。クラスの抽象度や扱える種類の数はアプリケーションによって違いますが、タスクは特定のデータクラスと紐づいていると言えるでしょう。 一方、オブジェクト指向のシンタックスにおけるオブジェクトとは、すなわちあるデータ集合におけるインスタンスとなります。 以前開発が進められていた「OpenDoc」は、パソコンにおける基本的なシンタックスを、タスク指向（アプリケーションにファイルが従属する）からオブジェクト指向（ファイルにアプリケーションが従属する）に転換しようとする試みだったわけですね。 ちなみに、データ集合に対する CRUD のうち、Create Read Update は特定のアプリケーションが行い、Delete（および複製やいくつかのメタデータ変更）はOSのファイルブラウザが行うというのがこれまでのパソコンにおける基本的な役割分担です。ただし iTunes などはファイル管理までもをアプリケーション内で完結させようとしています。 次に、多くのアプリケーションにはメニューに「開く…」という項目があります。これを選ぶと、対象のファイルを選択するダイアログが開きます。つまり「開くモード」に入ります。目的のファイルを選び、ボタンを押すと、ダイアログが閉じて（モードから出て）そのファイルが開かれます。 同様に検索機能も多くの場合タスク指向のシンタックスになっていて、メニューやボタンで「検索…」を選ぶと検索ボックスが現れ、キーワードを入力してボタンを押すと実行されます。 「開く…」も「検索…」も、実行前に気が変わった場合は何らかのキャンセル操作をしなければモードから出ることができません。検索の場合は更に、検索結果を表示するのに通常の一覧ビューを検索結果表示モードに切り替えることが多く、これもまた通常のビューに戻すために何らかのモード終了操作が必要になります。 ユーザーがまずタスクを選択し、何らかの入力操作（コマンド実行の引数となるパラメーター指定）を行い、最後にそれをサブミットすることで処理が実行されるという意味では、「印刷…」や「名前をつけて保存…」もタスク指向のコマンドです。ただしこれらの場合は対象物が現在見ているファイルということで自明なので、オブジェクト指定の操作はありません。 Windows のコントロールパネルやアプリケーションのユーザーオプションでは、このようにパラメーターの指定をメモリにためてサブミットでまとめて処理に投げるという実装がほとんどです。つまりモーダルな操作になっています。だから入力パネルには必ず「OK」と「キャンセル」のボタンがあります。 ところが、Mac の場合はずいぶん事情が違います。あまり語られることがないので Windows ユーザーは知らないのではないかと思いますが、最近の Mac では、そういったモードがほとんど絶滅しつつあります。 これについては、また後日書きます。

僕は、オブジェクトの選択がインタラクションの起点となっているようなデザインを「オブジェクト指向のユーザーインターフェース」、タスクの選択が起点となっているものを「タスク指向のユーザーインターフェース」と呼ぶことにしました。オブジェクト指向といっても、プログラミング様式のそれとは実現のための手段が全く違いますが、コトよりもモノを基準にして構造を作るということや、状況の変化に強い（というか文脈が不確定であることを前提にする）ことを重視するという意味で、根本的には同じ価値観を共有していると言えるでしょう。 GUI のポテンシャルを引き出すには、当然オブジェクト指向のユーザーインターフェースが望まれます。しかし、決められた業務を行うためのシステムにおいては、タスク指向にせざるを得ない場合が多いということも分かって来ました。 ぼくはこの「オブジェクト指向」と「タスク指向」の対比について、よく「自動車」と「電車」に例えて説明します。自動車は、目的地までの行程を自由に決定することができ、途中で道を変えるのも行き先を変えるのもドライバーの自由です。一度行った場所に二度目に行く時には、一度目よりももっと効率的なルートを思いつくかもしれません。ドライブという仕事の帰着点は、結局ドライバー自身が「ゴールに着いた」と自覚した場所ということになります。ただし、目的地までのルートをドライバーが全く知らない、もしくは予測しづらい場合には、あっちでもないこっちでもないと迷子になり、結局辿り着けない（ゴールにたどり着いたと自覚できない）かもしれません。一方電車は、最初に選択肢から目的地を選ぶ（電車に乗る）だけで、途中の地理について全くイメージを持っていなくても確実に辿り着くことができます。しかし途中で道を変更することはできませんし、自分なりの工夫で行程を効率化することもできません。どちらを好むかは人によりますが、ひとつ言えることは、GUI というのは本来自動車であるということです。自動車式の作業に向いたユーザーインターフェースなのです。 最近ではパソコン以外にも、携帯電話や複合機やテレビやゲームや券売機などあらゆるデバイスにグラフィカルなユーザーインターフェースが用いられています。けれど、「目的語 → 動詞」というオブジェクト指向のシンタックスが実現できているものは案外少ないのです。それだと、見た目はアイコンやフォルダといったグラフィック表現になっていたとしても、GUI とは言えないと思います。なんちゃって GUI です。 例えば携帯電話のインタラクションでこういうのがよくあります。メールの本文を表示していて、ある文字列をコピーしたいとします。そのためにはまずメニューを開いて「コピー」を選びます。すると「始点を指定してください」といったメッセージが現れ、十字キーでカーソルを移動して始点に持って行き、「確定」ボタンを押します。すると「終点を選択してください」といったメッセージが現れ、また十字キーでカーソルを動かして終点を指定します。これでやっと「コピータスク」が完了します。ペーストする時にも同様の手順を踏みます。これは相当まどろっこしくないですか？ 操作のステップごとに「始点選択モード」や「終点選択モード」が発生していて、途中でやめようと思ったら、いちいちモードから出るためのキャンセル操作が必要なのです。 つまりこういうことです。オブジェクト指向のシンタックスを実現するには、「対象選択」の操作をいつでも行えるようになっていないといけないのです。そしてそのためには、対象となるオブジェクトが最初から見えていて、それを指し示すためのポインターがシステムの状態に依存せずに常にフリーになっている必要があるのです。 余談ですが、iPhone には当初コピー＆ペーストの機能がありませんでした。これを後から実装するにあたって、いくつかの課題があったと予想します。 まずポインターの自由度についてですが、iPhone におけるポインターはユーザーの指ですから、かなりフリーな状態にあります。ただし指でのタッチ操作では、指し示す対象物を指自体が隠してしまうと同時に、選択範囲の指定という細かい座標移動がしづらいということがあります。また、任意の文字列範囲選択をモードレスに行うためにはドラッグ操作が必要になりますが、iPhone においてドラッグ操作はスクロールを意味しているので使えません。文字列の特定箇所でしばらくタップ＆ホールドしてからドラッグを開始するという操作も考えられますが、このジェスチャは「カーソル周辺の拡大表示」に使われてしまっています。 結果的に、完全にモードレスにすることはできず、タップ＆ホールド＆リリースからのメニュー表示と、ダブルタップでの選択開始という若干手続き的な操作になりました。それでもさすがに「対象選択 → コマンド選択」というオブジェクト指向なシンタックスは崩さないインタラクションを実現しています。また指が対象を隠してしまう問題に対しては、選択ハイライトの両端につまみをつけて、更にドラッグ中にはその周囲を拡大表示するという従来からの表現を再利用することで、なんとか解決しています。 ということで、GUI においては、オブジェクト指向のシンタックスが重要であり、そのためには対象物が最初から見えている必要があり、またポインターは常にフリーでいつでも選択ジェスチャを行えるようになっていなければならず、そうすることでモードを減らすことができる、という方程式が見えてくるのです。

いろいろな業務アプリケーションのユーザーインターフェースを設計していると、「動詞 → 目的語」というシンタックスの壁をどうしても打ち破れないことがあります。不自由な操作性であることは分かっていても、モードを作らざるを得ないのです。それは例えば次のような場合です。 タスクによって処理対象となるオブジェクト集合が異なる場合。この場合、タスク選択はアプリケーションの選択と同じような位置づけとなる。 タスクによって、ユーザーに提示すべきオブジェクトのプロパティやメソッドが大きく異なる場合。この場合、先にオブジェクトを提示しようとすると、情報量が多くなり過ぎてユーザーインターフェースが破綻する。 対象オブジェクトが（ユーザーのメンタルモデルにおいて）存在しない、あるいは対象オブジェクトがひとつだけで選択の必要がなく、アクションの引数指定としての入力操作がタスクの大部分である場合。例えば切符の券売機。 ユーザーの創造的な作業を禁止し、一定の順序で限定的な操作をさせたい場合。つまりウィザード。 データの整合性やセキュリティの都合上、トランザクションを一元化する必要がある場合。そのためには、モードの中で決まった項目だけを入力させて、モードから出るタイミングとトランザクションのタイミングを一致させるのが望ましい。 これらの状況が、業務アプリケーションにおいては結構多く発生するのです。 考えてみれば、それは当然のことなのです。なぜなら、そもそも業務というのは一定のタスクのことであり、決められたことを決められた手順で行うことだからです。その業務手続きをオンラインで行えるようにしたのが業務アプリケーションですから、ビジネスロジックのほとんどがタスクに依存してしまうのです。その結果、タスクを選択してからでないとオブジェクトを選択できないような作りになり、システム全体がモードのごった煮みたくなってしまうのです。 これを打破するためには、業務手続き自体をもっと自由にするか（これは企業ガバナンス的にあり得ない方向性ですが）、もしくは、業務アプリケーションの役割を「業務手続きのオンライン化」から「業務のオンライン化」に変えていく必要があるのではないかと思います。

最初の頃に手がけた案件で、ある SIer が開発中の、画像データに特化したアセットマネージメントのシステムがありました。このシステムの、要件定義段階のモックアップがあり、それに対してエクスパートレビューと改善デザインを行うという仕事でした。 要は、管理対象の画像データのデータベースがあり、そのデータベースに対して CRUD（Create, Read, Update, Delete）を行うためのユーザーインターフェースが必要とされていました。 エンジニアが作ったモックアップのポンチ絵を見て、僕は強烈な違和感を覚えました。このシステムの基本要件は、画像（メタ）データの照会、追加、変更、削除、他システムへの送信といったものだったのですが、モックアップでは、初期画面において、「照会」「追加」「変更」「削除」「送信」というボタンがそのまま並んでいるのです。そして例えば「照会」ボタンを押すと、画像データのサムネール一覧が検索機能などと共に表示され、そのうちひとつを選ぶと画像の内容が表示されます。初期画面に戻って今度は「変更」ボタンを押すと、同じように画像のサムネールが表示され、ひとつを選ぶとメタデータ変更フォームが表示されます。いずれも同じ対象データを同じように一覧表示するのですが、そこでできることは初期画面で選んだ項目（タスク）に依存していて、別なことをやろうとしたら一度初期画面に戻らなければならないのです。 担当のエンジニアは、このインタラクションについてこれといった課題意識は持っていませんでした。恐らく発注者側もそうだったのでしょう。むしろ、定義されたユーザー要件を適切に画面設計に落とし込んだと思っているようでした。また、一覧画面においてサムネールをドラッグ＆ドロップできるようにするといったアイデアを自慢げに語っていました。 僕の感じた違和感というのは、当然、その基本的なシンタックスについてでした。このモックアップのシンタックスは、「動詞（タスク選択）→ 目的語（対象画像データの選択）」となっています。しかし、同じオブジェクトの集合に対して操作をするのに、あらかじめタスクごとにモードを生成する必要があるでしょうか。タスクによってビューの表現が全く違うのであればまだ分かりますが、これでは単にユーザーの自由を無意味に制限しているだけです。 そこで僕は、まず最初にサムネールを一覧させて、そこで選んだものに対してアクションを選択するという、「目的語 → 動詞」のシンタックスに作りかえたデザイン案を作成しました。それが GUI の自然なインタラクションだと思ったからです。 その後、僕はいろいろな案件で沢山の業務アプリケーションを目にすることになりました。それらのほとんどは、何らかの形でデータベースに CRUD する要件を持っていましたが、驚くことに、かなりの割合でシンタックスの問題があったのです。僕にとってこれはもうカルチャーショックみたいなもので、改善デザイン案を出すのに躊躇してしまうほどでした。しかしいざ提案してみると、操作が合理的でかつ画面数が減るということで、それなりに「なるほど」と言ってもらえるのでした。どうやら彼等の多くは、日々様々な画面を設計しながらも、シンタックスについては考えたことがなかったようです。

そんなこんなで、僕は、ユーザーインターフェースの評価や設計を専門に行う会社で働くようになりました。 僕の最初の仕事は、いわゆるエクスパートレビューのための評価メソッドを作ることでした。オリジナルの評価項目を作るにあたって、僕はいろいろな資料を漁って、ユーザーインターフェースのデザイン原則と言われるものを集めました。Apple Human Interface Guidelines をはじめ、ニールセンのヒューリスティック項目や、クーパーの格言、等々。そしてそれらの中から重要だと思われるものや汎用性の高いものを抽出して整理し、20項目からなるオリジナルのヒューリスティック項目を作り上げました。このヒューリスティック項目は、その後少しずつ修正を加えながら、8年たった現在も評価案件で使われています。 僕は実案件を行う傍ら、雑誌や技術系情報サイトに記事を書いたり、セミナーの講師をやったりするようになりました。そういうものの中で僕は、よくデザイン原則を紹介してきました。例えば「直接操作」だとか「一貫性」だとかそういう項目を5個から10個ぐらい挙げて、良いユーザーインターフェースを作るために必要な考え方として説明してきました。 僕がデザイン原則的なものを紹介するのを複数の場所で見たり読んだりした人は気づいたかもしれませんが、「デザイン原則10箇条」とかなんとかそういう言い方で挙げる項目というのが、実は毎回ちょっとずつ違うのです。ある時は「ユーザーによるコントロール」というのが入っていて、別の時には入っていなかったりするのです。かわりに「迅速なフィードバック」が入っていたりとか。 要するに、自分の中で納得のいくデザイン原則がまとまりきっておらず、ああでもないこうでもないと迷っているのです。有名なコンサルタントやデザイナーが、書籍やメソッド紹介の中でいろいろなデザイン原則を掲ています。それらは皆似ているところもあるけれど少しずつ違っていて、これという定説になっていません。また項目同士があまり排他的になっていなくて、かなり近い意味合いのことを別な項目として挙げていたりします。例えば Apple のガイドラインにある「Direct Manipulation」「See-and-Point」「WYSIWYG」「User Control」あたりは、結局同じようなことを言っていないでしょうか？ そういう様々なデザイン原則あるいはヒューリスティック項目の中から似たものを集約していって整理したら、本質的には、実はものすごく少数の項目になってしまうのではないかという気がしてきたのです。

その頃僕は、プログラミングの真似事として、REALbasic でちょっとしたシェアウェアを作ったりしていました。 GUI アプリケーションの基本的な実装方法をそこで（感覚として）把握できたのは、後々役に立ちました。例えば、ウィンドウやコントロールの生成と管理の方法や、イベントの扱い方、ファイルの読み書きとそのタイミング、状態の持ち方とその表現、等々。 全てのコントロールが、要はグラフィックを描画する汎用オブジェクトのサブクラスであることを改めて意識できたのも良かったと思います。完成されたアプリケーションを使っているだけだと、各コントロールがまるで生きた個体として独自に発生したかの見えますが、中を覗けば、全て同じ分子構造を持った「絵」なのでした。 OSが様々なクラスを用意していて、基本的にはそれらのインスタンスを組み合わせればよいということ。もし機能を拡張したければ独自のサブクラスを作ればよいということ。そういった基礎的な方法論も分かってきました。 オブジェクト指向の環境において分かりにくかったのは、概念的なクラスについてでした。コントロールやコンテナーといった目に見える部品のクラスはなんとなく分かるのですが、例えば日時とかデータストリームなどの目に見えない概念上の要素までもオブジェクトとして部品化するというのは、なかなか馴染めませんでした。それらは非常に文脈的であり、サブジェクトに近いと感じたからです。ただしそれらにも共通の型としていくつかのプロパティがあり、自分自身の性質を表現／変更するためのメソッドを持たせることで、オブジェクトとして便利に利用できるということが分かると、なるほどという感じでした。 それから、これも基本的なこととして、メモリの消費量とパフォーマンスが比例関係にあることも実感できました。単純に、多くの情報を変数にして使い回せば処理は速くなりますが、メモリの消費が増えると同時に、バグも発生しやすくなります。そこはバランスの問題です。サブルーチンをどれぐらい細かく構造化するのかというのも、同様に経験的なバランス感覚が必要だと思いました。 いずれにしても、if 文を重ねた条件分岐で処理を変更するような書き方をしていると、簡単にプログラムがぐちゃぐちゃになることが分かりました。そういう作りだと、あらゆる状況を想定して各オブジェクトの動きをテストしないといけなくなります。そうではなく、オブジェクト同士がお互いの（あるいはユーザーの）文脈にできるだけ無関心でいられるようにするのがコツだと思いました。GUI においては、状況は無限にあるからです。

その頃僕は、コンピュータのスクリーン上に展開されるユーザーインターフェースに関して、視覚的な部分だけでなく、操作性のデザインについてもっと理論やノウハウを知りたいと思い、いろいろと本を読んでいました。 特に面白かったのは、クレメントモックの「ウェブデザインビジネス（この邦題は完全にずれてると思いますが）」、ノーマンの「人を賢くする道具」、ブレンダローレルの「劇場としてのコンピュータ」、それから少し後になりますが、ニールセンの「ユーザビリティエンジニアリング原論」あたりでした。それらを通じて僕は、認知工学やユーザビリティ工学といった研究領域、そしてインタラクションデザインやインフォメーションデザインといったデザイン領域の存在をはっきりと意識するようになりました。 クレメントモックの本にあった、ユーザーインターフェースとインタラクションが直交する概念図や、ブレンダローレルの本にあった、人とコンピュータの間のコミュニケーションが厚みを持った「経験」として両者を繋いでいる概念図は、気に入って今でもよくプレゼンテーションで使っています。 僕は身の周りのあらゆるユーザーインターフェースについて、使いにくい点を見つけては、その理由と改善方法を考えるのが癖になりました。 ユーザビリティという要素が、僕にとって最大のデザイン課題になっていったのでした。

オブジェクト指向という言葉はどこかで聞いたことがありましたが、その意味はほとんど分かっていませんでした。調べても難しくてよく理解できなかったのですが、要するに、オブジェクトを重視しろということだと思いました。 オブジェクトという英単語は僕の中ではサブジェクトという単語と対になっていたので、サブジェクトよりもオブジェクトを中心に考えろということだと解釈しました。サブジェクトは文脈的ですが、オブジェクトは宣言的です。サブジェクトは暗示的で、オブジェクトは明示的です。サブジェクトがリンクだとすれば、オブジェクトはノードです。サブジェクトが事なら、オブジェクトは物です。つまり事よりも物に着目するということです。 このように僕の場合、プログラミングの方法論としてではなく、物事を整理したり組み立てたりするための考え方として、オブジェクト指向というコンセプトをまず認識したのでした。 僕の作った実験サイトは、実際にはオブジェクト指向というよりも「構造化されている」という程度のものでしたが、ユーザーインターフェースの実装に関して、次のようなオブジェクト指向に繋がる考え方を学習するきっかけになりました。 共通の部品は使い回す 使い回せるように一定の部品の集合で全体を構成する 部品は文脈に依存せずに存在できるようにする 部品は部品によって呼び出される 文脈はその呼び出し方によって決定され、文脈に応じて呼び出される部品の状態が変化する こういった手法は、特に勉強などしなくても、あるシステムの構造を効率化して、なおかつ柔軟性を最大化しようとすれば、自然に導出されるものであるはずです。つまりあらゆるデザイナーにとって基本のノウハウと言えるでしょう。 僕が特に重要だと考えたのは、文脈をユーザーに解放するということでした。システムは自身の機能を体現するだけで、使い方をユーザーに指示するべきではないと思いました。ある道具が役に立たないとすれば、それはその道具が状況に適していないだけで、ユーザーの使い方が悪いのではないはずです。 物それ自身がありのままの状態で状況とのマッチングを待っている、というのが、僕の解釈したオブジェクト指向の世界でした。 そしてユーザーインターフェースもそうあるべきだと思いました。 その頃はまだ、ポリモーフィズムとかカプセル化とか継承といったことについては何も理解していませんでしたし、いわゆる OOUI と呼ばれるデザインメソッドの存在など知る由も無かったのですが…