メール件名のべからず集

メールの件名は非常に重要だ。みんな、1日に大量のメールを受信している。いちいち全部に目を通していられない。そんな相手にメールを読んでもらうためには、件名を工夫する必要がある。よい件名の付け方は別の機会に書くとして、これはやってはいけないという件名をいくつか挙げる。

1. 用件が分からない件名

「教えてください」「質問」「ご参考資料」といった件名はだめだ。最低でも、何について教えて欲しいのか、何についての参考資料なのかを明示すること。私は、括弧でこれらの語句をくくり、その後に主題を書くようにしている。

（例）
【質問】○○の性能
[Question] Performance of XXXXXX

2. 「緊急」「大至急」「URGENT」を使った件名

トラブルが深刻なときに、「緊急 ○○社のトラブル」「URGENT: XXXX doesn't work」と、件名に「緊急」「大至急」「Urgent」をつけたメールをときどき見かける。ご丁寧に感嘆符付きで送る人もいる。最高記録は感嘆符4つの「!!UREGENT!! 」だ。 読んでもらいたいメールには「URGENT」をつけるようにと指導している本もある（佐々木かをり著「さっと書けて心が伝わる英文メール術 ― あなたのビジネスをパワーアップ!」）。

国際コミュニケーションの専門家のお勧めだが、やめた方がいいと私は思う。相手の事情を考えず、自分の都合を押しつけているからだ。実際、相手の気分を概して、関係が悪化したことがある。念のため、メールを送ったのは私ではない。

それに、緊急の用件のときにメールを使うこと自体がおかしい。こういうときは電話を1本かけるべきだ。複数の関係者に知らせたいときは、電話の後でまとめのメールを送ればよい。重要な用件であればあるほど、1対1の直接コミュニケーションを使うべきだ。

ちなみに、この手の件名はスパムメールと誤認識されるおそれがあるという意見も紹介しておこう（参考記事1）。佐々木かをり氏の著書の記述はイーウーマンのWebにも載っている（参考記事2）。日付が1997年だ。スパムメールという言葉すら知られていなかった時代のノウハウであり、すでに時代遅れといっていいだろう。

私は、顧客の重大トラブルについて海外の幹部の注意を促したいときは、「Need your help」と書くようにしている。これは、以前勤めていた会社の社長が使っていた方法だ。「Urgent」と書くより、ずっと穏やかで冷静な印象を与えるはずだ。

（例）
[Need your help] Problem at XXXXX

3. 全部大文字の件名

幸いにしてあまり見かけないが、全部大文字の件名は御法度だ。本文も同じである。大文字だけで書いた件名や文は、大きな声で叫んでいるのと同じだ。ビジネスの場で使うべきではない。いくら丁寧な表現（たとえばWould you ・・・）を使っても、これを大文字だけで書くと、ものすごく横柄に、上から見下して指示しているように取られる。

（参考記事1）
スパムに間違われない電子メール件名の付け方
http://allabout.co.jp/study/bizenglish/closeup/CU20050623A/

（参考記事2）
英文メール入門 【第2回】必ず開いてもらえるうまいタイトルの付け方
http://www.ewoman.co.jp/eng/mail/02.html

（当ブログの関連記事）

「インパクト倍増文章術」
http://raven.air-nifty.com/night/2005/10/post_7394.html

聴衆をひきつける講演タイトルの付け方
http://raven.air-nifty.com/night/2005/11/post_8dc5.html

メールのテキスト整形（秀丸エディタのマクロ）
http://raven.air-nifty.com/night/2005/11/post_b2da.html

ビジネスメールに感嘆符は禁物
http://raven.air-nifty.com/night/2006/07/post_e68d.html

サーバ「統合」かサーバ「集約」か

最近のIT業界では、管理コストを削減するためのサーバやストレージの「統合」が重要なキーワードである。これは「Consolidation」に対する訳語であるが、私は「集約」の方がいいと思っている。理由は、「Integration」も同じく「統合」と訳されていて、この2つの区別がつけられないからだ。

先日翻訳した文書に、「サーバをconsolidateする際には、既存環境とのintegrationが必要だ」という主旨の文があった。これをどちらも「統合」と訳すと、「サーバを統合する際には、既存環境との統合が必要だ」と、何をいっているのかわからない文になってしまう。原文が別の言葉を使っているなら、訳語も別にするべきだ。

「Integration」は、複数のものを組み合わせることによって、お互いに足りないところを補い合い、完全なものにするという意味だ。American Heritage Dictionaryでは「To make into a whole by bringing all parts together」と解説している。「Integrity（完全性）」も同じ語源だ。IT業界で「Integration」といえば、複数の監視ソフトを連携させて、システム全体の状況を1台のコンソールで把握できるようにするといった場合に使われる。1つのソフトでは監視できない部分を、別のソフトからメッセージをもらうことで補い、完全な監視システムを作り上げるというわけだ。

いっぽう「Consolidation」は、「To unite into one system or whole」、つまり、いくつかのものを1つにまとめるという意味である。単語の成り立ちは「con - sol -i - date」であり、「solo」と同じ語幹を持っていることがわかる。Server Consolidationは、別々に購入したサーバを、仮想化ソフトウェアを使って1台のサーバにまとめることであり、Storage Consolidationは、あちこちに散在しているディスクを、やはり仮想化技術を使用して1つのプールにまとめるといった具合に使われる。この場合、まとめられる対象のサーバ群やストレージ群がお互いに何かを補っているわけではなく、1つにすることで効率化を狙っている。

いってみれば、Integrationは「1 + 1 = 2もしくは3」であり、Consolidationは「1 + 1 = 1」である。全く違う概念であり、「統合」という1つの言葉で表現するのは適当ではない。Consolidationは「集約」とするべきだ。

しかし、おそらく手遅れだ。Consolidationの訳語として「統合」がほぼ定着している。これから「集約」を普及させて行くのは難しいし。もっとも、ほとんどの人はここまで言葉のニュアンスを気にしていないという気もする。翻訳者がきちんと「集約」と訳しても、チェックする発注側のIT業界の人間が「統合」に直してしまうかもしれない。

Cygwinのインストール

仕事用PCにCygwinをインストールした。主に、UNIX系の環境で採取した資料を処理するためだ。

いま取り扱っている製品はWindowsとUNIX系の混在環境で使うものなので、トラブルシューティングの資料も両方のプラットフォームで採取する。文字コードやファイルの圧縮形式だけでなく、テキストの改行コードも異なるファイルを取り扱う。

いまのところ、Windowsのみで処理できる環境を整えている。テキストは秀丸エディタ。文字コードや改行コードを自動認識して、文字化けせずに表示してくれる。強力なマクロ機能や正規表現を使った検索やgrep機能も重宝する。圧縮解凍ツールはExplzhと各種アーカイバDLLだ。ログ解析・整形用にはActive Perl。そのほか、バイナリエディタやファイル比較ツールなど、だいたいWindowsのソフトでまかなっている。

唯一うまくいかないのが、gzipで圧縮したファイルの解凍だ。UNIX系プラットフォームの資料は、tarとgzipで書庫化・圧縮して送ってくることが多い。Explzhとtar32.dllで処理できるのだが、きちんと解凍できないものがたまにある。ログファイルの最後の方が切れてしまう。最初は、圧縮時のミスだと思っていた。しかしLinuxではきちんと解凍できるので、tar32.dllに問題がありそうだ。

1人でLinuxとWindowsの2台のPCを持つほど裕福な会社ではないし、VMWareでWindowsとLinuxを同時稼働させられるほどパワフルなPCでもない。そもそも、gzipとtarだけのためにLinuxをインストールするのは馬鹿馬鹿しい。こういうときはCygwinで十分だ。

Cygwinは、インストールしただけでは日本語が表示されないので、少しカスタマイズした。今後のためにメモとして記録しておく。参考記事は末尾に記す。

bashのカスタマイズは2箇所。まず/etc/skel/.initrcに以下を追記。

set kanji-code sjis
set convert-meta off
set meta-flag on
set output-meta on

次に、/etc/profileに以下を追記。

export LANG=ja_JP.SJIS
export TZ=JST-9
export JLESSCHARSET=japanese-sjis

lsで8ビット目を表示させるためにaliasを設定する。/etc/profileに以下を追記。

alias ls='ls --show-control-chars --color -F'

ホームディレクトリを設定する。

マイドキュメント内にCygwin_homeディレクトリを作成
Windowsのユーザ環境変数にHOMEを追加し、<マイドキュメント>\Cygwin_homeを設定

ひととおり使えるが、解凍したときにディレクトリに書き込めず、Permission Deniedエラーになることがある。ユーザやグループの設定が不足しているような気がする。また、実害はないが、ls -lコマンドの1行目の「合計」が文字化けする。

（参考記事）
Studio Sixnine.「Cygwin Documentation Library」
http://www.sixnine.net/cygwin/cygwin-doc/index.html

uenox HomePage「Cygwin 日本語化」
http://uenox.ld.infoseek.co.jp/cygwin/japanese.html

Cygwin情報
http://www.jaist.ac.jp/~fujieda/cygwin/

プレゼンテーションとウナギ屋のタレ

私のプレゼンテーション資料の作り方は、老舗のウナギ屋のタレと同じだ。ウナギ屋のタレは、少しずつ継ぎ足しながら大事に仕込み、それが店の味になっている。プレゼンテーション資料も、一気に作るのではなく、必要最小限のものができたところで一度使ってみて、その反省をもとに修正したり不足部分を補ったりする。継ぎ足し継ぎ足しして、徐々に完成度の高いプレゼンテーション資料に仕上げていく。

最初に使うときは、見た目や体裁は二の次である。アニメーションはつけないし、図も非常に少ない。ほとんど字ばかりで、キーワードが箇条書きになっているだけのプレゼンテーション資料ですませることが多い。その代わり、話の流れやポイントをじゅうぶんに練る。プレゼンテーションは発表者の話が主体であるべきなので、これが最も大事だ。へたにプレゼンテーション資料に装飾を加えると、聴衆の注意がそちらに行ってしまい、話に集中してくれない。

とはいえ、絵や図の多いプレゼンが日本では主流だから、このままでは物足りないはずだ。持ち帰った配付資料で勉強しようという場合に、キーワードだけの資料では困るだろう。日本人は、話は聞かなくても資料は読む。受験勉強の悪影響だろうか。パートナービジネス主体のベンダーは、プレゼン資料をパートナーに引き継いで、販売活動に役立ててもらうこともある。その場合も、字ばかりのプレゼンではパートナーが使い切れない。

そこで、図やアニメーションなどを少しずつ付け加えて、見栄えのするプレゼンテーションに仕上げていくわけだ。最初から完璧な資料を作るのは、どだい無理な話だし、喋りが主であるべきプレゼンテーションでそれを目指す必要もない。「ウナギ屋のタレ」方式で、徐々に継ぎ足していけばよい。

（関連記事）

効果的なプレゼンとデモのヒント
http://raven.air-nifty.com/night/2005/10/cognos_performa_c0e2.html

聴衆をひきつける講演タイトルの付け方
http://raven.air-nifty.com/night/2005/11/post_8dc5.html

講演時間の注意点
http://raven.air-nifty.com/night/2005/11/post_23ed.html

講演資料を事前に配布するべきか
http://raven.air-nifty.com/night/2005/12/post_2ab2.html

ThinkPadのプレゼンテーション・ディレクター
http://raven.air-nifty.com/night/2006/05/thinkpad_eb97.html

Googleデスクトップ

デスクトップ検索ソフトを、WindowsデスクトップサーチからGoogleデスクトップに替えた。Windowsデスクトップサーチは、Outlookメールがどのメールフォルダにあるかを検索結果画面で見られるところが気に入っていた。しかし、検索に引っかからないメールや文書が散見される。Googleデスクトップでは、そういったメールもきちんと見つかる。

最初のバージョンに比べて、検索対象フォルダの指定もやりやすくなったし、ネットワークドライブも検索できるようになった。進化のスピードはGoogleデスクトップの方が明らかに速い。Windowsデスクトップサーチは、最初のリリースからまったく更新されていない。

Googleデスクトップは、ユーザインタフェースがWebブラウザだ。内部にブラウザのプロセス名などを持っているらしく、Sleipnirをデフォルトブラウザにしていても、Internet Explorerが起動する（参考記事1）。これは少々使いにくい。

しかし、SleipnirとGoogleデスクトップを連携させる方法があった（参考記事2）。Sleipnirの検索ツールバーにGoogleデスクトップを設定するのだ。Sleipnirで検索して、結果もSleipnirで表示することができる。残念ながら、Ctrlキー2回押下で表示する検索ウインドウで検索すると、その結果はInternet Explorerで表示されてしまう。

Googleデスクトップのアイコン設定方法も解説してあり、非常に助かる（参考記事3）。ひとつ付け加えると、同じアイコンファイルをコピーして「desktop.google.co.jp16.ico」というファイルを作っておくとよい。「16」付きのアイコンは検索エンジンボタン（画面の右側）が、「16」なしのファイルは検索キーワード入力フィールド（画面の左側）が使っているようだ。

（参考記事1）
続 Google Desktop Search 連携手段
http://naoya.dyndns.org/~naoya/mt/archives/001400.html

（参考記事2）
Sleipnir検索バーでGoogleデスクトップ検索
http://dearborn.at.webry.info/200511/article_11.html

（参考記事3）
Sleipnir: Googleデスクトップのアイコンを追加
http://dearborn.at.webry.info/200511/article_18.html

JCBコールセンターの「ご安心ください」

JCBのコールセンターに電話をかけたとき、応対した女性の「ご安心ください」というひとことが心に残った。

電話をかけたのは、新規に契約したクレジットカードが届いたが、支払い口座が「コンビニ支払い」になっていたからだ。申込書には銀行口座を書いたはず。不安になって電話をしたところ、どうやらカード発送と口座登録のタイミングのズレが原因だったらしい。

「ご安心ください」という言葉は、私の質問に答えるときの第一声だ。「ご安心ください。お客様の銀行口座は登録されております」。心配して電話しているこちらにとって、最初のひとことはとても気持ちよかった。

プレゼンテーションの講師として質問を受けるときや、ユーザとの打ち合わせで質問されたときも、まず結論を答えるのが原則だ。「はい、そのとおりです」「いえ、違います」と結論を提示することで、疑問を持っている相手を宙ぶらりんにせずにすむ。

これは簡単なようでいて、けっこう難しい。特にITエンジニアは、ものごとを論理立ててきちんと説明しようとする。それが災いして、細かい説明をくどくどとしゃべってしまい、結論を最後に回しがちだ。対話だけでなく、メールもそうである。

細部にこだわりすぎて大局を見逃すことを戒める「木を見て森を見ず」という言葉がある。プレゼンテーションやビジネス文書も同様である。まず大まかな地図を示して、これから何を話すのか、どういうゴールを目指しているのかを提示し、そのあとで各論を述べる。これによって受け手（聴衆、読者）が話を理解しやすくなる。

ただし、「結論を先に」という大原則を意図的に破ったほうがよいケースも存在する。これについては、別の機会に書く。

ビジネスメールに感嘆符は禁物

紙で配布・提出するビジネス文書に感嘆符を使う人はいないだろう。いっぽう、メールで感嘆符を使う人は少なくない。メールがカジュアルなコミュニケーション手段なので、気分がゆるみ、つい使ってしまうのだろう。しかし、それも時と場合によりけりだ。

感嘆符を使っていいのは、よい知らせのときだけだと私は考えている。英文メールでも日本語メールでも同じだ。

うまくいきました。ありがとう！
商談が取れました！
Thank you for your help!

こういう使い方は全く問題ないし、相手との人間関係を強化するの役立つ。

さて、次のメールはどうだろう。ある日本のエンジニアが、米国ベンダーのサポートにトラブルを報告したものだ。

Hi,

I cannot create a file whose name is Japanese!!
（中略）
Then I get a logfile.
Please analyze!!!!!!!

Thank you.

最後の感嘆符7つも原文のままである。これを受け取ったアメリカのエンジニアがどう感じたのか、想像するのは簡単だ。ヒステリックにわめき散らしているだけの、子供のような人間だと思ったはずだ。日本語で書くと、こんな感じだろうか。まともなビジネスパーソンが書く文章ではない。

日本語のファイル名が作れないぞ！
ログファイルを採取した。
解析してくれ！！！！！！！

トラブルであわてていたり、エンドユーザに責め立てられてイライラしているとしても、それをぐっとこらえて対処するのが「大人の」ビジネスパーソンだ。感嘆符の多いメールは、ちんぴらが粋がっているような印象を受ける。大物は急がずあわてず、ゆっくり話しながら凄みをきかせるのである。

中田英寿はビジネス界で成功するか

サッカー選手を現役引退した中田英寿がビジネス界に進出するのではないかとの憶測がある。彼の進路についてとやかく言うつもりはないが、少々気になるのは彼のコミュニケーション力だ。マスコミを通して伝わってくる範囲で判断するしかないが、あまりコミュニケーションが得意ではなさそうにみえる。移籍先のチームでも、監督や他の選手とうまくいっていなかったようで、期待されて入団したのに、徐々に出場機会が減ってしまった。

ビジネスでコミュニケーションがきわめて重要なことはいうまでもない。サッカーと同じく、人を動かし、チームで目標に向かっていかなければならない。引退声明「人生とは旅であり、旅とは人生である」に中田が書いた次の部分を読むと、彼自身、コミュニケーションの難しさを感じていたようだ。

時には励まし、時には怒鳴り、時には相手を怒らせてしまったこともあった。

だが、メンバーには最後まで上手に伝えることは出来なかった。

さて、サッカー界でのコミュニケーションがうまくいかなかった中田が、ビジネス界・スポーツ界を問わず、今後の活躍の場で成功を納めるだろうか。社外向けの情報発信は、自分のホームページで情報を出すというこれまでの方法でなんとかやっていけるだろう。仕事仲間も、自分の気心の知れた人間だけを集めればよい。社外のビジネスパートナーはどうだろう。これも、馬の合う人とだけビジネスをやるという選択がある。果たしてそれでビジネスが成り立つか。

話は変わるが、彼の引退声明は評判がよく、フィオレンティーナがホームページに翻訳転載しただけでなく、FIFAがホームページへの転載依頼を申し込んできたり、学校の授業や教科書に使いたいという依頼が舞い込んだりしている。名文に対して重箱の隅をつつくようで気が引けるが、気に入らないところが一箇所ある。「“新たな自分”探しの旅」という部分だ。他人と一線を画す生き方を貫いてきた彼が、女性向け転職情報誌などでいやとなるほど見かける「自分探し」というありきたりの表現を使ったのにはがっかりした。そのほかの部分が彼の考え方や生き様をよく表現しているだけに、残念だ。

引退発表をホームページの声明文で行われ、会見をやらせてもらえなかったマスコミは、ほぞを噛む思いだったろう。とてもインタビューといえない低レベルの質問しかできなかった彼らの自業自得である。中田に限らず、タレントやスポーツ選手がホームページで自らメッセージを発信し始めた。言ってみれば、問屋の中抜きだ。日経ビジネスの井上編集長の、マスコミの存在意義が問われているという話は一聴の価値がある（参考記事）。

（参考記事）
日経ビジネス編集長の終わらない話 2006年7月7日号
http://business.nikkeibp.co.jp/podcast/index.shtml

Windows Mobileのタイムゾーン機能

「海外出張で便利なOutlookとiPAQのタイムゾーン機能」という記事で、複数のタイムゾーンを切り替える技を紹介した。私はこの機能をすばらしいと思っているが、映像系エンジニア/アナリストの小寺信良氏の好みには合わないようだ（参考記事）。

時差を考えながら現地の予定を入力するのが面倒だという小寺氏の主張はもっともだ。これは、Windows Mobileが複数タイムゾーンを同時に表示できないからである。PDAや、PDA機能付き携帯電話をスタンドアロンで主に使う人は、やりにくいだろう。私はOutlookがメインで、PDAはほぼ閲覧のみの運用だ。Outlookで訪問先の時間を見ながら入力することにしているので、特に不都合を感じていない。

さらに、出張時に現地時間だけを気にすればよいのなら、タイムゾーン切り替えに連動して予定時刻を変更する機能は不要だ。しかし現地で仕事をしつつ、日本の会議なども気にしなければならない人もいる（私がそうだ）。その場合には、タイムゾーンに合わせて時刻を変換してくれる仕様の方が都合がいい。両者の要求を満たすためには、予定の時刻を変更するかどうか選択するオプションがあればよい。

Windows Mobileの現在の仕様で何とかするには、現地の予定を日本で入力するときに、訪問先タイムゾーンに一時的に切り替えるのがよいだろう。数ステップ余分にかかるので面倒だが、少なくとも時差を計算しなくてよい。

（参考記事）
コデラ ノブログ「アメリカ至上主義を捨てよ」
http://plusdblog.itmedia.co.jp/koderanoblog/2006/07/post_4f81.html

「条件がわからないので見積もれません」

商談についての社内打ち合わせで、「条件がわからないので見積もれません」と、あるSEが発言したことがある。商談のごく初期段階であり、ユーザの利用環境が明確でなかったから、この言葉はいちおう正しい。しかし、それはジュニアSEならば、という条件付きだ。

そもそも、見積条件をユーザがきちんとそろえて提示してくれるのを期待するほうがおかしい。RFPをきちんと書くユーザが増えてきたが、まだ少数だろう。曖昧模糊としている状態で、ユーザ自身が気づいていない課題を引き出すこともSEの役割だ。

少々極端な例になるが、トラブル対応のときに、トラブルの原因をユーザに教えてもらおうと言っているようなものだ。原因を見つけ出すのがITプロフェッショナルであるSEの仕事である。同様に、見積の前提条件を導き出すのもSEの仕事である。

ユーザ情報があまり入手できていない商談初期なら、一般的な利用形態をもとにしてとりあえず見積りや構成を作ってみる。これが「たたき台」だ。ユーザの実態と大きくかけ離れていてもよい。まずは、議論の共通土台を具体化・可視化、最近はやりの言葉なら「見える化」することが大事だ。同じ図や数字を見ながら議論すれば、「ここはそのとおり」「この部分は、実際はこうなっている」と、ユーザも情報を提示しやすい。

たたき台としての条件を設定するには、豊富な事例が必要だという人もいる。それもいちおう正しい。しかし、新製品を売り込む場合には、そもそも事例そのものがないから、無い物ねだりだ。その商談で事例を作るという気持ちで臨む必要がある。頭をひねってたたき台を作り、それをもとに会話を重ねれば、ユーザに教えられることも多いだろう。