昨晩 Mew をアップデートしたついでに、MHC もいれてみる。
メールベースのスケジューラ。Mew や Wanderlust や Gnus と連携する。
受けとったメールがスケジュールならば C-c . | する。 そのメールから日時がスキャンされ、メールに MHC 固有のヘッダをつけたコピーが指定したディレクトリに格納される。 メーラ上で C-c . . すれば今月のスケジュール一覧が出るので見たいものを選択して . や SPC を押すばそのメール(のコピー)が見られるわけ。
受けとったメールにはスケジュールの詳細が書いてあるわけだから、あらためて入力する必要もない。
emacs 上で作業できるし、多くの予定は電子メールではいってくるのでこりゃよさそげ。
Debian GNU/Linux sid で mhc 0.25+20010625-1 + mew では
(mhc-select-mailer-package 'mew)
を .emacs に追加して
cp /usr/share/doc/mhc/examples/DOT.schedule.sample.jp ~/.schedule
で使いはじめられる。
以前から何度も議題になる(けれども改善されない/しない)問題として、本社/東京オフィス間のコミュニケーション問題がある。 うまく情報共有ができていなかったり、共通認識になっていない背景にもとづいてのコミュニケーションによってうまく意思が伝わっていなかったりするという問題である。 特に電子メールによるコミュニケーションに多発気味のようである。
しかしなにもこれは本社/東京オフィス間だけの問題ではない。 電子メールをその特性を意識せずに使用することによって、コミュニケーションしていると思いながらも「実は一方通行」でしかなかったり、あるいは「その一方通行さえうまくできていな」かったりすることがままあるのである(もちろん自分も含めて)。
そこでまずは電子メールを含むコミュニケーションツールの利用方法について検討し、ガイドラインを決めていこうということになった。 もちろんガイドラインはシンプルかつ効果的なものにしたい。
まずは電子メールについて現状としての雑感を(特に自分の場合について)。
「ま、返事しなくてもいっか」と思わせるメールの筆頭は、メーリングリスト宛のもの。 以下のものは無視してしまう(あるいは先送りしているうちに忘れてしまう)事が多いタイプ。
「検討しなければならないなぁ(そのうち)」->「しばらくたっちゃたなぁ」->(リファイル)
「意見を考えなければならないなぁ」->「しばらくたっちゃたなぁ」->(リファイル)
○○した -> (完了報告なし) -> (リファイル)
(そうですね) -> (リファイル)
「○○について問題があればご指摘ください」-> 読めん (Mew が wvHtml で変換して表示してくれるからちょびっとだけ見るけれど)。
「○○について問題があればご指摘ください」-> 読めん (Mew が xlhtml で変換して表示してくれるからちょびっとだけ見るけれど)。
ヤバ。間違える(自分)。送信前に読み返しても、なぜか気がつかない。
まぁそういう場合もあるので、差し引いて読まないといかん。
いいね! 非常にいい。ほっとする。嬉しい。いい気分。
自分ではほとんど書かないんだけれど。
「誰に」「何を」「いつまでに」「どの品質で」して欲しいのかが不明確というのが問題の大部分を占めていると思う。 会話におけるリクエストでもこれを明確にできていないのだから、メールではなおさらな状態である。
逆に言うとこれらがはっきりしていて約束がかわされたならば、、添付ファイルフォーマットの問題などは些細な問題で(いや、面倒ではあるけれども)、相応に努力してしかるべきアクションをとっていくであろう。
それから、リクエストメールに対してはどうするにせよ「受ける」「断わる」「別の提案をする」というレスポンスをリクエストした者に返すべきだけれど、メールだとこれがないがしろになってしまう事も多い。 これも大きな課題であるな。
まずは、メッセージのタイプ(指示/命令? リクエスト? 情報? ……)を分析して、どのようにすれば効果的なコミュニケーションがなされるようになるか検討してみよう。
[ ビジネスメール ]
以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。
そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。 照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。
すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43
おお、ちょうどこういう切り口を探していたところだったんだ。 電子メールによるコミュニケーションも全く同じ枠組みである。 記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。
この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。
感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。 それから署名その他、一般的な話もいまのところ省略。
ポイントを列挙しただけなので、他人にもわかる形にはなっていない。
まずは自分自身に適用して、整理していってみることにする。
○○様へ # 受け手 △△の××(自分)です。 # 伝え手 テーマ ****** コミュニケーション設定 ○○の結論 # 答え (結論) ========== ... (ここまででポイントを言いきる。) 具体的な内容 # 答え (詳細) ============ 項目1 ----- .... - リスト項目 - リスト項目 項目2 ----- ... - リスト項目 - リスト項目
コミュニケーション設定を行う。
結論を書く。
根拠・資料などを書く。
どれか
メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。
L: は nanoformats の書式のひとつで位置を表すのに用いる。 Twitter などで現在地を示すのによく使われる。
自分も普段 Twitter を使っていて「L:秋葉原」などとしているわけだが、この間はその癖でケータイメールに L: しそうになった(http://twitter.com/.../4708946010)。習慣はおそろしいものだ。 しかし考えてみるとケータイメールでも活用すべきだよな。
用件や返事のついでに今いる場所を件名や本文に「L:場所」と書いておく。 簡潔だし、辞書登録していれば入力も簡単。
移動中のメールなら、受信者にあとどれぐらいで着くのか推測してもらえる。 そうでなくても「あの辺りに今いるんだ」と想像してもらえて、親近感をアップしてくれるに違いない。
まあ Twitter-ers 同士なら「イマココ!」は互いに Twitter に書き込んでチェックしあえるのであまり必要がないかもしれない。 けど 非 Twitter-er とのケータイメールでのやりとりでは L: の意味を伝えておくと便利じゃないかな。
あ、そういえばもともと電子メールでは「名前@どこどこ」っていう文化もあったよね(というか今でも使っている)。 しかしケータイメールではあらためて名乗ることはほとどないから見かけることもない。 Twitter では @ は at ではなく mention という意味に使われていることから今後 @ だと混乱しやすくなることも予想される。やはりここは L: を活用するのがよいんじゃないかと。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。