一応、本記事は公開されたＭＬについて書いてあります。公開 とは、不特定多数の人 の目のつくところにＭＬの存在が明らかになっている状態を指します。例として WWW上 というのが挙げられると思います。ＭＬの内容にも依りますが、公開すると、思っていた 以上の広範囲から問い合わせが来たりします。公開して、後悔しないように:-。どういう 反応があるか予測がつかない場合は、最初部分公開にしてメンバを募り、その後で、メン バ同士で協議しても遅くはないでしょう。部分公開の方法として一例をあげるなら、すで にあなたが別のＭＬに入っているとかであれば、そのＭＬ内だけにそっと告知するという 手もありです。参考までに私が知っている公開方法をレベル別に書いてみると

公開度	アクション (細分類)
closed	身内にDMで紹介する (転載の可・不可)
	自分が入っているMLで紹介する (転載の可・不可)
	同系統のＭＬで紹介を流してもらう (転載の可・不可)
	fj に書く・ 月刊ＭＬ紹介 に載セル
opened	Web に書九 (他者からのリンクの可・不可)・ 情報誌への掲載

etc.

細分類で、転載を可にするとかなり公開度が高九なります。ここで、「どのレベルまで の転載を許可するか？」という設定もできます。が、情報は流れ手こそ情報であり、流れ 出したら結構止間羅名いものです。ネットワーク上で情報の漏洩は良くある話です。

公開度を決目る時葉、マシンの処理能力や接続するネットワークの太差も考慮にいれた いものです。

公開・非公開についで選択肢のある、登録方式ですが、手動と自動の２種類に分かれま す。基本的にＭＬは 特定多数 の通信形態であると考えるのが妥当だという考え方から、 メンバ登録は、管理人が手動で行なうものが普通です。ＭＬソフトの機能・設定によって は、メンバ外の人からのメイルが来ると、そのメイルの情報を使ってＭＬソフトが登録作 業を自動的にしてくれるようにできますが、使用方法を間違えると問題が発生しますので 自動登録にする場合は、本当に必要な場合だけにしたほうがいいと思います。また、現在 では商品の広告や勧誘メイルをＭＬ宛てに投げてくるというケースがあり、自動登録の場 合ではメンバチェック(登録されたアドレス以外からのメイルを弾く機能)をしませんから そのアドレスを登録してしまうだけでなく、広告メイルまでメンバにばらまいてしまいま す。 公開度の高いＭＬでは、自動登録は極力避けた方が良いと思います。本来、自動登録機 能は、二次的なＭＬ(ひとつのＭＬのメンバの部分集合で構成されるサブＭＬ)に使われる ように作られています。

ある程度知識があって、それを運用できるメンバーだけだったら特に問題は発生しない のですが、必ずしもそうとはいえません。特に、公開されたＭＬにおいては、メールはお ろか、マシンの基本的操作もままならないレベルの人の参加もあるのです。問題が発生し やすい背景には、ユーザ教育の受け皿（教育する側）がないに等しい状況があることを挙 げることができると思います。雑誌や通信教育もあるとは思うのですが、雑誌では心もと ないし(やはり商品ですから:-)、通販で勉強したという人を私は知りません。大学や研究 機関などでは教育もしていると思いますが、プロバイダ経由からでしか入ってないユーザ は誰がその役割を果たしているといえるのでしょうか。

まずは、その「ＭＬに参加するための最低限度の知識」がどういうものか、考えてみま しょう。

1.言語

海外のＭＬに入ると、そのほとんどは英語が共通語です。逆に最近では外国からの参加 者が来るケースがあり(WWWで情報を公開していると来ます)、「日本語が理解できる」とい う条件をつけているＭＬもあります。意志疎通の手段となる言語が理解できる ということ は最低限のものとみていいでしょう。

2.コンピュータ・環境

少なくともメイル環境は整っていて欲しいですね。また、設定などで分からないことを 聞かれることがありますが、その話が「認められている」ＭＬを除き、基本的すぎる話は 結構メンバが嫌がる場合があるので注意が必要。どうしても分からないことがある場合は、 ＭＬの雰囲気や参加者の応対の感じをつかんでからにするか、気心知れた知人にするのが いい ということを参加者には伝えた方がいいでしょう。

ＭＬのシステムや、ユーザの範囲外となる部分についての質問も、できればＭＬ上でな く、管理人に直接問い合わせてもらうようにした方がいいと思います。内容的にＭＬの他 のメンバにも伝えた方がいい質問だった場合は、管理人が回答の際に、または回答を編集 してＭＬへフォアワードすると他から同様な質問があった場合に有効です。またフォアワ ードが好ましくないとき、コマンドメイルが実装されている場合はこの質問と回答をファ イルにまとめておいて、ユーザが取れるようにしておきましょう。

3.基本的なマナー

管理人が「管理人です」といって出て行くと、結構ＭＬの雰囲気がさめてしまうことが あります。この理由は、管理人の権限は管理人が思っている以上に大きく思われている節 が理由として考えられ、特に BBSユーザ の場合、管理人の権限はいわゆるシスオペと同義 に取っていることもあるようです。従来のケースであれば、管理人の権限はそんなに強く ないんだということを理解してもらえばよかったのですが、規約や規制を実施しているＭ Ｌや、これから導入を検討している場合は注意が必要になると思います。規約や規制が緩 いＭＬでは、管理人として出るのは仲裁や雰囲気の維持など、管理人として行使しないと いけない場合のみにして、それ以外では一人のユーザでいれば大丈夫だと思います。逆に そういうものが設定・制定されているＭＬでは、行使する回数も増えてきますのでいまま でのようにはいかないかもしれません。また権利がある分、責任も付随します。あまり重 く考えなくても大丈夫だとは思いますが……。ＭＬは管理人の 所有物 とはいうけれど、 その方法を誤ってしまっては意味がありません。

微妙ではありますが、同じ内容を伝える時、「管理人です」といって出した場合と、同 一人物でも名前(ハンドル)で出した時とで受け取り側でその効果が違うみたいです。実空 間の管理人が問題なのではなく、メール上の、名前として出た文字列としての、管理人の ほう、です。参加メンバの構成によって変わってくる部分なので実際に即した対応をしま しょう。

逆に(管理人の仕事として)教えないといけないこともあります。コマンドが扱える場合 はその使い方など、メンバとして知っていて欲しい情報はその筆頭といえるでしょう。そ のために、ＭＬのガイドやコマンドヘルプ(ある場合)、規約(これもある場合)などの情報 をまとめ、ユーザが取得できるように整えておく作業をしましょう。そして、本来ならガ イドや規約は「承諾した上で」加入するものですが、「ＭＬがある」という情報だけしか 得ないで登録希望を伝えてくるユーザがいますので、登録時にＤＭで確認の上でそれらを 送ってあげましょう。規約などについては、重要なことが定められているわけですから。

コマンドメイルを実装している場合は、仮に「多分分かっているだろう」と思われる事 象も冗長と思われがちですが解説しておきましょう。自分が分かっていることは相手も分 かっているだろうと思い込むのは、よくない癖です。あなたが今まで参加していたＭＬが あるのなら今までの経験を活かして FAQ を作ることもできるかと思います。あくまで

分からない人が読んで分かる

ように書きましょうね。書いた後、周囲の人に意見を聞いてみるといいかも知れません。 ＭＬ固有の情報も、ちゃんとまとめておくほうが親切なＭＬといえるでしょう。

数年前までは別に問題にもなりませんでした。ＭＬは管理人の所有物であり、管理人の 好意による運営 というのが一般的だったからです。インターネットがより開放的になり、 ユーザも各種存在するようになると、同じような対応でそれまでの状態を続けることは難 しくなりました。

商用利用ができるようになって、あるいは昔ほど規制が厳しくなくなってきたおかげで？ この 好意による運営 が公共サービスと勘違いされたという事件がありました。また、プ ロバイダやリメーリングサービスも出てきたので、さらにその混同は進む一方と考えられ ます。配送などのネットワークトラブル(配送遅延は日常茶飯事…電子メイルの速達性を過 信しているユーザからの苦情がある)、また、ホストマシンの故障などでのサービスの停止 のとき、混同しているユーザからは驚くような苦情が届くことがあったりします。プロバ イダサービスを利用している場合、どこまでが管理人の責任でどこからがプロバイダの責 任になるのか、一度考えておいたほうがいいでしょう。苦情に対してどのように回答すれ ばいいのか、自分なりにシミュレーションしておく(もちろん障害対応の方も)といざとい う時のためにいいと思います。基本的に管理人の手の届かない範囲(sendmail や配送中の 事故など)は管理人が謝る必要はないです(が、そういうことだ という説明ができるように)。

よくあるケースとしては、
・「出したのにまだ戻って来ませんが……。」 → まず、いつ出したのか聞いてください。log(例えば /var/log/syslog* や maillog 等)があるのならそれを見てもらって、ちゃんとそこから外へ配送が行われたか確認 しましょう。その後、ＭＬのlogを確認して、受理されて、再配送されたことを確認、 もし、ちゃんと再配送されているのであれば、経路でつっかかってる可能性が大で す。ユーザにも、事前にそういうことは起こりうるんだよ、という説明をし、戻って こないからといって、何通も同じものを出させないように注意しておくことも大切だ と思います。
また、遅延ならいずれ時間が経てば来ますが、時に通信経路上で消失してしまうこ ともある、ということを知らせておいた方がよいでしょう。重要なメイルは自分のと ころにも残しておくように…と。

ＭＬによっては通し番号(X-Ml-Count: 等)があるかも知れません。その時には…
・「届く順番がぐちゃぐちゃなんですけど……。」 → 必ずしも、番号順には届かないことを説明しましょう。余裕があれば、必ずしも同 じ経路を伝って配送されるとは限らないこと、違った経路先で、片一方が重ければ 重い方のメイルは遅延します。バケツリレー式の配送であることを説明すればいい のではないかと思います。

現在、インフラストラクチャの整備が進んでいますが、それにも増してユーザ数の増加 と、ネットワークトラフィックの増加(http)が速いです。配送が遅れるケースは当たり前 になっています。遅れる理由はさまざまですが、traceroute(tracert) などでネットワー クの状態を調べたり、log で送り出しはしたものの、途中の経路でつっかかってることを、 車の渋滞かなにかで例示して説明してあげましょう。とりあえず、

なにかあったら log を確認

そのための、log です。ぜひ活用しましょう。

また、NIFTY で受け取ってたり、MSIM(Microsoft Internet Mail)などを使用している場 合では削除されて見ることはできないですが、メイルヘッダを見る癖もつけましょう。配送 の状態やつっかかり具合が記録されている部分です。log と同様、重要です。

プロバイダなどで運用している場合、プロバイダ側の責任範疇と思われる部分で原因が考 えられるようなときは、プロバイダの運用管理部門に問い合わせたりする姿勢も大切です。 あなたの提案が、状況を変えるかもしれません。ただし、

どうなっているんだ？責任者出せ、責任者！

という喧嘩腰では、何も事態は進展しません。悪化する一方です。ＭＬで、何か分からない ことがあれば管理人に問い合わせが来ます。その時、上のようなメイルが来たら嬉しくない でしょう？同じです。確かに、プロバイダとあなたは、顧客という形で契約を結んでいます。 ですから、怒りたくなるのも分かります。しかし、状況を好転させたいなら、情報を整理し、 冷静に、

いつ、どういう条件で、こういうエラーが起きました。 これこれという状況(logなどで確認する)なので、どうも この辺りが原因と思われますが、どうにかならないもの でしょうか

原因の探求については、かならずしも当たってなくても構いませんが、責任のなすりつけ はいけません。もし、結果として自分のプログラム側のエラーであっても、その原因がはっ きりしたところで、「私はこのプログラムが使いたいんです。どうか使えるようにサービス を拡張してもらえないだろうか？」という話にもっていくことも可能ではないでしょうか。 配送遅延の場合でも、「現在のトラフィックを考えるにあなたのところの回線は細くないだ ろうか？ユーザ数も増えてきたのだから、回線の増強工事とか検討してもらえないだろうか ？」あなたは、プロバイダの一ユーザです。提案する権利もしくはおかしな点の報告の義務 があるのかも知れません。

提案・報告はどんどんした方がいいと思います。自分のために、ひいてはプロバイダのた めに。プロバイダの運用部門(担当者)とは いい関係 にいたいものです。

最初は非常に難しいかもしれません。なにせ一般論がないのですから。でもそれほど心 配はいりません。不安が大きいようであれば、管理人を複数置くことも可能です。知人に 協力を要請して手伝ってもらうとか可能だと思います。また、すでにどこかのＭＬに入っ ているならば、そこの管理人や、メンバで他のＭＬの管理人をしている人に質問してみる とか方法はいくらでもあります。さきほども書きましたが、知らないということは恥ずか しいことではありません。分からないことをそのままに放っておくことが恥ずかしいこと なのです。

最初は規模の小さな、メンバも知り合いだけといった閉鎖的(closed)なＭＬから始めて いくと徐々に慣れてきて自信もついてくると思います。

客観的に判断することが必要です。

基本的には門戸を広く開け(これを狭める唯一の条件は公開度だけ)、ＭＬの中心話 題に興味がある人であれば誰でも参加できるのが理想です。しかし、"問題児"はどこ にもいるもので？、もしその人の参加を認めると、ＭＬの評判まで落ちかねない、等 の理由で参加をお断りしないといけないと判断するときもあるでしょう。そのときは 理由をはっきり明示してお断りするようにしましょう。本当はそんなこと、したくな いですがね、管理人のつらいとこかもしれません。この お断り の基準を不正して、 個人的に気に入らん！ とかの理由で参加を却下してしまうのはどうでしょうか？ＭＬ は管理人の所有物、たしかにそうですが、管理人の独裁は、孤立を招きかねません。 「俺はそうしたいんだ！」という向きには何もいいませんが、私は好きになれません。 いかがなものでしょうか。

プロバイダサービスの場合では切ってくれないことがほとんどです。

使用するＭＬプログラムによってこの辺りの話は変わってきます。fml系は、コマン ド用アドレスの使用を推奨していますが、配送用アドレスとの併用ができます。この 場合は誤配送が発生する可能性があります。majordomo の場合は、コマンド用アドレ スが別に用意されているのが普通のようですので、使用するサービス・プロバイダで 確認をしてください。

各管理人の器次第

強制をする気はありません。あくまで管理人の判断に任せます。ただ、管理人が許 容しても、ユーザ(他のＭＬメンバ)が許さない場合もあります。正しい状況判断を心 がけましょう。