Author Archives: Manabu

ユーザー中心というスローガンが、時としてユーザーを神格化してしまうことに、僕は違和感を覚えます。道具は、ユーザーに合わせてデザインするのではなく、課せられたタスクあるいは処理対象のオブジェクトに合わせてデザインするべきだと考えるからです。それがうまくいけば、ユーザーが便利にその道具を使うのです。 よく、デザインとアートは違う、という話をする人がいます。デザインには目的があるけどアートには無いとか、デザインは理論的でアートは感性的だとかいう話です。一般的な語感としては間違っていないと思いますが、このように両者を区別することで、デザインとアートの本来の可能性を見誤る恐れがあると思います。 デザインとアートは、本来同じような価値観を指しているはずです。 辞書的な意味合いとしては、デザインとは、ある目的を達成するための計画もしくはその計画をモデル化したもの。アートとは、人が知識とスキルによって物事を体現／具現化したもの。つまりデザインとアートは「モデル」と「ノウハウ」の関係であって、我々は普段何かを作る時、思考過程でこの両者を区別しないでしょう。これらは表裏一体で、どちらか一方だけを行うことはできないはずです。（コンテンポラリーアートの世界では、モデルもノウハウも無くほとんど無作為に作られたような作品が多くあります。それらは偶然性の産物であって、アートという言葉の本来の意味からは正反対の存在だと思います。） ダビンチやミケランジェロは、アーティストでありアーキテクトでした。現代の感覚からすれば、彼等はひとりでいくつもの才能を持った多重人格者のように映るかもしれません。実現不可能と言われたサンピエトロ大聖堂の巨大ドームを設計した建築家と、システィーナで天井画の最高傑作を描いた芸術家が、同一人物であるということは、にわかには信じ難いことです。しかし当時は、建築と絵画や彫刻は切り離せないものであり、教会を中心とした社会システムの構築という目的への一元的なデザイン活動だったわけです。その意味で、彼等は単にデザイナーなのです。 その後建築や美術は、モチーフが持つメッセージよりも機能性や表現方法自体に意味を持たせるようになっていきました。しかし、印象派に代表される近代絵画の方法論に当時急速に発展した光学研究の成果が欠かせなかったように、もっと言えば、ニュートンがこの世界に遍在する絶対的な法則を探求する上で彼の宗教観がモチベーションになっていたように、バッハが分散和音を起譜する時に神の旋律を聞いていたように、我々は理論と感性を区別せずに物事を創作してきたはずです。というか、理論と感性が完全に同化したような創作物ほど、美しく見えるのです。 人はそのような創作活動の中で、時折ものすごいものを作り出します。例えば「車輪」がそのひとつでしょう。誰が作ったのか知りませんが、理論だけでも感性だけでも到底到達できないような完全性がそこにはあります。よく「車輪の再発明をするな」などと言いますが、あんなものは、発明しようと思って発明できるものではないのです。その完全性は、ほとんど神がかっています。プチ神の領域という感じです。 神格化すべきは、そのような完全性の高いデザインなのではないでしょうか。 前に書いたとおり、デザイナーは、「直進、左折、右折」という要求に対して、三つのボタンではなく、「ハンドル」を生み出さなければいけません。そのためには、積み上げ式のロジックを超越する飛躍が必要です。飛躍するためには、視点の相対化と、課題の本質を見極める洞察力が求められます。 別な言い方をすれば、発案者と設計者が別々である場合（つまり請負型の開発案件）、発注者によって要求事項が明文化された時点で、デザインは半分死んでしまうのです。特に発注者がモーダルな人だと、良いデザインは生まれにくくなります。「直進、左折、右折」という要求に対して「ハンドル」を提案しても、「真っ直ぐ進むためには手でずっとおさえてないといけないじゃないか。それでは要求を満たしていない。」といって却下されてしまうのです。受注者側がこれを論破するのはかなり困難です。発注者はデザインの完全性に対価を払うのではなく、リストされた要求事項ひとつひとつへの対処に対価を払うからです。 つまり本当は、ユーザーがそうであるのと同様に、発案者自身も、デザインに合わせて自らの要求を変化させる必要があるのです。でも普通そういうことは起こりません。だから極端に言えば、発案者と設計者（デザイナー）が異なる場合、良い製品は生まれないのです。世の中に存在するよく出来た製品は、たぶんほとんど、発案者自身がデザインしたものではないでしょうか（ひとりでなくても、極近しい組織内で）。発案者がデザインするというよりも、デザイナーが発案すると言った方が良いかもしれません。料理家が料理を発案するのと同じです。漫画家が漫画のストーリーを考えるのと同じです。例外もありますが、基本はそういうことでしょう。 デザイナーが発案した製品は、自分のデザインの可能性に最適化されています。また、デザインの過程において、実験的な検証を経て元のアイデアを修正しつつ、それでも全体の世界観に秩序を維持することができます。デザインの過程において、次の一手は、その時点のデザインの状態から逐次判断されるのです。 そう考えると、デザインという行為は基本的にモードレスなもので、それを行うデザイナーというのはモードレスな人間ということになります。モーダルな人（決められたことを正確に実行することに達成感を感じる人）はデザイナーには向きません。そしてデザイナーが発案して作った製品は、それが決められた要求への対処として作られていないという意味で、モードレスな道具だということです。 モードレスな人がモードレスな活動によってモードレスな道具を作る。それが良いデザインの背景にある構図ではないでしょうか。

道具のデザインの二大コンセプトである「モーダル」と「モードレス」。その「モードレス」の方について考えてみます。 モードレスなデザインはオブジェクト指向であり、その目的は、ユーザーを多様なゴールに導くための「プロセス自体を提供すること」です。ユーザーが行うべき意思決定は「各作業ステップにおける次の一手」です。次の一手をどうするかの判断は逐次的になされ、その判断基準は、処理対象のオブジェクトが「望む感じに近づいているかどうか」です。このイディオムは主に創作系のアプリケーションで採用されており、ユーザーがこれでよしと思った時点が作業の終了となります。 オブジェクト指向の道具は、タスク指向の道具と違って、ユーザーのタスクを特定しません。特定してしまうと、操作のイディオムがモーダルになってしまい、作業を実験的に進めることができなくなるからです。Photoshop で画像を作るのに、作業手順が決められていたら困ります。iTunes で音楽を聞くのに、ジャンルごとに別なウィンドウを開かなければならないのだと不便です。Amazon で商品を探すのに、トップページで「今日は買い物をしますか？ それとも冷やかしだけですか？」と質問されるのだと嫌です。そんなおかしなデザインにするわけがないと思うかもしれませんが、身の回りにあるタスク指向のデザインを見てください。例えば駅の券売機や ATM、そしてほとんどの業務アプリケーション。これらは皆、タスクを特定した結果として（それが必然だったとしても）、モーダルで不自由な操作性になっているはずです。 思うに、モーダルな道具が世の中に増え始めたのは最近のことではないでしょうか。つまりテクノロジーが発達することで道具の機構が複雑化し、利用価値の評価対象が「オートメーション」に移行したのです。オートメーションとは処理プロセスの自動化ですから、すなわちモードと同義です。 では、オートメーション以前の道具に求められていた価値とは何でしょうか。 例えば単純な道具、ハンマーを考えてみましょう。ハンマーは腕の延長として機能し、自身の質量や硬性、そして振り下ろす時の梃子の作用を利用して釘を打ち込みます。つまりユーザーの身体動作と道具の静的な性質が相乗して利便性を生み出しています。 釘をうまく打ち込めるかどうかは、ハンマー自体の性質にもよりますが、ユーザーのスキルにも多く依存いています。ユーザーはどうやってスキルを向上させるのかというと、知識やマニュアルの理解などではなく、単に何度もハンマーを使って、自分がどのような動きをすればそのハンマーのポテンシャルを引き出せるのかということを経験から体得するのです。別の見方をすれば、ハンマー側の性質として、ユーザーのスキルを素直に結果に反映する「操作と結果のシンプルな対応」が実現されていなければなりません。 ハンマーはモードレスな存在であり、コンテクストを限定しません。誰がいつ何の目的で使うのか、ということには無関心です。初心者の大工が使うのか、熟練の大工が使うのか、犬小屋を作るのに使うのか、高層ビルの建築に使うのか、基礎工事に使うのか、室内施工に使うのか、雨の日に使うのか、晴れの日に使うのか。それらはユーザーが決めることであり、基本的には、デザインの仕様に影響を与えません。 とは言っても、ハンマーには色々と種類があるでしょう。プロの大工は、コンテクストに応じてそれらを使い分けるかもしれません。ではハンマーの種類はどのような観点で区別されるのでしょうか。それは、打ち込む釘の性質であったり、叩く対象物の性質です。小さな釘を打つためのハンマー、大きな釘を打つためのハンマー、柔らかい物を打つためのハンマー、硬い物を打つためのハンマー、といった具合です。 前に包丁の話をしましたが、包丁も同じで、寿司屋のための包丁とかラーメン屋のための包丁というものがあるわけではなく、刺身を切るのに最適化された包丁、麺を切るのに最適化された包丁があるだけです。仕込みのための包丁とか、閉店間際に使う包丁というのは無いのです。 つまりモードレスな道具は、その道具が扱う対象物の性質に合わせてデザインされるべきだということです。考えてみれば単純な話で、タスク指向な道具がタスクを手掛かりにデザインされるのだから、オブジェクト指向な道具はオブジェクトを手掛かりにデザインされるのです。そして、そこで提供される機能性をコンテクストにマッチさせるのは、道具側ではなく、ユーザー側の責務なのです。 例えば Photoshop が扱う対象物は「デジタル画像」です。だから Photoshop は、デジタル画像というものが持つ性質を手掛かりにデザインされていて、それを処理するための効果的な機能を提供しているはずです。Photoshop が創り出すユーザーイリュージョンはかなり強力なので、ヘビーユーザーであるほど、自分の要求が Photoshop の性能に知らず知らず最適化され、そしてそのことに気づかないでしょう。しかしそれは悪いことではないのです。そもそも Photoshop のようなツール無しにデジタル画像を編集することはできないのですから、可能な範囲で最高の結果を得るためには、要求がツールの性能とマッチしている必要があるのです。 同様に、iTunes のデザインはデジタル音声という対象物に最適化されていますし、Amazon のデザインはオンラインの商品というものに最適化されています（ただしショッピングはタスクなので、ショッピングという行為を確実に行わせるために、EC サイトでは購入フローの部分をモーダルなウィザードで提供するのが普通です）。 扱う対象物を手掛かりにデザインする場合、そこにどの程度の機能性を持たせるかは、純粋に製造者の判断で決めることができます。任務として特定のゴールがあるわけではないので、ライトユーザー向けに単純な機能をだけを提供するのか、ヘビーユーザー向けに複雑な機能を提供するのか、製造者側が好きに決められるのです。ビジネスとしては当然、顧客が求める「価格と機能と使い勝手」のバランスによって仕様の落とし所が決められるでしょう。その意味で、モードレスな道具の仕様は、ボトムアップに定義されるものだと言えます。これはタスクというトップダウンの要件で仕様が決まるモーダルな道具と対象的です。 少しまとめてみましょう。 コンテクストは構造化できないのでデザインの手掛かりとしては曖昧過ぎる。 人という単位が道具のデザインに対して意味を持つわけではない。よってユーザー像を特定してもデザインの手掛かりにはあまりならない。 モーダルなシステムは課せられたタスクを手掛かりにデザインする。 モードレスなシステムは処理対象のオブジェクトを手掛かりにデザインする。 そしてモードレスなシステムは、ユーザーの行動と相乗することで利便性を生み出すのです。 アランケイは、マクルーハンの「メディア論」について次のように言っています。 彼が「メディアはメッセージである」という場合、メディアを利用するには自分自身がメディアにならなければならないということを意味している。これはかなり恐ろしいことである。人間は道具を作った動物ではあるが、道具の使い方を学ぶことが私たち自身を変える、という点に道具と人間の本質があることを意味している。 人の歴史は道具の歴史でもあります。人は道具を使うことで物事の捉え方やコミュニケーションの意味を変容させてきました。しかしそのことにあえて気づかされるには、道具がバーチャルなイリュージョンを創り出し、抽象概念を直接操作するという、現代のコンピュータメディアの登場が必要だったということでしょうか。 … Continue reading →

ウィキペディアの「Smalltalk」のページには、次のようにあります。 アラン・ケイが「オブジェクト指向」という言葉を創った当初は、Smalltalk システムが体現した「パーソナルコンピューティングに関わるすべてを『オブジェクト』とそれらの間で交わされる『メッセージ送信』によって表現すること」を意味していた。 これは非常に興味深い話だと思います。なぜなら現在一般に「オブジェクト指向」という言葉が使われる場合、それはプログラミングにおける設計／実装の手法のみを指しているからです。しかし本来アランケイの発想では、ネットワーク上のノードや、クライアントデバイス内の各種フレームワーク、そしてユーザーがインタラクトするUIのイディオムなど、コンピュータメディアを構成するアーキテクチャの全てについて、抽象的なものから具象的なものまでをシームレスに包含するコンセプトだったのではないかと思われるからです。もしそうならば、Alto という GUI 環境と Smalltalk というオブジェクト指向開発環境は、同じコンセプトの実現に向けて作られたものだと言えるでしょう。すなわち、OOUI のコンセプトです。（ただし Smalltalk は特定の GUI フレームワークに依存しないようですが） 実際、「人間のためのコンピュータ – インターフェースの発想と展開」に寄稿されたアランケイのエッセイ「ユーザーインターフェース 個人的見解」を読むと、次のように書いてあります。 Smalltalk のオブジェクト指向性は非常に示唆的であった。オブジェクト指向とは、オブジェクト自身が自分が何をできるのか知っているという意味である。抽象的なシンボルの場では、それは、最初にオブジェクト名を記述（するかあるいは持ってきたり）してそしてそれに何をするかを指示するメッセージを付ける。具体的なユーザーインターフェースの場では、それは最初にオブジェクトを選択することを意味している。それから何がしたいのかをメニューによって提示する。どちらの場合でも、オブジェクトが先であり、やりたいことがその次となっている。これは具体的なものと抽象的なものとを高い次元で統合している。 また、そのような環境で実現すべきコンピュータならではの魔法のような演出を、アランケイは「ユーザーイリュージョン」と呼んでいます。ユーザーイリュージョンはメタファーを高次元化したような概念で、例えばハイパーメディアのように、現実世界にある道具をメタファーとしつつも、現実世界には存在し得ない新しいメンタルモデルを、自然な形で与えることが望ましいとしています。他にも例えばデスクトップのフォルダについて、現実世界のメタファーに縛られたために排他的な存在になっているのはおかしいとして、「受け身的な容器ではなく、関連したアイコンをたえずとらえようとする、能動的な探索子」であると良いと言っており、最近の Mac では当たり前になっているスマートフォルダのアイデアなども披露しています。 GUI（OOUI）では、空間に見立てたスクリーン上に、操作対象であるオブジェクトがアイコンやウィンドウといった視覚表現で提示されます。各オブジェクトはそれぞれの属性情報や機能性を内包した静的な存在で、それ自体はコンテクストに依存せず、自発的に動き出すことはしません。つまりその存在は状況に対する必然ではありません。しかし各オブジェクトは、ひとたび外からのメッセージを受けると動きだし、自分自身の状態を変化させたり、他のオブジェクトに連鎖的にメッセージを送ったりします。 メッセージの起点となるのは基本的にユーザーからの入力イベントです。入力は、マウスなどの GID によってスクリーン空間上のオブジェクトに直接行われるので、即物的であり、ある操作が作業に及ぼす影響は、基本的にその操作の直後に起こるフィードバックによって完結します。各オブジェクトは、決められたストーリーを構成するために存在しているのではなく、ただ自分の役割を果たすためだけに存在しているのです。その様は、あたかも、自身の客観的性質に従いながらモードレスに存在する現実世界の物体のようです。 このような世界観自体が、アランケイの言うユーザーイリュージョンの一環であると言えます。そしてこのイリュージョンは、一定の処理フローを前提にプログラムを記述する手続き型／構造化言語では実現が困難でしょう。だから OOUI のパラダイムを実現するためには、オブジェクト指向言語が必要だったということではないでしょうか。 ところが後年になると、オブジェクト指向で作られたソフトウェアが持つ高い保守性や拡張性にばかり注目が集まり、単なるプログラミングの様式のように認識されるようになってしまったのだと思います。 一般的に OOA/OOD の過程では、システムの構造や働きをモデル化するのに、UML が用いられます。UML には複数のダイアグラムがあります。表したいシステムの側面に応じて使い分けるわけですが、別な言い方をすれば、あるシステムの性質はひとつの記法では抽象化できないということです。 UML はその名の通り、複数のモデリング手法を統合して標準化したものですが、その成り立ちにおいては、RUP に代表される、ビジネスアプリケーションの開発プロセスに対する親和性が強く意識されています。 ビジネスアプリケーションというのは、業務システムと言ってもよいですが、それがオフィスで使われるかどうかに関わらず、もしくはユーザーインターフェースを持っているかどうかに関わらず、ステークホルダーの特定の要求を特定のビジネスロジックによって満たすために作られます。だから当然、要求やロジックが特定できることを前提とした存在です。つまりタスク指向の道具というわけです。そのようなシステムを開発するプロセスでは、必然的に、上流工程において適切にタスクを分析することが重要になります。 … Continue reading →

ユーザーフレンドリーとかユーザー中心といったスローガンは、我々に、製品はユーザーに合わせてデザインされるべきであるという価値観を強要しています。 もちろん出来上がった製品がユーザーにとって役立たなければ意味がないのですが、デザインの過程においてユーザーというものをどのように捉えるべきかということについては、再考の余地があると思います。 ひとりのユーザーの要求でもその分解には際限がないのと同様に、ユーザーグループを定義するというのも相当に困難です。 確かにユーザー間にはなんらかの共通属性があるかもしれませんが、コンテクストというものがゲシュタルトである以上、採用されたセグメンテーションの基準は常に設計者にとって都合のよいものにしかなりません。これは、製品のコンセプトをプロジェクト内で共有したり、マーケティングなどで特定の観点から統計を取得するためには役立つかもしれませんが、デザインという厳密な仕様を決める上では明確な手がかりになりません。だから普通は、セグメント毎の要求リストを好き勝手に作り、それに矛盾しない範囲で、誰かがえいやっと仕様を決めることになります。 人はそれぞれ皆違った状況下にあり、またその状況は変化し続けるので、ユーザーサイドの総合的な要求、つまりコンテクストを手がかりに仕様を決めようとすると、ターゲットユーザーの数に比例して仕様が膨らんでいきます。要件リストが長大であれば、システムにまとまりのある世界観を与えられなくなり、デザインは破綻します。しかしユーザーを限定し過ぎれば、汎用性が低下し、多くの場合、製造者の資本集約的なビジネスモデルが成り立たなくなります。 また、なんとかあるユーザーのコンテクストにぴったり合うデザインができたとしても、その分、他のユーザーのコンテクストには合わなくなっているかもしれません。出来上がったシステムについて言えば、仕様は常に厳密であるため、全てのユーザーのコンテクストにマッチするものを作るのはたぶん不可能です。 何が言いたいのかというと、使う人と作る人が分離している場合、ユーザーのコンテクストに合わせてデザインをするという発想は、そもそも無理があるということです。 うまく要件を定義するための取り組みとして、ペルソナを作るのが良いと言われることがあります。これは、ターゲットセグメントにおける個別要件の集積として要求事項を整理するのではなく、仮想の人物像を作ることで実際的なまとまりをもつ要求セットを導き出そうとするものです。そうすれば、コンフリクトを含んだ長大な要求リストではなく、ひとりのコンテクストに無理なくマッチしたシステム像が描けるだろうということです。 確かにこれならば、無秩序な要求の取り込みによって「誰にとっても使いにくい」ものが出来上がってしまうという状況は避けることができそうです。けれど、ユーザーのコンテクストから要求事項を抽出するという意味では、依然として不確定性の問題がありますし、そもそも仮想のキャラクターからリアリティのある要求事項を得られるのかという疑問があります。誰かがそれを代弁するなら、それはその人の「意見」になってしまいますし、何かの統計から「そのセグメントに一般的な要求」を持ってくるのなら、わざわざキャラクターを作る意味がありません。ペルソナのもとになった特定人物がいるのであれば、その人を直接観察なりインタビューなりするべきでしょう。 ペルソナのポイントはキャラクターのリアリティにあるのだと思いますが、キャラクターにリアリティを与えるのはそのキャラクター固有の状況です。けれどその固有の状況を強調すると、セグメントの代表者としての性質がぼやけます。セグメントの代表者でないのなら、そのペルソナの妥当性を説明できません。 ペルソナにしてしまった時点で、そのキャラクターは活動を止めてしまいます。ある人の服をオーダーメードするのに、その人を採寸するのではなく、その人の写真を見て採寸するようなものです。それなら、デザインの手掛かりとしてはターゲットユーザーの属性リストと変わりません。 ペルソナが有効であるとするならば、それは仮想敵国ならぬ仮想ユーザーとして、開発者のモチベーションを高めるプロパガンダになるからでしょう。少なくとも我々の仕事相手は、IDE のエディタ画面ではなく血の通った人間である、というイメージを共有することで、インタラクションデザインの重要性をプロジェクト内で確認するのです。 考えてみれば、なぜユーザーに合わせてデザインしなければならないのでしょうか。ユーザー毎に最適なデザインが異なるとするなら、その考えを突き詰めると、ユーザーの数だけ別々のデザインが必要であるということになります。ペルソナは何人作ればよいのかという質問に対して、「理想はユーザーの数だけです」と答えなくてはなりません。でもそれだとあまりに面倒だし、要件定義として風呂敷をたたむどころか、広げる一方になってしまい、収拾がつきません。道具には、本当にユーザーの数だけデザインが必要なのでしょうか？ ユーザーは人です。人というのは、自分自身では一貫した存在であると思っているかもしれませんが、客観的に見ると、非論理的で、支離滅裂で、気まぐれで、定義しにくい存在です。人という単位で要求をまとめても、仕様に落とし込めるほどの体系を見出すことは難しいでしょう。 道具を使うのは人ですが、その道具がある人の全生活をサポートするのでない限り、人という単位が道具のデザインに対して意味を持つわけではないのです。これは前に書いた、柱に対する行為（寄り掛かったり身長を記録したり）が柱の性質を決定するわけではないというのと同じです。むしろ逆で、柱の性質がそれに対する人の行為を決定するのです。 ユーザーのコンテクストが定義不可能なら、それをもとに要件を定義しようとするプロジェクトは全て失敗します。では、世の中にあるデザインが全て失敗なのかというと、そうでもありません。気に入って使っている道具はいくつもあるでしょう。そのような道具は、自分のニーズに合っていて、思い通りに目的を達成できます。これらを作ったデザイナーは、どうやって僕のコンテクストを定義したのでしょうか。 もう分かると思いますが、そのような道具を作ったデザイナーは、僕のコンテクストなど考えていません。僕自身がその道具に合わせて行動を変えたのです。はじめはうまく使えなかった物に、次第に慣れて、使いこなせるようになったのです。もし、使いこなせるようになるまでに習得しなければならない事柄が多すぎたり、デザインに一貫性が無くて学習不能であったり、そもそも自分の用途に合っていないようなものは、僕にとって役立たない道具ということになります。シンプルで一貫性があり、操作と結果の対応が自明であれば、短期間で使いこなせるようになります。そのような道具は、自分なりの工夫が効くので、多少期待と違う性能だったとしても、我々は自らの要求を変更して、その道具を使うことで得られる利便性を最大化することができます。そうすることで、当初イメージしていた成功体験を超えるような満足が得られるかもしれないのです。 つまるところ、ユーザビリティというのは、ある道具が定数的に持っている属性ではなく、その道具を使う者が、利用体験を通じて感じる認知上の変数なのです。 ということで、ペルソナの理想的な数はいくつか。その答えはゼロだと思います。デザインは、人という単位に対して行うべきではないからです。人という単位に着目してしまうと、デザインの落とし所が見つからなくなってしまいます。 では、我々は、いったい何を手掛かりにデザインをすればよいのでしょうか？

デザインには常に目的があります。というか、あるモノやコトの目的を外在化するための、外界とのインターフェースとなるのがデザインです。機能のデザインはもとより、装飾のデザインにも目的があり、そのモノの性格やメッセージを表現しています。だからデザインの作品というものは無くて、人は作品をデザインするのです。 目的を持ったモノやコトは、それに対峙する何かとの直接的あるいは間接的なインタラクトを期待されているはずです。その意味で、意図的に作られたモノやコトはすべてある種の道具であると言えるでしょう。それに対峙するのが人間である場合、その人はユーザーと呼ばれます。 道具というのは基本的にテクノロジーの産物であって、たとえ耳かきのような単純なものであっても、その形状や材質には何らかの工夫があり、その存在価値である利便性を創出しています。だからテクノロジーが優れているほど、高い利便性を提供できます。利便性を高めることができるテクノロジーほど優れているとも言えます。 道具に高度なテクノロジーが要求されると、それを作るのは専門家の仕事となります。職人とかデザイナーとかエンジニアと呼ばれる人がそれです。彼等は専門的なテクニックを用いて道具を作ることを生業とします。この段階で、道具を使う人と作る人が分離するわけです。 作る人は、その道具の利用価値を高めるために、使う人のニーズをさぐります。使う人の用途や好みにぴったりのものができれば、自分の仕事が高く評価されるからです。 19世紀初頭に家具職人であったミヒャエルトーネットは、画期的な曲木技術を発明し、また効率的な製造方法を確立したことで、その後発売した No.14（214）という椅子を大ヒットさせました。これがマスプロダクションの始まりと言われています。それまで家具というのは高度な工法を要する量産困難なもので、基本的に手作りの受注生産でした。それが、産業革命による工業化と独自の加工技術によって大量生産できるようになり、高品質の製品を安価に提供できるようになったというわけです。 それ以前にもちょっとした小物であればそれなりの量産ができたのでしょうが、家具のような複雑な道具についてまで大量生産されるようになったことで、道具のデザインは、個別のクライアントのニーズに対してではなく、不特定多数の「ユーザー層」のニーズに対して最適化される必要がでてきました。 ユーザーが限られていれば、道具の合目的性を高めるのは比較的簡単です。しかしユーザーが多くなれば難しくなっていきます。オーダーメイドであれば発注者の希望を細かく反映することができますが、不特定多数がターゲットである場合、人によって利用のコンテクストが異なるため、仕様について割り切らなければならない度合いが増します。つまり言ってみれば、デザインというのは、合目的性と汎用性のバランスのことなのです。どちらに寄せていくかは、製品の性質によって自然に決まります。 もし合目的性のみを最大化するなら、ユーザーを限定して、徹底的に要求を分析し、いつ何をどのようにしたいのかということを厳密に定義すればよいのです。そうすると、例えばあるひとつの業務を完全に定義し、それに特化した画面を作ったら、そこには、ボタンがひとつだけ見えているということになるでしょう。「業務実行」というボタンです。要求事項が完全に特定されているならすべての処理を自動化して内部に隠匿できるからです。ユーザーの操作はそのボタンを押すだけです。いや、それすら必要ないかもしれません。ジェフラスキンは、「ある状況でユーザーに許された操作がひとつだけであれば、その操作は省略できる。」と言っていますから、ボタンがひとつだけしかないのなら、それは無くすことができます。つまり、そのユーザーがシステムにログインした瞬間に処理が実行されればよいのです。もっと言えば、朝出社してタイムカードを押した瞬間でよいのです。というか、そうなったらもうその業務は存在しないのと一緒ですね。 このような極端なことに普通ならないのは、要件定義の段階において、ユーザーのコンテクストというものを完全には定義できないからです。人の活動には必ず恣意的な側面があり、あるいは、仕様化できない創造性が期待されているのです。コンテクストというのは、個々の要求事項から帰納的に構造化できるものではないのです。コンテクストの全体像を特定できないとすれば、要求分析の限界点を事前に予測することもできないということです。 要求の特定が必ずしもユーザビリティの向上に直結しないというのは、次のように考えると分かります。 あるシステムに対して1000通りの要求があったとします。それらひとつひとつを厳密に定義できたなら、それぞれの要求に対応した1000個のボタンを画面に並べればよいということになります。そうすればユーザーは何をするにもボタンを一回押せば済むので、合目的性と操作効率は最大になります。しかし実際には、そんなシステムは誰も使えないのです。それはデザインとは言えません。 1000通りの要求というのを、もっと汎化できるのではないかと思うかもしれません。しかしコンテクストは無際限に細分化できるので、どこまで分析しても最小粒度に行き着かないのです。最小粒度が曖昧であれば、構造化は不可能です。1000通りの要求を特定できたと思っても、その粒がユーザーの目的に照らして十分に細かいのかということを、短時間で評価する方法はないのです。なぜならユーザー自身ですら、自分のコンテクストの変化を正確には予測できないからです。 このように、ユーザーのコンテクストを分解することでシステムの要件を定義しようとする試みは、簡単に壁に突き当たってしまうのです。

我々は、道具の操作性について議論をする時、ユーザビリティという概念を用います。ユーザビリティという概念は、定量的な計測対象として厳密に定義されることもありますし、もっと感覚的な評価も含めて広く定義されることもあります。ただし教科書的な文脈においては、ISO 9241-11 の定義がよく引用されます。 定義の原文はこうです。 ISO 9241-11 のユーザビリティ定義： Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. また、ISO 9241-11 をもとにした JIS Z 8522 というものがあり、上の定義を和訳したものとして次の一文があります。 … Continue reading →

僕はゲーマーではありませんが、FPS は結構好きで、特に「Marathon」シリーズと「Call of Duty」シリーズにはかなりハマって、それぞれ数年間やり込みました。もちろんネットワーク対戦です。その反面、RPG やシミュレーションもの、シューティングでも第三者視点のものにはあまり面白さを感じませんでした。僕はガンダムに乗りたいのであって、ガンダムの背中を眺めたいのではないのです。 僕が FPS を好きなのは、それがモードレスでありリアルタイムだからです。スクリーンに映る世界は僕の視界そのものであり、僕がとったほんの小さな動きも、相手を含むその世界全体に何らかの影響を及ぼします。僕は、スコープの向こうでこちらに照準を合わせる敵と、というかその敵を操作する誰かと、目が合うのを感じることができます。不意に敵に遭遇した時、引き金を引くか逃げるかの判断は瞬間的になされなければいけません。敵は待ってくれませんし、僕も待ちません。ステージ上の全員が同じ時間と空間を共有しているのです。 もうひとつのポイントは、バーチャルな世界にいる自分のアバターのスキルは、そのまま僕自身のスキルだということです。何か特定の手続きを踏むことで勝手に能力が上がったりはしません。僕の射った弾が当たるかどうかは、純粋に僕の状況判断とマウス操作のスキルにかかっているのです。だからそのアバターは、感覚的には、僕の分身ではなく僕自身です。視覚と聴覚に限定されているとはいえ、僕の意識はほぼ100パーセント没入し、その世界と直接インタラクトしているのです。そうでないとやられてしまうし。 FPS では、戦況を読んで戦術を考えることはあっても、操作を計画することはありません。状況は無限にあり、操作を手続き的に計画することに意味がないからです。今何をするかは、その場その場の状況から逐次判断しなければならないのです。 なんだかこれと同じようなことを前にグラフィックソフトの話で書きましたね。まあそういうことです。 さて、ここに、ヨーロッパの包丁と日本の包丁を比較した興味深い記事があります。両者の比較から日本人の美意識を定義するのは少し乱暴な気がしますが、デザインというものが目指す大きなふたつの方向性を示唆しているのは確かでしょう。以下は引用。 一つはドイツのヘンケル製。人間工学的によく出来ていて大変使いやすい。これが西洋流のシンプル。握ると自然に親指の位置も決まる。しかし、超絶技術を持つ日本料理の板前はグリップに凹凸のない包丁を使う。平板な把手は貧しさや未成熟ではない。むしろその逆である。どこを持ってもよいという完全なプレーンさが、板前のあらゆる技術を受け入れる豊かさになる。 この日本の包丁のプレーンさが、僕には強烈にかっこよく感じられるのです。 T字型カミソリの宣伝では、首振り3枚刃でどんな顔にもフィットしてよく剃れるとか何とか言っていますが、プロの理髪師はそんなもの使わないのです。固定の一枚刃です。というか、T字型安全カミソリではなく、フリップ式で刃が剥き出しの危険カミソリを使いますね。T字型にしても剥き出し型にしても、勝手に刃の角度が変わってしまったら、力の加減ができないから思い通りに剃れないのです。最高の結果を出すカミソリは、切れ味だけを提供し、力や角度の調節については人が提供する余地を残しておくべきなのです。 このような道具は、ユーザーに相応のスキルを要求します。だからもしユーザーがそれをうまく使えずに目的を達成できないとしても、それは道具のせいでもユーザーのせいでもないのです。 前にオブジェクト指向のところでこう書きました。「僕が特に重要だと考えたのは、文脈をユーザーに解放するということでした。システムは自身の機能を体現するだけで、使い方をユーザーに指示するべきではないと思いました。ある道具が役に立たないとすれば、それはその道具が状況に適していないだけで、ユーザーの使い方が悪いのではないはずです。物それ自身がありのままの状態で状況とのマッチングを待っている、というのが、僕の解釈したオブジェクト指向の世界でした。」 これはそのまま、板前の和包丁の価値感に通じています。 たしかブラックジャックの本間先生がこんなことを言っていました。「人間が生き物の生き死にを自由にしようなんておこがましいとは思わんかね。」あるいは、どこかのお百姓さんの言葉、「わしらは水とちょっとの肥料をやってるに過ぎん。育つ力は種自体の中にあるんじゃ。」というのを思い出します。 デザインが人の仕事を決めるのではなく、人が自分の仕事に合うデザインを選ぶのです。そこで選ばれるためにデザインは、道具自体をモーダルなコンテクストから解放する必要があるのです。 以下は僕が一番気に入っているジェフラスキンの言葉です。 作業に対するニーズというものがユーザーごとに異なっているとしても、ユーザー集団は多くの一般的な心理属性を共有しているのです。つまりインターフェースデザイナーは、アプリケーションの調査や個人差を埋める作業を始める前に、全人類が共通して持っているインターフェースデザインに対する要求を活用して、自らの作業量を低減させることができるのです。

Apple が実践する「モードレス＆リアルタイム」のインタラクションデザインは、作業の中から課税的な手続きを減らして、現実世界で我々が直接的に物に接するのと同じような感覚でソフトウェアを扱えるようにするための、よい方法だと思います。アプリケーションウィンドウには「保存」という手続きが無く、ユーザーは、動的にファセット分類されたデータオブジェクトを、大工がハンマーで釘を打ち込むように直接操作することができるのです。 ただしこの動的なグルーピングは、これまでの GUI の肝であった「空間的な一意性」と両立できないため、大きなトレードオフとなっています。そこで Apple は、Finder における「スマートフォルダ」、iTunes における「（スマート）プレイリスト」、iPhoto における「イベント」や「人々」などのように、タスクをオブジェクトのように見せることで、GUI 要素についての再定義を行おうとしているように見えます。 そうは言っても、コンピュータからモードを完全に取り去るのはほとんど不可能だと思います。それはコンピュータの特徴である多態性と矛盾するからです。デジタルデータやそれを処理するプログラムが概念的なロジックの産物である以上、そこには非連続的に定義された「用途」が存在し、それはタスクとなってユーザーを教育し、「意味のある操作」と「意味のない操作」をはっきりと区別します。ボタンも何もない所をクリックしても、システムにとってそれは意味のない操作なので、対象オブジェクトへは何の影響も与えません。つまりコンピュータプログラムは、必要な処理だけを実行するのです。プログラムに書かれていないことは起こらないのです。 コンピュータが持つこの従順性は、ユーザーの行動をコントロールしたいという管理者の欲求を満たすためには都合がいいのですが、その反面、自然界で経験するような、複雑な因果関係の中で偶然（と感じられながら）生まれる創作結果、言ってみれば人と道具が無限の可能性の中から限定的な根拠に基づいて作り出すコピー不可能な質をクリエイトするには向かないものだと言えるでしょう。 そうだとしても、操作のイディオムが「自動車」式であり、入力した内容がリアルタイムに反映され、そのフィードバックが即座に示され、そして各オブジェクトがコンテクストに対して自律的であれば、コンピュータでの作業にも奥行きを持たせることができるだろうと思います。別な言い方をすれば、ソフトウェアにも味わいを持たせることができるということです。 道具の味わいというのは、それを使った結果に良い意外性があるとか、使い慣れる程に思い通りの成果をあげられるようになるといった状況で感じるものです。はじめは分からなかったデザイン上の工夫に後から気付いたり、不合理だと思っていた部品に合理性を見出すなど、使い手側がある程度の経験を積むことで道具の特徴を理解し、あるいは目的に対して不足している点を補えるようになることで、人と道具が互いにポテンシャルを高めるような状況です。こういう状況になると、人はその道具を手放すことができなくなります。それはもう自分の能力の一部になってしまうからです。 もう少し単純に言えば、自分なりの応用がきくかどうかということです。応用がきくということは、道具に柔軟性があるということと同時に、使う側も道具に合わせて使い方を変えることができるということでもあります。だから人間の気まぐれに対して道具が一貫した性能を出せるかということが問題なのです。これは、道具が常に同じ結果を出すという意味ではありません。むしろ逆で、結果がユーザーのスキルと一貫した対応を示すということです。下手に使えば下手な結果になり、上手く使えば上手い結果をもたらすということです。スキルとは、一定の手続きを正確になぞることではなく、自分で良いやり方を考え実践できるということです。そのようなスキルに応じる道具、打てば響くような道具というのは、シンプルで無駄が無く、操作と結果の対応が自明であるようなコンポーネントの組み合わせで構成されている必要があります。 Apple の1987年版「Human Interface Guidelines: The Apple Desktop Interface」には、巻頭の「Philosophy」の章に、次のような一節があります。前にも少し要約した部分ですが、改めて引用してみます。 ———— A view of the user （前略）このように人と仕事との関係に注目し、目的に合ったインターフェースを生み出すため、Apple Desktop Interface は、その対象となる人々のモデルを想定してきました。しかし、実際には人間の活動は複雑で変化に富み、人とコンピュータとの関係を完全に体系化できるような理論を構築するには至っていません。このような理論は極端に単純な形に置き換えて考えることができます。これは、人間の思考や行動様式はコンピュータ側からも影響を受けるからです。この意味で、コンピュータの設計と人間の活動は互いに影響し合いながら発展するものだと考える必要があります。Apple 社は、人間の行動の詳細の多くが理解されていなくとも、人間が示す反応に着目することが、わかりやすく効率的なコンピュータ環境の設計に役立つと考えています。 Apple Desktop Interface は、人間が生まれながらに好奇心を持った存在であるということを前提としています。好奇心は学習への欲求と言い換えることができますが、学習効果は自分の置かれている環境に自発的な探究心を持って接した場合に最も高くなると言えます。人間は自分を取り巻く環境をコントロールしたいという欲求を持っています。これには、自分の行為に対して掌握感を持とうとすること、そして、その結果を確認し、理解しようとする欲求が含まれます。また、意思の疎通には、言語をはじめ視覚や身振りによる伝達手段が用いられているように、人間は記号や抽象表現に慣れ親しんでいます。そして、条件が揃えば創造的で芸術的な存在ともなり得ます。作業や生活の場を楽しむことができ、やりがいに満ちたものであれば、生産性や効率は非常に高くなります。 ———— … Continue reading →

CRUD における Create、つまり新規作成の操作をテンプレート方式で行うことについて、Keynote などに見られるような、アプリケーション起動後にテンプレート選択を促されるインタラクションは成功していないと書きましたが、これは、「アプリケーション起動」と「テンプレート選択」が「動詞 → 目的語」のモーダルなシンタックスに感じられるからです。もしテンプレートがファイルとしてあらかじめデスクトップに見えていて、そこからすぐに新規作成ができ、編集内容が自動保存されるようになっているなら、逆に「目的語 → 動詞」のシンタックスになるでしょう。 ちなみに Keynote では、テンプレート方式という点でひとつ興味深いインタラクションが提案されています。PowerPoint や Illustrator などのベクターグラフィック編集ソフトでは、たいてい図形描画ツールというのがあって、例えば矩形描画ツールを選ぶとポインターが十字になり、キャンバス上でドラッグすると、その始点と終点を対角線とする矩形オブジェクトが生成されます。しかし Keynote では違う方法で矩形オブジェクトを作ります。まず図形メニューから矩形のアイコンを選びます。するとすぐにキャンバスの中央にデフォルトのスタイルを持つ矩形オブジェクトが生成されます。ユーザーはその矩形に対して大きさや塗りなどのスタイルを指定していくことになります。 PowerPoint と Keynote の違いは、PowerPoint がまず描画モードの選択から入るのに対して、Keynote ではテンプレートとしてのオブジェクト選択から入ることです。Keynote における矩形オブジェクト生成はモードレスなのです。これは小さな違いのように見えますが、Apple のインタラクションデザインの方法論が色濃く反映された特徴的な振る舞いだと思います。 その方法論とは、「モードレス＆リアルタイム」です。 昨今の Apple のソフトウェアでは、「モードレス」と「リアルタイム」ということがはっきりと意識されています。例えば、システム環境設定をはじめ、ユーザー設定系のダイアログには、ほとんど「キャンセル／OK」のサブミットボタンがありません。ダイアログボックスの体裁はとっていても、それらはモードレスダイアログであり、各入力項目は基本的に入力したそばから反映されます。ボタンを押して入力内容を確定させるという課税タスク的な手続きは不要になっています。Windows ユーザーが Mac にスイッチした場合、慣れるまでは OK ボタンを探して混乱してしまうかもしれません。しかし慣れると、これはとても自然な操作性であるように感じられるはずです。 現実世界にはモードは無い、と前に書きましたが、例えば目の前の紙に文字を書く時、書いた内容を確定するなどという手続きは不要であり、書いた瞬間からそこに書かれているのです。 このように、リアルタイムに入力が反映されると、ちょっとした入力ミスに対する修正タイミングや、入力内容に対する心理的な確認ステップが欠落しているように感じられるかもしれません。しかし多段階アンドゥが可能であれば、入力ミスを恐れずに、操作に対するシステムの状態変化を逐次的に確認できるので、むしろ心理的な負荷はずっと低いはずです。 それから、モードレスなイディオムが反映された特徴的なコントロールとして、「Done（完了）」ボタンがあります。最近の Apple のソフトウェアでは、この「Done」ボタンを頻繁に目にします。これは一時的に表示されるペインの中などに表示され、これを押すとペインが閉じたり元の画面に戻ったりするという意味でサブミットボタンのように見えます。しかし従来の「OK」ボタンとは違います。「OK」ボタンはそれが押された時に入力内容をシステムにサブミットしますが、「Done」ボタンは単にペインを閉じるという意味しか持ちません。つまり入力内容はすでにリアルタイムに反映されているのです。だから「Done」ボタンの隣に「キャンセル」ボタンはありません。入力した（反映された）内容を無効にしたい場合は、必要な回数だけアンドゥを行えばよいのです。 例えば iPhoto … Continue reading →

GUI においてモードを表す最も基本的なコントロールがウィンドウです。このウィンドウというものを、Apple がどのように定義付けているのか、ガイドラインを見てみます。 まずウィンドウというものは、アプリケーションやデータを見たり、それらとインタラクトするためのフレームであると言っています。そしてウィンドウには次の四種類があると言います。 ドキュメントウィンドウ アプリケーションウィンドウ パネル ダイアログ＆アラート ドキュメントウィンドウはファイルと対応していて、そのファイルの内容を表示します。ワープロソフトなどで用いられるものです。 アプリケーションウィンドウはアプリケーションと対応していて、そのアプリケーションで行う作業に必要なオブジェクトをひとつのウィンドウの中にまとめて表示します。Windows における MDI とは違い、複数のペインをタイル状に配置した表現になります。iTunes などがこのタイプです。アプリケーションウィンドウは、インスタンスとして、同時に複数開くことができます。 パネルはいわゆるフローティングパレットで、補助的なコントロールをモードレスに提示するのに用いられます。Keynote のインスペクタなどがこれに当たります。パネルも、インスタンスとして複数開けるようになっている場合があります。 ダイアログ＆アラートはユーザーからのレスポンスを要求するためのもので、いわゆるモーダルダイアログです。 ここで注目したいのが、アプリケーションウィンドウです。最近の Mac および Mac 用アプリケーションでは、このタイプのウィンドウが増えています。前回書いたとおり、Finder も、かつてはフォルダと対応したドキュメントウィンドウだったのが、Mac OS X になってアプリケーションウィンドウになりました。システム環境設定もこのタイプですし、iTunes、iPhoto、Mail、iCal、iMovie ’09、アドレスブックなどもこれです。 アプリケーション選択とは、すなわち作業対象のクラスを選択することであると前に書きました。アプリケーションウィンドウはこの考え方をビジュアルに体現していて、特定クラスのデータ集合を管理するダッシュボードとなっています。 アプリケーションウィンドウの中では、デスクトップメタファが提供してきた空間概念がありません。データはファイルとしてパッケージングされた存在ではなく、抽象的なオブジェクトとして表現されます。実際には iTunes で扱う音楽データも iPhoto で扱う画像データも個々のファイルとしてどこかのディレクトリ階層の中に保存されているのですが、アプリケーションウィンドウの中では、各オブジェクトが持つファセット属性によって動的にグルーピングされて見えています。 扱う対象のデータが増えると、デスクトップメタファにおける空間的な、排他的なフォルダ階層では管理が難しくなります。この問題に対する積極的な解決策として、ファセット分類をベースとしたダイナミックな一覧表現を全面的に採用しているわけです。 動的なグルーピングでは、ひとつのオブジェクトが同時に複数のビューに見えていてもメンタルモデルとして破綻しません。同じ曲が複数のプレイリストに入っていてもおかしくないのです。プレイリストやスマートフォルダは「保存された条件で検索する」というタスクを意味しているわけですが、これらをファイルやフォルダといった従来のオブジェクト表現で提示することで、モードをオブジェクトのように感じさせることができます。また、アプリケーションウィンドウはインスタンスとして複数存在できるので、アプリケーションというモード自体もオブジェクトのように扱うことができるわけです。 ところで、前に、一般的なアプリケーションでは「開く…」というメニュー項目において「動詞 → 目的語」のシンタックスが入り込んでいるということを書きました。とは言っても、ファイルを開くための操作としては、対象のファイルアイコンをまず選択してから「開く」コマンドを実行するとか、ダブルクリックするとか、アプリケーションアイコンにドロップするといった「目的語 → 動詞」の方法もあるので、大した問題にはなりません。 … Continue reading →