熟練が必要なUIについて、それがよくない理由と、UIの慣性について
久しぶりに記事を書く。最近マルス端末のUIについてツイートがあった。
この件に関して、UIについてやUXに対して日々やってきている人間は「ダメなUI」という認識の人が多いように思う。一方で、システムの開発者にとってはこれは、その認識でない人間が多いようだ。なので、この辺を私なりに意見を書いておこうと思う。
まぁ、これはいつもなのだが、書いていることが散らかってる。基本的に音声入力のメモなので、読みにくいかもしれないが読んでくれ参考になれば幸いだ。
熟練が必要なUIは基本的によくない
まず、基本的に熟練が必要なUIはそもそも良くないって話をしていく。順番に話していこう、まず、熟練が必要なUIが支持される理由を考え、それに対して、批判していき、なぜ熟練が必要なUIはダメかを語ってみよう。
熟練が必要なUIが支持される理由
その前に、こういった熟練のUIが支持される理由についてかいておこう。それは主に2つの理由があるように感じる。
熟練することで効率化する？
まずこのようなUIが支持される背景に、第一にこのようなUIは、UIについて熟知して、慣れていって達人になっていくことで、業務がより効率化していくってことがあるだろう。最初は大変だけど、使いこなすと、快適に効率的になりうる。おそらく、複雑なUIを使い倒した経験がある人であれば、あるいは、複雑なUIを使いこなしている人間を目の当たりにしたことがある人間なら同意する人は多いように思う。
業務がそもそも複雑だから
第2にタスク自体がそもそも複雑なプロセスになっているからということある。タスクが複雑だから、当然システムが複雑化するのも当然というわけだ。プロの使うツールは当然、素人がぱっと理解できるほどのUIにはならなだろうと。
こういった理由に対する私なりの意見
さて私なりの意見を述べていこう
効率性に対して
習熟コストを軽視するな
私なりに「効率的」になるということに対して述べていく。まずは、習熟のUIが効率的だという意見に対して、習熟コストを無視したり軽視していることが多くあるということである。本来、効率的に操作が可能な習熟までにかかる時間の分だけ、習熟するUIは効率的ではない。極端な例だが、高速にタスクをこなせるが習熟までにたとえば10年かかるものがあったとして、それよりも若干低速にタスクをこなすが1週間で習熟することが可能なUIの方が全体として効率的なことが多い。
ほんとに効率的になってる？
第2に、慣れたら効率があがるという点である。実際のUIで、そういう意見を目にしたとき、基本的に私は懐疑的になることが多い。そういうUIを私はよく観察したりするのだが、見てみると、慣れたからそのUIのノービス（初心者）ユーザーよりも効率的だとか、単に快適になった程度のことでしかないことが多い。達人の素早い操作に圧倒されて、効率的に作業したかのように見えてしまうことがあるかもしれない。
このとき大抵の場合「じゃあもっと改善した、初学者にもとっつきやすく、エキスパートにも効率的なUI」について考える余地があることが多い。経験上「エキスパートのための敢えてノービスがとっつきにくいUIに設計している」ということはほとんどないのである。基本的にはノービスのとっつきにくいUIは「UIの設計に関する考慮が足りない」というだけのことが多い。それは、悲しいかな現実にはUI設計に関して余裕がないことの方が圧倒的に多いのだ。
ひとつ例を上げよう、日本語入力を考えてみよう。たとえば、キーボードとフリック入力だ。キーボードとフリック入力だったら、フリック入力の方が初心者にとって容易だ(異論はあるかもしれないが)。キーボードは不自然なキー配列を覚えてい、5本の指を協調させてタイピングする点で難しく、一方フリックは自然は配置であり、1つの指で文字が入力できるという点で比較的容易だ。一方、キーボードの方が高速にタイピングできると信じられやすい。わたしもそう考えてた時期があったが、以前、フリック入力の方が早いと結論づけた記事があった。
もちろん、この計測は非常にラフなもので、たとえば、キーボード入力の方が実はそこまで熟達していないってことも考えられるかもしれない。
さらに、キーボードと音声入力を考えてみよう。音声入力の方が明かないノービスには容易だ。だって喋れば入力できる。そして、速度も音声認識の方が早い。このような感じで、実際にはよりよい入力がありえる余地がある。
「慣れるUI効率的」というより、「慣れないとそもそも使えない」類いのものが多い。あるタスクを遂行するためのUIを見せられたときに、私はより改善した形を考えてしまうのだが、ほとんどのユーザーは「これ以外に考えられない」と思ってしまうのかもしれない。そして、いびつな形のまま使い込み、「慣れたら快適」のUIができてしまう。このあたりは、あとで書こう。
業務自体がそもそも複雑だからに対して
業務が複雑であるから「UIに習熟が必要」に必ずしもなるわけではない
習熟が必要なUIというのは、UIの配置やUIのインタラクション、振舞がそもそも複雑であり、いくつかのやるべきタスクに対する適切な操作方法を習熟しなければならないものである。そのシステムを使いこなすために、UIの用語を余計に覚えたり、あるタスクを遂行するためのUIがそもそもどこにあるのか覚えなければならなくなる。これは、あくまでUIの設計ものであって、情報設計だったりすれば改善できる余地がある。
UIの複雑性は、業務とは別だ。むしろ、複雑な業務であればあるほど、「UIの習熟」はなくすべきだ。UIが複雑なお陰で、余計にUIについて学習したり、また操作エラーの対応だったり、が増えて、さらに業務が複雑化する要因になりえる。そうじゃなくて、必要な業務の知識を覚えてしまったら、自然と使いこなせるようにUIを設計すべきであり、ただそれらがほとんどの場合それらが達成できていないから、UIの知識が必要になるだけである。
ただし、もちろん、業務知識がなければ一見、複雑に見えるUIも存在する。けれども、それはその知識は本来必要な知識であり、むしろ「UIを使いこなす」ことが業務自体の深い理解につながることもありえる。その意味では、必要な複雑性たりえる。
そもそも熟練が必要になるような、複雑な業務が良くないこともありえる
このツイートに近いことでもあるのだが。(というかこの記事を書いていたら、わりと良いツイートを深津氏をしていた)
UXデザインを考えてみると、そもそも、複雑な業務である必要はどこにあるのか?みたいなところから考えるべきであって、複雑で習熟が必要な業務経験設計自体はそのままでいいのか?という視点もある。実際にユーザー調査をどんどんやって、理解を深めていくと、こういう業務プロセスに対する改善点が見えたりする。
さらに言えば、こういった業務プロセスの改善をせずに、そのプロセスをむしろ支援するような、UIを設計してしまうと、そのUIを機能させるために、その業務自体を変更できなくなってしまうこともある。つまり業務自体は「そのUIを使いこなす」ということになり、手段が目的化してしまう。
プログラミングと複雑性
そういえば、習熟させるUIがダメなら、プログラミングエディタは全部だめだ！という意見がある。これに対しても後ほど述べるかもだが、プログラミングの習熟を考えると、例えば配列や木造像、グラフなどのデータ構造の構築や操作、状態管理などを自体はそもそも複雑で、これらはプログラミングさせるUI自体の複雑性とは関係がない。
また、プログラミングのためのエディタは実はシンプルだ。VSCodeなんかをみるととても洗練されているだろう。EmacsやVimが習熟すること自体は実はプログラミングの習熟と全く関係がない。
UIの慣性：「慣れた」UIは固定化する。
こういった、習熟が必要なUIの最大の問題点は固定化しやすいところにある。キーボードの 「QWERTY」配列なんかはその代表的な例である。あの不自然な配列が、未だに使われているのは、古いタイプライターからの歴史的な経緯であって、多くのユーザーがそれを使ってしまっているので、今更抜本的に変更するなんてことはできない。
そしてそのUIに「親しみ」を持ってしまう。EmacsやVimははっきり言ってUIとして最悪だと私は思う。はじめにそれを覚えてしまったが故に、「そうあるべき」だとエクストリームユーザーは思ってしまう。私もEmacsユーザーでSKKを利用している分、それらに愛着を持ってしまう。これらの熱心なユーザーの中には、テキストの編集やプログラミングをより快適にすること自体が目的化する。悪いことではないが、過剰さを私は感じてしまう。Emacsを快適にするためにEmacs Lispに対して書いた時間のことを考えると、正直非効率だ。
テキストプログラミングの慣性
プログラミング言語もそうである。多くの人は、テキストプログラミングを最初に覚えてしまい、テキストプログラミングこそが効率的にプログラミングできるのであると考えてしまう。テキストプログラミングこそが、プログラミングを習熟するのに必要不可欠だと考えてしまう。そして、プログラミングの体験の改善は、テキストプログラミングの構文や機能設計の改善になる。そして、多くの人がテキストプログラミングの改良を考えて、テキストプログラミング言語が発展してしまう。
一方で、私はテキストプログラミングがプログラミングにとって効率的だと考えていない。なぜ、私はそのように考えているかと言えば、私のプログラミングの初体験がMaxであり、データフロー型のビジュアルプログラミング言語から私のプログラミングのキャリアが始まっているからだ。そういう私にとっては、現状では政治的に仕方なくテキストプログラミングをしているだけであり、いつももっとより良い形があるのになと考えてしまう。私にとってプログラミングで重要なのは構造であり、文字列の流れではない。
UIを習熟したいわけじゃない。
結局のところ、UIの習熟が問題になるのは、タスクの遂行や課題解決、問題解決のための手段が目的化しやすいところにある。多くのユーザーはEmacsに習熟したいのではなく、テキストを編集したいのだ。エクセルやTableauをマスターしたいのではなく、データを集計・分析したいのである。よく「ドリルが欲しいのではなく穴が欲しい」という格言があるが、これはまさにその通りである。
より良いUIのために
UIは使いやすさと効率性を両立させることが理想である。UIの改善は常に進化し続けるべき課題であり、熟練を要するUIはそれを阻害する要因になりうる。私は、できるかぎり、ノービスからエキスパートまで、ストレスなく快適につかえるUIが理想的だと考えいて、ノービスにとってとっつきにくいUIは改善の余地がある。「使いこなせたら快適だよ」とか「プロの使うUIは違うんだ」とかいう言葉で、初学者の使いにくさや複雑性を言い訳にするべきではない。
追記: 楽器の習熟について
そういえばDanさんからこんな意見を見た
これについて追記しておこうと思う。つらつらと、私の思考を書くので読みにくいかもだが。
陸上競技、ダンス、歌
まずこのような楽器の習熟を言われたとき、私自身が陸上競技をやっていて、現在はダンスを趣味にしているのもあってこれらのことについて考えしまう。なぜなら、これらは、道具なんてまったくないのにもかかわらず「熟練」があるからだ。あえて「道具」を考えていいのは、服、靴(スパイクやダンスシューズ)、地面(床)である。陸上競技なら、それに加えて、スターティングブロックや、投擲種目の投擲物(砲丸、やり、ハンマー)、棒高跳びの棒などが考えられるが、シンプルにスターティンブブロックを使わないトラック種目、を考えてほしい。
そこにある「上達」とは、基本的には、筋肉を発達させたり身体の動かしかたフォームなどの「身体的上達」と、陸上においては予選は流して走って本番は本気で走るみたいな戦略、ダンスなら音楽や表現的なところの理解に対する、「知性的や感性的な上達」がある。
これらの上達はそもそもそれ自体が目的なことがある。つまりそもそも、これらの分野においては「上達」=「目的」であり、手段ではない。いや「目的」だとしっくりこない。目的よりも、欲求に近いなと考える。上達こそが欲求そのものであるのだ。
マズローの成長欲求
ここで、私はマズローの成長欲求を思い出す。マズローは近年否定されていたりするのだが、それは置いておいて、わたしとしては、マズローの欠乏欲求や成長欲求の分類の言語化は非常に有効だと考えている。つまり、人間には潜在的に成長したいという欲求がある。ちなみに、成長欲求はマズローにおいては自己実現の欲求であり、それ以下の低次の欲求(安全の欲求、生理的欲求、承認欲求など)は欠乏欲求だと分類されている。
たとえば、ゲームにハマる理由の一つが成長欲求だと思う。ゲームは「もっとうまくなりたい」「もっとうまくやりたい」という欲求を刺激する。格闘ゲームにおいて、複雑なコマンドを入力できて、上手くコンボを決めたときは嬉しいものだ。音楽ゲームやアクションゲームにおいても、高難度で複雑な課題に関して、昔できなかったのが、だんだんできてくるのに楽しさを感じるだろう。
楽器について
楽器はむしろシンプル
では、楽器をUIとしてみたとき、私が思うのは、楽器の上達には、「楽器の使い方そのものの上達」「身体的な上達」「知性的や感性的な上達」 など、さまざまな要素がありそれらは、道具の複雑性の理解における上達に留まらない。むしろ、楽器は道具としてはシンプルなUIだと私は考えている。ドラムなんて、スティックで叩けば鳴るわけだし、ピアノは鍵盤をたたくだけで良い、ギターは弦を弾くだけ。金管楽器は鳴らすこと自体がむずかしいが、それは身体的な発達に近いように感じる。そこに楽器をならすインタラクション自体には、たとえば状態の複雑などが全くない。
そもそも音響現象、音楽、音の知覚は複雑
そもそも楽器は音響現象をコントロールする道具だと考えられるが、そもそも音響現象、音楽、音の知覚のしくみ自体が複雑なのだ。そこは、「知性的や感性的な上達」に分類されるように思うが、ともかく、うまく楽器演奏するには、それらの複雑性の要因が大きい。
楽器もまた上達こそが欲求だ
楽器もまたマズローの成長欲求みたいなもので、うまく演奏すること、自分の表現したいことを表現すること(自己実現欲求)であり、それは成長欲求である。それを満すことが目的のものであり、課題解決のための道具ではない。
人間としての成長欲求は無視してはいけない
以上のことから、私がふりかえって思うのは、仕事としての成長欲求自体は否定してはいけないということだ。成長欲求があるからこそ、生活のために仕事をする以上の仕事の価値を与えうる。UIとして考えるなら、適切な課題解決をしつつ成長体験を設計させることが重要なのではないかと考える。
成長欲求と社会的な貢献の両立
また、成長欲求は個人の欲求だ。仕事は、それだけでなく、社会のニーズに答えて課題解決をしなければならない。そういした従業員の欲求と、顧客の欲求両面を考慮したUIやシステムの設計が求められるのではないかと思う。
「うまくやりたい」は否定せず、「うまくやらなければならない」はよくない
ここで重要なのは、成長自体を要求することだと思う。「うまくやりたい」と思うから、満足するのであって、「うまくやらなければならい」状況は単純なストレス要因だ。私がUIの習熟がよくないというのは「うまくやらなければならい」という状況自体をつくるな!という意見である。
EmacsやVimを私がつかっている理由
VimやEmacsは前段で盛大にDisっているが、一方では、未だにそれらを使っている。なぜなら、それらの道具は楽しいからであり、成長欲求を満たしうるものだからだ。それはとても個人的なことだ。実際に初めてプログラミングをやる人には対しては洗練されたVSCodeをつかわせる。それは使うのがとても容易だからだ。しかし、彼等にもし仕事に関して余裕がでてきたら、EmacsやVimを試してほしいとは私は思っている。たのしいからな。
追記2： マルスの自体のUI評価
そういえば、冒頭にマルスの話題に触れながら、あくまで一般論的になってしまったので、一応マルス端末についても他人のツイッターを引用しておく。これとほぼ同意見である。(記述、忘れてたのと、JRの業務自体の複雑性の認識あるよねみたいなので甘くなった。)
また、天重さんの記事が大変素晴らしいので読んでほしい。
Discussion
筆者の意見と同じく、UIDやUXDをちゃんと勉強してきた人は概ね同じ感想になるのかなーって思った。
個人的にはこのUIは難しそうに見える時点でダメなUIだと思っていて、難しそうに見えれば習熟するためのモチベーションが下がるし、やる前から苦手意識を覚える人がいるだろう。いわゆる予期的UXが悪い状態。
（もちろん、実際の業務内容を知っている方がUIの良し悪しを正確に判断できるが、簡易的に判断するためにはXの動画だけで判断できると思う。実際、あれを見たほとんどの人は難そうなことをスピーディーにやる熟練の技すげーって思ったんじゃないだろうか）
また、これからの日本の業務機器UIはより多くの人が使えるUIにした方が良いと思っていて、習熟度の高いUIというのは当然誰でも使えるようになるわけではない。これから人口がさらに減少していく日本では、例えば10人中4人できていたことが、5人中2人しか出来なくなっていく。
そうなっていくと人が休んだ時に誰もこの業務ができないみたいな確率が増加していく。
そんな状態よりかは5人中4人できるUIの方が、持続可能で良いんじゃないかと思う。