* email [#rc1e4434]
今のプロジェクトでは,email による社外とのやりとりが多い.
もちろん,メールはフォルダに分類してはいるのだが…とても見通しが悪い.
はっきり言って破綻している.
email の限界というのは,案外低いところにあるのではないだろうか.

** email リテラシーの問題 [#u5d376c4]

 1 問題 A
 2 └ Re: 問題 A
 3    └ 問題 B

これは「メール 2 のメンバー全員にメールを送りたい」というので,メール 2 に対して「返信」し,2 のメールとは奸計の無いメール 3 を書いた場合である.
メール一覧でツリー表示させるとこんな形で表示される.

 4 問題 A
 5 └ Re: 問題 A
 6 問題 B
 7 └ Re: 問題 B
 8 問題 A 解決

今度はスレッド破りの例.
8 のメールは問題 A に関するものだから,4 のスレッドにくっついている方が一覧性は高い.
が,別スレッドとして存在しているので,メール一覧で問題 A について追っていくことが困難となる.
「使っている人がスレッドという概念を知らない」という場合もあるのだが,Outlook Express がスレッドブレーカーだったのは,そう昔の話ではない.

** データ構造もしくは表示構造の問題 [#g65e33e9]

  9 問題 A
 10 └ Re: 問題 A
 11 問題 B
 12 └ Re: 問題 B
 13 現在の問題点のまとめ
 14 └ 問題 A 解決

今度は使っている人に(たぶん)問題は無いのに時系列が追いにくくなってしまっている例.
メール 13 でいままでの問題点をまとめていて,メール 14 で問題 A が解決したことを報告している.
メール 13 をメール 10 やメール 12 の返信として書くと特定のスレッドの下に埋もれてしまって,妙だ.
というわけでメール 13 を新たなスレッドとして起こしたのだろう.
そこにメール 14 が返信として付け加えられたのである.

実は email ヘッダ自体は,このような関係を表すことが可能な構造になっている.
References: 行に,参考となる email の ID を複数指定できるようになっているのである.
上記のメール群の場合は References: が
  9: なし
 10: 9
 11: なし
 12: 11
 13: 9 10 11 12
 14: 9 10 13
となっていれば,メールの関係をうまく表していることになる.

ところが今度はメールの関係が木構造にならないので,従来のスレッド表示では表現することはできない.
あえて表現するならば
  9 問題 A
 10 └ Re: 問題 A
 13    └ 現在の問題点のまとめ
 14       └ 問題 A 解決
 11 問題 B
 12 └ Re: 問題 B
 13    └ 現在の問題点のまとめ
というふうになるのかなぁ.

** メンバー管理の問題 [#x90640b1]

というのもある.
多人数でメールをやりとりしてると
> ん,そのメール,オレんとこ来てないぞ

というようなことが必ず発生する.

この対策としては,原始的な所では「アドレス帳を配布・交換」という方法もある.
が,アドレス帳というのは MUA に依存した形式であるため,異なる MUA を利用している人がいるとアウトである.
社内なら「MUA は〜を使うべし」というお達しで統一されていることも期待できるが,取引先で使ってる MUA まで統一されているなんてことは期待できない.

で,「メーリングリスト」というのがこの場合の常識的な解決策だろう.
が,大きな会社になってくると,サーバ管理部門の意識が現場の意識と離れてしまっているところも多々あるようであり,この様な場合は利用することが困難である.

** 途中参加者の問題 [#fac3dcc8]

誰かが途中でプロジェクトに参加した場合,メールによるいままでのやりとりの経緯がわからない,という問題が発生する.

原始的には「メンバーの誰かがいままでのメールを途中参加者へ転送してやる」という方法もあることにはある.
が,「今までのメール」が 100 通以上あったりなんかしたりすると…不可能ではないんだけど現実的ではないだろうなぁ.

aliases による簡易なものでなく fml とかを使ったメーリングリストならば,「過去メール取り寄せ」で問題は解決する.

** とか考えていると,そもそも [#y4334a88]

各人が同じ内容のメールの束を別々に管理しているのって,現代においては果たして合理的なのだろうか.
MUA の操作を誤って必要なメールを消してしまうかもしれないし,ユーザの PC が故障するかもしれない.
コンピュータウィルスにやられてマッサラからインストールし直し,なんてこともありうる.

そういうあたりを考えると「IMAP サーバにメールを蓄積する」というのも悪くはないのかもしれない.
メーリングリストへのメールは特定のフォルダに落ちるようにしておき,メンバはそのフォルダへの read only アクセスが可能とする.
これならば,各人が参照する「メールの束」の実体は1つだけとなるので,トータルでのメール管理のコストも下がるだろう.
また,先の「途中参加者」の問題も解決してしまう.

かくしてリソースは中央集権されてしまったわけだが,となると,
> 別に email にこだわらなくてもいいんじゃないか

という気分にもなってくる.
web 掲示板でもいいだろうし,Wiki なんかでもいいだろう.
そうすれば,錯綜したメール一覧を見てウッキー,なんてこともない.
というか,そうならないような web アプリを選べばいいだけの話である.

** というわけで [#a41d22e7]

email は,インターネット以前から存在したメディアであり,電話回線とモデムでバケツリレー転送されていた時代もあった.
インターネットに接続されていても,組織外への接続は 64 kbps の専用線,という時代もあった.

email の親戚に NetNews なんていう電子掲示板メディアもあるが,こちらは風前のともしびである.
理由はいろいろあるのだけど,大きな理由としては
> もう web 掲示板でいいじゃん

というのがあるだろう.
昔に比べて回線も太いし,web サーバの処理能力も上がっている.

昔と今では環境が違うわけだから,昔のベストソリューションが今でもベストとは限らない.
現代は現代でベストを模索すればいいわけで,ジジィのノスタルジーに付き合う義理はない.

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS