モードレスはどこから来たか – オブジェクト指向UIの起源 –

November 7, 2018
Manabu Ueno

いや、「モードレスはどこから来たか」ではなく、本来の疑問は「モードはどこから来たか」なのだ。なぜなら自然界にモードはないから。

モードは何もないところに生まれる形だ。混沌に生じた秩序だ。例えばファッションがそう。一般的にモードという言葉は、新しい流行や様式を指す。そして文化的な多様性と進化を促す力として肯定的に受け取られている。つまりモードはデザイン性の証なのだ。

しかしユーザーインターフェースデザインの分野、特にコンピュータソフトウェアの操作性に関するテーマにおいては、モードはほとんどすべてのシステムが宿している原罪として、解決すべき問題として扱われる。

なぜ原罪なのかと言えば、コンピュータというものの発想自体の中に、用途によって役割を変える道具 ＝ 無数のモードを持つ多目的な存在としての性質が込められているからだ。そしてコンピュータは、その宿命であるモードによって、生得的に使いにくいというジレンマを抱えているのである。

コンピュータはその原罪としてモードを宿しているため、それを自然に返すために ー 私たちがもっと自然に使えるようにするために、モードレスネスへの挑戦が必要なのだ。

Design Principle

ユーザーインターフェースデザインにおいては、モードレスネス（モードが無いこと）が重要だと言われる。多くの研究者が、ユーザーインターフェースにはできるだけモードが無い方が良いと言い、またデザイン原則としてモードレスネスを提唱している。

例えば2011年の “Mac OS X Human Interface Guidelines” には次のような記述がある。

Embrace Modelessness
Users appreciate apps that allow them to be in control and they generally dislike apps that wrest control away from them too often. One of the most common ways that apps take control away from users is by overusing modes that require users to follow a specific path.

モードレスネスを信奉しなさい
ユーザーは彼／彼女らにコントロール権を与えるアプリを好み、また彼らから頻繁にコントロール権を奪うアプリを大抵嫌います。ユーザーからコントロール権を奪う最も一般的な方法は、ユーザーに特定の進路を強要するモードを乱用することです。

では、この「ユーザーインターフェースはモードレスである方が良い」という考え方を最初に言いだしたのは誰だろうか。

Apple の Human Interface Guidelines には伝統的にモードレスの重要性が書かれており、最初期の “The Apple II Human Interface Guidelines”（1985） においてすでに、“The Desktop Interface” の章（Apple II/ Lisa/ Macintosh 用のウィンドウユーザーインターフェースについて書かれた章）の冒頭で、Bruce Tognazzini による “Avoiding Modes”（モードの回避）という文章が掲載されている。

初期の Macintosh 開発を率いたジェフ・ラスキンは、2000年の『ヒューメイン・インターフェース』の中で全8章のうち1章をモードの話に割いており、熱心にモードレスの重要性を説明している。例えば次のように言っている。

私は、インタフェースがモードを持たず、かつ、可能な限りモノトナスであれば、その他全てのデザインが現代のインタフェース水準から見て平均的なものであっても、劇的に使いやすいものとなると信じています。（中略）もし私の考えが正しいのであれば、モードが無くモノトニーに基づいた製品を使用することによって、ほとんど病みつきとも言える習慣が形成され、製品を愛するユーザ人口も増加していくことでしょう。

Mode Error

ドナルド・ノーマンは80年代の『誰のためのデザイン？』やその他の論文で、エラー（操作ミス）の種類のひとつとしてモードエラーをあげている。モードエラーとは次のようなものだ。

モードエラーは、装置がいくつか異なる操作モードをもっていて、あるモードで適切な行為が他のモードでは違う意味をもつようなときに生じる。モードエラーは、その装置がもっている制御スイッチや表示の数よりも、実行可能な行為の数の方が多く、それゆえ一つのスイッチが二つの役割を果している装置ではいつでも生じうる。

ここから分かるのは、ユーザーインターフェースにおけるモードというのは、機械的な道具が電子制御されることによって生まれたということだ。それ以前の機械や道具では、基本的に操作の状態を記憶しておくことができなかった（できたとしても物理的な機構として目に見える）から、モードの問題は顕在化しなかった。

家電が使いにくいという話をよく耳にする。ボタンが多すぎて使い方が分からないという。しかしよく聞いてみると、問題の原因はむしろ逆だ。機能の多さに対してボタンが少なすぎるのだ。ボタンが10個あるのが問題なのではなく、それに対して機能が20個あることが問題なのだ。

メーカーの論理として、ボタンなどの部材はできるだけ増やしたくない。しかし機能は増やしたい。そこで、操作体系の中にモードが作られる。ひとつの機能を実行するために、恣意的なボタンの組み合わせが設定される。これは学習困難なので使いにくさの原因となる。簡単なことをするにも複雑な操作（の記憶）が必要になったり、はじめからやり直さなければならなかったりする。例えば次のようなことがあるだろう。

  • 全自動洗濯機で、洗濯の途中で中止して水を抜きたいのだが、「排水」ボタンがどこにもない。排水するには、一見関係のない3つのボタンを特定の順序で押さなければいけない。
  • DVD プレーヤーにディスクを入れると再生が始まる。中断しようと停止ボタンを押すと再生が停止し、テレビモードになる。続きを見ようと再生ボタンを押したが再生されない。仕方なくディスクを一度取り出し、挿入するところからやり直す。

ボタンが増えたとしても、それぞれがモードを持たずひとつの機能に割り当てられていれば、混乱は少ない。機能が増えてボタンが膨大になれば確かに使いにくくなるが、だからといって、モードを作ったり階層化したりすれば解決するというものではない。むしろ問題を見えにくくして学習を困難にしてしまう。

航空機のコックピットにはたくさんのスイッチがある。各スイッチはそれぞれひとつの機能に割り当てられている。パイロットはすべてのスイッチを覚える手間があるが、一度覚えれば咄嗟の操作ができる。しかし電子化／コンピュータ化が進み、グラスコックピットと呼ばれる大型ディスプレイを用いた階層式の操作体系が導入されるようになったことで、モードの混乱による操作ミスが問題視されるようになった。

道具が電子制御され、特にコンピュータによって多量の状態保存と複雑な条件分岐が可能になると、設計者たちはそこへ次々とモードを詰め込みはじめた。プログラムを読み込んでメモリー上に展開できるコンピュータでは、複数の決まった手順のセットを組み合わせて連続的に（かつ高速に）実行できる。これはつまり人の記憶力や計算能力を超えて深いモードを作れるということだ。だからコンピュータを使うことは、モードを複雑化させていくことと同義だったのだ。

そういうわけで、冒頭に書いた通り、モードはコンピュータの宿命であり、そしてユーザーインターフェースデザイナーにとっては最大の宿敵となった。

Object – Verb

UIをモードレスにする最も基本的な方法は、操作の順序を「Object（目的語）→ Verb（動詞）」の構文にすることだと言われている。Object → Verb のシンタックスは GUI の操作性を特徴づけるもので、CLI の Verb が先にくる入力シンタックスと対照をなす。

GUI では操作の対象物（オブジェクト）がまず画面上に見えている。ユーザーはそれを選択し、次にアクションを選ぶ。これが逆だと、つまり先にアクション（やりたいこと）を選び、次にその対象物を選ぶのだと、アクションを選んだ後に「対象物選択待ち」の状態、つまりモードが発生してしまう。対象物選択待ちモードの最中に気が変わって別のことをしたくなったら、ユーザーはそのモードを解除する操作をしなければいけない。一方 GUI の Object → Verb シンタックスではモードは発生しない。もし対象物を選んだ後で別のことをしたくなったら、何もせずそのまま別の行動に移ればよい。

GUI の操作体系の裏にあるオブジェクト優先の発想は、オブジェクト指向プログラミングのパラダイムと同期している。GUI とオブジェクト指向プログラミングは70年代後半の同時期に、アラン・ケイをはじめとする Xerox パロアルト研究所のメンバーによって、その初期の完成形が作られた。

Smalltalk

アラン・ケイは「ユーザーインターフェース 個人的見解」で次のように書いている。

Smalltalk のオブジェクト指向性は非常に示唆的であった。オブジェクト指向とは、オブジェクト自身が自分が何をできるのか知っているという意味である。抽象的なシンボルの場では、それは、最初にオブジェクト名を記述（するかあるいは持ってきたり）してそしてそれに何をするかを指示するメッセージを付ける。具体的なユーザーインターフェースの場では、それは最初にオブジェクトを選択することを意味している。それから何がしたいのかをメニューによって提示する。どちらの場合でも、オブジェクトが先であり、やりたいことがその次となっている。これは具体的なものと抽象的なものとを高い次元で統合している。

また彼が発明したと言われるオーバーラッピングウィンドウ（画面上で複数のウィンドウを重ねて表示すること）について、次のように書いている。

動く視覚の精神は、できるだけたくさんの要素を画面に表示することで創造性をかきたて、問題解決を促し、妨害を防ぐ。ウィンドウを利用するときの直観的な方法は、マウスをそのウィンドウに入れて、ウィンドウを「上」にしてウィンドウをアクティブにすることである。このインタラクションは特殊な意味でモードレスである。確かに、一つのウィンドウに絵を描く道具があって、もう一つはテキストを保持しているというように、アクティブなウィンドウはモードを構成している。しかし、何かをするときには停止せずに隣のウィンドウに移ることができる。これが私にとってモードレスたる由縁なのである。

当時の Alto/Smalltalk がどのようなものだったかを紹介するビデオがある。これはスティーブ・ジョブス率いる Apple のエンジニア達が PARC を訪問して目にした Smalltalk-76 である。これを見たジョブス達は衝撃を受け、Apple 初の GUI パーソナルコンピュータである Lisa、そして次の Macintosh が作られることになる。

このビデオは、初期の GUI がどのようなものだったかということがわかる貴重な映像だ。（プレゼンテーションの全編はこちら）

また、Smalltalk のオブジェクト指向プログラミング環境が GUI の表現と完全に一体化している様子も興味深い。ジオ・マンデルは『The Elements of User Interface Design』の中で、オブジェクト指向UIでは「全てのオブジェクトが常にアクティブ」であるべきだと言ったが、Smalltalk では実際、すべてのものが対象化されて、アクティブだ。テキストはコンテンツでもありコマンドでもあり、またメニューやウィンドウなどと区別されずに、オブジェクトである。それら対象化されたものを直接的に指し示すためにポインターがあり、グラフィック表現がある。Smalltalk では、今動いているシステムプログラムのクラスライブラリを画面に表示し、一部を書き換え、その場でコンパイルして反映することもできる。ブラックジャックが自分を手術するように、Smalltalk ではプログラムとユーザーインターフェースが、抽象と具象をつなぐ同じパースペクティブの中に偏在しているのだ。

アラン・ケイはまた、初期のテキストエディターの操作にモードが多く用いられていたことに対し、次のように書いている。

モードレスにするのに最も難しい領域は、ごくささいな例であるが、初歩的なテキスト編集がある。何人ものエディターを悩ませている「挿入」と「上書き」モードからどうやったら逃れられるのだろうか。（中略）単純化を試みた主な点は、挿入、上書き、消去という区別をキャラクター文字の間隔の選択に置き換えたということである。すなわち、幅がゼロである選択を許すと、すべての操作は上書きでできる。挿入とは、幅がゼロであるところに上書きすることになる。消去は、幅がゼロであるキャラクター文字で上書きするという意味になる。私は1ページ程度の Smalltalk のプログラムを書いて、勝ったと思った。ラリー・テスラーはこれを褒めた上で、彼の新しい Gypsy エディターで動いているアイデアを見せてくれた。

さて、ここに名前が出てきたラリー・テスラーである。彼こそが、モードレスデザインの始祖とも言える人物なのだが、その前に、70年代 PARC での GUI 研究の元になった、NLS と Sketchpad について簡単に触れておきたい。

NLS

NLS は、ダグラス・エンゲルバート率いる研究者チームが60年代に開発した革新的なコンピュータシステム。ビットマップディスプレイによるグラフィカルな情報表現、マウスによる直接的なポインティング、ハイパーテキスト、遠隔ネットワークによるマルチユーザー連携などの原型となった。

NLS は、コンピュータシステムの概念が、中央集権的な演算装置から、よりパーソナルで創造的なコミュニケーションメディアへと変化していく大きなきっかけとなった。そしてその後の、パーソナルコンピュータ、GUI、オブジェクト指向プログラミングといったコンセプトの源泉となったのである。

エンゲルバートが1968年に行った伝説的な NLS のデモのビデオがある。この最新技術を駆使したライブデモンストレーションは、後に “The Mother of All Demos” と呼ばれるようになった。

Sketchpad

Sketchpad は1963年にアイバン・サザランドが開発したコンピュータプログラムで、画面に表示されたグラフィックを直接的に操作するという、GUI のアイデアの起源とされている。

サザランドはヴァネヴァー・ブッシュの Memex（ハイパーテキストの元になったシステムの概念） に触発されて Sketchpad を作った。エンゲルバートの NLS は、Sketchpad に影響を受けて開発されたと言われている。

Sketchpad では表示されたグラフィックオブジェクトをライトペンで操作し、CAD のような作業ができる。その実現のために、データ構造として「オブジェクト」や「インスタンス」の概念を採用し、オブジェクト指向プログラミングの先駆けのひとつでもあった。

Sketchpad の操作の様子をこのビデオで見ることができる。

Tesler

そしてテスラーに話を戻す。ラリー・テスラーは、「カット＆ペースト」の発明者として、また「テスラーの複雑性保存の法則」でも知られるソフトウェア研究者だが、70年代の PARC でアラン・ケイ等と共に GUI の基礎的な操作体系を作ったことでも有名だ。テスラーの信条はとにかく「モードを無くすこと」だった。彼はソフトウェアからモードを無くすことを早くから主張していて、”Don’t mode me in”（俺をモードに入れるな）とプリントしたTシャツを来たり、自分の車のナンバープレートを “NOMODES” という文字にしたりしていたと言われる。現在では nomodes.com というドメインを使っている。

NOMODES と書かれたナンバープレートの写真

テスラーが初期の GUI 開発の中でどのようにモードレスネスを実現していったのかについて、近年に書かれたこの記事がとても興味深かった。

A Personal History of Modeless Text Editing and Cut/Copy-Paste
（上記リンクは有料ダウンロードですが、ネットで探すと無料で読めるものも見つかります…）

要約すると、次のようなエピソードが書かれている。

テスラーは高校でプログラミングを勉強し、1961年にスタンフォードに入学。ソフトウェアの使い勝手に興味をもち、いろいろなプロジェクトで操作性の改善を試みていた。コンピュータの使われ方はバッチ処理が中心だったが、インタラクティブなシステムも現れはじめた。しかしどれもモードがあって使いにくかったので、彼はモードとモードエラーをなくすための研究を始めた。

1968年に Stanford Artificial Intelligence Laboratory (SAIL) で働き始め、そこでアラン・ケイやドナルド・ノーマンと会い、認知心理学を勉強することになる。そして1969年にダグラス・エンゲルバートの Augmentation Research Center を訪ねる。エンゲルバートが NLS の伝説的なデモを行った直後だった。

60年代の後半に、彼は地元の団体のために季刊カタログの版下づくりを手伝っていた。そこでカッターと糊でカット・アンド・ペースト（切り貼り）作業をしているうちに、これらの作業を簡単にできるインタラクティブなページマークアップシステムを思いついた。

同じ頃、TVEDIT というフルスクリーンのテキストエディタがあり、そこには間違いを簡単に訂正できる oops という機能があった。また、2ステップでテキストを移動できる機能もあった。そこでは、特定のテキストを delete するとそれがスタックの先頭に追加される。そして retrieve するとスタックの先頭の項目がユーザーが指定した箇所に挿入される。ステップの間にユーザーは検索やタイピングなど他のことができた。TVEDIT にはモードがあったが、2ステップの移動機能や oops のような間違い訂正のようなもので、エディタをモードレスにできると考えた。

1973年に Xerox PARC に入り、 PARC Online Office System (POLOS) のチームに入った。また時々、アラン・ケイのグループで Smalltalk の仕事をした。ケイと仕事をした理由は、彼の発明であるオーバーラッピングウィンドウが興味深かったからで、それがモードの代わりになると感じたからだった。

POLOS のメンバーの多くは SRI のエンゲルバートグループから Xerox に来た者だった。そこでマウスの設計や NLS のデモをエンゲルバートと一緒に作ったビル・イングリッシュが上司になった。NLS は技術仕様書やソースコード、その他のインデント式アウトラインを書くのに使われた。これは優れたツールだったが、テスラーは、一般の人が書類を書いたり手紙を書いたりメモを書いたりするのには受け入れられないだろうと考えていた。なぜならコマンド言語が膨大なモードを持っていたから。テキスト入力モードの外では、全てのキーストロークとクリックがモードを作った。NLS のコマンド言語のシンタックスは進化を繰り返していたものの、常に「動詞がオブジェクト選択の前にくる」入力構文だったのだ。例えばパラグラフを削除するには、まず NLS に delete と伝えてから対象のパラグラフを伝える。文字列を移動するには、move と伝えてから、移動したい文字列の先頭を指定、末尾を指定、そして移動先の挿入ポイントを指定する。これらのコマンドラインを指定したら、ok を押してやっと実行される。

ポインターが何かの上にある時にクリックすることを marking と呼んだ。NLS の主要なコマンドは次のようにマーキングされた

D(elete) W(ord) <mark affected word> <ok>

M(ove) T(ext) <mark source text start> <mark source text end> <mark destination> <ok>

I(nsert) S(tatement) <mark destination> <type text to insert> <ok>

コマンドを実行するアクションが <ok> でこれはキーボードからでもマウスでもできた。ユーザーがタイプしたりクリックすると、コマンドの行がウィンドウの端に表示された。ok するとそれが消えて実行された。

このシンタックスの問題について、ほとんどのメンバーは認識していなかった。彼らは、NLS の「Verb → Object」の構文は英語の文法と同じだから直観的だと思っていたのだ。

そこでテスラーは、目的語が先にくる「Object → Verb」シンタックスの利点を説いてまわった。

つまり、文字列を消去したければ、まず削除したい文字列をマウスのドラッグ操作で直接的に選択して delete コマンドを実行する。文字列を移動したければ、やはり移動したい文字列を直接的に選択し、cut コマンドを実行、そして挿入ポイントを直接指定し、paste を実行する。

そして、オブジェクト選択先行のシンタックスに関する懸念については、次のように払拭した

  • もしユーザーがオブジェクト選択を間違えたら、選択し直せば良い。コマンド行を保持して表示する必要はない。
  • もしユーザーが間違った動詞を選んだら、結果はすぐに目に見える。訂正するには、取り消しのコマンドを実行すれば良い。（その頃別の LISP シェルのプロジェクトで、oops よりも自然な undo という機能が作られていた）

また同僚のジェフ・ラリフソンが読んだ記号論の本からヒントを得て、ラベル付きのピクトグラムがコンピュータの操作に役立つと考えた。これが現在の「アイコン」である。

それらを含んだ当時の様々なアイデア、つまり、モードレスなカット＆ペースト、アンドゥ、アイコン、挿入ポイントへのタイピング、ドラッグによるテキスト選択、ダブルクリックによる単語選択、等を実装した Gypsy というエディタを開発した。

テスラーはそのモードレスなエディターについて、ユーザビリティテストを行った。すると、コンピュータを触ったことがない人でも5分で使えるようになった。そこで彼は、モードレスな操作性が持つパワーを確信した。

その Gypsy エディターの、テスラー本人によるデモビデオがこちら。

Modality

PARC での研究が Macintosh や Windows、その他の多くのシステムに反映され、GUI は普及した。今ではスマートフォンも含めて誰もが普通にオブジェクトベースのUIを使っている。それにも関わらず、業務アプリケーションを中心に、タスクベースの、Verb → Object シンタックスの使いにくいシステムが作られ続けている。設計者たちが、いざ自分でツールのデザインを考えるとタスクベースのものしか思い描けないのはなぜか。

企業のシステム企画者やシステムエンジニアが自分たちのシステムを考える時、描かれるポンチ絵は大抵タスクベースでモーダルなものになる。業務を区分し、それぞれを線形なプロセスとしてウィザードにすることをまず考える。それをそのまま実装するから、学習効率や操作効率の悪いものが出来上がる。

釘を打つ時、まずハンマーを持ってから腕を振り下ろす。振り下ろしてからハンマーを持つ人はいない。しかし道具を設計しようとする時、多くの人はユーザーにまず「やること」を選ばせようとしてしまう。本来は「対象物」を先に選ばせないといけないのに。

ナサニエル・ボーレンスタインは、デザイン感覚、技術知識、ソリューション経験に欠ける人々（つまり普通の人々）が考えたアプリケーションの基本設計は、囚人移送スケジュールのように「順番通りにやるだけ」のものになると言っている。

便利な機械という時に人々が思い浮かべるのは、簡単な命令で複雑な自動処理をしてくれるブラックボックスだ。しかしそのような存在が価値を持つのは目的の特殊性が高くプロセスのコントロールが不要な場合だから、実際にはコストの割に使い道が限定されすぎたものになる。

もちろん求める利便性のスコープにもよるが、基本的に良い道具というのは、要求に対してそれを抽象化したレベルからユーザーをエンパワーするものだ。それによりユーザー自身の観点や振る舞いを良い方向に変化させるものだ。

ハンマーという道具的存在性が認められる時、私達の中ではそれを振り下ろす行為と目標を求める意識は一体になっている。しかし打ち込まれた釘のイメージがそれを実現する行為のイメージと分離している場合、目標状態への切符としてタスク選択が促されることになる。

なぜ人の頭で目標状態と行為のイメージが分離してしまうのか。この疑問に対して私はこれまで「業務というものがそもそも行為だから」「要求分析のゴールが一般にタスクの特定と考えられているから」といった理由をあげてきた。しかし本当はそれよりも根本的な理由があるように思う。

子供が言葉を認識しだすと、親はしつけをはじめる。物や概念の名前を覚えさせ、その良し悪しを教え、そして目標状態へのプロセスを言語化する。服を着替えさせるために、靴下の脱ぎ方やボタンのはめ方などの手順を線形化してコピーさせる。つまり物事に区別をつけ、目標への到達はプロセスに還元できるという思考を持つことは、人が人になっていくということと同義なのだ。動物は餌を食べる時、その目的や、自分がどうやって餌を食べているかを意識しないだろう。

タスク指向 ＝ モード指向は、人として最初に教育される世界認識の基本メソッドなのである。だからその感覚－目標とプロセスの分離－に従ってデザインをするなら、Verb → Object シンタックスのモーダルなものになるのは自然だろう。コンピュータのメタメディア性を具現化するに至ったエンゲルバートでさえ、NLS では Verb を先にしてしまったのだ。そこには天動説のような確かさと安定感があった。だから、ラリー・テスラーやアラン・ケイの洞察は奇跡的だ。モードレスデザインは彼らのコペルニクス的転回によって発見された新しい世界認識なのだ。

そう考えると、コンピュータシステムのような内部に膨大なプロセスがある道具を、視点を逆転させてオブジェクトベースでデザインするという GUI の発想は、ある意味、人間らしさの再定義であり、動物的な非言語的世界への回帰なのかもしれない。

オブジェクト指向では、世界をプロセスとして正規化する前の段階、一種の空間として扱う。ソフトウェアデザイナーがモードレスデザインに到達するには、彫刻家のように動物的な目を持つ訓練が必要だ。

とはいえ、オブジェクト指向の実装は、構造化や記号化をそのエッセンスとしている。抽象としてのクラスにはイデアがあり、インスタンスはそこから実体化される。このような「動物の目を通した人間的世界認識」というアウフヘーベンが、モードレスデザインの高次性であり、普遍性なのだ。

References / Related Articles

なお、この記事を書くにあたっては、sumim さんから多くの参考資料をご紹介いただきました。ありがとうございます。

Comments are closed.