混沌の廃墟にて -168-

使っていると気付かない

1992-02-24 (最終更新: 1996-03-15)

[↑一覧] [新着] [ホームページ]

「/」という文字は区切りを意味するのだと思うのだが、UNIXの世界では必ず しもそうとは限らない。通常のパス区切りという意味においては区切りであるが、 例外がある。すなわち、ルートディレクトリを表現する場合には端を表現するこ とになる。端も区切りと思えばそれまでだが。

「rootから/へのメッセージ」という本がある。この本はUNIXの知識のあ る人なら「ルートからルートへのメッセージ」と読むかもしれない。または、 「ルートからスラへのメッセージ」と読むかもしれない。しかし UNIX に対して 予備知識を持たない人なら、「/」に対してあたりまえ的解釈を行なうので、 「新古典シリーズ/源氏物語」と同じように「/」は発音しないだろう。となる と、書店では

「えーとなんだっけ、そうそう、へのメッセージ、という本はありますか？」
「へ？」

という不毛な会話が行なわれるのだ。ちなみにこの本、UNIXよりは鉄道のエッ セイが面白いので、俗に「てっちゃん」と呼ばれている人にはウケがいいと思わ れる。 

    *
NIFTY-Serveのデータライブラリの使いにくさには定評があるらしい。特に、ど のフォーラムに何が入っているのかわからないのが困るという。ちゃんとシステ ムフォーラムをまたいで検索できるよう設計しておかないから、「NIFTY-Serve データライブラリ」とかいった本を買って目で見ながら捜さなければならないの である。一体誰が悪いのだろうか。

ちょっとした所で使いにくいことが沢山ある。もっとも使い方が悪いのかもし れないのだが。検証するためにいくつか例を示す。まず、データをダウンロード する時に、DIRコマンド等で一覧表示してから、番号を選択する。私はたいていこ のパターンである。すると、指定した番号に対して、より細かい情報が表示され る。 

 >  データ名：
 >        ID：
 >  登録日付：
 >      属性：
 >    バイト：
 >      参照：
 >  補足説明：
成程と納得していてはいけない。普段使い馴れてしまったものには納得するの が世の常かもしれないが、使いにくいものに馴れてしまうというのも変な話では ないか。まず、IDを表示する必然性は、わかる。が、ハンドルを表示しないのは なぜか。殆どの人は、IDではなくハンドルで相手が誰だか識別する。これは経 験的に理解いただけると思う。いつも表示されないのに馴れているので、ハンド ルが表示されないのは当然、と思っている人はいないだろうか。仮に電子会議の ヘッダにハンドルが表示されなくなったらどんな反応があるか考えてみてくださ い。実際は、それで当り前と思っているどころではなく、どうせ提案しても無視 されるに決まっていると思い込んでいて、提案する気がさらさらない人もいるか もしれない。私のことだって？ 冗談、私は単に出し惜しみしているだけだ。

昔は、データライブラリは後から登録されたもの程小さい数字が割り当てられ、 番号がくり上がっていた。さすがにこれは改善要求が多かったらしく、現在の仕 様のように固定の番号が割り当てられるようになった。これによって、データを ダウンロードしたかどうか、管理しやすくなった。何番ライブラリの何番のデー タ、と言えばいいから。

と思ったら甘いぞ。上の情報からデータが何番なのかわかる人は相当凄い。デー タ番号がどこにあるのだ。指定した時にはわかっていても、詳細表示の時には表 示されないのである。仕方がないから、後でログを最初から見直して、何番のデー タかわかるように、 

 >      番号：
というのを自分で追加している。こんな情けない作業も、私だとawkでも使って ほいほいと処理できるかもしれない（実は手作業でやっていたりして）。では、 例えば MSDOS のコマンドは DIR と COPY と DEL 位しか知らないような他の人は どうやって管理するのだろうか。番号を表示する位なら、ニフティのシステム担 当者がちょっとその気になれば簡単に変更できる（それとひきかえにいくつ致命 的なバグが追加されるかもしれないが）。

ただ、この件は、とりあえず現状では自分に不都合ないので、どうでもよろし い。最近自分勝手だと思う。では真打ち登場。とても不都合なのは、次である。 データライブラリをしばしば使う皆さんは、次のようなメッセージか補足説明の 最後の行あたりに書かれているのをよく見かけるはずだ。 

 >  Filename : BPL50J.LZH
または、次のように。 
 >  このデータは「BPL50J.LZH」という名前でダウンロードしてください
なぜこんなことが書いてあるのだ？ 最も根本的な問題は、ファイル名という 項目がないからである。B Plus Protocol にはファイル名を端末に送信する機能 がある。皆さんが手作業でわざわざ入力しているのが、それである。 
 >  ファイル名 (改行のみで終了)
 >  ：BPL50J.LZH
ファイル名は、殆ど誰でも同じことを入力するに決まっているのだから、セン ターにファイル名が登録できれば、こんなことを手作業で行なう必要はないのだ。 わざわざ手で入力させれば時間がかかり、回線が混雑するだけだ。時間がかかれ ばニフティが儲かるって？ 基本サービスで回線を無駄使いさせて得するわけが ない。どうせならクリッピングサービスのように行末に余計な空白を表示させて 時間をかけさせた方がずっと得だ。というのは冗談（で済みますように）だけど、 クリッピングサービスの行末空白も困ったものである。

できる限り料金節約したいので、クリッピングサービスに入る前にログを取り 始め、一気に表示した後で全部削除し、すかさず回線を切ることにしている。そ の後、できたログに例えば次のようなスクリプトで awk を実行し、ニュースの所 だけを取り出す。しかし下手なスクリプトだな。 

BEGIN {
    h = 0
    print_flag = 0
}

{
    gsub(/  *$/, "")    # 行末の空白を取り除く
}

/^ *[0-9]* *[0-9]*¥/.*/ {
    header = $0
    h = 1
}

/^....ニュース速報.*/ {
    if (h == 1) {
        h = 0
        print header
        printf("¥n")
        print_flag = 1
    }
}

{
    if (print_flag != 0) {
        print
    }
}

# [1992-02-03-20:35]
/¥[199[0-9]-.*/ {
    print_flag = 0
    print "¥n¥n"
}
このスクリプトは 1999 年までしか使えないようだが…。まあ先の話だ。(*1) 話を元に戻してデータライブラリの話である。さて、ファイル名というと、 すぐ思い付くことがあろう。これは何だ？ 
 >  データ名：
質問！ ファイル名とデータ名の違いを述べよ。そりゃファイル名はファイル の名前で、データ名というのはデータの名前だべえ。ぐわ〜。厳密に言えば、フ ァイル名というのはダウンロードした場合に端末側に作成するデータの名称と考 えておけばよいと思う。だから、ファイル名とデータ名が別々に登録できればベ ストである。これは NIFTY-Serve が PROT:BPL をサポート開始した時に変更して おかなければならなかった仕様だ。会員を増やすのはよろしいのですが、このよ うな変更すべき所は早く直しておかないと、後になればなるほど、会員数が増加 しているので、混乱する人が増えるのだ。

ただ、経験的に解釈すれば、データ名としてファイル名と同じものを入力する 場合が、かなり多い。だったら、どうして 

 >  Filename : BPL50J.LZH
なんて書くのだ？ データ名を見ればわかるのだから書かなくてもいいじゃな いか…。甘い。補足説明が長いと、画面がスクロールしてしまって、ダウンロー ドしようと思った時には既にデータ名は忘却済みなのである。だから、わざわざ 補足説明の最後にこんなことを書かなければならないのである。

フォーラムによっては、スタッフが登録前にわざわざ手間をかけて、補足説明 を修正するのである。なお、これを修正できるのはスタッフといっても、SYSOP か SUBSYSOP のみである。こんな手間も馴れてしまえば…という発想かもしれな いが、それなら、

補足説明を表示した後に、もう一度「データ名」を表示すればいい

だけの話じゃないのか。

こういう所か気がきかないのである。ただ、この手のアイデアを思っているだ けでは全然改善されそうもないから、本来はなんとかニフティの担当者とコミュ ニケーションするよう努力するべきであると思うわけだが、ちょっと訳もあって、 私にはそのような場は見あたりませんので、いつも思っているだったりする。

ただ、全く方法がないかというと、そうでもない。実は入会後一定の日数がた つとメールが届くと思いますが、この「中村 明」さんからのメールには(*1)、 意見があったらご遠慮なく、といった内容が書いてあった記憶がある。だから、 この返事に書いてしまえばいいのだ。これは実はニフティの担当者も「それは反 則だ〜」と言った位の過激な技だから、多分ちゃんとしかるべき所（どこだ？） に伝わると思われる。もし暇があったら、上に書いた程度の改善提案なら山のご とくあるので、怒涛の攻撃を試みてもいいのだが、暇がないんだ。とにかく今は 書くところがどこにもないので（ここに書けばいいのだ）どこにも書いていない という単純な話なのである。

私がFPRG以外で発言する時には、多かれ少なかれ「ん、この発言者はどこのフ ォーラムの人なんだ？」と読者の興味を引いて釣ってしまうことを目的にするの で（そのためには興味をそそることを書かないと駄目なんですが、なかなか…）、 メールのようにマンツーマンのサービスに文章を書く手間は惜しい。だから、セ ンター宛メールで提案する気は殆どなかったりする。 

    *
最近は日本のオンラインコミュニケーション市場は、外見上は(!) PC-VAN とニフティサーブの二大サービスが分けている状況だが、あと数年もたたな いうちに、通信速度は数倍になり、画像・音声データの通信も普通になり、ユー ザーインターフェースの大激変が予想されている。予想しているのは私だけかも しれないが。その時に、今のサービスを全部入れ替える程の革命的な状況が生じ ると思う。後発のサービスが下克上するチャンスが、まだあるのだ。

来たるべきその戦国時代の勝者となるには、ユーザーの提言を真摯に受け止め ているだけでは駄目である。そんな事は、誰でもやるのだ。単にやらなかった所 が敗北するだけのことだ。

パッケージソフトウェア業界の激戦もそこにあるような気がする。使ってみて、 ここはこうしたら便利だ、というのは利用者に聞けばすぐわかることが多い。も ちろん、利用者が答えてくれたら、の話である。だから、利用者の話を聞くため に、なりふり構わずどんな手でも使うべきだ。

しかし、勝者になるにはさらに一歩先に進まなければならない。使っているだ けでは思い付かないような改善項目を発見しなければならないのだ。もちろん、 それを改善するのだ。例えば、ニフティサーブの場合はどこが改善できるか考え てみたが、…いや、これは内緒にしよう。

補足

(*1) そろそろ2000年問題という名前まで付いたようだ。しかし、まだ3年以上ある。

(*2) 最近は京増　弘志さんから送られてくる。「京増メール」と呼ばれている。 

    COMPUTING AT CHAOS RUINS -168-
    1992-02-24, NIFTY-Serve FPROG mes(12)-397
    FPROG SYSOP / SDI00344   フィンローダ
    (C) Phinloda 1992, 1996