-263-
FSHISO(*1)の運営会議室が今年になって盛り上がりを見せている。特にプライバシー 関係の話題は興味深い。これは簡単に言うと「SYSOPがルールを無視して発言削除 しているのではないか」という会員からの批判が発端になっている一連の発言群 である。
私の記憶では、FSHISOはローカルルールを制定する時にFPROGのルールを参考に していたと思う。しかし、FPROGの最も重要なローカルルールである次の項目は、 そのまま採用されることはなかった。
発言者自身から削除の要求のあった発言は、その理由にかかわらず、SYSOP は保守機能を使ってその発言を削除することとします。FSHISOでは、これを参考にして似たような独自のルールを採用したようである。 要旨だけ紹介すると“書かれた発言に対して不利益があると考えた人は抗議する ことができ、SYSOPは該当発言へのリンクがあれば外して、発言者に削除の判断を 任せる”という感じである。具体的に詳細を知りたければ、FSHISOの「お知らせ」 を見て欲しい。
(FPROG ローカルルールより)
ただし、一部の場合はSYSOPが発言を削除することになっている。これが今回の 論争の種と思われる。
これを見ていただくと、私がFSHISOをハイレベルなフォーラムだと考えている ことを想像していただけると思う。私ごときのレベルの読解力では、何が書かれ ているのか理解するのに大変な苦労を要するのである。ただ、理解できないのが 私だけかというと、実はそうでもないらしい。なぜなら、実際、最近起きている トラブルの原因は何だろうか。それは「抗議・反論」の解釈の違いだったり、あ るいは「プライバシーの侵害」とは何かという解釈の違いだったりするのだ。>Ｃ SYSOPによる発言削除は、以下の場合に行う。 > > C-1. > ある発言が、プライバシーの侵害であり、発言削除が緊急に必要であると判断さ >れるとき。 > この場合、SYSOPは会議室に報告するものとする。 > C-2. > FSHISOの会員ではない人に対して向けられた発言が、ニフティ規約に違反する内 >容をもっていると判断される場合。ただし、この場合、SYSOPは、当該発言者に対し >て、その発言意図を問い、発言がFSHISOの会議室に掲載されることの問題を指摘し >た上で行う。その指摘は、必ず、削除行為の事前に行われ、発言者が意図を説明す >る機会を保証しなければならない。 > C-3. > 当事者が、Ｂ項に定めた抗議・反論をしたにも関らず、発言者が10日間何等の応 >答もせず、発言を放置させる意図が明らかなとき。 > この場合、当該発言はSYSOP預かりとする。発言者が発言の意図を会議室で表明し >削除に抗議した場合に限り、発言者の責任で当該発言を再ＵＰすることを妨げない。(NIFTY-Serve FSHISO, ANN 3、「えふしそのルール」(94/06/22)より」
例えば、「たとえ自ら公開した情報であっても、FSHISO以外のフォーラムに書 かれた内容をFSHISOに持ち込んだ場合はプライバシーの侵害とみなすことがある」 という意図を、この文面から想像しなければならないのである。私だったらたと え現在消滅しているフォーラムに5年前に書いた内容であっても、特に本人が自主 的に公開した内容は、もはやプライバシーには該当しないと判定する。ネットと いうのはそれ自体が今までマスコミが独占してきた「情報発信」という役割を個 人の手に開放したという大きな意義がある。つまり、そこに書いた内容は例えば 記者会見して発表した内容と同じ位の周知性が発生すると思うのだ。何万人も参 加している、また、誰でもその気になれば参加できる場というのは、たとえ会員 しか参照できないとしても、公開されたと看做すのに何の躊躇もいらないだろう。
しかしFSHISOではそのような発想は通用しなくて、プライバシー侵害のおそれ があるという理由でSYSOPの削除対象になるかもしれないのである。
想像を駆使しなければならない難問はそれだけではない。例えば、C-1ないしC- 3に該当しない場合にもSYSOP削除が有り得るか? これ以外にも会員規約上はSYSOP が削除することがあるケースが存在していて、最終決定はSYSOP次第ということに なっている。例えばコンピュータウイルスの入ったISHファイルや、「家庭ででき るサリンの作り方」のような文書ファイルはこれらに該当しないが、どうするの か?
「SYSOPによる発言削除は、以下の場合に行う。」という文章が既に難しい。こ れ以外の場合に発言を削除しないとも読めるし、これらは削除するケースの一例 に過ぎないとも読めなくはない。確かに「以下の場合にのみ行う」とは書いてな いから、一例であるという解釈も不可能ではないと思う。しかし、「以下の場合 にはSYSOPによる発言削除を行う」という表現に比べると、原文は「のみ」という ニュアンスが強く感じられるような気もする。こういう所を悩み始めるときりが ない。私なら「例えば、以下のような場合にはSYSOPが発言削除することがある」 と、一例であることを強調するか、あるいは「SYSOPによる発言削除は、以下の場 合のみ行う」と明確に範囲を表現したくなるのだが、テクニックとしては意図的 に曖昧に書くというのも一つの方法である。
条件判断が増えると処理が面倒になるというのが、プログラミングでは基本で ある。その都度該当するかどうかを考えるのは面倒くさい処理だ。全てのケース が判断可能である保証もないのである。だからFPROGのローカルルールは
その理由にかかわらず、SYSOPは保守機能を使ってその発言を削除すると言い切っているのである。
NIFTY-Serveでは、コメントが付いていない発言は、発言者がいつでもRDコマン ドで消すことが出来る。FPROGではこの機能を拡張して、コメントが付いても削除 できる。という程度の発想である。こういう仕様にすると、SYSOPに削除依頼が殺 到するおそれはないか? 確か、数年前だと思うが「ROM墓場からの声」 (*2)で、お遊 びの削除依頼があった。つまり「この発言をSYSOP削除してください」の類の発言 で、要するに一種のjokeである。考える必要は何もない。SYSOP削除にした。本人 の依頼があったから削除する。単純明快な処理だ。こういう希望を含めても、削 除要求は年に1度あるかないか程度である。現実的には、よほどの理由がないと、 削除要求する方も面倒なのだと思う。
ところで、FPROGローカルルールでは「保守機能を使って」という条件が付いて いる。コメントが付いていない場合は、発言者はRDコマンドで自分の発言を削除 できる。この場合も発言者がSYSOPに「消せ」と要求したら、SYSOPは「RDコマン ドを使って自分で消してください」と回答することはできない。ルールに従い、 保守機能を使って削除しなければならないのだ。
このように決めた理由は? うっかりハンドルを設定し間違えたり本名のまま発 言したり、普段使わない内緒のIDで書いてしまった場合に、ハンドルとID部分を 含めて削除できることを保証するためである。RDコマンドで削除した場合は、発 言ヘッダ部分のハンドルとIDは残ってしまうが、保守機能による削除の場合は、 それらの情報も本文と同時に消去されるという違いがある。
実際はこれらの要求は希にしか来ないので手間はかからないのだが、人手で処 理するのも面白くないから、最近はこれを機械化してしまう計画もある。SYSOP宛 てに決まったフォームのe-mailを送ったら、内容で示した発言を当方のオートパ イロットで自動的に消してしまおうというのだ。本人であるかどうかの確認はID の一致で判断するのだから、まさに機械的な処理である。わざわざ手作業で処理 するのは数万円でパソコンが買える時代のこととは思えない。
何かFSHISO的な風味は難解だと思っていたところ、最近FSHISOの心得という文 章を作ろうという動きがあって、文案も会議室でだされている。その文案だが、 何といってよいか、一言でいえば全然意味が分からなかった。この発言に、これ で分かりにくいと言われたら絶句するしかないという意味のことが書いてあった。 あまり係わらない方が無難だとは思ったのだが、いつにも増して分からなかった ので、つい勢いで、
「分かりにくい」
と書いてしまったら、これを書いた人、本当に絶句してしまったようです。申 し訳ありません。当方、ちと修行が足りないです。
FSHISOでは、心得原案はかなり好意的に受け止められている、または支持され ている、いや、少なくともFSHISOの発言者達はこの文章を理解しているようなの である。やはりハイレベルなフォーラムは違うのか。
ただ、考えてみると、これは読解力の問題だけが原因ではないのではないか、 と思えて来た。つまり、読解力だけの問題ではなく、FSHISO的思想とFPROG的思想 の違いがあるのではないか、と思い付いたのである。
FPROG的思想という表現自体がFSHISO的かもしれないが、言いかえれば、FSHISO で多用される表現を見ていると、プログラマー風発想と相性がいまひとつではな いか、と思える所があるのだ。
例えば、心得案の文中に「ハンドル・ネーム」「ニフティ規約」「ニフティ・ サーブ・ネットワーク」などの表現が出てくる。この傾向は該当発言に留まらな い。SYSOP自らの文章の中にも「電子会議室」「リアルタイム会議室」、「データ ライブラリー」といった表現が出てくる。蛇足かもしれないが、FPROGだったらこ れらは「ハンドル」、「NIFTY-Serve会員規約」、「NIFTY-Serve (又はニフティ サーブ)」、「電子会議 (又は会議室)」、「リアルタイム会議 (又はチャンネル)」 、「データライブラリ」と書く所である。
「データライブラリ」だけは状況が特殊なので先に説明する。NIFTY-Serveでは、 システムの表示するメニューの内容は「データライブラリ」となっているが、ニ フティが掲示する説明文の中では、殆どが「データライブラリー」と書かれてい る。なぜ一致しないか問い合わせたら、ニフティの回答は「ライブラリー」と表 記する方針だというものだった。
しかし、私の方針は「ライブラリ」と書くというものなのである。理由は次の 三つある。
三つ目は半分jokeだが、とにかく、このような用語を選択するというのが、ま ず多分プログラマー的発想なのである。変数定義の時に1文字違っただけで別のオ ブジェクトになるという世界で生活していると、厳密な表記を使うということを、 自然に身体が覚えてしまうのだろう。
さて、他の表現を考えてみると、「NIFTY-Serve」というサービス名称は登録商 標であり、つまり固有名詞である。人名や会社名、商品名は、ビジネスマナーと しては誤記するのは基本的に大変失礼なことであると看做す慣習がある。それを あえて別の記述にするというのは、何か含みがあると思うのだが、どうもそのあ たりは理解できないのである。
しかし、プログラマー的発想としてはマナーとか礼儀いう次元では考えないの である。単に「最初に定義された通りに記述する」という感覚なのだ。勝手に表 現を変えるとエラーが発生する、という日頃の学習成果かもしれない。
「電子会議室」という表現も、個人的には各フォーラムに「電子会議」という サービスがあって、そのサービスを選択すると20個程度の「会議室」というサー ビスがある、と理解している。ニフティの掲示している説明文を読むと、そのよ うな構成を前提にしていると考えられるのである。「電子会議室」と言われると 何を指しているのかよく分からなくなるのだ。多分会議室のことを指すのだとは 思うが、自信が持てないのである。そんなことどうでもいいじゃん、という割り 切りができないのがプログラマー的発想か? 「リアルタイム会議室」と表現して、 仮にそれがリアルタイム会議のサービス全体を意味するのか、そこにあるチャン ネルを意味するのか判断できなくても、現実的には何も困らないのである。 (*3)
ところで、「ニフティは電子会議室という表現を使っていない」と言い切れる かというと、実は「電子会議室」という表現が全くないわけではない。ただ、ど こにあるかを即答できる人は100人中に1人いるかいないか、という超カルト問題 であると思われる。実は私も「使っていない」と言い切ろうとして、念のためニ フティの掲示した文章のログをサーチしたら一個所だけ出てきて驚いたのだ。 (*4)
とにかく、この種の曖昧な未定義語が結構出てきて自由に解釈できるというの がFSHISO的ならば、FPROG的思想としては「未定義語を排除しよう」という潜在意 識が働いているのではないかと思われる程、曖昧な表現を避けようとするのでは ないか、もしくは未定義なら思いきって未定義だと言い切った上で使う:-)、とか、 仮の定義を突っ込んで話を進める傾向があるようも気がする。全部作るのが大変 な時にとりあえずスタブを使うという発想である。
もう一つ興味があったのは、文章の構成規則である。典型的だと思われる文章 を一つだけ引用させていただく。なお、内容に関しては特に考えない。
> また以上に列挙しました「個人情報」は、迂闊に、個人的な経験談とか個人 >的事情などを、公開の場（会議室・ＲＴ・ＤＬ）で発言し、開示したりしてい >ますと、情報の蓄積によって、推論から推定可能な場合が時にありえます。(BXD03020 Miranda さんによる、「FSHISO運営者より会員への言葉」、 nifty:FSHISO/MES/10/06855 1997-02-11 より引用)
これをパッと読んで「は?」と思ったのは、私の思考能力がかなり低下している せいかもしれない。最近、かなりハードなスケジュールが続いていて、精神的疲 労も限界に近付いているのは違いないのだ。で、私なりに理解した結果を、私な らこう書くという例を示せば、次のようになる。
また、個人的な経験談とか個人的事情などを迂闊に公開の場（会議室・ＲＴ ・ＤＬ）で発言したり開示したりすると、情報が蓄積して、その結果、以上に 列挙したような「個人情報」が推定できてしまう場合もあります。
細かい表現は趣味の問題だし、もしかすると原文と意味が違うのかもしれない が、その点はこちらの力不足ということでご容赦いただければ幸いである。
で、どこがポイントかというと、将来どうなるか分からないけど、現状のパラ ダイムから想像すれば、多数のプログラマーは基本的に細部の構成を逐次処理的 に書こうとする傾向があると思うのである。つまり、何がどうなって、こうなっ て、ああなって、結果こうだ、という順序で書くという意味だ。もちろん、プロ グラムの中には分岐とかgotoとか、その他スパイシーな要素もたくさんあるが、 それを議論すると炸裂するおそれがあるので、今回はパスする。
だったら、この種の文章も「ナニすればアレになる」という構成で書いた方が、 日頃プログラムで見慣れたパターンなので認識しやすい、ということではないか。 私の書き直した文は「〜すると、…できてしまう場合もある」という構造になっ ている。これは条件判断処理の書き方だ。
IF (個人的な経験談とか個人的事情などを…開示したりすると)
THEN (情報が蓄積して、その結果、…が推定できてしまう場合もあります)
という構造になっているのである。
原文に対して、無理にプログラミング的解釈を行うと、
CASE (以上に列挙しました「個人情報」は)
IF (迂闊に、…したりしていますと)
THEN (情報の蓄積によって、推論から推定可能な場合が時にありえます)
という感じか? キーワードはデタラメだが、最初に個人情報というクラスを限
定して、後の部分で、その性質を指摘している、と言えなくもない。もしかして
オブジェクト指向的思想? だったら単に私がOOに慣れてないとか遅れているとい
うことかもしれない。FSHISOはFPROGよりプログラミングにおいても進んでいるの
かもしれない。
さて、FSHISOのSYSOP氏が提案した入会希望者向けのオープニングメッセージの 案文中に、特に感動した表現が一つある。
また、興味のある会議室の過去の発言を少し逆上って、読まれ、会議室の雰 囲気を知ってから、発言されることをお勧めいたします。(GEC01342 WAKEI さんによる「RE^2:えふしそ整備計画」、 nifty:FSHISO/MES/10/06973 1997-02-16 より引用)
余談だが、普段控えめな人が会議室の雰囲気をチェックして「おっと、ここま で書いても構わないのか」と知った後に、一体どういうものを書くのか、と想像 してみると面白い。fj newsgroupでも「過去の投稿を読んでから」という主張を たまに見かけるが、fj.news.usageあたりの過去の投稿を読んで参考にすると、… さあどうなるか。
でも感動したのはそこではない。「逆上って」 (*5)というのは、やはり逆上した状 態を意味するのだろうか、と思い浮かべてしまったのだ。あまりにハマった表現 だ。ちなみに、「さかのぼる」は一般には「遡る」と書くのだが、あえてこう当 て字にしたのか単なるtypoなのかはよく分からない。個人的には、ぱっと見た時 のイメージが面白いのでこのまま採用して欲しいのだが、言霊というのは割と 強力だから、こう書いてあると後から来る人来る人皆逆上していたりすると大変 かも。そういえばbackupって直訳すると逆上かな、とか考えてみると、割と深い 表現かもしれない。
(*2) FPROGにある会議室。毎月末で閉めてリニューアルする。毎月2,000〜3,000程度の発言 がある。
(*3) その後の調査で「電子会議室」や「リアルタイム会議室」の意味がだいたい分かった。 これに関しては機会があれば書く。
(*4) NIFTY-Serveのオンラインマニュアルを検索すると、もっとたくさん出てくる。それ以 外の所だと、一個所しか知らないのだが…。オンラインマニュアルの中には「電子会議 室」という表現があるのだから、第三者がこの表現を使っても問題ないのでは、という 疑問があるだろうか。それは一見筋が通っているが、オンラインマニュアルの中には「 電子会議室」の定義は見当たらないのだ。
(*5) 本当はどういう意図か分からない。FSHISOでもこの件は無視されている。それはともか くとして、一般的には「逆上って」は「さかあがって」と読むようである。もちろん、 意味は違ってくるかもしれない。
COMPUTING AT CHAOS RUINS -263-
1997-02-18, NIFTY-Serve FPROG mes(6)-190
FPROG SYSOP / SDI00344 フィンローダ
(C) Phinloda 1997