書き忘れました。マンマシンインタフェースについて一言補足です。この表現が「マン」という単語を使っているから差別的であるという趣旨で、最近はヒューマンマシンインタフェースという言い方を提唱している方もおられます。でも、個人的には今更「マシン」か、って気がします。それにー、過去の動きを歴史として語るのであれば、それは「当時」使われていた言葉をむしろ使うべきじゃないか、とも思ってます。

さて今回は前史の二回目、ユーザインタフェースの時代についてです。コンピュータとのインタフェースが重要なものとして認識されるようになり、特にソフトウェアとの関わりが大きくなってきた時代。その時代について、ここではフィードバックの話題を取り上げることにしましょう。

フィードバックが重要視されるようになったのは、ソフトウェアの働きがポイントになってきて、インタラクション、つまり相互作用(ぼくは「やりとり」という和語を使うこともあります)のあり方が重要になったから。

人間だってそうですね。ヒトに何か話をしていて、その人が虚空を見つめ口あけてポカーとしてたらムッとする。おい、聞いてんのかっ、とポカリの一つもやってしまいたくなるでしょう。反応してくれないでもアクションをしてしまうのは仏像とか墓石の類。お祈りしても言葉をかけても実際には何もフィードバックは帰ってこないけど、それでもヒトは満足できる。むしろ余計なフィードバックがないからいいのかもしれないし。こういうのを僕は勝手にハイパーアクションと呼んでます。超越的相互作用という感じかな。

鉛蓄電池を充電フロートする方法

基本的にヒトは「やり」をしたら「とり」を期待します。「とり」があって次の「やり」が決まってくる。いわゆる対話型システムでもそうですが、もちろんそうした側面はソフトウェアに限らない。ハードウェアインタフェースでも同じこと。ただ機械的インタフェースの場合には、動かせばそれなりに連動して動いてくれる。メカニカルに結合されているからです。ペダルをこいでるのに自転車が動かなくなったとしても、見りゃすぐにチェーンが外れていることは分かります。機械的インタフェースはその点でわかりやすい。シンプルです。もちろん自動車やコピー機くらい複雑になるとその機械的部分についても理解は大変になりますが・・。それに比較するとソフトウェアというのはブラックボックスとしての情報処理システ� ��を媒介にしているから、そう簡単には処理の様子をのぞくことができない。「やり」に対していったい何が起きているのかがわかりにくい。とてもわかりにくい。そこでフィードバックが重視されるようになったのです。

インタフェース設計のガイドラインとして二段階のフィードバックを設定することが推奨されています。これはユーザビリティガイドラインという形で現在も継承されています。つまり、ユーザがなにか「やり」、いやそろそろアクションといいましょう、それをしたら、まずはアクションがやられたことに対する「とり」、つまりリアクションをすること。アクションがなされたことを受け取ったよ、というフィードバックです。それから処理が始まります。単純で短時間の処理であればすぐにリアクションがきますから二段階目は必要ないこともありますが、ちょっと処理に時間を要するような場合には、処理が完了した時点で、処理完了を知らせるリアクションを行う。こうした二段階のフィードバックが必要だとされています。� ��あ了解可能なガイドラインだと思います。

独自の投石機を作成する方法

画面上のボタンをマウスでクリックする。そのときに処理が終了するまでリアクションがないと、ユーザはそもそも自分がやったアクションが受け入れられたのかどうか心配になります。そこでもう一度ボタンクリックをしてしまったりする。すると時には処理が二重に走り始めてしまい、エラーを引き起こしてしまうこともあります。だからガイドライン的には、ボタンはクリックしたら色が変わるとか、ベコッとへこんだように見えるようにするとか、何らかのビジュアルな応答、いや音を使ってもいいんですが、たいていは視覚的効果の方ですね、それを返すように説明しています。こんなこと基本中の基本だと思うんですが、実際にはいまだに、そう今の今になっても、まだ一段階目のフィードバックを返さないシステムが結構� ��ります。インタフェース設計のイロハがわかってないんだなあ、ユーザビリティの考え方がいまだに設計者やデザイナの間にきちんと普及していないんだなあ、とも思います。

処理が終わったら、その結果を表示する。これも大切です。そうでないとユーザとしては何時、次のアクションをしていいのか分からないからです。たとえば Windowsの起動の時を思い出してください。電源を入れます。パソコンのモニターランプが点きます。これは一段階目のフィードバックです。画面にだらだらと色々表示されてきます。これは途中経過・・これについては次に説明します。そしてパスワードを入力してデスクトップがでてくる。それでもまだすぐには終わりません。いろいろと処理をしているらしくカーソルが砂時計になったりする。いや、砂時計になっていれば、まだ途中経過を表示しているということでマシなのですが、砂時計になっていないこともあります。で、よく分からないうちに起動処理が終了し、通常の入力待ち受け状態になります。このタイミングで Windowsは何もフィードバックを返しません。二段階目のフィードバック欠如のシステムです。だからユーザは何時の段階でアプリを起動していいのか分からない。こういう時にアイコンクリックしてもすぐにはその画面になりません。それでもう一度アイコンクリックしてしまったりする。そうするとアプリが二重に起動されてしまったりする。こういうのは仕様のバグです。

エチレンglygolはどのように作られるのですか？

ヒトの場合もそうですね。話をきいていて軽くうなづいてくれたりする。これは一段階目のフィードバックです。で、話をおえると「じゃあ・・」とか「だけどさあ・・」「そういやあ・・」といってリアクションが返ってくる。二段階目のフィードバックです。こうした形でアクションに対するリアクションが構成されているのが通常のインタラクティブな状況です。

ちなみに以前ダイアログという言い方が使われたことがあります。ダイアログデザイン、とか。でもこれだと言語的応答のニュアンスが強いので、現在はインタラクションという言葉を使うのが普通です。

さて、三番目のフィードバックインタフェース。これが途中経過表示です。パソコンの起動処理だとか、ソフトウェアのインストールだとか、ファイルの移動だとか、比較的長い時間がかかる処理については、止まってしまったのではないよ、ちゃんと処理がすすんでいるよ、という形のフィードバックを返すことが必要です。対人場面でいえば「うーん」とか言いながら考えている様子が見えること、これが途中段階のフィードバックになってます。だから電話で相手が考え込んでしまって無音状態になってしまうとヒトは心配になります。「あー」でも「うー」でも言って欲しいわけです。

途中経過表示には大別して二つのバターンがあります。動いていることを表示するだけのものと、全体処理のうちどこまで進んでいるかという状態を表示するものとです。前者はカーソルが砂時計に変わるようなもの。これでもいいのですが、数分の処理とかになると、これだけではユーザは心配になる。プログラムにバグがあったりして、そうなったままで処理が無限ループに陥ってしまっていることもあるからです。もともと100%完璧なソフトなんて作れません。どこかにバグが残っているのが普通です。だから困るんですけど。

そういうわけでプログレスバーといわれる表示をすることが一般化してきました。典型的にはバーがでていて処理の進捗につれて左から順に処理済みの色違いの部分が伸びてゆく。それが右端まできたら処理完了ということです。それを%表示と併記するやり方もあります。ただ、これについても色々と問題があります。プログラムとしてはほとんどの場合、全体でどのくらい時間がかかるかを予想することが困難です。したがって、簡単なやり方としては、プログラムのエントリーポイント、つまり入り口に仕掛けをいれておき、特定のプログラムモジュールに処理が移ったら、その分だけプログレスバーを前進させる、そんなやり方があります。ところがモジュールにはすぐに終わるモノも時間のかかるものあります。データの内容に よって同じモジュールでも所要時間が違うことがあります。だからプログレスバーの進み具合は滑らかではありません。

ついでにいうと、ゆっくり進むプログレスバーであれば、その間コーヒーでも入れようか、トイレにでもいこうかという見通しを立てることができます。その意味でもプログレスバーの適切な表示は、ユーザの行動に対して適切な情報を提供していることになります。日常行動でも、ちょっと待ってくださいといって奥にひっこんで10分も20分も待たせるのはマナーに反します。長くかかりそうだったら応接室にとおして椅子に座らせお茶でもだす。そういう話と同じです。

分かり切ったことではあったのですが、静大の卒論で適切なプログレスバーのあり方についての研究をやらせてみました。最初はスッスッと進むけど途中から遅くなるパターン、その逆のパターン、円滑に定速で進行するパターンなどを作らせました。結果は当然ですが定速パターンがもっとも好まれました。最初ゆっくりでもあとでスーッといくパターンはそれなりに受容されました。一番ストレスフルだったのは最初はスーで、最後に近くなってどんくさいほどのろくなるバターンでした。実際にもありますね。98%, 99%といってその先で時間がかかったりする。時には100%表示を示していながらなかなか処理が完了しない。こういうのは確かに腹立たしい。

また困るのは、複数の処理に対して、それぞれ独立のプログレスバーがでてくる。順番に。さあ終わったと思うと次のプログレスバーが表示されてしまう。あれあれ、となります。こうした時のために、処理全体を示すプログレスバーと個別のプログレスバーを二列表示しているものもあります。たしかVisioのインストールの時はこうした形になっていたかと思います。

このような形でフィードバックには一段階目のものと二段階目のもの、それに途中経過表示の三種類があり、処理の負荷の大きさによってそれを適切に選択して使うことが必要です。

ユーザビリティの観点からすると、これは有効さや効率の問題というよりは、むしろ満足感に関わるものといえるでしょう。有効さの点では処理が正常終了してくれればそれでいい。効率の問題はマシン性能にもよるでしょう。これは仕方ない、という範疇に属する点です。ただ、フィードバックの欠如による不安感や不快感を引き起こさないためには、それを適切に表示すること。これがフィードバックインタフェースのユーザビリティを確保するために必要なこと。そういったことだと思います。

今回は、フィードバックという事例をとりあげ、インタラクション場面における人間の不快感情を除去し、適切な認知的状況を構築するという目的のために適切なフィードバックが必要であるということ、そしてそれがインタフェース設計の試行錯誤の歴史の中でいろいろと考えられ、結果的に現在のガイドラインがまとめられた、というようなお話をしました。

（第13回・おわり）