Monthly Archives: December 2009

スクリーンを空間として扱い、そこにユーザーの関心の対象であるオブジェクトを示し、ユーザーがそれに直接触れながら好きな方法で目的を達成できるようにする。それが OOUI のコンセプトです。 スクリーン上に見えているのは、全て（タスクとの対比としての）オブジェクトであることが望ましいのです。メニューやボタンは、「目的語 → 動詞」のシンタックスにおける「動詞」選択のコントロールなので、できればこれらの関節的なコマンド指示は用いずに、オブジェクトに対するジェスチャに同化させた形で「動詞」を指定できるようにすることが望ましいのです。そのイディオムが自然なものであれば（アイコンをドラッグして移動したり、ウィンドウをクリックして作業対象のクラスを切り替えたりなど）、手順を事前に計画するという認知的負荷を軽減することができます。 スクリーンにオブジェクトを示し、ユーザーがそれを扱えるようにするということは、つまり、システムの利用にユーザーが主体的に関与できるようにし、コンテクストをユーザーに解放するということです。システムの提供者は、オブジェクトの性質に合わせてその存在を素のまま見せることが望ましいのです。というか、そういうオブジェクトの性質を決定するのが提供者もしくはインタラクションデザイナーの役割でしょう。 ということで、そろそろウェブの話をしなければいけません。 ウェブには大きく「能動型」と「受動型」があると思います。能動型とは、そのウェブをユーザーが能動的に操作して何らかの知的生産活動を行うもの。つまりアプリケーションとしてのウェブ。受動型とは、運営者が提供するコンテンツをユーザーが受動的に閲覧するもの。つまりメディアとしてのウェブです。両者の境界は必ずしもはっきりしていなくて、アプリケーションにはデータオブジェクトとしてのコンテンツが格納されていることが多いですし、メディアの操作にはアプリケーションとしてのユーザーインターフェースが必要です。 しかし一般的に、能動型と受動型では設計視点が異っています。能動型がコンテクストをユーザーに委ねるのに対し、受動型は、提供者がそれを管理し、主導しようとするのです。その意味で、両者はモードレスとモーダルの関係にあります。そして両者の思想的な隔たりは、年々大きくなっているように感じます。 いわゆるコーポレートサイトは、受動型ウェブの代表です。コーポレートサイトの目的は企業の広報／宣伝を行うことであり、企業のコンテクストを主張するものです。例えば商品の魅力を伝えようと、刺激的かつ一方的な表現でコンテンツを編集します。単純に言えば、オンラインの広告です。 コーポレートサイトにアクセスするユーザーの目的は、その企業の情報や商品／サービスの情報を知ることです。ただし、誰でも経験があると思いますが、複数の企業（メーカー）にまたがって同一ジャンルの商品を比較しようとした場合、コーポレートサイトはほとんど役に立ちません。宣伝文句は客観性に欠け、良いことしか書いておらず、他社製品との直接的な価格／スペック／評判の比較はほとんど提供されていないからです。またコンテンツのフォーマットもサイトごとに違うので、自力で情報を集めて比較するのはかなり困難です。つまりコーポレートサイトは、「購買の意思決定支援ツール」としては機能しないのです。 だから我々は通常、ECサイトや価格比較サイトや口コミの評判が掲載されているようなサイトなどをみて意思決定を行います。これらのサイトは、意思決定支援ツールとして、もしくは商品購入ツールとして役立ちます。 コーポレートサイトの中にも、もちろん、問い合わせや資料請求などの機能があります。しかし多くの場合、これらは付加的なものであり、サイト自体をユーザーにとってのツールとして設計している企業はあまり多くありません。例えばもしメーカーが自社サイトを「ユーザーにとってのツール」にしようとするなら、競合同士でコンテンツのフォーマットを統一し、オンライン販売のインターフェースを一元化するなど、ユーザーがそのジャンルの商品を「買いやすくする」必要があるでしょう。現在のインターネットでは、それぐらいの変革が起きても不思議はないと思うのですが、どうもその気配はありません。 僕はこのようなコーポレートサイトの在り方に疑問を感じ、自分の会社のウェブサイトを作った際にちょっとしたチャレンジをしてみました。コーポレートサイトを少しモードレスにする試みです。 自社サイトをモードレスにするために、まず最初に掲げたコンセプトは、「潜在顧客層が我々の会社を利用するためのユーザーインターフェースとする」というものでした。サーバーには自社が提供するサービスに関連する情報が格納されていて、サイトはその情報を検索するツールであるという考え方です。 検索ツールとして表現するためには、検索対象となるデータオブジェクトの単位を決める必要があります。そこで、コンテンツになりうる情報を分析し、エンティティとしてのクラス定義を行いました。例えば「サービス」というクラス、「ニュース」というクラス、「UIデザインパターン」というクラス、「書籍」というクラス、などです。 トップページには代表的なクラスの一覧がアイコンで見えていて、そのうちのひとつをクリックすると、インスタンスの一覧が表示されます。これがデータオブジェクトの単位です。そしてひとつのインスタンスを選ぶと、その内容が表示されます。 トップページを除いて、サイト全体が「一覧」と「詳細」というたったふたつのテンプレートでできており、それはクラスとインスタンスの関係になっています。コンテンツは全てオブジェクトとして表現されるので、タスクをベースにした分類や階層はありません（コンテンツの分類名が「◯◯する」とタスク指向になっているサイトはたいてい使いにくいです。タスクではなく閲覧対象のエンティティを直接示すべきです）。また全ての「詳細」ページが、インスタンスとして1ページで完結しています。 もうひとつ、潜在顧客にとってのユーザーインターフェースとなるためには、我々の会社にコンタクトするための「問い合わせ」機能が重要になります。そこで、サイト内の全ページに問い合わせフォームを設置しました。 問い合わせフォームは、通常は邪魔にならないように閉じていて、ユーザーがボタンをクリックするとディスクローズして表示されます。そして、ここが重要なのですが、僕はそのディスクローズボタンのラベルを「問い合わせ」としました。 問い合わせフォームにアクセスするためのラベルが「問い合わせ」となっているコーポレートサイトを、僕は他に見たことがありません。普通は「お問い合わせ」となっているのです。でも「お問い合わせ」はおかしくないでしょうか？ 少なくとも、ユーザーインターフェースのラベルとしてはおかしいでしょう。オブジェクトを示すにせよ、タスクを示すにせよ、ラベルに「お」は要らないのです。なぜなら、ラベルはユーザーがシステムに対して入力するパラメーターを選択肢として提示したものであり、ユーザーの視点に立ったものだからです。「お問い合わせはこちら」といった運営者からの語りかけであれば良いのですが、ユーザーインターフェースのラベルとして「お問い合わせ」は、かえってユーザーをおちょくっている感じになってしまうのです。 こういうおかしなラベルがコーポレートサイトに氾濫しているのは、運営者が自社のサイトをアプリケーションとして捉えていない証拠だと思います。またコーポレートサイトを作っているデザイナーも、ユーザーインターフェースとしての設計視点や、シンタックスについての意識が、不足しているのだと思います。 いずれにしても、システムをモードレスなアプリケーションにするためには、コンテクストをユーザーに解放し、ユーザーサイドの視点で全体のイディオムを設計する必要があります。オーナーサイドの視点でコンテクストを主導すると、システムはモーダルになっていくわけです。 モードレス：ユーザーサイド モーダル：オーナーサイド

僕は iPhone を使っていて、かなり気に入ってます。このブログも全文 iPhone で書いているのです。iPhone 以外の携帯を使うことは、今となっては苦痛以外の何ものでもありません。ところが、今日、iPhone を1年使って解約したという女性の記事を読んだのですが、これには何というか、妙に納得してしまうところがありました。 この人が iPhone に感じた不満の第一は、文字入力がしづらいということでした。歩きながら片手で入力するのが難しいということです。それから不満の第二は、ナビ機能が弱いということでした。GPS の地図や施設案内の使い勝手が悪く、使い物にならないというのです。 確かにハードキーを持たない iPhone は、手の小さな女性が早歩きをしながらタイプするのは難しいかもしれません。僕にとってもそれは難しいです。また、iPhone のナビ機能的なものがドコモやAUのサービスと比べてどうなのか僕はよく知りませんが、たぶんこの記事の通りなのでしょう。 ただ、少なくとも僕はこれらのことに大きな不満に感じたことはありません。というか、そもそも歩きながら文字を打たなければならない状況はそれほど多くないですし、マップや施設案内といった機能は普段あまり使わないのです。考えてみたら、僕は滅多に道に迷いません。道を間違えることはあっても、迷子にはなりません。 むしろ僕が不満なのは、モバイルスイカが使えないことと、ソフトバンクの通話品質が悪いことです。でもそんなことが iPhone を解約する理由にはなりません。iPhone のユーザーイリュージョンの前には、そんなのは些細なことなのです。 この人が iPhone を解約した理由は、iPhone の機能性についての不満もあるでしょうが、それ以前に、もともと iPhone に何かとっつきにくさを感じていたからではないでしょうか。と、かなり勝手に予想します。 この人は、自身のことを極度の方向音痴と言っています。また記者という職業柄、文字を書く（タイプする）のが好きなのでしょう。そこがポイントです。 俗説として、男性は空間感覚に優れ、女性は言語感覚に優れると言われます。地図を見る時、男性は現在地と目的地の関係を空間的に捉えるけれど、女性は記憶や目印を手がかりに道順を知織化しようとする、というやつです。 男女間での差異が実際どれぐらいあるのか知りませんが、確かに世の中には、物事を大局的に見ることに長けた人と、シリアライズして見ることに長けた人がいると思います。空間認識というのは、位置、方向、大きさ、形状、間隔といった相対的な関係性の中で物事の性質を大局的に把握することです。これは恐らく、身体の運動能力やビジュアルコミュニケーション能力とも密接に関係しているでしょう。一方言語認識とは、始まりと終わりを持つ順次的な展開によって物事をシリアライズして理解することです。我々の話す自然言語は、当然、言語認識能力を使って入出力されるものでしょう。 OOUI、特に iPhone のUIは、極端に記号的です。記号的というのは、自然言語によるガイダンスをほとんど排除し、空間的表現を多用した非自然言語的なビジュアルボキャブラリーで構成された世界ということです。今何ができて、その結果何が起きるのかは、オブジェクトの位置や形状、視覚的な状態変化などを通じて示され、学習されることが期待されています。つまりそれを活用するためには、結構な空間認識能力が必要なのです。 iPhone の使い方を言葉で説明するのは難しいのです。でも使っている様子を一度見れば、同じように使えるはずです。そこにはグラフィックオブジェクト同士の精緻なインタラクションが織りなすモードレスな世界が広がっています。 けれど、空間認識があまり得意でなく、自然言語的な情報表現を好む人にとっては、この極端に記号的なUIは、理解するのにちょっと頭を使わなければならないパズルのように感じるかもしれません。そこまで大袈裟でなくても、地図の中から曲がり角ごとにひとつひとつ目印を見つけなければいけないような不安感があるのかもしれません。 十字キーでの順次的なフォーカス遷移を基本とした携帯電話の操作は、リニアで、モーダルなものです。操作方法を操作の手順として言葉で説明したり、覚えたりすることができます。自然言語的なコミュニケーションを得意とする人にとっては、とっつきやすいでしょう。前にも書いた通り、絶対数で言えば、このような自然言語的な操作を好む人の方が多いようです。彼等は、つまりモーダルな人々は、普通の携帯電話に対してそれほど大きな不満を感じないのでしょう。でもモードレスな人達は、そんな携帯電話ががまんならないのです。iPhone を触ったらもう戻れないのです。 モードレス：空間的 モーダル：言語的

ほとんどの業務アプリケーションは、タスクとして決められている手続きをオンラインで行えるようにしたものです。しかしタスクを厳密に定義するほど、またそれを忠実にオンライン化するほど、アプリケーションはモーダルになっていきます。モーダルなアプリケーションは使い方が限定的かつ暗黙的なので、知識として学習していないと正しく使えないし、使っていて楽しくないのです。 前に、業務アプリケーションの役割を「業務手続きのオンライン化」から「業務のオンライン化」に変えていく必要がある、と書きました。これはつまり、タスクの手順を操作の手順に置き換えるのではなく、タスク自体をオンラインに最適化するべきであるということです。 例えば、申請系の業務アプリケーション（勤怠の申請とか出張旅費申請とか）の多くは、通常は必要ないようなオプション項目がやたらと沢山あり、妙に面倒な画面になっていたりします。よく見るとこれらのアプリケーションは、「申請すること」が目的なのではなく、「申請書を作成すること」が目的になっているのです。その申請書はかつて紙ベースで業務を行っていた時のフォーマットそのままであって、オンラインならではの効率化が全くなされていないのです。例えば自分のログイン情報から自動的に決定するような項目を入力しなければならなかったり、条件分岐で不要になる項目がずっと見えていたり、必要に応じて後から追加すればよい情報を事前に全て入力しなければならなかったりするのです。オンラインで申請することを目的とするなら、申請項目の種類や見せ方、優先度の表現、承認フローと入力タイミングなども含めて業務を再設計することが望ましいでしょう。 前回の販売実績照会で言えば、1, 2, 3 の作業を手続きとしてオンライン化するのではなく、「自分が売った商品」というオブジェクトをオンラインで自由に照会できるようにすることが重要なのです。結果的に、それまで業務と思われていたものは実は手段の一例であり、必要なオブジェクトを自由に扱えるようにすることで、ユーザーはもっと創造的になれるかもしれないのです。 業務自体は変えず、単に手続きをオンライン化するということに、企業は、つまりモーダルな組織は莫大なコストをかけてきました。これはモードレスな者からすれば無駄としか言えないのですが、モーダルな組織は自身を維持することが最重要課題なので、コストの配分について保守的にならざるを得ません。すでに出来上がっている枠組みの中で少しずつの改善を行いたがるのです。少なくとも、その枠組みで物事がなんとか回っているうちは、あえてそれを変更することはしません。 ところがモードレスな人間というのは、とりあえず現状を否定してゼロから作り直してみることにチャレンジしたがります。結果として今よりも状況が悪くなる恐れがあっても、現状が理想と違うと思えば、そもそもの枠組みから変えなければならないと考えるのです。このような無鉄砲さはビジネスにリスクをもたらしますが、逆に言えば、こういう進歩的なモチベーションがなければ、積み上げ式ロジックからの飛躍は不可能でしょう。 モードレス：進歩主義 モーダル：保守主義

スクリーンデザインに先立つ要求事項の明文化が、どれだけシステムをモーダルなものにしてしまうかということを、僕はSEを対象にしたUI研修の講師の仕事を通じて思い知らされました。 例えば、UIデザインの実習として、よく次のような課題を出します。 ■次の要件を満たすUIを考えて下さい： 通貨換算を行う画面です。例えば、「128USドルを円に換算するといくらか」、といったことを調べるのに使います。 扱える通貨の種類は「USドル、円、ユーロ … 」など特定の10種類です。 続けて色々な通貨の組み合わせで換算しやすいようにしてください。 このような課題に対して、まず、それなりに論理的で無駄の無い画面をスケッチできるのがだいたい受講者の半数です。半数は、操作の順序とレイアウトが合っていなかったり、明らかに重複する入力を強いていたりしていて、論外です。 半数の妥当なデザイン案のうち最も典型的なのは次のようなものです。 一番左に数字を入力するテキストボックスがあり、その右に通貨選択のドロップダウンがあります。その右にまた通貨選択のドロップダウンがあり、その右にボタンがあります。 最初のテキストボックスとドロップダウンで換算前の金額と通過を指定し、その右のドロップダウンで換算後の通貨を選択し、そしてボタンを押すと、換算結果がその右もしくは下に表示されるという感じです。ひとつ目のドロップダウンの右に「を」というラベル、ふたつ目のドロップダウンの右に「に」というラベル、ボタンには「換算」というラベルをつけて、 ［　　　］［ドル▼］を［円▼］に【換算】＿＿＿ という風に、いわゆる「穴埋め式」にします。 このデザイン案は、特に大きな問題も無くそれなりに妥当だとは思いますが、一度換算をした後に続けて次の換算をしやすくするための工夫に欠けています。またそれ以前に、「複雑性の移動」が試みられていません。 ラリーテスラーの「複雑性保存の法則」が言う複雑性とは、要するに目的を達成するために入力しなければならない情報量のことです。この課題の場合、任意の金額と通貨で換算を行うためには、「換算前の金額」「換算前の通貨種類」「換算後の通貨種類」「換算実行の合図」という入力情報が必要です。上記のデザイン案は、これらを行うコントロールをただ並べたにすぎません。 複雑性は減らすことができないわけですから、操作性を高めるためには、複雑性の一部をユーザーサイドからシステムサイドに移動してやる必要があります。 ひとつの模範回答は、Mac の Dashboard にある単位換算ウィジェットのUIです。 ふたつのテキストボックスが左右に並んで配置されていて、それぞれのすぐ上にひとつずつ通貨選択のドロップダウンがあります。左右のテキストボックスの間には「=」というラベルがあります。 ［ドル▼］　［円▼］ ［　　　］＝［　　　］ 例えば左側のコントロールで換算前の通貨選択と金額入力を行い、右側のドロップダウンで換算後の通貨を選択すると、右側のテキストボックスに換算結果の金額が入ります。四つのコントロールのいずれかを変更すると、反対側に結果が反映されます。実行ボタンは無く、選択やタイプに応じてインクリメンタルに計算され、UIに反映されます。 このデザインが秀逸なのは、まず、手間が少ないことです。入力コントロールが出力コントロールを兼ねているため、換算結果をそのまま次の換算の入力とすることができます。それから、決められた操作の手順というものが無く、モードレスであることです。どのように操作しても、左右のオブジェクトが常にイコールになるようになっており、「入力内容をメモリにバッファしてサブミットする」というシーケンシャルなフローを排除することに成功しています。もはやそこでは、「通貨を換算する」というタスクはデザインに対して拘束力を持たず、「左右のオブジェクトが互いにイコールになろうとする」というオブジェクト同士の静的な性質があるだけです。ユーザーはその性質を利用しながら自由な方法で目的を達成できるのです。 こういうモードレスなデザインをスケッチできる人は、全体の1割ぐらいです。 更なる模範回答があります。こういうものです。 通貨の種類の数だけ、つまり10個テキストボックスが縦に並んでいて、それぞれの左には通貨名のラベルがあります。それだけです。いずれかのテキストボックスに金額を入力をすると、上記の単位換算ウィジェットと同様にインクリメンタルに計算が実行され、残りの9個のテキストボックスに一斉に換算結果が入ります。 　ドル［　　　］ 　　円［　　　］ ユーロ［　　　］ 　　　・ 　　　・ 　　　・ このデザイン案では、入力コントロールが出力コントロールを兼ねると同時に、換算後の通貨選択という操作すらも無くしてしまっています。一度に見せる通貨は換算前後の一対だけでなくてもいいわけなので、常に全部見せてしまうのです。目的を達成するのに必要な「換算前の金額」「換算前の通貨種類」「換算後の通貨種類」「換算実行の合図」という入力情報のうち、「換算後の通貨種類」と「換算実行の合図」の入力は不要になりました。複雑性の約半分がユーザーサイドからシステムサイドに移動したのです。そして「換算前の通貨」を選ぶための操作は、入力するテキストボックスの選択という操作に同化されているので「モードレスモード」であり、課税的な手続きを発生させません。 このデザイン案の欠点は、扱う通貨の数だけ面積を多く必要とすることです。通貨が50種類もあれば使いにくくなるでしょう。ただしあらかじめ通貨の数が10と決められているならば、またそれだけの面積を使えるならば、ベストなデザインだと思います。 ここまでのデザイン案に到達できるのは、全体の1%ぐらいです。ほとんどの設計者は、明文化された要件の中から「必要な入出力情報」を抽出し、それを「操作の手順」としてリニアライズしようとしてしまいます。その結果出来上がるのは「穴埋め式」のようなミニウィザードです。しかしUIをモードレスにするためには、「必要な入出力情報」を抽出した後は、「複雑性」の一部をシステムサイドに移動するような「オブジェクトの性質」を検討しなければならないのです。 もうひとつ、別な課題の例を挙げてみます。次のような課題です。 ■次の要件を満たすUIを考えて下さい： … Continue reading →

デザイナー、つまりモードレスな人の癖は、ソリューションの創出に際して、既成概念をどこまで遡って崩せるかという脳内チャレンジを繰り返すことです。現行のイディオムや機能表現を無かったことにして、問題解決に辿り着く最短ルートを模索するのです。その時、製品コンセプトの中心から距離のある付加的な要素についてはいったん無視します。それらがもたらす細々とした制約を考慮していると、整合させなければならない事項が多すぎて、新しいイメージを獲得できないからです。 そしてひとたび理想像をイメージできると — 例えばエレベーターに人感知センサーがあれば「開く」ボタンも「閉じる」ボタンも不要になる、というソリューションを思いつくと — 今度は、そのアイデアを実装する上で障害となる二義的な問題の解決方法を考え始めます。例えば、急いでいる時に意図的にドアを閉めたい場合にどうするかとか、乗ろうとしている人とただの通行人をどうやってセンサーに区別させるか、といったことです。 デザインには必ずトレードオフがあるので、新しいアイデアを採用するとそれに伴ってこれまでには無かった新たな課題が発生します。しかし課題には優先度があるので、重要な課題Aを解決するために課題Bが生じる場合、Aを諦めればBが解決されるからといって、そのような方策は何としても避けたいと考えます。モードレスな人は理想主義者なのです。 しかし現実には、デザイナーが到達した理想像に対してプロジェクトでGOサインが出ることは稀です。特に現行システムの改修を行おうとしている場合、デザイナーが示した理想的なデザイン案はほぼ100%却下されます。その理由は次のようなものです。 理想像を実装するとなると、現行システムをほとんど捨てて作り直すことになるので、コストがかかりすぎる。 理想像は現行システムと違い過ぎるので、それが本当に改善になるのか判断できない。 理想像を実装する上で新たに発生する課題の解決コストが、その改修によって得られる追加利益を上回る。 理想像は現行システムと大きく異なるので、ユーザーの再学習、販促物やマニュアル類の作り直し、保守やサポートコストの再見積もりなど、不確定要素が多すぎて、ビジネス性を定量化できない。 これらは確かにもっともなことで、デザイナーがいくら新しいデザインの完全性を訴えても、モーダルな人々には無意味です。モーダルな人々のモチベーションは、デザインのロジックではなくビジネスのロジックにあるからです。モーダルな人々は、現実主義者なのです。 つまり、産業において「発注者（モーダルな人）→ 受注者（モードレスな人）」という構図が一般的である以上、良いアイデアのほとんどは実現されずに闇に葬られるのです。 これまで僕が携わった案件でも、どれだけ残念な思いをしたか分かりません。理想像を追及できないとすると、後は大して意味の無いちまちました小改善を重ねることしかできません。「発注者がビジネス性を納得できるスコープでソリューションを提供するのがプロのデザイナーだ」と言われればそれまでですが、こういった状況は、職業デザイナーにとって恒常的なストレスになっています。 だから発注者にとって、製品の最初のバージョンにおける良いデザイナーの存在が、どれだけその後の製品ロードマップを左右するかは、計り知れないのです。なぜなら最初のバージョンというのはもともとビジネス性が多分に不透明であり、デザインのロジックが純粋に評価されやすいからです。 モードレス：理想主義 モーダル：現実主義

近視眼的な要求の断片から課題の本質を見定めて、シンプルで包括的なソリューションを考案するためには、すでに慣用的になっているデザインパターンを活用するのも手ですが、それにしても、目の前の事象や表層的な問題にとらわれず、一度常識を疑って全く違うアプローチをイメージしてみる想像力が必要でしょう。 例えば、エレベーターの操作パネルにおいて「開く」ボタンと「閉じる」ボタンを押し間違えてしまうという問題。エレベーターに先に乗り込んだ人が、続いて乗り込もうとしている人のために「開く」ボタンを押したつもりが、間違って「閉じる」ボタンを押してしまい、後から乗ろうとしていた人がドアに挟まりそうになる、ということがよくあります。 この問題はエレベーターのメーカーも認識しているようで、多くのエレベーターの操作パネルでは、「開く」ボタンと「閉じる」ボタンを視覚的に区別するための様々な表現が試みられています。 まず、「開く」と「閉じる」のボタンを「＜｜＞」「＞｜＜」のような記号で表している場合、これらは言語に依存しないので良いのですが、両者が視覚的に似すぎているので、やはり記号ではなく文字ラベルを使おうということになります。しかも漢字の「開」と「閉」はパッと見似ているので、漢字を使わずに「ひらく」「とじる」と平仮名で表記する方法があります。 それから、ボタンの大きさに変化をつけて、「開く」を大きく、「閉じる」を小さくしたり、色での区別もつけて、「開く」ボタンは緑色、「閉じる」ボタンは黒など他のボタンと同じ色にする方法。つまり視覚的に「開く」の方を強調しようとすること。そしてこれらを組み合わせた方法。 そんな試みが見受けられます。 ところが、これらの工夫をしても、やっぱり押し間違えてしまうのです。そのようなシーンを僕は何度か目にしました。ふたつのボタンの区別をはっきりさせるというデザイン上の工夫が、全く役立っていないとは言いませんが、根本的な問題解決には至っていないように思われます。これは何を意味しているのでしょうか。 いったい、ふたつのボタンの大きさを変えたり色を変えることで、どれぐらい判断の助けになるでしょうか。定量的に検証したわけではありませんが、僕は大して助けになっていないと思います。その理由は、ある選択肢セットにおいて、選択肢の数がふたつしかない場合、そのうちのひとつを強調するのは常に難しいからです。 強調表現をとるためには普通、相対的に大きくしたり太くしたり濃くしたり彩度を高めたりするわけですが、これが有効なのは、強調する項目の数が強調しない項目の数よりも少ない場合なのです。なぜなら、強調というのは「通常よりも相対的に重要」という意味だからで、強調項目の数が通常項目と同じもしくは多いと、「通常」の状態が定まらないからです。また、人の目はパターン認識に長けていますが、それが可能なのは複数の項目を群としてグルーピングできる場合であり、項目がふたつしかない場合にはパターン認識が働きません。ふたつの差は、「通常と強調」という群の相対性ではなく、 単に「AとB」という異なるふたつの個になってしまうからです。もしボタンが三つあって、そのうちのひとつが強調表現されていれば話は違います。その場合は強調が強調として正しく機能します。 ボタンがふたつの場合、強調したい方（「開く」ボタン）を緑色にするというのも、上記の理由からあまり有効ではありません。さらに、色というもの自体はそもそも強調表現になりません。大きさ、太さ、濃度、彩度などと違い、青とか黄色といった色には相対的な意味がありません。だから「開く」ボタンが緑色であってもそこから強調のニュアンスは発せられないのです。ただし例外は「赤」です。我々は赤だけには特別に反応します。だから赤であれば強調表現に使えます。ただしエレベーターのような乗り物では「赤」は非常ボタンに独占的に使われるべきなので、「開く」ボタンには使えません。 「開く」ボタンを「閉じる」ボタンよりも強調するために、大きさを大きくしつつ色も緑にすると、大きさだけを変えたり色だけを変えるよりもむしろ強調効果が下がる恐れもあります。選択肢セットの中で特定項目を強調する時には、「変化させる属性はひとつだけにする」という鉄則があるからです。我々の目は、同じものが沢山ある中で、そのうちのいくつかが小さな違いを持っている場合には目ざとくそれらを発見出来ますが、大きな差異には疎いのです。変化が大きすぎると、それらは選択肢セットの一員とはみなされずに無意識に視界から排除されてしまうからです。それらを認識するためには、もとの選択肢セットとは別の要素として「見直す」必要があるのです。 仮に「開く」ボタンをうまく強調できたとしても、やはり効果は低いでしょう。なぜなら我々はその表現を学習していないからです。全てのエレベーターが「開く」ボタンの強調表現を統一していれば良いのですが、実際にはそうではないので、「開く」ボタンを押そうとする時には、結局操作パネル上の沢山のボタンの中からラベルを頼りに探すことになります。これは相当大変です。また、「開く」と「閉じる」のセットが他のボタンとは位置的に離れた目に着きやすい場所に配置されていたとしても、「このエレベーターでは開くボタンが閉じるボタンよりも強調されている」ということを知っていなければ、やはりラベルを見て押すべきボタンを判断しなければいけません。 つまりボタンの表現という表層的な工夫だけでは、問題は解決しないのです。 ふたつのボタンの区別をはっきりさせるという試みの前提には、問題の原因が「ふたつのボタンが紛らわしいこと」にあるという仮説があります。そもそもそこから間違っているのです。 問題の本質を考えてみましょう。ここでは「開く」と「閉じる」という互いに正反対の動作を開始する一対のボタンを話題にしていますが、問題が起きるのは、常に「開くボタンを押そうとして閉じるボタンを押してしまった場合」であることに着目する必要があります。この間違いによって、今エレベーターに乗ろうとしている人がドアに挟まれるという危険にさらされるのが問題なのです。逆に「閉じるボタンを押そうとして開くボタンを押してしまう」というケースももちろんありますが、これは誰も危険にさらされず、急いでいる場合に若干の時間のロスが生じる程度で、大して問題にはなりません。 もうひとつ、「開く」ボタンを押す状況というのは、今から人が乗ろうとしているのに、ドアが間もなく閉まろうとしている（あるいはすでに閉まり始めている）ような時です。エレベーターに先に乗った人は、後から乗ろうとしている人の危険を察知して（あるいは乗せてあげようという善意から）急いで「開く」ボタンを押そうとします。急がなければドアが自動的に閉まってしまうからです。この「急いでいる」というのが押し間違えの大きな原因となっているはずです。誰でも焦っている時には判断や動作を誤りやすくなります。 つまり「開く」と「閉じる」は対の存在ですが、それらを押す状況としては全く深刻度が違うのです。そして問題を解決するためには、「開く」ボタンを即座に押せるようにすることが重要なのです。 ヒックの法則を適用してみると、「開く」と「閉じる」というふたつの選択肢からひとつを選ぶという意思決定にはだいたい240ミリ秒かかります（実際に押下するまでの時間は、これに加えて、状況判断の時間や押下動作の時間が必要）。それ以前に、沢山のボタンの中から「開く」と「閉じる」のセットを発見する必要がありますし、ボタンに手を伸ばして押下する時間も必要です。「開く」が強調されていたとしても、ユーザーはその表現を学習していないので、結局ふたつのボタンを確認してからどちらかを選ぶことになります。選択肢としてふたつのボタンがある限り、そこには選択行為が必要になるのです。 危険を回避するための緊急ボタンとして「開く」ボタンを機能させるのであれば、「閉じる」ボタンと対にして配置するべきではないのです。選択肢が増えればそれだけ選択のための意思決定に時間がかかるのですから、問題解決のためには、選択肢をできるだけ減らす必要があります。もし「開く」と「閉じる」が対ではなくて、「開く」ボタンが単体で目立つ所に配置されていれば、ボタン押下までの時間を短縮できます。ヒックの実験値で言えば約150ミリ秒です。また、「閉じる」ボタンが無ければ、そもそも間違ってドアを閉じてしまうということがなくなります。 実際、海外に行くと、「開く」のみで「閉じる」ボタンの無いエレベータをよく見ます。上記のような考察の結果かどうかは分かりませんが、少なくとも、押し間違いによって人をドアに挟んでしまうという状況は起こりにくくなっています。そのようなエレベーターでは、「閉じる」という明示的なボタンが無いわけですが、行き先の階数ボタンを連続押しするとすぐにドアが閉じるようになっていたりします。急いでいる人は階数ボタンを連打する傾向があるので、この仕様はそれなりに有効だろうと思います。優先度の低いタスクについては明示的な機能提示を行わず、でも「やる方法が無いわけではない」という風に落とし込む方法です。これにより重要な機能を効果的に強調して、全体をシンプルに保つことができます。 「開く」 ボタンだけにしてしまうというのは、そういったわけで、なかなか良いソリューションだと思います。ただそれでも、操作パネルの中から「開く」ボタンを発見できないという可能性がありますし、発見できても、手を伸ばしてそれを押す時間が必要です。エレベーターに複数の人が乗っている場合、ボタン押下の役目を譲り合ってしまって結局閉まってしまうということもあります。 それよりも、もしドアに人が接近したことを感知するセンサーがあれば、「開く」ボタンすら必要なくなります。実際そういうエレベーターも見たことがあります。そうなれば、センサーの精度にもよりますが、ほぼ100%問題を解決できそうです。これはかなり完璧なソリューションではないでしょうか。なぜ全てのエレベーターがそうなっていないのか不思議なぐらいです。ドアに挟まっても大した怪我にはならないからとか、防犯上の理由からでしょうか。保守性とか、何か他に理由があるのでしょうか。

良い製品の背景には、「モードレスな人がモードレスな活動によってモードレスな道具を作る」という構図があります。しかしこれは、ビジネスにおいてはなかなか厄介なことです。 仕事がモードレスであるということは、要するに、無計画であるということです。企画段階や設計段階で、作業の計画を立てられないということです。やってみないと、良いものが出来上がるかどうか分からないのです。はじめのうちは、何が出来上がるのかさえ分からないのです。当然スケジュールを立てたり工数を見積もることもできません。いつ完成するのかは、完成の5秒前ぐらいになってやっと分かるのです。これではビジネスになりません。少なくとも、現代の請負型案件としては成立しません。 モードレスな人というのは、やることが決まっていると仕事がつまらなく感じます。やることは自分で決めたいのです。しかも、やりながら決めたいのです。計画どおりにプロセスが進むことに、何の充足感も安堵感も覚えないのです。それよりも、先の分からない状態からスタートして、自分のノミのひと振りひと振りによって、大理石の中から徐々にダビデ像が出てくることに喜びを覚えるのです。仕事のモチベーションは自己満足にあります。与えられた課題に対して、何かうまいソリューションを生み出せそうかどうかは、自分の経験から感覚的に判断するしかありません。だから楽観主義者でないとやっていけません。 一方、モーダルな人というのは、事前に綿密な計画を立てて、それを正確に実行することに価値を見出します。どれぐらいしっかりとした計画を作れるかが最大の課題であり、次にその計画を遂行するための忍耐力や持久力や調整能力がチャレンジの対象になります。スケジュールや工数を見積もれないような状況は仕事をする状況ではありません。そして計画どおりに仕事が終われば、それが達成感になります。計画どおりに仕事が進まず、想定していたものと違うものが出来上がってしまったら、それは失敗です。最初の段階で出来るかどうかを判断できないのなら、出来ないのと同じなのです。様々な失敗要因を想定して、それらを回避しなければいけません。失敗の想定が不十分な状態でプロジェクトが開始されると、不安で眠れません。基本的に、悲観主義者なのです。 組織においては、一般的に、モーダルな人の方が評価されます。その人の価値を定量化しやすいからです。それに、複雑なものを一定のコストで作り上げるには、仕事をシステマティックに整理する必要があり、モーダルな人によるモーダルな活動でないと成立しないのです。その結果出来上がるものは、当然モーダルなものになります。 組織が大きいほど、その組織内で行われる取り組みはモーダルになっていきます。組織が大きいほど維持コストの割合が増えるのと同じです。社会全体で見れば、システムを維持するためのシステム、手続きのための手続きが、膨大に発生しています。 そのこと自体はどうしようもないのかもしれませんが、デザイナーの価値観は違うところにあります。モードレスな取り組みによってモードレスなものを作りたいのです。それは恐らく、複雑なものをシンプルにする活動なのです。しかしそういう人や活動は、価値を客観化しづらいので、モーダルな人々、つまり組織からは疑問視されがちです。出世するのは難しいかもしれません。歯車として社会の機構に当てはまらないからです。鉄郎みたいな存在なのです。 モードレス：楽観主義 モーダル：悲観主義

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

道具のデザインの二大コンセプトである「モーダル」と「モードレス」。その「モードレス」の方について考えてみます。 モードレスなデザインはオブジェクト指向であり、その目的は、ユーザーを多様なゴールに導くための「プロセス自体を提供すること」です。ユーザーが行うべき意思決定は「各作業ステップにおける次の一手」です。次の一手をどうするかの判断は逐次的になされ、その判断基準は、処理対象のオブジェクトが「望む感じに近づいているかどうか」です。このイディオムは主に創作系のアプリケーションで採用されており、ユーザーがこれでよしと思った時点が作業の終了となります。 オブジェクト指向の道具は、タスク指向の道具と違って、ユーザーのタスクを特定しません。特定してしまうと、操作のイディオムがモーダルになってしまい、作業を実験的に進めることができなくなるからです。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 →