Author Archives: Manabu

僕はよく自動販売機で缶コーヒーを買うのですが、あの釣銭返却レバーを見るたびに、そこに無反省なブルジョアジーを感じて気分が悪くなるのです。なぜ自販機というのは硬貨投入が先で商品選択が後なのでしょうか。硬貨投入が先であるために、商品選択待ち状態というモードが発生するのです。商品選択が先なら、モードをキャンセルする返却レバーは不要になり、操作も自然になるはずです。 巷ではユーザビリティの重要性が叫ばれ、良いデザインを実現するためのプロセスについて諸説を耳にするようになりました。しかしそのほとんどは、プロセス自体に冗長性を持たせるだけの保守的なものであり、シリアライズされた言語的な理論にすぎないのです。そこからは、要するに良いデザインとはどういうものか、という疑問に対する具体的な回答を得られないのです。ましてや、僕が実際の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を学習し、電車式でなく自動車式に目的に近づきながら、理論でなく実験によって、徐々に自分なりの使い方を作り上げていきます。そこには決まった使い方というものは無いのです。後は、ユーザーの学習を阻害するような暗黙の制約や不明瞭な因果関係を排除していけばよいのです。 ひとつのシステムにおいて複数の主要クラスを扱う場合は、対象クラスを選択する機能が必要になります。クラス選択はタスク／業務選択と同義であることも多いですが、できれば選択肢のラベル／アイコンにはタスク名ではなくクラス名を用います。その方がモードレスなメンタルモデルを形成しやすいからです。このクラス選択が、ナビゲーションになります。クラス選択からインスタンス選択へ、インスタンスの属性概要から詳細へ、という抽象度のズーミングによるドリルダウンも有効でしょう。ナビゲーションには他にも、特定のツールやビューを呼び出すものがありますが、これらの振る舞いをリアルタイムに反映することで、モードを無くすことができます。それ以外のナビゲーションは全て課税的な操作になるので、できる限り排除します。 オブジェクトは常にユーザーがマウスクリックやタップで直接ポイントできるようにし、またオブジェクトは自身の状態をできる限りリアルタイムに反映するようにします。 スクリーン上で、あるオブジェクトに対する処理がひとつだけなら、シングルクリックでそれを実行できるようにするべきです。アクションが複数あるなら、対象オブジェクトの選択後にアクションを選択させます。インスタンスの一覧においては、複数のアクションを属性として見せ、それらをシングルクリックで実行できるようにしてもよいでしょう。主要なアクションをダブルクリックに割り当てて、その他のアクションはメニューやボタンとして提示するのもよくあるパターンです。ただしドラッグ＆ドロップのような直接的なジェスチャがユーザーの認知的負荷を軽減できる場合にはそれを積極的に採用し、動詞選択という手続きをインタラクションから取り除きます。 同じオブジェクト（群）が複数のビューを持っていてもよいですが、できるだけ同じ場所で切り替えられるようにして、ビューをタスク／モードに依存させない方がよいでしょう。そうすることで、ユーザーはオブジェクトを実体として認知するようになり、ユーザーイリュージョンが強力になります。 — ここに書いたような方法論を用いれば、創作系ではない業務システムのようなものでも、かなりの割合でモードレスにすることができると思います。ただしそれには、前にも書いたとおり、システムオーナー側がユーザーの仕事というものをもっとモードレスなものとして、進歩的な価値観をもって、再定義する必要があるでしょう。デザイナーの本当のチャレンジは、もしかするとそこにあるのかもしれません。 モードレス：オブジェクト指向 モーダル：タスク指向 モードレス：直接操作 モーダル：間接操作 モードレス：自動車式 モーダル：電車式 モードレス：実験的 モーダル：理論的

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