Author Archives: Manabu

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

最初の頃に手がけた案件で、ある 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 と呼ばれるデザインメソッドの存在など知る由も無かったのですが…

その頃、ウェブのデザインにおいて「コントロールの不自由さ」を強く感じていたのが、ページメタファでした。 HTML はドキュメントをマークアップする言語なので、当然と言えば当然なのですが、ブラウザに表示される内容は基本的に一枚の紙であり、主なインタラクションはリンクのクリックでページをめくるだけという、相当しょぼい世界でした。 しかしウェブデザインのトレンドは次第に、クレメントモックが作った諸々の企業サイトに代表されるような、かっちりとしたヘッダーやサイドメニューを持つ、アプリケーションの GUI ライクなものに変化していました。サイト内の全てのページに共通のナビゲーション要素があり、ページを遷移すると現在見ているページのメニュー項目がハイライトされるのです。これは単に、全パターンのハイライト状態があらかじめ用意されているだけで、（サーバーサイドでどの程度自動化されていたかは知りませんが）結局はページ全体を毎回表示しなおすパラパラ漫画なのでした。 そもそも僕は、はなからウェブの画面をドキュメントとしてではなくユーザーインターフェースとして見ていました。HTML をコンテンツではなくユーザーインターフェースの実装手段として捉えていましたので、この子ども騙しのようなギミックがどうしても気に入りませんでした。 当時は今のように標準化された DOM スクリプティングはありませんでしたし、僕は JavaScript が書けなかったので、ユーザーのアクションに応じてページの一部を変化させようと思ったら、フレームを使うしかありませんでした。 ある時、会社内でデザインコンペみたいなのがあり、僕は実験的に、フレームを多用した、ページ遷移の無い、アプリケーションのようなサイトを作ってみました。 画面上部にはメニューバーのようなものがあり、項目ごとにフレームになっていて、クリックするとその下の領域のフレーム内にサブメニューが表示されます。その中からひとつをクリックすると、画面中央のフレームにコンテンツが表示されます。コンテンツ内には関連リンクを呼び出したり注釈を呼び出したりするリンクがあり、それらをクリックすると画面左右の小さなフレームに表示されます。小さなフレーム内で何かクリックすると、中央のフレームが変化したり、自分のフレームを書き換えたりします。このように、あるフレーム内でのクリックが他のフレームを次々と変化させて、画面全体で見れば無数の表示状態があるというものでした。 フレームの位置関係が固定的であることや、サーバーサイドでの動的な処理を一切行っていないことを考えると、パラパラ漫画をいくつも分割して同時に見せているに過ぎなかったのですが、画面の表示内容が一定でなくユーザーの行動に対して解放されており、ページ遷移無しに無数の段階で変化するという点で、コンセプトモデルとしてはなかなか満足のいくものになりました。（今となっては、ウェブ的ではない表現として一蹴されそうですが） それを見た上司が、こんなことを言いました。 「これはオブジェクト指向だね」

モードレスネスの説明としては、こんなことが書いてありました。アプリケーションはできるだけモードが無い方が良い。モードが無いということは、ユーザーが好きな時に好きなことができるということ。モードはユーザーの行動を制限してしまい、ひとつの作業を終えるまで次の作業に移ることができない。モードが無ければ、ユーザーはもっとコンピュータをコントロールできる。 僕はユーザーインターフェースにおけるモードというものをそれまであまり意識したことがありませんでしたが、これを読んで思い浮かべたのは、Windows におけるウィザードでした。 はじめて Windows を触った時、◯◯セットアップウィザードというのがやたらと多いのに気付きました。それらはどうやら初心者向けに用意されたプログラムのようでしたが、僕にとっては、留守中に母親が勝手に机の上を片付けてしまったような気持ち悪さがありました。 Windows においてこの気持ち悪さを増長させていたのが、そのデスクトップの実装コンセプトでした。何かのアプリケーションをウィザードでインストールした後、そのアプリケーションの起動方法が分からずに人に聞くと、スタートメニューにアイコンが追加されているはずだというのです。確かにそこにはアプリケーションのショートカットが登録されていましたが、アプリケーションの本体がどこにあるのか全くイメージできませんでした。ディレクトリの中を探し回って、やっとそれらしきアイコンを見つけたので、自分で用意したフォルダにそれを移動しようとすると、移動できませんといったアラートが表示されました。移動できるアイコンと移動できないアイコンは、見た目からは全く区別できません。やってみるまで分からないのです。自分の意思ではなく、誰かの意思で勝手に自分のコンピュータが変更され、しかもその状態を変更することができないのです。そういうのがいちいち煩わしくて、頭にきました。 そういったことから、モードというのは、単にウィザードのことだと捉えていてはダメで、もっと広く「コントロールの不自由さ」のこととして考えなければならないと思い当たったのでした。

技術文書を読んで泣く奴があるかと自分でも呆れましたが、それは技術文書というよりも、哲学書か思想書のようなものでした。実際、冒頭の「What’s in This Book」という内容紹介には、この本は The Basic Philosophy、The Interface Elements、Appendix で構成されていると書かれています。 その哲学は、第一章の「The Human Interface Principles」に集約されています。デザインの原則として、メタファーを使うことや、直接操作を可能にすること、ユーザーにコントロールを与えることなど、いくつかの基本方針が謳われていて、Mac 自体のUIデザインの成り立ち、そして Mac のアプリケーションを書くデベロッパーが覚えておくべき心得が説明されているのでした。 簡単に言えば、ユーザーにとって使いやすいことが第一義であり、そのためにはよく考えてUIをデザインしなければならないということです。UIがダメなら他は全部意味を無くすということです。 今となっては、当たり前過ぎて、なぜ自分がそれ程までに感銘を受けたのかよく分からなくなっているのですが、とにかくその時は、「使いやすさを実現するための技術」というものに正面から取り組む姿勢が、強烈に進歩的で、 人類を解放に導くもののように感じたのでした。Apple にしてみれば、もう十年以上前から主張してきたことだったわけですが。 その頃僕はまだ、ユーザビリティーとか UCD といった言葉はおろか、そういう類いの研究領域があることすら想像したことが無かったので、尚更、Apple の Human Interface Guidelines が大きな扉を開いたように思ったのです。 僕はそれまで、Mac の楽しさは偶然の産物だと思っていました。けれど Human Interfece Guidelines を読んで、その考えが間違っていたことを知りました。Mac の楽しさは、かなり意図的に、膨大な研究と試行錯誤の上に実現されていたのでした。 デザイン原則として挙げられているのは次の項目でした（1995年板）。 Metaphors Direct Manipulation … Continue reading →

DTP というのは、印刷物のイメージをパソコンのスクリーン上で作る仕事です。版下や刷版を作る前に画面でほぼ完全なプレビューを得ながら作業できるという点では画期的なのだと思いますが、あくまでそれはプレビューであり、アウトプットそのものではありませんから、作業をしていてもなんとなく靴の上から足をかいているようなもどかしさがあります。なので僕は、コンピュータのスクリーンが最終出力先であるウェブの仕事に転職しました。ウェブには、僕がやりたかったバンド音楽や絵画や写真や小説などが全部あるような気がしたのも理由です。 スクリーン上でレイアウトをしたりグラフィックを作ったりするという意味では、ウェブのデザインは DTP の作業とよく似ていました。ただひとつの大きな違いは、ユーザーインターフェース要素を沢山作らなければならないということでした。例えばナビゲーションのメニューとか、ボタン状のリンクなどです。これらは紙媒体には無い要素でした。 当時（1997年頃）はほとんどがスタティックなページだったので、同じような部品のバリエーションを全て手作業で作っていました。しかも、見栄えを気にする要素は文字であってもどんどん画像で作っていたので、100個もあるメニュー項目の通常状態とハイライト状態を全部画像で作るなど、地味な作業が膨大に発生していました。そういうのはかなり忍耐力のいる仕事でしたが、それでも僕は、ユーザーインターフェースを作っているということが嬉しくて、結構楽しんでいました。 例えば、Photoshop の鉛筆ツールを駆使してアンチエイリアスフリーのグラデーションを作ったり、ウェブセーフカラーのカスタムパレットを自作して全ピクセルの RGB 値を把握しながらイラストを減色するなど、スクリーン表示を前提に如何にグラフィックを最適化するかといったことに情熱を傾けていました。僕は自分に、ピクセルマッドネスというニックネームをこっそりつけていました。 僕は相変わらず Mac が好きで、仕事でももちろん使っていました。周りにも Mac 好きの人が沢山いて、かなり幸せな職場でした。 そんなある日、僕は何かのきっかけで（どういうきっかけだったのか思い出せないのが悔しいのですが）、apple.com のサイトに Apple Human Interface Guidelines なるドキュメントが掲載されていることを知ったのです。そういえば、以前に一度本屋でそんな感じの書籍を見かけたことがあるような気がしましたが、その時はなぜか手に取らず、それきり忘れていたのでした。 オンラインのそれは、HTML と PDF になっていて、誰でも無料で読めるようになっていました。僕は PDF をダウンロードして、最初から読み始めました。それは衝撃的な内容でした。僕は読み進めるうちに、なんだか目頭が熱くなってくるのを感じました。