-181-
もう一つ、あまり知られていない事実を。データのアップロードの時には、B+ を使った実測値で 800〜900 バイト／秒の速度が出ている。これは ROAD 2 の４ 倍程度の値である。(*1)
従って、アップロードする機会の多い私は、ROAD3 を使うことが多くなるのだ が、困ったことに、最近東京の ROAD 3 アクセスポイントが無茶苦茶不調である。 とにかく、電話がつながった時点で、無反応である。俗に「ＡＰのモデムが死ん でいる」という状態だ。これでもNTTにはしっかり10円徴収されるのである。 完璧な無駄金ということになる。
ついに頭にきたので、GO CENTER で障害報告をすることにした。結果として余 計頭に来たわけだが、その顛末を紹介しよう。(*2)
*
GO CENTER を実行すると、「センター宛メール」という項目にたどり着く。こ
のメニューは、7/18 現在は、6つの項目から選択することになっている。この中
の3番目の項目が「アクセスポイントの異常について」である。これを選択した
以後は、課金は無料となる。ただし、電話代が無料になる訳ではない。本来は0120
で別回線を用意するべきだと思う。特に、アクセスポイントの異常の場合には、
つなぎたいアクセスポイントからアクセスできないのだから、NIFTY-Serve に入
ってから報告ということ自体、いまいちだと思う。
3を選ぶと、まずメッセージが表示される。
全ての質問にお答えいただけない場合には、復旧が遅れることがございます。これは、一般論として考えるなら経験的に理解できる。実際、トラブル調査に おいては情報が不足することは致命的なことがあるから。ただ、もう一つよくあ ることを指摘するなら、必要以上の情報が与えられることにより、問題解決が遅 れることもよくあるはずだ。
さて、報告を始めよう。
異常が発生した日をお教えください (例:1992/04/22)これは簡単な質問だが、ＵＩの設計で最も基本的な事項、例を表示するという ポイントを守っていることは評価できる。1992/07/18 と入力した。しかし、年は 入力する必要がないと思う。通常、このような報告を１年以上遅れて行うことは ないから、月・日がわかれば推定できるからだ。(*3)
異常が発生した時間をお教えください (例:23時頃)私は「時刻」という表現の方が好きである。「時間」という表現が「時刻」を 意味することはよくあるので、誤った表現とはいえないが。時計を見ると 16:20 だったので、それを書いた。
異常が発生したアクセスポイントをお教えください (例:東東京)今回の場合は、これが重要な情報になるはずである。ところで、次の項目が問 題だ。
異常が発生したときご利用されていたアクセスポイントの電話番号をお教え ください (例:03-3739-9120)多分、電話番号がわからない場合を想定して、一つ前の項目でＡＰを尋ねてい るのだと思う。しかし、電話番号がわかれば、ＡＰは完璧に特定できるのではな いか？ ということは、直前の質問は明らかに無駄な質問である。質問の順序を 逆にした方がよい。とりあえず、03-5703-2950 と書いた。
異常が発生したとき、端末を設置されていた地域の電話番号 (市外，市内局番) をお教えください(例:03-5471)このあたりから、「？」となってくる。なぜ端末の電話番号が必要なのだろう か。モデムが電話を取る所までは進むのである。普通はここで応答側（すなわち センター）のモデムが「ぐわ〜」と言うのだが、今回はそれがないというトラブ ルだ。ゆえに、電話回線には異常がない。少なくとも、こちらの番号は関係ない。 全く同じ電話回線で、今 ROAD2 につないでいるのだから、明白である。従って、 こんな情報はなくても問題なかろうと思いつつ、03- と入力した。
ご利用になっていらっしゃる回線を下記より選択してください見にくい。項目ごとに行を分けるべきだ。それに、なぜ _ が必要なのだろうか。 これは、余計利用者を混乱させる。
スペースの表示は_で表記しているので実際の表示とは異なる場合があります
1.FENICS-ROAD_1(.00+でのアクセス) 2.FENICS-ROAD_2(C_NIFでのアクセス)
3.FENICS-ROAD_3(INS-Cでのアクセス) 4.FENICS-ROAD_3(V.32/MNP10でのアクセス)
...
1.FENICS-ROAD 1 (.00+でのアクセス)
2.FENICS-ROAD 2 (C NIFでのアクセス)
3.FENICS-ROAD 3 (INS-Cでのアクセス)
4.FENICS-ROAD 3 (V.32/MNP10でのアクセス)
...
この方がずっとよい。とにかく 4 を答えた所で、はっと気付いた。既に電話番
号を答えているのだ。なぜこんな情報を教えないといけないのだ？ 疑惑が渦巻
く中、さらに先に進む。
状況をご記入下さいこれは明快。「電話がつながった時点で無反応」だ。こう書いたのである。し かし、後で考えると、この説明は不親切だった。電話をとった状態で何の音も戻 ってこないのである。そこまで書くべきだった。例えば、モデム同士のハンドシ ェイクに失敗して無反応、ということもあり得るからだ。
(入力は 4行以内 終了は行頭で/E)
ご利用の端末 (ワープロ、パソコン等) の機種をお教えください (例:FM-TOWNS)かなり頭にきていたのだが、この時点で完全に切れた。「＊」と入力する。だ いたい、センターのモデムが何の音も戻してこないという症状に対して、パソコ ンの機種が何の関係があるというのだ。私にとっては、このような場所で FM-TOWNS という文字が出てくることに、悪いサブリミナルの効果がある。つまり、トラブ ル→FM-TOWNSという連想が頭の中に生成されるからだ。
ご利用のモデムの機種をお教えください (例:富士通PM2400F II)無視しようかと思ったが、なんとか我慢して、とりあえず OMRON MD96FB5V と 書いておく。例はあからさまに富士通だが、先程書いたような理由で、他のメー カーの名前を出すわけにはいかないのだろう。トラブルが多いメーカーであるよ うな印象を与えられてしまう富士通がかわいそうである。
ご利用の通信ソフトをお教えください (例:TOWNS VNET Ver1.0)時間だけが無為に過ぎていく。既に私は切れているので、この項目は無視する。 次に進む。
フロー制御はどのように設定されていますかあのね…。今回の場合、全く関係ないはずだ。なお、モデムは ATM1 コマンド を送って、接続の時に音で確かめるようにしてある。それで電話をかけて、つな がった後に何も音がしないのである。フロー制御以前の問題だ。しかし答えない と次に進めないので、2 を選択した。しかし、ここも見にくい。こう書くべきだ ろう。
1.XON/XOFF制御(ソフトウエアフロー制御) 2.RS/CS制御(ハードウエアフロー制御)
3.わからない
1.XON/XOFF制御(ソフトウエアフロー制御)
2.RS/CS制御(ハードウエアフロー制御)
3.わからない
このように書くことにより、番号の位置が縦方向に１列になるので、どこに番
号が書いてあるかとまどう危険が少なくなるのだ。これもＵＩの教科書には書い
てあるはずである。
モデムの設定、ソフトの設定等をご記入くださいいきなり /e を入力する。
(例:モデム:ATX4&C1B0E0M1Q0&Q2¥V2ソフト:MYTALL/H/M等)
(入力は 4行以内 終了は行頭で/E)
ところで、MYTALL というのは何なのだろうか、私は聞いたことがないのだが？
もちろん、FM-TOWNS や PM2400F というのは「聞いたこと」がある。:-)
その他お気づきになったことをご記入ください気付いたことなら、ここに書いたようにたくさんある訳だが、このシリーズは 今年中に200回まで書くことになっているので、ネタにしてしまう訳だ。とりあえ ず、こう書いたのだ。
(入力は 4行以内 終了は行頭で/E)
電話が取られた時点で、何も反応がないんですよ、なぜこのように多くの 無駄な項目に回答しなければならないんですか。電話代を支払っているのは こちらだということをぜひ理解していただきたい。うっかり「課金が…」とか書いてはいけない。この間の課金は無料なのだから。 激昂していると墓穴を掘るかもしれないので、注意すること。
住所を入力して下さい…無視してしまったのだが、もしかして、ちゃんと書いておけば、毎月１名に FM-TOWNS が当たる、といったサービスがあるのだろうか。あるかもしれないな、 惜しいことをしたぞ。
名前を入力して下さいこれも無視してしまった。「フィンローダ」と書けばよかった。「フィンロー ダ、フィンローダをよろしく！」。でも選挙をやっているわけではない。
なぜ無視したかというと、ちょっとした用事があったために、急いでいるから である。とにかく、早く終わらせたいのだ。私が SYSOP という立場でなく、ニフ ティに対する義務感を持ち合わせていなかったとすれば、ここで止めてしまった かもしれない。
これで入力は終了しました。入力情報を登録しますか ?やっと終わりのようだ。やれやれ。
登録 (1:登録する 2:しない)
お申し出ありがとうございました。どういたしまして。しかし、はっきりいって、２度と報告したくないと思った が、本当に粗品進呈があったのかもしれない。手間を惜しむことなかれ、といっ た所か。しかし、こんなに手間がかかるとは思いもしなかったのである。センター の担当者に、
本件につきましては早急に調査を行い対処させていただきます。
「東京 ROAD 3 AP に電話をかけると、つながった後モデムが無音状態です」といえば、問題のモデムを調査して、故障しているモデムを取り替えられる。 これで済むことなのだ。しかし、他のケースもあることを考えると、どこまでが 必要なのか考えてみる価値がある。最も問題なのは、これで私としては二度と報 告したくないと思ったという所にある。報告フォームが原因でトラブル報告が減 ってしまうと、全体の品質に影響するだろう。トラブルが実際に発生してしまっ た以上、報告は早ければ早い方がいいのだ。利用者にすみやかに報告させる気に するような手順を検討する必要があるのではないか。
< ＞bye < LOG IN −−− 92/07/18 16:17:57 < LOG OUT −−− 92/07/18 16:24:51 < ご利用時間は、 06分54秒でした。この報告だけで７分かかったことがわかる。…あれ？ 待てよ、トラブルの時 刻を 16:20 と書いたような覚えがあるのだが…。
調べてみると、なんと手元の置き時計が 10 分も進んでいるのだ。これはいか ん。タイムトラベラーになってしまったようだ。いや、正確にはタイムトラブラー というところか。
※なお、17:20 現在、東京 ROAD 3 AP で接続に成功した。トラブルが取り除かれたのか、偶然つながったのかは、わからない。
(*2) これらのメニューが現在も同じである保証はない。
(*3) 管理上は年がある方が便利である。それは管理者の都合だ。管理者が勝手に付ければよいのだ。
COMPUTING AT CHAOS RUINS -181-
1992-07-18, NIFTY-Serve FPROG mes(3)-425
FPROG SYSOP / SDI00344 フィンローダ
(C) Phinloda 1991, 1996