研究ノート

E メイルになにかを添付しようとしているのに，添付しわすれたまま送信してしまうということは私もよくやっている． Dredze ら [Dre 06] はこういうことがおこらないように，メッセージの内容を解析して添付物があるかどうかを自動的に判断して，送信直前またはメッセージを書いているときに警告するしくみを実現している． たしかにメッセージを解析すればかなり確実に添付すべきものがあるかどうかわかるとはおもうが，とはいっても，ほんとうにこれがただしい解決法なのだろうか?

Whittaker ら [Whi 96] が "email overload" について書いてからすでに 10 年になる [Fis 06]． "Email overload" とは，E メイルが単に他者との非同期的なテキスト・メッセージの交換につかわれるだけでなく，仕事 (task) の管理や個人的な情報の蓄積・ファイリングなどのさまざまな目的につかわれることをいう． この論文はかなりのインパクトをあたえたようにみえる． しかし，それにもかかわらず，それがでてからもメイル・システムやそのユーザインタフェースがあまり変化していない． また，それ以降おこなわれてきた研究もそれらを本質的に改革するものになっていないようにおもわれる．

Gwizdka ら [Gwi 04] はワーキングメモリ (WM) や視覚的なメモリ (VM) などに能力のひくいユーザをたすけるインタフェースによって，能力のひくいユーザの作業効率を大幅に改善することができること，また能力のたかいユーザの作業効率が多少低下することはあるとしても，それはかぎられていることをしめしている． この結果は示唆的である．

この研究ノートのつかいかたとして，いろいろ，こころみていくつもりである． ひとつの有力なつかいかたとして 「仮説検証」 がある． これは，まずこの場で仮説をのべて，それに関する文献をさがしたり実験をおこなったりしてそれを検証し，結果がでたらそれについて報告するということである． 成功することもあるだろうし失敗することもあるだろうが，いずれにしてもここで報告する． とりあえずは，この目的で使用するエントリーを 「仮説と検証」 というカテゴリーに分類してみようとおもう．

Email の研究において，workflow または flow ということばがつかわれる [Siu 06] [Ven 01]． 通常 workflow といえば複数のひとにまたがる仕事のながれを意味しているが，この文脈においては，ひとりのひとの作業のながれを意味しているようである． これは，Email の研究において個人をまたがる作業の最適化がめざされてこなかったことを意味しているとかんがえられる．

最近はメイルの処理のためにも検索を多用するユーザがふえてきた． Gmail のようにメイラーはそれに拍車をかけている． 私自身は 10 年以上まえから 「メイルを分類しない」，「過去のメイルは全文検索でさがす」，「メイルはすてない」 という方針をきめて，それを実行してきた． したがって，メイル検索の経験にかけては，ひとにまけないつもりである． それほどいろいろくふうをしてきたわけではないので，いろいろ不便はあったが，不便差に関する経験もメイル関係のプログラムを開発するうえではやくにたつのではないかとかんがえている．

有名な Whittaker らの論文 [Whi 96] をはじめ，メイルの内容やつかいかたを分析した論文は多数あるが，その大半は勤務先におけるメイルに関する分析である． 現在ではおおくのひとが個人使用などの目的のメイルアドレスももっているが，そこでのメイルを分析した論文は，すくなくとも私はまだみていない． 勤務先のメイルと個人使用のメイルとでは内容がかなりちがうはずであり，したがって，とくにそれをとりあげて分析する価値があるはずである．

メイルは非同期のコミュニケーション手段であるから，本来は緊急の用途にはつかえないはずである． ところが，最近は会議をはじめる 30 分まえ，ばあいによっては 10 分くらいまえになってやっとその通知をおくってくるひとがけっこういる． しかも，おどろくべきことは，そういうメイルがけっこう機能している，つまり，ひとがあつまるということである． そういうメッセージはメイルではなくて IM によっておくるべきだとおもうが，IM はつかっていないひともおおいので，メイルで連絡することになる (これも Whittaker らがいう overload のひとつである)．

Whittaker [Whi 96] らの論文がでて以来，メイルの用途のひとつとして "ファイリング" があることが周知されている． 私自身も，他人からおくられてきた添付ファイルつきのメイルをファイリングのために保存しておいたり，情報をファイリングするために書類を添付したメイルを自分あてにおくったり，覚え書きをメイルの本文として自分あてにおくったりすることがある． PC の本来のファイル・システムとメイルによるファイリングのシステムとが 2 重化されていることによる問題点も指摘されている [x]． しかし，私自身，2 重化されているために生じる利点を享受してもいる．

類似の内容のメイルを何度もだすとき，あるいはおなじあてさき (To:, Cc:) のメイルをいくつもだすときには，ひながたをつかうのが便利である (ここでいうひながたはメイルの背景などに関するものではなく，あてさきや文章の形式などに関するものである)． ひながた (テンプレート) といっても，べつに特別なしかけをつかう必要はかならずしもない． あらかじめ通常のメイルの形式でひながたをつくっておいて，それを適当なメイル・フォルダに保存しておけばよいだけである． あるいは，すでに送信または受信したメイルを保存しておいて，その一部をかきかえてつかうばあいも，それをひながたとしてつかっていることになる．

メイル・システム改革をめざした研究を構成するタスクとして，メイルの分類をおこなう． 従来の研究におけるメイルの分類は近視眼的だとおもわれる． これをあらためて，コラボレーション，あるいはプロジェクト指向でメイルを分類する必要がある．

小規模の研究活動の仕様はタスクとして定義し，タスクごとにカテゴリーを定義して，そのもとで研究をすすめる． 最初のタスクとして別項目でメイルの分類 (「タスク仕様: コラボレーション指向のメイル分類」) をとりあげる．

さまざまなメイルのつかいかたのそれぞれに関して実際にケーススタディをおこなうには相当のコストがかかる． とくに現在のメイル・システムが対応していないケースに関しては機能の開発・くみこみからはじめなければならない． そこで，とりあえずはシミュレーションを実施してみることにする． すなわち，コラボレーションの種類や登場人物を設定して，そのあいだのやりとりをストーリーとして記述する． 以下，ケースごとにエントリーをわけて記述することにする．

メイルの用法として定期報告と不定期報告があるとかんがえられる． 日誌や週報のような定期報告は従来は紙にかかれることがおおかったが， (証拠はあつめていないが) メイルでおくられることがおおくなってきているとかんがえられる． (より定型化されていればワークフロー・システムがつかわれることもあるだろうが，そこまではしていないばあいがおおいのではないだろうか.)

メイルの分類のひとつとして Q and A (質問返答) があるだろう． Q and A においては通常，返答期限がある． 返答が満足のいくものであれば返答がかえされた時点でやりとりは終結するが，満足できないときには再度，返答をもとめることになる． そのときは満足できない理由を説明する必要があるので，やりとりのかたちとしては Q and A が 2 回くりかえされるのにちかい (したがって，システムとしてはそのようにあつかうという選択肢もある)．

チャットはメイルの分類項目のなかで，もっとも制約のすくない形式である． 「チャット」 ということばは通常は IM のような実時間のメディアにおいてつかわれるが，ここではメイルをつかった 「おしゃべり」 を意味する． 返答期限はないし，そもそも返答はかならずしももとめられない． 3 人以上が関与するばあいは，だれがどのような順序でメッセージをおくってもよい． チャットのメンバーも自由に追加・削除できるべきであるが，メンバーは一応きめられるべきであろう． メンバーとして指定されていないひとが勝手にチャットに参加することは制限できるようにするべきであろう．

ECA (Event-Condition-Action) 規則によるフォローアップのための方法として，サーバ・ベース，受信クライアント・ベース，送信クライアント・ベースの 3 とおりがある． これらのうちサーバ・ベース (メイル・ワークフロー・サーバ・ベース) がもっともつよく，送信クライアント・ベースがもっともよわいとかんがえられるが，後者には送信クライアントだけがワークフロー対応していればフォローアップできるという利点がある．

メイル・ワークフローにおけるタスクおよび執行者の分類．

プロジェクトを構成するタスクがメイルの送信，受信，ルーティングだけであるようなプロジェクト (のクラス) をメイル・ワークフローという．

メイル・ワークフローの要素を定義する．

メイル・ワークフローにおいてはつぎのようなシステム・レベルのスケジュール管理機能がもとめられる．

論文，仕様書などのドキュメント，あるいはメモを定義する． 送信者と受信者とがことなるばあいと，同一のばあいとがある． 同一のときは単純なファイリング，ことなるときは FTP とみなすことができる． ただし，ドキュメントは更新されることがある． つまり，版管理が必要になる．

メイルのひながたの用法にテンプレートの利点をのべたが，そこには添付ファイルについては書かなかった． もしテンプレートにおいて添付ファイルをつけることを条件とすることができれば，テンプレートをつかうことが添付わすれ防止にもやくだつ．

David Mann による題記の本 (Apress 刊) を読んでいる． 最近の Windows (Vista/XP) におけるもっともおおきな変化 (進歩?) のひとつは Windows Workflow Foundation (WF) がとりいれられたことだとおもうが，この本はそれが Office 2007 においてどういかされるかを書いている．

Firefox もそうだが，Thunderbird でもあまりつかわれていない機能はデバッグがすすんでいない． メイルのテンプレート機能はワークフロー機能の基礎になる重要かつ便利な機能だが，Thunderbird のそれはうまく動作しない．