混沌の廃墟にて -97-

待ち時間

1989-12-30 (最終更新: 1996-03-22)

実はオフィスに行くには必ずエレベーターを経由しなければならない。すなわち、階段がないのだ。一度、エレベーター故障のため、非常階段を経由しないと縦方向へ移動できなくなってしまった。セキュリティが高い設計と言えなくもない。:-)

短気な人なら、ボタンで呼び出してからエレベーターが乗り込む階にくるまでの時間が気になるだろう。これはある程度不可抗力だし、待ち時間を積極的に少なくすることはできない。ところで、エレベーターに乗ると「閉」ボタンというのがあって、それを押すと強制的にドアを閉じることが可能である。もちろん、エレベーターは今ではほぼ自動化されているため、何もしなくてもドアは勝手に閉まるのだが。

ドアが開いてから閉じるまでの時間を考察してみた。まず、例のエレベーターの観察の結果、これに乗る人が、ほぼ間違いなく「閉」ボタンを押すことがわかった。もちろん、このエレベーターは、他の多くのエレベーターと同じく、放置しておいても自動的にドアが閉まる。普段「閉」ボタンを押さないとドアが閉まらないエレベーターを使っている人は希有だろう。つまり、「閉」を押さないとドアが閉まらないと思っているわけではないと思われる。ということは、ドアを早く閉じたいから「閉」を押すことにになる。

ところで、私は滅多に「閉」ボタンを押すことはない。特にそれで不便でもない。かえって、「閉」を押すのが面倒な位だ。エレベーターを設計した人の立場を想像してみれば、利用者を想定し、どの程度の時間で自動的に閉まると便利か見積もり、ドアの開いている時間を設定したに違いない（違ったりして）。おおげさかもしれないが、計者の意志を尊重するという意味を込めて、「閉」を押さないで自動的に閉じるドアを楽しむのである。

このように書くと、どんなに長い時間ドアが開いているのだろう、という疑問が出てくる。そこで、実際にドアが自動的に閉まる時間を計ってみた。その結果、ドアが全開になってから、閉じ始めるまでの時間は、およそ 3.5 秒であることがわかった。

私の経験によれば、これは次の程度の時間である。５人以上でエレベーターに乗った時には、よほどうまく降りないかぎり、「開」ボタンを押さずに全員外に出るのは難しい。４人なら、最後の人がすり抜ければ、何とか脱出できる。３人なら、お互い譲り合わないかぎり、何も問題なく全員外に出ることができる。

繰り返すが、このエレベーターに乗る人は、ほぼ間違いなく「閉」ボタンを押すのである。普通の人がエレベーターに乗り込んでから、振り向くまで、１～２秒かかると思う。残りは 1.5 ～ 2.0 秒。インタラクティブなアプリケーションのインターフェースを設計するとき、ユーザーを待たせて不快感を与えない限界は３秒と言われている。エレベータ利用者がこの1.5～2.0秒を耐えられないということなら、場合によっては、この指針を考え直す必要があるかもしれない。

MIFES というエディタを使っている。サイズが 100KB 程度ある。以前はフロッピーディスクから起動していたので、起動に数秒かかっていた。読み込む時間である。私の性格がのんびりしているのかもしれないが、イライラすることはあまりなかった。

今はハードディスクから起動する。起動時間が短くなったはずだ。ところが、今までと違って、逆にイライラすることがある。理由を考えてみた。長い時間待たされることが前もってわかっていると、それなりの心構えというものがある。ところが、瞬時というわけでもなく、長時間でもない場合の、若干待たせている間が、イライラの「イラ」程度を誘発するらしい。精神的な分析がさらに必要だと思われる。

余談になるが、ハードディスクを買って、思わぬ効果もあった。あちこちのフロッピーに散在していたMIFES を削除することができたため、それぞれ 100K 程度の容量節約になったのだ。特に、システムディスクにコンパイラなどの大きなファイルが入っていると、エディタを入れる余地がなくなる場合があり、やむなくソースプログラムを入れるべきフロッピーにエディタが分散して入っていたのだった。 (*1)

いわゆる「パソコン通信入門」の記事には、いまだに「モデムの選び方」全盛である。それもそのはず、選択肢が多いのだ。特に、通信速度と MNP のクラスが混乱に輪をかけている。最近は 9600bps という高速モデムもちらほら出てきたので、これらが記事に参加している事もあるが、入門者向けの解説にはこれは無意味だと思う。

私は、2400bps の MNP モデムが必須だと思う。特に NIFTY-Serve では、通信時間単位で課金されるのだから、1200 は駄目。MNP は文字化けを防ぐためには必要だ。ある程度の文字化けがあっても、読めるから問題ないという人もいるが、そんなことはない。絶対に化けない方がいい。文字化けというのは、精神的なストレスを蓄積するのである。特に、コマンドを入力する場合にはそうだ。

XMODEM と相性が悪いから MNP は不要という人もいる。:-) だが、MNP を使えるモデムは、必ず MNP を無効にするコマンドを持っている。例えば AT コマンドの場合は、電話番号の最後に 'D' という文字を追加するだけで非 MNP 接続できるのである(*2)。MNP でないモデムを買ってしまうと、MNP を使うことは絶望的である。根性のある人はソフトウェアでエミュレートするという最後の手段がないわけではないが…。

では、2400bps のモデムを使えば、１分間にどの程度のデータをやりとりできるだろうか。1 文字が 10 ビットとすると、240 文字？答はノーである。私の経験では、NIFTY-Serve で通常の時間帯に接続すると、150～200 文字程度の速度になる。ただし、これは login してから logout するまでの時間で計算したもので、コマンドを入力してから実行されるまでの待ち時間を含んでいる。(*3)

会議室の内容を down コマンドで表示するような場合には、ほぼ 200bps 程度の速度は出ているのだが、down コマンドを使ったことのある方はご存知のように、このコマンドは実行されるまでに「ただいま作業中です」というメッセージが表示され、かなりの時間待たされる。場合によっては数分以上かかる。その間も課金されるのだから、実効速度の計算に含めるのに文句はないだろう。

ちなみに、早朝などに NIFTY-Serve に接続すれば、普段とのレスポンス速度の差、電子会議の発言の表示の速さに驚くのである。つまり、これはセンターの負荷の問題であって、端末側ではない。

では、普通の場合、コマンドを入力してからプロンプトが表示されるまで、どの程度までなら我慢できる時間と言えるだろうか。これに関しては、応答時間と作業効率の関係を短期記憶のメカニズムをあてはめて論証した人がいる。この理論によると、およそ 15 秒を超える待ち時間は短期記憶の限界を超えてしまうため、作業能率が低下する。

おそらく、何かコマンドを入力して 15 秒を超えても反応がなければ、何か変だと思って次のアクションを試みると考えてよいだろう。しかし、イライラなしに使うことのできる限界は、もっと短いようだ。エレベーターの例を出すまでもないが、多分 1 ～ 2 秒という所が限界だろう。しかも、私のように、一瞬待たされるとかえって神経にさわる、という人がいると、ますます始末が悪い。かと言って、瞬時にレスポンスを返すのは事実上不可能である。何かよいアイデアはないか。

補足

(*1) MIFESって、こういう使い方でよいのでしたっけ?　とはいっても、ハードディスクがない時は、そうしないと使えない状況だったわけだが。ちなみに、今はMIFESは使っていない。ダイレクトメールは相変わらずやってくる。

(*2) モデム依存のコマンドと思われる。

(*3) 1996年2月現在、FENICS-ROAD5で実測したら、3000バイト/秒を超える場合があるようだ。速くなったものだ。

    COMPUTING AT CHAOS RUINS -97-
    1989-12-30, NIFTY-Serve FPROG mes(5)-022
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1989, 1996