Monthly Archives: January 2010

僕はよく自動販売機で缶コーヒーを買うのですが、あの釣銭返却レバーを見るたびに、そこに無反省なブルジョアジーを感じて気分が悪くなるのです。なぜ自販機というのは硬貨投入が先で商品選択が後なのでしょうか。硬貨投入が先であるために、商品選択待ち状態というモードが発生するのです。商品選択が先なら、モードをキャンセルする返却レバーは不要になり、操作も自然になるはずです。 巷ではユーザビリティの重要性が叫ばれ、良いデザインを実現するためのプロセスについて諸説を耳にするようになりました。しかしそのほとんどは、プロセス自体に冗長性を持たせるだけの保守的なものであり、シリアライズされた言語的な理論にすぎないのです。そこからは、要するに良いデザインとはどういうものか、という疑問に対する具体的な回答を得られないのです。ましてや、僕が実際のUIデザイン案件を通じて感じてきたイデオロギーギャップについて言及しているものは皆無です。 コンピュータメディアに新しいサービスが現れると、人々はそれにまつわるコミュニケーション論やコミュニティ論を展開します。けれどサービス像の具象化を担うデザイナーの立場からすれば、まず議論すべきはデザインのコミュニズムなのではないかと思うのです。そのデザインは、いったい誰に力を与えるものなのか、と。 そんなことを考えながら、ある夜、会社からの帰り道、缶コーヒーを飲みながら僕は、何げなく iPhone で古い友人の名前を検索してみました。ずっと前に、彼とデザイン論みたいなものを交わしたことがあったなあと思い出したからです。というのは嘘で、本当は彼が清志郎について何か書いてるんじゃないかと思ったからなのですが。それで僕は彼がデザインについて書いているブログを発見しました。それがとても面白かったので、僕も何か自分の考えを書いてみたいと思いました。帰宅途中の坂道で書くデザインについての連載小説。それがこのブログを書いたきっかけです。 これで「Modeless and Modal」は終了します。 最後に、さっき浅野さんに教わった記事から、かっこいい言葉を引用しておきます。 In particular, if we think about Interactive Design, the highest goal should be to empower people to create their own meaning spaces, not solve pre-determined problems or even make great … Continue reading →

スティーブジョブスはかつてこんなことを言っています。 僕は「サイエンティフィック・アメリカン」だったと思いますが、人を含めた地上のさまざまな動物の種の、運動の効率に関する研究を読みました。その研究はＡ地点からＢ地点へ最小限のエネルギーを用いて移動する時に、どの種が一番効率が良いか、結論を出したのです。結果はコンドルが最高でした。人は下から数えて３分の１のところでした。 しかし、人が自転車を利用した場合を、ある人が考察しました。その結果、人はコンドルの倍の効率を見せたのです。つまり、自転車を発明した時、人は本来持っている歩くという身体的な機能を拡大する道具を作り出したといえるのです。 それゆえに、僕はパーソナルコンピュータと自転車とを比較したいのです。なぜなら、それは、人が生れながら持つ精神的なもの、つまり知性の一部を拡大する道具だからです。個人のレベルでの生産性を高めるための特別な関係が、人とコンピュータの関わりの中で生まれるのです。 aki’s STOCKTAKING より これは、パーソナルコンピュータという、当時普及しつつあった新しい道具の意義を比喩的に語ったもので、Mac 登場直前の話です。彼が「生産性を高めるための特別な関係」と言う時、どの程度 GUI の思想的インパクトを意識していたか分かりませんが、Alto や Mac が示したモードレスな世界観は、オートメーションを崇める管理主義に対して投げかけられた強力な反旗となったことは間違いないでしょう。 ここまで考察してきたように、モードレスとモーダルの対立構造は、人の生まれつきの認知特性から、社会システムに対するイデオロギーまで、非常に多方面に波及しています。世界の近代史を見れば、社会の発展には恐らく両方が必要で、両者が互いの欠点を補うことが、致命的なリスクを回避する自浄作用になるのでしょう。 しかし、ことコンピュータシステムの分野においては、モーダル党が圧倒的に優位を誇っています。これは、多くの場合、システムのオーナーとユーザーが「管理する者」と「管理される者」の関係にあるからで、「管理する者」は、「管理される者」の仕事や生活を特定のタスクによって統制するために、コンピューティングパワーを大規模に導入してきたからです。 例えば業務アプリケーションを企画する人々は大抵、UIをタスク依存に定義しようとし、そのことに何の疑問も罪悪感も持ちません。コンピュータシステムとはそういうものであると信じこんでしまっているのです。コンピューティングパワーによって仕事をもっと楽しくしようなどとは考えないのです。彼等は無自覚の管理主義者であり、無意識にユーザーから創造性を奪っています。その結果として、道端のコーラの自動販売機にまでモーダルなデザインがはびこっているのです。 フォームのサブミット時に確認画面が必要だと主張する人々は、データの不正合をユーザーのせいにして、ユーザーが気にしなければならない画面が二倍に増えていることを何とも思わないのです。メールアドレスの入力を繰り返させて、しかもわざわざコピー＆ペーストできないような細工をする人々は、人間の仕事とコンピュータの仕事が逆転してしまっていることに気づかないのです。彼等は、ユーザーに厳密な操作を強要しているうちはまだ業務に自動化できる余地があるということを理解できないのです。 別の言い方をすれば、システムをタスクファーストにするのは、オブジェクトが自明で選択の必要がない場合か、あるいはユーザーの創造性を排除したい場合なのです。少しでもユーザーに人間らしい仕事を期待するなら、ユーザーインターフェースはオブジェクトファーストにするべきです。 このような価値観は、しかし、システムのオーナー層、つまり請負型案件の発注者層にはなかなか通じません。彼等は組織や業務というシステムを管理する立場にあるモーダル党員だからです。僕は提案したデザインに思想的な同意を得ようとして何度も挫折しました。あるいは現行システム／業務が手の付けられないほどモーダルで、はじめから OOUI の提案は諦めて、モーダル党員を装って無難なタスク指向のデザイン案を作るという屈辱を何度も味わいました。繰り返されるストレスの中で、僕は、「これは闘争だ」と感じるようになりました。 コンピュータシステムがもっとモードレスになれば、我々は我々自身の創造性によって、仕事を有意義で楽しいものにできるはずです。一部のクリティカルな手続型業務を除いて、ほとんどのコンピュータシステムは、コンテクストをユーザーに解放し、ユーザーをモードから解放できるはずです。そのためには、モードレスデザインの思想と方法論を理解して実践するデザイナーがもっと必要です。人と道具が互いに影響し合い、相乗的にクリエイティビティを高められるようなデザインがもっと必要なのです。受発注関係の構図がその活動の障害になるなら、モードレスデザイナーは自発的な取り組みの中でアーキタイプを生み出し、共有し、耐久戦に向けて決起していかなければならないのです。 機は熟していると思います。我らが歩武の先頭には、すでに先人の掲げた反旗が翻っているのです。

優れたユーザーインターフェースやインタラクション、ひいてはプロダクト／サービスをデザインするためのメソッドとして、UCD や HCD と呼ばれるものがあります。いずれもおおよその考え方を示すもので、プロセスの詳細やアウトプットが厳密に標準化されているわけではなく、作業レベルでは色々な方法論が提案されています。 プロセス上の一般論としては、まずユーザーの要求を如何に発見するか、ということが課題になります。ユーザーは自身の要求をデザイン要件として明文化できないので、それをユーザビリティエンジニアが観察なりインタビューなりを通じて明文化しようというものです。 次に、抽出された要求事項をシナリオなりにして、タスクとして構造化します。そのタスクを手がかりにしてユーザーインターフェースを作ります。 ただし、普通ユーザーインターフェースは一度で良いものが作れないので、プロトタイプによるテストを繰り返してブラッシュアップしましょう、という流れになります。 このように、テストによって問題点を潰し、求められる機能を付け足していったデザインは、使っていて何となく分かるものです。つまり、少し分かりにくいような場面では説明調のラベルが用いられていたり、「ここであの機能が使えたらいいな」という場面で確かにそのためのボタンが現れたりするのです。しかし、それらがとって付けたように唐突に現れるのです。システム全体で見ると、一貫性やまとまりに欠け、学習や予測がしづらいのです。あるいは、マニュアルを見て操作を覚えた後であればそれなりに各コントロールの合理性を理解できるものの、それはあくまでもハード的な部品数削減のための合理性であり、メンタルモデルの形成には寄与しないものであることが多いのです。 このような、「一応便利に使えはするけどイマイチなデザイン」について、僕はどのように評価すればよいのか迷います。ただ、それが目指すべき理想のデザインでないことは確かです。 問題は恐らく、UCD/HCD のメソッドが、RUP と同様に、ユーザーのタスク（業務）を拠り所としていることにあります。ユーザーの要求を知ろうとすることは確かにシステムの有効性を高めるために必要だと思いますが、ユーザー（コンテクスト）の多様性を考えると、タスクをベースにしてデザインされたシステムは、モーダルで非効率で学習しづらいものになってしまうのです。 そのようなタスク指向のデザインメソッドに対するカウンターパートとして、OVID に代表されるオブジェクト指向デザインのプロセスがあります。 オブジェクト指向デザインのメソッドでは、OOA/OOD で行うオブジェクト分析の結果を流用できます。すなわち、ユーザーの関心の対象であるオブジェクトをクラスとして定義し、それをそのままスクリーンに登場させるのです。またその結果として、モデル層のオブジェクトとビュー層のオブジェクトが比較的自然に対応するようになり、アルゴリズムの見通しも良くなるはずです。 プログラム設計のためのクラス定義では、ユーザーのメンタルモデルには関係しないような抽象度の高いクラスやコントローラーのためのクラスなどが必要ですが、OOUI ではそれらは無視して、ユーザーにとって意味のあるクラスだけをUI上のオブジェクトとして表現します。 開発メソッドにおいてオブジェクト分析の手法が確立されているのに、それがUIに適用されていないのは、RUP に代表される標準的プロセスがタスク指向であるからだと前に書きました。しかしタスクを包括してクラスの性質を定義するというロジックの飛躍を許容するならば、モードレスなデザインもある程度メソッド化することが可能だろうと思います。その飛躍部分をノウハウとして整理するのが、デザインパターンの役割というわけです。 UIを通じて「ユーザーが行えること」を決定するのはオブジェクトのクラスであり、その性質（プロパティとメソッド）です。つまりユーザーが接するクラスの性質を定義することが OOUI デザインの中心的作業になります。 ということで、これまで繰り返し書いてきた方法論を、今一度まとめてみます。 オブジェクト指向でデザインされたインタラクションは、基本的に、オブジェクトファーストになるはずです。ユーザーに対して、まず関心の対象であるオブジェクトのうち、作業の主要な処理対象となるものが提示されることになります。そしてそれらが、空間に見立てたスクリーン上に、自律的な存在として自然にマッピングされているようにするのです。 スクリーン空間に配置されたオブジェクト達は、それぞれの見た目や振る舞いによって自身の性質を体現するので、ユーザーはそれを触って動かしてみることでシステムのポテンシャルを感じ取ることができるはずです。よくユーザビリティテストを観察するオーナーが「この画面の使い方をユーザーは分かってくれるかな？」という心配をしていますが、そのような心配があるうちはUIがどこかモーダルになっているのです。UIがモードレスで、オブジェクトが空間に自然にマッピングされていれば、ユーザーは自分の作業を通じてUIを学習し、電車式でなく自動車式に目的に近づきながら、理論でなく実験によって、徐々に自分なりの使い方を作り上げていきます。そこには決まった使い方というものは無いのです。後は、ユーザーの学習を阻害するような暗黙の制約や不明瞭な因果関係を排除していけばよいのです。 ひとつのシステムにおいて複数の主要クラスを扱う場合は、対象クラスを選択する機能が必要になります。クラス選択はタスク／業務選択と同義であることも多いですが、できれば選択肢のラベル／アイコンにはタスク名ではなくクラス名を用います。その方がモードレスなメンタルモデルを形成しやすいからです。このクラス選択が、ナビゲーションになります。クラス選択からインスタンス選択へ、インスタンスの属性概要から詳細へ、という抽象度のズーミングによるドリルダウンも有効でしょう。ナビゲーションには他にも、特定のツールやビューを呼び出すものがありますが、これらの振る舞いをリアルタイムに反映することで、モードを無くすことができます。それ以外のナビゲーションは全て課税的な操作になるので、できる限り排除します。 オブジェクトは常にユーザーがマウスクリックやタップで直接ポイントできるようにし、またオブジェクトは自身の状態をできる限りリアルタイムに反映するようにします。 スクリーン上で、あるオブジェクトに対する処理がひとつだけなら、シングルクリックでそれを実行できるようにするべきです。アクションが複数あるなら、対象オブジェクトの選択後にアクションを選択させます。インスタンスの一覧においては、複数のアクションを属性として見せ、それらをシングルクリックで実行できるようにしてもよいでしょう。主要なアクションをダブルクリックに割り当てて、その他のアクションはメニューやボタンとして提示するのもよくあるパターンです。ただしドラッグ＆ドロップのような直接的なジェスチャがユーザーの認知的負荷を軽減できる場合にはそれを積極的に採用し、動詞選択という手続きをインタラクションから取り除きます。 同じオブジェクト（群）が複数のビューを持っていてもよいですが、できるだけ同じ場所で切り替えられるようにして、ビューをタスク／モードに依存させない方がよいでしょう。そうすることで、ユーザーはオブジェクトを実体として認知するようになり、ユーザーイリュージョンが強力になります。 — ここに書いたような方法論を用いれば、創作系ではない業務システムのようなものでも、かなりの割合でモードレスにすることができると思います。ただしそれには、前にも書いたとおり、システムオーナー側がユーザーの仕事というものをもっとモードレスなものとして、進歩的な価値観をもって、再定義する必要があるでしょう。デザイナーの本当のチャレンジは、もしかするとそこにあるのかもしれません。 モードレス：オブジェクト指向 モーダル：タスク指向 モードレス：直接操作 モーダル：間接操作 モードレス：自動車式 モーダル：電車式 モードレス：実験的 モーダル：理論的