一覧 
 
 
福井県立大学・経済学部 田中求之 (Motoyuki Tanaka)
最終更新日: 08年02月05日 16時31分

*1996年から2006年まで、このサイトで Web Scripter's Meeting という会議室を運営していた。以下の文章は、その会議室を終了して半年程たった頃に、Mac 仲間の ML のニューズレター用に書きかけていた回顧録である。残念ながら書き上げることができなかったのだが、文章としてある程度まとまっていた冒頭部分をここに載せておくことにした。

●はじめに

研究室に着いたら、まずLC475のモニターの電源を入れて、サーバや各種CGIが無事に動いているのを確認してから、一日の仕事を始める。そして、休憩時などには、自分がコメントできそうな発言にコメントを書いたり、ニュースなどがあれば新しい話題を投稿する。そして、帰宅する際には、念のために、その日の投稿をすべて読み返してから、サーバやCGIの動作を確認して、モニターの電源を切り、研究室から出る。Web Scripter's Meeting (以下WSMと略記)を運用していた10年、こうした一連の作業が日課になっていた。今年の1月16日、10年の運用を区切りにして、会議室の運用を停止するまでのことである。それから半年余り。今では研究室にいてもLC475のモニターの電源を入れない日も多くなってしまった。WSMの運用をやめてしまったLC475は、ある意味で自分の個人的なサイトという本来の姿に戻った。たとえ落ちたりハングアップしても、まぁ、それはそれでいいか、という気持ちで動かしている。WSMの運用を止めて自分に起きた一番大きな変化は、この個人サイト運用の気楽さを得たこと(取り戻したこと?)にあるように思う。

ちょうど10年で運用を止めたことにそれほどの意味はないのだが、それでも振り返ってみれば、この10年というのは個人が非UNIX系のパソコンOS上で Web サイトを運用してみることの可能性や喜びを味わえた10年だったように思う。不安定で非力で制約も多いかもしれないが、それだけに自分の身の丈にあったサイトというものを意識して作り込む中で、色々なことを学び、楽しめた。それが「時代遅れ」とされて、今では新しくサイトを立ち上げて見ようとするときの選択肢としても無くなってしまったことは残念に思う。

WSM を始めた時、それほどたいした意気込みや野望があったわけではない。サーバの機能向上と自分のスキル向上とによって、AppleScript の CGI で色々なことが可能になった状況で、何か「まともな」、他の人たちが来てくれるような会議室を運用してみようかと思ったから始めたようなものだ。もちろん、前年に仲間達との共著で出した『Macintosh インターネットサーバー構築術』の補助的な情報交換や、自分の公開しているフリーウェアのオンラインサポートの場にしたいということもあったし、自分が積極的に発言したり運用にかかわることができる内容ということで、Mac のサーバ運用を話題にしたわけである。自分がただやってみたかったから、という理由で始めた会議室が、思いもかけなかった多くの人たちに支えられ利用してもらうものになったのは、色々な偶然の重なった結果であって、こういうことが起きるのがネットの面白いところだと思う。

基本的には、あまりうるさいことは言わず、Mac のサーバ運用に関連しそうな話題ならなんでもよいというスタンスで運用してきたが、この話題の限定以外に、自分なりにこれだけは譲れないというものを持ってやっていた。偉そうに言うほどのものでもないのだが、それらは以下のものである:

  1. :CGI は自作する
  2. :話題ごとに発言が時系列で並ぶスレッド型にする
  3. :匿名性
  4. :管理者として逃げない・ごまかさない

以下、順に説明する。

●CGIは自作

まず最初のCGIは自作するということだが、これはそもそも自分でCGIが作れるのがうれしくて始めた会議室なのだから当然のことではあるが、それ以外に、LC475 で実用上問題がないものを作るという意味も含んでいる。

話題が投稿でき、それにコメントがつけられるならばそれで会議室は作れるわけだが、あらゆる状況を想定してきちんと作っておこうとすれば、必要とされるCGIのスペックはどんどん高度なものになる。しかし、WSMを含めた自分のサイトでは、とりあえずLC475で普段は問題が起きない程度でかまわないというゆるい条件で作っていくことにしてあった。

たとえば、投稿されたデータはすべてテキストファイルで管理して、データベースは使わないのも、データベースを動かすには無理があることや、トラブルが起きたときにテキストファイルでデータが残っているなら、なんとかなるだろうと考えてのことである。たとえディスクがクラッシュしても、テキストデータであればノートンを使って復活できるチャンスも大きい。またファイルのデータの仕様を変更したときでも、AppleScript でバッチ処理で一括変更といったことが簡単。さらに、データの検索や絞り込みに OS のファイル管理機能を使える。こうしたことから、とにかくデータはテキストファイルで扱うものにしてあった。

また、テキストファイルの管理番号は投稿時のタイムスタンプ(日時分秒)を使っていたが、これだって、厳密に考えれば、二つの投稿が同時に(あるいは1秒以内に連続して)ポストされると、前の発言を後の発言が上書きしてしまう危険があり、仕様としては杜撰なものだ。しかし、LC475 上の AppleScript の CGI はマルチスレッドでは走らないことが幸いして、たとえ連続して投稿しても同じタイムスタンプにはなりえないため(一つの投稿の処理が1秒以内には終わらないため)、何の問題も起きないのである。AppleScript の仕様とオーバーヘッドに寄り掛かった緩い規格でプログラムを書くことで、楽をする(というか、不要な努力を避ける)という方針で作ってきた。

もちろん、緩いながらもできる限りの高速化はあれこれと試した。CGI がテキストファイルによるデータ管理を基本とするということは、当然のことながら、色々な処理においてテキストファイルの読み書きを行うということである。Mac OS のファイルシステムの処理は決して高速ではないが、ファイルを読み込むだけであれば、それほど負担にはならない(OS のキャッシュが利くし)。しかし、少しでも処理速度を上げたいと思い、複数のファイルを同時に読み込んだり、同じ内容のファイルを複数同時に書き込んだりできるように osax (AppleScript の機能拡張用のプラグインソフト)を作ったりしていた。リソースにデータを埋め込んでインデックス代わりに使うのを試みた時期もあった。また、LC475 でも 64M の SIMM が使えることが分かり、RAM を 68M まで増やすことができてからは、システムのキャッシュを多くとる以外に、RAM ディスクを使って高速化を試みた。コメントがつけられる話題のファイル(アーカイブに移行していないファイル)については、RAM ディスク上にコピーを置き、ファイルの検索と読み込みは RAM ディスク上のものを使うようにしたのである。これにより、気持ち、早くなったように思うのだが、言うほどのものでは無いかもしれない。このように、色々なアイデアを、自分なりに試してみて、それがうまく行くことだけで自己満足していた部分は結構ある。で、結局のところ、高速化で一番有効なのは、当たり前といえば当たり前なのだが、AppleScript で処理していた部分を osax として作り込むことであった。フリーウェアとして公開している Tanaka's osax がどんどん肥大化していき、また別のパッケージも出したりしたのは、ユーザーからの要望を受けて機能を追加したものも少なくは無いが、WSM の運用を少しでも高速で安定的にするために AppleScript でも何の問題もなく行える処理を、あえて osax にしたものが少なからずあるからだ。

色々と試してはいたが、やりたくてもできなかったこともある。なんといっても、まともな検索機能を結局組み込むことができなかったというのが、その最たるものである。話題(スレッド)が少ないうちは、全文検索も不可能ではなかった。一時期、全文検索ソフトを使って実装していたこともある。しかし、話題数が増えるにつれて実行速度がネックとなって、結局、CGI に内容の検索機能を組み込むことはできなかった。Phantom というサーチエンジンのソフトを別マシンで動かすことで、英単語だけでも検索できるようにしておくのが精一杯であった。結局、Google を使うことができるようになって、ようやく、それなりに満足の行く検索機能が「できた」のだが、これなどは LC475 ゆえにできなかったことである。PowerMac であれば Sharlock を CGI と連動させるという手も取れたし、場合によってはデータベースソフトを動かすこともできたのだろうと思う。

その他、サイトのメンテナンスの自動化(一定期間コメントが付かなかった話題はアーカイブに移動させる等)のように、やろうと思えば作れたが、結局、手作業でやることにして、プログラムにはしなかったものもいくつかある。安定的な運用を第1にして、そのためには多少の手間がかかるのは仕方がない、ということで運用していたからだ。これなどは、LC475 というマシンによる制約というよりも、会議室へのアクセスが増えて疑似公的なものになったということ(そういう意識を自分がもったこと)からくるものである。

なにはともあれ、このように、自分の手元のマシンで、自分が納得いって、それなりに問題も起きないものを、自分で作って運用していく、というが CGI プログラムに関する自分のポリシーだったし、これは今のサイトの運用でも変わっていない。

●会議室はスレッド型

会議室をスレッド型にした理由は、WSM 仕様の会議室用 CGI (EasyBBS) の仕様を説明した文書(EasyBBS の哲学)の中で述べたことがある。それを再録しておく(*時間が無くて文体に統一はできていない):

●はじめに

私がフリーウェアとして配付している EasyBBS を中心に、私がオンラインの会議室をどのように考え、そしてそれを EasyBBS において実装してあるのかといったことを述べてみたいと思います。

まず、言うまでもないことですが、この、一つのスレッド(話題)を一つのページに収めるという形式は、古くからコンピュータの会議室(掲示板)の形式として存在したものであって、EasyBBS がはじめて採用したものでは決してありません。ですから、なぜ、私がこの形式を「採用」したのかという話になります。

さらに、ここで述べる考えは、あくまでも現在の私の考えであって、この会議室や EasyBBS を作り始めたときに私が考えていたことではありません。つまり、後付けの理論というものになります。その意味では、事後的に自分の選択を正当化しようとするバイアスがかかっていることは否めません (^_^;; 決して、中立的な立場で考えたものではなく、私がなぜこの形にこだわるのかということを述べた独断に過ぎないということには注意してください。

●バーチャルと仮想

本題に入る前に、いきなりわき道にそれます。

EasyBBS はコミュニケーションの場を設けるためのソフトウェアであり、言うなればバーチャルな組織を構築するための道具です。

この「バーチャル」ということについて、普段、私が気になって仕方のないことがあります。もしかすると、それはささいなことなのかも知れませんが、私にとっては、オンラインのコミュニケーションを考えていくうえで、一つの重要なポイントだと感じられますので、ここで述べておきます。

今ではすっかりバーチャル(あるいはヴァーチャル)というカタカナ用語が定着した感がありますが、この日本語のバーチャルは、英語の virtual との間に、大きなズレがはらまれているように思います。

バーチャルを漢語にするとき、「仮想」という言葉があてられます。そして、日本語のバーチャルは仮想と同じ意味で使われているように思われます。

仮想という日本語の言葉は「事実でないことを仮にそう考えること。仮定しての想像」(岩波国語辞典第5版)という意味の言葉です。あくまでも現実ではないという意味をもつ言葉でなのです。この仮想という言葉に示されているのは、しょせんコンピュータ(あるいは他の装置)を介した体験というのは非現実的なものであり、生身の人間が顔や(身体)を直接に向かい合わせて交わすコミュニケーションから見れば嘘(あるいはせいぜいが代替)でしかないということであると言えるでしょう。つまり、無媒介のコミュニケーションこそが「正しく」「本当のもの」なのだという観点が、仮想という言葉には宿っています。

一方、英語の virtual という言葉は「見掛け上/名目上は違うが、実質的/実際的には」という形容詞です。つまり、virtual reality とは、(コンピュータのディスプレイに表示された画像のように)見掛け上は現実とは違うものではあるが、実質的には現実であるもののことなのです。それは一つの現実なのです。ボタンを押してミサイルを発射するにせよ、コントローラーを使って跳び蹴りを繰り出すにせよ、その操作に対して影響を被り反応する他者が存在するということ、それがバーチャルという言葉には含意されているわけです。

仮想という言葉が「見かけは現実っぽくても嘘」というフィクションを志向した言葉であるのに対して、virtual は「見かけは嘘っぽくても現実」というリアリティを志向した言葉だと言えます。いうなれば、ベクトルの向きが全く違う。この志向の差異は、ネットワークというものをどううけとめるのか、ということに関して、少なからず影響を与えているように思います。

EasyBBS は、virtual な場を生成するためのソフトです。見かけはどうであれ、そこでは人格によるコミュニケーションが行われる、リアルな場であることをめざしているということです。言い方を変えるならば、最低限リアルな場として機能するためには何が必要か、という観点で使用を決めたものになっています。

●装置としてのソフトウェア

会議室(掲示板)を設けるということは、コミュニケーションの場を作るということです。ですから、そのアーキテクチャは、当然のことながら、望むようなコミュニケーションが生成しやすいような場を作り仕組みになっている必要があります。そして、コンピュータによるコミュニケーションにおいては、広義のソフトウェアの仕様が日常生活における社会的要因に相当するわけですから、ソフトウェアの仕様、つまり会議室の使い勝手=インターフェースが、コミュニケーションの生成に大きな影響を与えることになります。

たとえば、会議室で皆が車座になって座って話し合あうのと、前面の論者に対して授業を聞くように並んで座るのとでは、その場の雰囲気とか話し合いの内容が異なるということは、普段の生活において私たちが普通に体験していることです。これと同じことが、コンピュータのネットワークにおいては、ソフトウェアの仕様の問題として現われるということができます。

では、そのソフトウェアの仕様というものは、どの点をもっとも重視するべきなのか? おそらく、この問に対する答えによって、会議室システムをどのような形式で構築するのかが異なると言っても良いでしょう。

●コミュニケーションの生成

EasyyBBS においては、なるべくレスポンスが簡単にできること、そして、できるだけ気軽にレスポンスができること、をもっとも重要なポイントだと考えて作ってあります。実際に運用をなさっている方は気がつかれることだとは思いますが、EasyBBS においては、アクセスしたユーザーが気軽にコメントができることを最優先にして、その分、管理者が苦労するという仕組みになっています。たとえば、誤った書き込みや無関係な書き込みの削除といった管理者向けの機能は、ある意味で無視しているとすら言ってもよい作りになっています(EX 2 ではかなり作り込みましたが)。

なぜか? それは、コンピュータのコミュニケーションにおいては、私たちの普段のコミュニケーションでは見えにくい、コミュニケーションに内在している不確実性が前面に現われ、そのため、ネットワークの会議室ではコミュニケーションを成立させることを最優先にするべきだと考えたからです。

信号伝送と人間のコミュニケーションを同じように考えるという杜撰なモデルが横行しているため、私たちは、コミュニケーションというものを、自分の意見を述べて、それを相手の意識に送り届けることだと考えがちです。つまり、Aという人が、自分の考えを表現し、それがBという人間に届くということがコミュニケーションだと思っているところがある。しかし、これには大きな間違いが潜んでいます。というのは、Bに「伝わったかどうか」は、Bから何らのリアクション(新たなコミュニケーション)があって、はじめて分かるということです。つまり、相手にどのように伝わったかは、相手からの反応が返ってくるまで分からない。また、たとえ相手からのリアクションがあったとしても、自分が思うように伝わったのかどうかは、あくまでも相手のリアクションから私が推定するしかないということです。

相手の意識、端的に言うと相手というものが、私にとっては最終的には不透明なものでしかありえない。自分にとって不透明なものだからこそ、他人なのであり、そして不透明だからこそコミュニケーションという行為を行なうしかないわけです。

端的に言うならば、私が「何を伝えた」のかということは、相手がそれをどのように受け止めて、どのように反応したのかということによって決まる。そこにおいては、私個人の意図ではなく、相手の理解こそが、私の行為=発言の意味を決めるという構造がある。別の観点から言えば、コミュニケーションとは、相手からの反応をもってはじめて完結するものだということ、更に言えば、複数の人々の間で進行するプロセスなのだということです。私が何かを言うということは、コミュニケーションのプロセスのある局面にしか過ぎないのであって、それだけではコミュニケーションが成立していないわけです。

レスポンス無き発言はコミュニケーションではない。

もし応答がなかったら、コミュニケーションは完了しないままなわけです。

あなたがどんなに「正しく」て「立派な」意見をのべたところで、相手がそれに応えてくれないのであれば、意味がないということです(単なる自己満足は別にして)。

ですから、コミュニケーションには、相手に応えてもらって初めて成立するという危うさがつきまとっているのだと言うことができます。そして、コンピュータによるコミュニケーションというものが、様々な技術的な制約や特異性をもったものであるがゆえに、このコミュニケーションに内在する危うさが大きな問題として浮上するのだと言ってもよいでしょう。

●ネットワークのコミュニケーション

対面での会話であれば、相手(発言者)が目の前にいるという、そのことによって、否応なく、何らかの反応を返さざるを得ないということがあります。無視すること(何も聞かなかったことにすること)ということも、対面においては、その瞬間の明確な意思表示としてコミュニケーションを担います。このように、対面の場合には、発言に対するレスポンスがあることが、事実上、保証されており、コミュニケーションされる内容が噛み合っているかどうかは別にして、コミュニケーション自体はスムーズに進行します。

しかし、ネットワークの会議室においては、発言は、応答を待つ状況で止まっている、つまり、コミュニケーションとして完了しない形で存在しているわけです。ですから、そうした場でのコミュニケーションにおいては、そのメッセージを読んだ人から応答を引きだすための工夫が発言自体に求められます。このための工夫が、いわゆる発言マナーの類いで述べられていることの本質です。端的に本質を要約すれば、その場に相応しい人間であること、その場を受け入れて肯定していること、そして、その場に応じたコミュニケーションを継続する意思があること、これらのことを示しつつ発言を行なうということです。情報の選択や伝達の仕方を、ちゃんと「わきまえている」ことを示さないといけないわけです。

こうしたことは、もちろん、対面でのコミュニケーションでも要求されることなのですが、対面の場合においては、私たちは、表情や身体的な動作によって、こうした自己呈示を自然と行なうようになっています(相手が目の前にいるという圧力が否応なくそうさせるとも言えるでしょう)。しかし、ネットワークでは、そのスキルを、書き言葉の中において表現するという技能が求められるのです。

このように、ネットワークでコミュニケーションを成立させるには、対面とは異なった工夫(スキル)が発言者の側に求められるわけです。

とすれば、コンピュータのネットワークにおいて、コミュニケーションの場を作りたいと考えるならば、必然的に、その場に参加した人々(アクセスした人々)からレスポンスを引きだすか、レスポンスを付けやすいようにするか、ということこそがポイントになります。ネットワークのコミュニケーションが持っている脆弱性、つまり応答を待つ形で中断されたままになるということ、この脆弱性を少しでも小さくする工夫が求められます。そのことは、発言する側の負担を減らすことにもなります。もちろん、発言者に最低限の自己呈示のスキルは必要なのですが、なるべく負荷を減らすということ、そして場の雰囲気や話の流れをつかみやすいものにすること、こうしたことがレスポンスを産みやすくすることになるわけです。

コミュニケーションの場を作るということは、端的に言うならば、レスポンスが付けやすい場を作るということに他ならないと言っても良いでしょう。管理者が管理しやすいなどということを考えるのは、まるでコミュニケーションの危うさが分かっていないのだと言ってもよい。

レスポンスが生まれてくることこそが、コミュニケーションを生み出すということにほかならない。

また、そのレスポンスも、更なるレスポンスが生まれてくることによってのみ生きたものになり、その応酬(必ずしも二人の人間に限られたものである必要はない)がプロセスとして進行していくことが重要だということです。

●EasyBBS における戦略

この点から考えると、現在の技術的な制約のもとでは、一つの発言にレスポンスが次々にぶら下がっていく形式が、コミュニケーションを生み出すという点においては、ここの発言が独立したものとなってリンクによってつながれていく形式よりも、優れていると考えることができます。

レスポンスを生み出しやすくする工夫というとしては色々なものが考えられますが、まず基本的なこととして、レスポンスを付けたい発言を読みながら文章が書けるということがあげられます。

私たちがレスポンスを書く場合には、レスポンスを付けるメッセージを、場合によっては何度も読み直しながら、メッセージを書くのが普通でしょう(というか、読み返しながら書かないメッセージは、たいてい、何らかのトラブルの元を抱え込みやすいと思う)。ですから、なんらかの形で相手の発言をすぐに読み返すことができるかたちでメッセージが書けるようにすることが、コミュニケーションを生み出すには大切なことだと考えます。

また、発言やコメントの文脈を読み取るという点では、過去の発言を遡って読めるほうがよいと思います。相手の発言だけにレスポンスするというのは、どうしても視野が狭くなったものになり、また、相手の表現に過度に(過敏に)反応しすぎるように思います。たとえば、NIFTY でも、みんなが Ninja Term でコメントを書いていた頃と、茄子のようなログブラウザが登場してからでは、コメントの付き方などに変化があったように私は感じています(調査してみたら、社会学的に面白い結果が出るような気がします)。

もちろん、コメントがリニアしか付けられない(つまり分岐できない)ことにはメリットとデメリットとがあります。しかし、一つの系列としてしかコメントがつながらないという制約が、一定の文脈にそった形でのコミュニケーションを形作るという点は、私は積極的に評価すべき点だと考えます。

●コミュニティ?

相手の発言を読みながらレスポンスが書けるようにすること、さらには必要に応じて過去のコメントチェーン(スレッド)を簡単に読めること、この2点がレスポンスを生みやすくするためには重要なことだと思うのですが、さらにもう一つ、コミュニティを閉じないようにするというか、極論すればコミュニティを作らないようにするという点も重要ではないかと考えています。これについては、アメリカなどのバーチャル・コミュニティの議論(代表的なものがラインホールドのバーチャル・コミュニティですが)と異なる点だと思いますので、すこし詳しく語ってみたいと思います。

掲示板(会議室)というものは、たいていの場合、コミュニティとして語られることが多いわけです。バーチャル・コミュニティってわけですね。確かに、コミュニティという言葉で語るに相応しいようなコミュニケーションが行われている(またそれを目指している)のは事実なのでしょうが、私自身は、コミュニティという言葉を使うのは躊躇するわけです。

というのは、コミュニティを日本語で共同体と書けば感じられやすいと思うのですが、コミュニティは、一定のメンバーで閉じた集まりという側面があるからです。いってしまえば、ムラ社会といわれるような、閉塞的な、どこかで排他的な、そうした側面がコミュニティにはあるのは事実でしょう。それが気になる。

もちろん、会議室でコミュニケーションを重ねる中で、色々な常連の人たちが出てきたり、親しみを持った関係が生まれてくることは当然のことなんですが、だからといって、その人たちが特別な帰属意識(参加意識)を持ったり、それを誇ったりするようになるのは、必ずしも良いことだとは思えないのです。Web の会議室の利点というのは、過去の発言が比較的容易に読むことがあげられます。たしかに、この会議室のように発言が溜まってくると、過去の発言に目を通すといっても、簡単とは言いがたい状況にはなるわけですが、それでも、最近の動向ぐらいなら簡単にチェックできる。このことは、その場に居合わせなかった人、今、初めてアクセスした人であっても、話の流れを掴み、そこに入っていくことができるということだと考えます。この点こそが、Web で、誰もがアクセスできる形で会議室を設けることの意義の一つだと思うわけです。

で、限られたメンバーによる内輪話に閉じてしまわないための仕掛けが、話題ごとにスレッド(ページ)にして、トップページからはそのタイトルだけしか見せないということと、全くの匿名(本名やメールアドレスなどの入力を要求せず、ハンドルや偽名での参加が可能という意味での匿名)での参加を認めるということにつながります。

トップページには話題のタイトルしか並んでいないということは、ささいなことのように思えますが、このことは、誰が数多く発言しているのかといったことが表には現われないということです。あたりまえのことですが、このことが持っている意義は、けっこう大きいかもしれないと思うわけです。

もちろん、色々な発言を読んでいくうちに、たとえば田中求之があれこれと色々なところで偉そうに発言しているといったことはわかってくることではありますが、少なくとも、初めてアクセスした人から見たとき、その会議室が特定の常連が活発に発言しているのか、それとも色々な人が発言しているのかといったことは「分かりにくい」わけです。このことは、ある意味では会議室の雰囲気というか状況の把握にはマイナスなのかも知れませんが、特定のメンバーの存在を感じさせないという点ではプラスではないかと考えられるわけです。

未完