マルスと「熟練が必要なUI」についての議論
JRの職員がマルスを操作する動画が話題になった。
この動画について、職人性を賞賛する立場と、UIとして問題があるという立場が対立していた。
nobkzさんのこの記事は、「熟練が必要なのはUIとして問題がある」という立場での記述だとおもう。
一連の話題に対して違和感を持ったが、違和感の源泉は明確で、「UIとしてよいかどうか」という立論自体に机上の論理以上のものにならないということもあるが、そもそも「マルスとはどういうシステムなのか」が議論されていないことがおおきい。
わたしもマルスについて名前は知ってはいたものの、具体的にはどういうシステムであるかは知らなかったので、少し調べてみることにした。
マルスについて
Twitter(X)で話題になっていたもとの動画はこちらである。
ここだけ取り上げてみて、マルスの良し悪しを論じるのは鉛筆を取り上げて絵の良し悪しを論じるようなものだとおもう。
次の動画は、駅員にとってのマルスの用途がよりわかりやすい。
駅員の業務は、目的地への経路を口頭でヒアリングし、検索・予約・発券することにある。現在はおもに新幹線の予約になるだろう。
おおまかには次のようなフェーズに分解される。
- お客さまから出発地と目的地をヒアリング
- 適切な経路と空席のある路線を検索し、提案する
- 承認が取れたら予約して発券する
いま新幹線の予約をする人であれば、これらが窓口対応でなくてもユーザー自身の操作によって成立することを知っているだろう。つまり、機械と人間は代替可能である。マルスを操作する駅員とは、それ自体が一種のユーザーインターフェースであり、エンドユーザーは音声を通じて予約・発券しているに等しい。
こういった業務はじつはいろいろなところに存在しているが、たとえばコンビニのレジ業務もその一つである。わたしがよく使うコンビニでは、有人レジと無人レジが向いあって存在しており、混んでいれば無人レジを使うし、無人レジでもいい場合でもなんとなく有人レジを使うことがある。スーパーの有人レジと無人レジの併設もこのごろよく見る。この労働について、最近わたしは「人間の認知能力を使った入力インターフェース」と名付けている。コンビニのコーヒーはセブンイレブンの場合はR(egular)とL(arge)だが、ファミリーマートはS(mall)/M(edium)/L(arge)であり、わたしはしばしばファミリーマートで「Rで」と言ってしまう。わたしの誤入力を人間の認知システムは適当に変換してくれる。つまりSサイズがでてくる。
みどりの窓口で、新幹線の予約を駅員に依頼するか機械で自分で予約するかは、その時の状況によるが、わたしの場合は機械で予約することが多い。次の図はJR鉄道情報システム株式会社のマルスの説明図である。
駅員も顧客もPC操作での予約もJR-NETに繋がっているのがわかる。新幹線の予約をしたことがある人ならわかるだろうが、使いやすいシステムではまったくない。とくにWeb予約システムは予期と実際の振る舞いがしばしば違うことがある。新幹線の発券機のまえで、操作がわからず、あるいは路線に迷って時間がかかる光景もよくみるものである。「人間の認知能力を使った入力インターフェース」のほうが優秀なのはあきらかだが(ただしこの「認知能力」は専門技能を必要とする)、このシステムは高価だし並列実行性にも難があり、容易にスケールしない。また、Twitter(X)で話題になった動画のYouTubeを注意深く見ると、ここで依頼している顧客はなにかしらの障害者であり、機械での操作が困難であるか、機械だと障害者割引に対応していないなどがあるのかもしれない。2番目に掲示した動画では、窓口の担当の方が、子供・老人・外国人など、鉄道移動や機械の操作に不慣れである人が安心して利用できることを目指していると語っている。人間は、アクセシビリティを担保するためにそこにいるのだ。
駅員にとってのマルス端末
ここは、自分があまり語れるようなポイントではない。駅員用のマルスを操作したことがないので、業務にとって最適かどうかの判断をつけようもない。
だが、動画を詳細に観察してみると、いくつかのことに気付く。まず、駅員さんの動作は「無駄のない洗練された動き」などとは程遠い。約3分の1くらいはリズムをとるだけで意味のない動作である。ここで発券しているのは京都から福井、福井から金沢の二つだが、おそらく「京都から金沢に行きたい」が元で、福井で途中下車する、という要望だとおもわれる。
駅員は、以下のような一連の操作をしている。
まず、出発地が「京都」、目的地が「福井」になっていることを見てほしい。いまから「駅逆転」というボタンを押そうとするところである。
「駅逆転」を押した結果、出発地が「福井」、目的地が「京都」になっている。
つぎに、おそらく目的地を「金沢」にセットするつもりで「金沢」を押す。
さて、これで金沢にかわるのかとおもうとそうではなく、目的地は京都のままである。おそらく、この端末は、左側に表示されている情報を更新するには、更新したいカラムを選択状態にしなければならず、そのカラムが水色になっているものが選択状態(更新ターゲット)なのだろう。それで、操作者は目的地の欄をタップして水色にし、再度右側で「金沢」を押し、目的地の更新をすることができた。
Twitterでは、この端末は熟練者にとって良いUIだという話があったが、果してどうだろうか。
わたしは、いくつかの理由でこのUIには問題がありそうには思った。また、熟練者のためのUIを志向しているわけでもないとおもう。この画面は、左側に操作ターゲットとなる情報が表示され、右がわに操作内容が表示される。左側はようするに発券する切符の情報である。上掲スクリーンショットの右側は「駅名」タブが選択されているが、「カナ検索」や「駅逆転」のような意味のレベルが異なる操作が混じっている。これは選択可能候補となる駅の数が増えたときにも一貫したUIを維持できるのだろうか。また、上掲の一連のスクリーンショットで操作者は操作を間違えたとおもわれるのだが、そのリカバリーに要した時間はおよそ0.3秒もかかっていないようにおもわれる。これは操作者がまさに「熟練者」であるがゆえに可能なのだが、やはりもっと良いUIを検討できそうな気はした(ただ詳細は結局やってみないとわからない)。ただし、操作ミスをしても基本的には安全側でのミスが中心であり、その安心感があるために積極的な手の運動が可能になる、などはあるのかもしれない(これは習熟のためには重要な要素である)。
このシーンは、おそらく顧客の要望は「京都から金沢に行きたい」「福井で途中下車したい」であるとおもわれ、それをここでは駅員は二つの切符に分解している。おそらく、そもそも「途中下車」という概念はシステムに存在しない。切符には乗車駅と下車駅の情報しかない。途中下車という概念がないのは、切符という情報についてまわる制約であってシステムの不備ではない。駅員がおこなっているのは、人間が自然言語で発した「途中下車」というニーズを、システムが解釈可能な「切符」という言語に翻訳する作業であり(「切符」とは、駅員含む電車交通システムが解釈可能な言語でなくてなんであろうか！)、手の運動がリズミカルであるかどうかはあきらかに非本質的な問題である。駅員のヒアリングを注意深く聴いてみると、ほとんどその翻訳にかかわることを確認していることがわかる。UIとは、人間がやりたいことをシステムの処理に変換して実現するためのものだとすれば、まさしく駅員こそが優れたUIとして機能しているのである。
予約台帳としてのマルス
そもそも、マルスの開発の経緯は予約台帳の代替にあったことは抑えておく必要がある。
指定席の予約は各地でリクエストされるが、予約台帳は管理センターで一括管理され、空席の管理など矛盾がないようチェックしてレスポンスを返していた。指定席の発券には30分くらいかかっていたらしい。それを背景としてマルスは開発されている。Wikipediaの記述を読んでも、指定席の予約システムとしてJR以外でも利用されているらしいが、予約管理システムである。マルスを経由して発券をするとき、この予約台帳への登録がおこなわれている。一般ユーザーが使うものではないのだから、「使いやすいUI」など問われる筋合いではなかった。分散的なクライアントから中央集権的な台帳への登録リクエストがあり、その整合性の確保と、空席の検索可能にすることが第一義のシステムなのである。それは業務が成立するための生命線であり、末端の従業員の操作が早いか遅いかはそんなにおおきな問題ではないだろう。タイピングの速度が早いか遅いかはプログラマーの生産性とほとんど関係がないのと相似である。
また、習熟という点から動画を見てみると、「UIに習熟が必要」というようなことはなさそうである。それは結局のところ順に入力していけば回答を出してくれるシステムなのだ。作業風景も、顧客からヒアリングをしながら順に入力している。「習熟」が必要になるのは、「切符」という情報構造の制約を常に意識することと、顧客の多様なニーズをいかにこの制約に押し込めるかということ、予約が埋まっている可能性を考慮して代替案を提出できること、などであろう。つまるところ、これは業務知識である。本来の問題は、「習熟」を不要とするようなシステムを開発するのかどうか、つまり業務知識がなくても業務がまわる構造物をつくるかどうかであるはずだ。これは表面的なUIの問題ではない、つまり画面が使いやすいかどうかは無関係だ。なぜならこの習熟が不要になるとき、この業務そのものがなくなるのだから。新人が1、2週間でトップスピードで仕事ができるかどうかもおおきな意味はない。なぜなら、全体で見たときに、みどりの窓口の現場駅員の作業が早かろうが遅かろうが、ボトルネックになるわけではないのだし、この業務の本体はアクセシビリティの担保のためにあるはずだ。作業速度などはあまり意味がなく、お客様と会話するときの情報パネル、そこからシームレスに予約・発券できるというようなことが重要であるようにおもわれ、それは必ずしも「作業的な」ものでもない。
個人的な意見を言えば、すべてのコンビニやスーパーから有人レジが取り払われる未来はあまり望んでいない。それがなぜかはあまり言語化できない。バズったマルスの動画をみたとき、これは90年代くらいの風景だろうかとおもったのだが、ノスタルジーというわけではなく、こういうものが無くなってほしいとはおもわなかった。別に会話するでもなく有人レジに並ぶとき、そこには「なんとなく」以外の理由がない。「駅窓口の向こう側 「マルス」操り切符をつくる職人技とは」の動画で、駅員の方がコミュニケーションを重視していることは「無駄」と切って捨てるわけにはいかないものを含んでいる。そのうちの一つはあきらかにアクセシビリティである。
Discussion
強く同意できる内容でした。マルスの背景なども詳しく書かれていて理解も捗りまして、ありがとうございます。
システムと人間が一体となってサービスを提供する形があり、それがアクセシビリティでもあるという考え方は素敵ですね。
究極はVisualStudioみたいなアプリにして、キーボードでコード入力して、入力補助があるような操作かなとも思います。
「ky（タブ）」で候補が表示されて、京都と入力されるみたいな。
「goto Kyoto from Kanazawa」だったら
「g（タブ）ky（タブ）f（タブ）ka（タブ）」で慣れたら1秒くらいじゃないでしょうか。
何億円も開発費にかけてGUIにしたのはよくわかりませんね。
合理的な効用面に着目してアクセシビリティ担保のために有人の対応が残って欲しいというのではなく、言語化できないもの（例えば人間としての全体性のような、曖昧ではあるがきっと我々が持っていると信じられているもの）のために、人と人とのコミュニケーションの手段が残っていて欲しいというのが素敵ですね 👍