GUIデザインのヘヴィネス、あるいはデザイナーとエンジニアの性質にみるソフトウェア開発の難しさについて
現代におけるソフトウェアやアプリケーションの開発では分業化が当たり前になっている。たぶんスケーラビリティなどが背景にありつつ、「良い感じのものをどう作るか」以上に「良い感じの組織をどう作るか」の観点が前景化してきたのだと思う。
そして、もはや大多数が疑うことすらなく参加しているこの分業体制を前提に、しばしばデザイナーとエンジニア（脚注1）の協業や連携の難しさが取り沙汰されるような印象だ。
現代では協業をなめらかにするべく設計された様々なソフトウェアが活用されているのに、この職種間における協業の難しさや課題感については、各所で目に入る記事などの感じだと「コミュニケーションで解決しました」といった対処療法こそ見かけるものの、全体として上手くいっているような印象はあまり受けない。
なぜそうなってしまうのか。どこに問題があるのか。単にお互いの知識不足でしかないのか。もちろんそういった側面もあるのだろうけど、もっと根本的な原因があるのではないか。
（脚注1: 最も多く使われている印象があるのでこの記事ではエンジニアと表記している。デベロッパーとかプログラマーとか読み変えてもらっても構わない）
デザイナーとエンジニア
筆者が今この記事を書くのに使っているのはMacBook Proだ。この記事を読んでいるデザイナー・エンジニアの皆さんも多くはMacやiPhoneを使っていて、あるいはWindowsやAndroidなど、大まかにはGUIのOSで読んでいるはずだ。
代表的なGUI環境のmacOSを例にすると話は80年代まで遡る。初期の、まだ名前がMacintoshだったころにはデザイナーとエンジニアで明確に職種が分かれた開発体制で作られたわけではなかった（らしい）。Macintoshのアプリケーションを作るエンジニアはソフトウェアの構造や振る舞いなどGUIをデザインしていたし、デザイナーもFinderなどのアプリケーションを実装まで手がけていた。というか、そもそもデザインと実装が明確に分けられているわけではなく、近しい部分もそうじゃない部分もごちゃ混ぜに絡み合っていた。
もちろんBill Atkinsonのように矩形ウインドウの角を丸くする重要性をSteve Jobsから力説されてもなかなか腑に落ちなかったけれどMacPaintやHyperCardなど素晴らしいソフトウェアを手がけた「構造的なデザインが巧みなエンジニア」だっているし、逆にアイコンデザインにおけるSusan Kareのような「イラストレーター・アートディレクター的な面が色濃いデザイナー」みたいな得意分野の違いはあった。けれども、今日のようにデザイナーとエンジニアが明確に分かれていたような様子はいくつかの文献を漁っても見えてこない。
かといって「現代の分業をやめて過去に戻すべき」でもないだろう。現代には現代なりの物事や事情がある。しかし歴史的なオリジンを参照することは、自分達が今どんなものをどうやって作るか考えたり、自分達が作っているものを再定義していく上で最も効果的かつ重要だし、その歴史があったからこそ今こうしてMacを使えている。
そういえば最近この辺りを題材にした記事見かけましたね。どんどんこういった記事増えてほしい。
CUIの自動化とGUIの自然化
今ほど明確にデザイナーとエンジニアが分けられていない状況で作られたMacintoshはMacと名称を変え、今でも広く使われている。
80年代まで、パソコンにおける操作体系の主流はCUIが主流だったのに対して、MacintoshはAppleがGUIへ本格的に挑戦し、GUIが世界へ伝播する流れの一翼を担った、GUI黎明期のOSだった（その前にもLisaとかあるけど）。
CUI: 黒い画面に流れてくる大量の白い文字を読み、キーボードでコマンドを入力して操作する
GUI: 白い画面に現実世界を模した書類やフォルダアイコンが並び、マウスやタッチパッドなどで直接操作できる
といったあたりが大まかにCUIとGUIの特性として認知されている。
コンピュータとして大量の情報をまとめて処理する上でCUIは威力を発揮したが、コマンドなどプログラミングを学習しなければ操作もままならない。ユーザーはごく一部のプログラマー・ハッカーなどに限られた。
その一方で、個人向け（パーソナル）コンピュータを目指すかたわらで研究・開発を進められたのがGUIだ。GUIは画面に映されたデスクトップから書類やフォルダのアイコンなどをマウスで直接選択し、開いたり操作できる。デスクトップに並んだアイコンはさながら机の上の書類や本などのような現実世界に見立てられることであたかも自然化しており、ユーザーは現実世界での概念と接続した感覚で操作に馴染みやすくなる（ユーザーイリュージョン）。プログラミングの概念やコマンドよりも馴染みやすく学習しやすい操作体系なので、パソコンの普及に一役買ったと言われている。XeroxのSmalltalkが最も有名な原始のGUI環境で、そのSmalltalkを参照して作られたのがApple Macintoshだ。
先にGUIとCUIそれぞれの性質を箇条書きしたが、別の視点で捉え直してみると、表示や入力操作のレベルだけでなく作業に対する意識や概念のレベルで大きな違いがある。その代表的な違いとして、CUIにおける作業は「直列化」「自動化」の側面が色濃くなっている。
CUIでコマンドを入力するとき、例えば「削除」などどんな処理をするかの動詞をまず入力し、次にその対象が何なのかの名詞を入力する。英語における命令形式の構文だ。動詞には複雑な条件を設定することも可能だし、名詞もさまざまな範囲指定が可能だ。そしてコマンドを実行し「裏側」で膨大な計算が行われることで、大量の情報をまとめて処理できている。
一方のGUIは
フォルダ（のアイコン）をクリックして開く
書類をドラッグしてゴミ箱へドロップする
など、現実世界のように「ものを手にとってからそれで何かする」を繰り返していくことになる。「あらかじめものを一箇所に集めておく」とか、人間の工夫次第である程度の効率化も可能だが、基本的にはアナログ味をともなったファジーで直接的な作業となる。逆にCUI的なコンピューティングの世界は、さながらベルトコンベアのように物事が直列的・自動的に処理されるシステムで成り立っている。そして人間は、直列化されたシステムの実行ボタンから間接的にシステムを駆動させるためのコマンドを発する。
実のところ、このCUIとGUIの違いには「モダリティ」、恣意性の有無が密接に現れている。
道具にとってのモダリティ
例えば、現実世界では水を注いだコップを傾けると中の水がこぼれるだろう。そこに人為的なモダリティは希薄で、行為と結果は自然的で直接的な関係になっている。GUIもこれに倣ったような形で、直接操作によって行為と結果の直接的な同期関係が描かれている。ところがCUIの場合、「水がこぼれない方がいい場合もあるよね」といったモダリティによって条件分岐がなされ、しばしば直列的なシステムが形成されたりする。
これだけ聞くと「CUIの方が便利だし気が利いてるのでは」と思われるかもしれない。実際に、今この文章を書きながら手元のグラスを危うくひっくり返しかけた。手首がグラスに接した瞬間に「中の水がこぼれますが大丈夫ですか」とモーダルなダイアログで確認されたらどんなに良かっただろうか。
GUIでは現実のようにものを直接操作する。すべてのものがただそこにあって、どう使われるかについての関心が切り離されている（オブジェクト指向的な性質だ）。つまりモダリティによる「〇〇の時だけはこうなる」みたいな、通常時と違う行為・結果の「モード」があまり介在していない。モードがないGUIの性質はモードレスなどと呼ばれていて、一方でモードの多いCUIはモーダルだ、と大雑把に区分できる。
そして、このモードレス性（Modelessness: モードレスネス）をソフトウェア設計の原則として取り上げたのが、Macintoshのソフトウェアにおけるデザイン指針が記されたガイドライン「HIG」こと「Apple Human Interface Guidelines」だった。
システムが置かれている状態により処理内容が決定される場合、"モード"という概念が必要となります。モードが存在するシステムでは、ユーザ側の操作が同一であっても、その操作がどのモードで行われたかによりシステム側の反応は変化します。通常、ユーザが行うことのできる処理は各モード内で許容されている範囲に制限されます。
モードレスオペレーション（p.12）
ソフトウェアという道具のデザインにおいて、モードの多い操作体系ではその恣意性を人間が推測しながら使うことになる。モードが少なく行為と結果が自然的・直接的な関係になっている操作体系と比べると、使用者にとって予測や学習がしにくい存在となる。さらに、直列化されたシステムは自由に変更したり融通が利きにくい。必然的に、システムが万全の状態でないと実行しにくいし、万全の状態かどうか確認するためのステップや仕組みが増えて、人間が推測すべき情報量が肥大化していく。
日常生活でモードの概念が使用されることはほとんどありません。したがって、モードの存在するコンピュータ環境は不自然で異質なものに思えます。
モードレスオペレーション（p.12）
現実世界やGUIでは、予測しにくい恣意性があまり介在していない。だからこそ、人間はものの性質を簡単に学習でき、それらを組み合わせて自分好みに作業できる。手元のグラスはお盆に載せれば水がこぼれても被害を抑えれるし、そもそも手が不用意に接触しないよう遠ざければ済むよね、といった具合に。
スケートボードはモードレス
そんなモダリティとモードレスネスの対比が印象的に描かれた作品がある。また80年代に遡ってしまうけれど、映画「Back to the Future（BTTF）」だ。
シリーズ1作目冒頭のシーンが印象的で、まず部屋の中で大量の時計が並んでいる。タイムマシーンでの時間遡行を扱った作品としてとても象徴的なカットに感じられる。
そのままカメラは「缶詰ドッグフードの開封から盛り付けまでが自動化された機械」が動作する様を捉える。
この機械は缶詰の開封と餌入れへの盛り付けが直列的に自動化されているのだが、そうまでして実装された割に肝心のドッグフードは盛り付けされたまま手付かずで放置されており、実用性に欠けているような描写がされている。単に犬がお腹を空かせてそうなときに手動でドッグフードを提供すれば済むだけに思えるのだが、開発者のドクはシリーズを通してこういった自動化が好きな感じに描かれていて、その中でも特に印象的な一幕が、シリーズ1作目の冒頭にプロットされている。
こういった直列的・自動的な仕組みに、それを作った人間側が手を焼くという滑稽さを通して機械文明や近代資本主義を風刺する手法は「Rube Goldberg machine」と呼ばれる。手法のオリジネーターであるアメリカの漫画家ルーブ・ゴールドバーグに由来しており、チャップリンの作品などでも用いられている。近年では風刺的な意味よりも、ピタゴラスイッチのように仕組み自体が注目を集めているけれど、BTTFのそれはルーブ・ゴールドバーグ以降の機械文明批評の系譜に位置しているように映る。
続くシーンはどうだろうか。部屋に主人公のマーティが入ってくると共に、BTTFにおいて重要な舞台装置であるところのスケートボードが部屋を横切る様子が、画面の横幅を一杯に活かして映し出される。
この作品におけるスケートボードは、先のルーブ・ゴールドバーグ・マシンと対極の、自由な道具として描かれている。例えばシナリオが終盤に差し掛かる頃、追手から逃げるマーティは通りすがりの子供が乗っていたキックボード状の乗り物を拝借し、取手を取り除いて板と車輪だけのプリミティブなスケートボード形状にした上で乗りこなす。BTTF屈指の名場面だが、ここでも道具自身がどのように使われるか関心を持たないことでモダリティを抑制し、さまざまな使用者に高い道具性で適応する、モードレスでオブジェクト指向的な道具性が浮き彫りになっている。
この映画が世に出たのは1980年代だけれど、奇しくも同時期に、同じスケートボードを用いてモードレスネスを表したのが「Apple Human Interface Guidelines」だったりする。
プログラムによるハンディキャップのサポートは、シンプルでコスト的にも納得のゆく範囲の変更で実現できる場合がほとんどです。これに加え、変更後のプログラムが一般ユーザにとっても、より使いやすいものとなるという副次的な効果も生まれます。このことは、歩道に設けられた滑べり止めは杖や車椅子を利用する人々への配慮であるのにもかかわらず、乳母車を押す人の助けになったり、スケートボードで遊ぶ場合に利用されることさえあるのと同じことです。
ハンディキャップを持つユーザへの対応（p.16）
この項で主体として例示されているのは歩道の滑り止めであり、スケートボードは滑り止めに作用する側だけれども、「恣意性が低く使用者それぞれに適応するモードレスネス」が表れた点はBTTFと重なっている。スケートボードはモードレスネスやオブジェクト指向性の象徴といっても過言ではないだろう（いや、過言かもしれないけど）。
BTTFに再び目を向けると、映画という連続的なメディアにおいては作品全体への印象に対して冒頭部分の影響が比較的大きいはずだ。そんな映画の冒頭で「直列的に自動化された機構」と「オブジェクト指向的でモードレスな道具」の対比が表現されていることは偶然でも筆者のこじつけでも何でもなく、直列化・自動化されたシステムへの風刺が作品全体に通底しているものだと捉えるのが自然ではないだろうか。
エンジニアの自動化文化
そもそも、直列化だとか自動化とはどういったことなのだろうか。
一般的には「人間の作業を減らすため、人力・手作業で行っていた作業をITなどの技術を使って置き換える」などと説明されている（のをよく見かけた気がする）。
人間は現実世界のものを多種多様に組み合わせ、繋げて、何かしらの作業なり仕事なりをしている。そんな作業を「Aが完了したらBをやる」といった具合で直列化していき、何かしらのトリガーによって自動的に作業が進むような仕組みを構築することこそが、一般に「自動化」として知られるところだろう。
ことITの世界において、自動化はエンジニアリングと密接になっている。エンジニアの美徳として挙げられる「怠惰」は自動化などと繋がっていて、例えば手作業を減らすために自動化への労力を惜しまないのが「エンジニア文化」と言われていたり、概ねエンジニアは自動化をしたがる傾向なのではないだろうか。
BTTFのドクはエンジニアなので（じゃなくて、正確には科学者なんだけども）、直列化や自動化に労力を割き、自動ドッグフード開封マシンみたいなものを作る。そして、さらに先鋭化した結果タイムマシンをも発明してしまう。
ここまでGUIやそのモードレスネスを持ち上げつつ、直列な仕組みや自動化を批評する文脈を連ねてきたけれど、まず前提として、自動化は文明化に欠かせない要素だし、モダリティも重要だ。全く恣意性のないモードレスでプリミティブなものだけの世界を目指すと、原始的な時代へと逆行してしまう。近現代的な文明は、人間のモダリティや直列化・自動化による高度な処理の仕組みによって成り立っているはずだ。さらに、モダリティのない自然的で原始的な世界では、適者生存、いや強者生存の枠組みからこぼれ落ちた人々が蔑ろになりかねない。そこで「なるべく多くの人が生きれるように」といった恣意性で駆動される仕組みによって、包括的な人間社会が実現しやすくなっている側面があるのではないか。
実際、BTTFシリーズ2作目ではスケートボードが浮遊している未来が描かれる。プリミティブな道具だったスケートボードにも機械文明の波が押し寄せた形だが、「水上では上手く動作しない」モーダルな性質も映し出されている。それでも水面を蹴って前進することは可能なわけで、スケートボードが宙に浮かなかった世界から浮く世界へ、確実に一歩進んでいる。
GUIデザインのヘヴィネス
やたら壮大な感じになってしまった。恣意性を抱えた仕組みが文明に必要なのは明らかだ、と思われるけれど、一方で、文明化ということは自然的なものの在り方からは遠ざかる。現代的なソフトウェアにおけるGUIの設計においては、モダリティとモードレスネス・オブジェクト指向性・道具性との相性の悪さについても意識されなければならないだろう。
エンジニアの自動化文化をベースとした取り組みから、直列化された処理を間接に実行するボタンが並んだ、GUIに似て非なるUI的な何かが世に出ているのを見た経験はないだろうか。これは単に「役に立たないものではなく役にたつものを作ろう」とか、よくある「モーダルとモードレスを適切に使い分けよう」といった話ではない。CUIとGUIのパラダイムのレベルで別物であり、そんな「使い分け」ができる人は、GUIにも関わらずその観点が見受けられないCUI的なプロダクトだったり、不可解なモードでがんじがらめになったプロダクトを良しとしないだろう。
基本的に人間が関わる以上、物事はモダリティを帯びていく。デザイナーが一人で作る物事であればモダリティの増大を最低限に留めることができるかもしれないが、今日の複数人による協業では、ましてやデザイナーとエンジニアの協業ではどうか。GUIのデザインにおいてはGUI本来のモードレスな道具性をベースにするのが自然になるし、その上でどうしても世界を一歩進めるために直列化・自動化の仕組むを作ること。そこでモダリティがもたらす文明的・未来的な何かと、それによって損なわれる何かに自覚的になること。これはエンジニアだけでなく、まずデザイナーから考えなければならないように感じている。
BTTFの終盤で描かれる、黒人音楽から影響を受けたロック音楽にのめり込んでいるマーティが、過去の黒人バンドへ音楽的影響を与えてしまう循環参照のようなシーン。黒人と白人の音楽的な（そして人種的な）差異や矛盾を抱えたまま転がっていくロックンロールのように、デザイナーとエンジニアの協業も、モードレスネスとモダリティという矛盾同士を抱え合わせて転がしていくしかないように思えている。なんてヘビーな話なんだろうか。そこに「使い分け」のような分かりやすい道筋はきっと無いし、しかしそういった分かりやすさ自体がある種のモダリティであることにも自覚的になれるはずだ。
最近では「AIと対話する形式のプロダクトが世界を席巻していくのでは」と予想する言説を見かけることも少なくない。いまのところLLMを活用したUIは概ね対話形式のものが多そうで、CUI的な性質を帯びていると言えるだろうし、人間と物との自然な関係を指向したGUIとはさらに距離を置いた方向性だ。
今後人と物との関係がどうなっていくか、UIデザインに携わる人がどれだけモダリティへ自覚的になれるかにも大きく影響されるだろう。2020年代のソフトウェアを、GUIを、どう作っていくか。少しでも内省のきっかけとなったり、デザイナーの能動性を喚起するのにこの記事が参照点となればいいと思う。
この記事はGMOペパボデザイナー Advent Calendar 2022の24日目のコンテンツで、itoh4126が書きました。クリスマスイブにふさわしい面白さのある話だと感じてもらえたら嬉しいし、そうでなくてもここまで読んでもらえたのなら何よりです。
この記事が気に入ったらサポートをしてみませんか？