1  英語業務メールの主な構造と特徴

仕事柄、日本からのメールに目を通す事が多いのだが、現地社員や関連会社への依頼がうまく通じずに苦労しているのを見たりフォローせざるを得なくなったりすることが少なくない。英語能力自体の問題や仕事の理解の問題などについては上達してもらうしか無いのだが、仕事のやり取りの流儀的な所で引っかかっている人もしばしば見かける。その辺を踏まえ、英語で仕事をする人向けに英語の依頼メールを書くコツを少しまとめてみた。なにかしらの参考になれば幸いだ。

メールの構造

メールの主題・依頼内容は、理由は後述するが1通のメールに1つに絞る。メールの構成は概ね以下のようなものになる。

1. Subjectに特定しやすく分かりやすい主題を記載
2. 宛先の名前と挨拶 (Hello Mr. Yoosee ...)
3. メール本文冒頭に依頼内容の要旨や求める期日を3行以内程度で記載
4. 要旨についてのより明確な求めるもの(ゴール)、及びその背景の説明
5. 更に細かい補足説明やデータ等の記載
6. 最後に「質問やコメントがあればご連絡下さい (Please let me know if you have any questions or comments)」などの定型文。メールが長くなった場合は最初に書いた要旨を繰り返してもいい。

ルールとして項目立てしてみよう。

1通のメールに書く主題・依頼内容は1つだけにする
1通のメールに書く内容は1つに絞る。 複数の依頼事項を1通のメールに書くと、かなり高い確率で2つ目以降の話に返信がもらえない。これは悪意があったり意図的に手を抜いているわけではなく、最初に書いてある内容を依頼事項と認識するのが通例なため、その項目に返事を書いた時点で完了!と返信してしまうのだろう。理由はさておき、複数のお願いを1通のメールに書いても、特に後半に行くほど返答に含まれない可能性は実際に高い。確実に返事がほしい場合には特に気をつける必要がある。

どうしても複数の話題を扱いたい、例えば複数の質問を一度にしたい場合などは、「以下の質問に答えてほしい」という依頼にして質問を箇条書きにしたり、「添付した質問票を埋めて欲しい」のような依頼にしてExcelかなにかで表を作って依頼すると、まだ返答を貰える確率が高くなる。 但しそもそもメールで大量の依頼事項を送りつけること自体が相手の都合を考えていないやり方なので、あまり依頼が膨らむようであれば打合せなどを設定して仕切りなおすなり仕事の仕方を見直すのが望ましい場合も多い。

Subject には依頼の Subject (主題・目的) を記載する
上記のルールを守ればそのメールには1つだけの明確な主題・目的があるはずなので、それをきちんとSubjectに書く。本文を読まずともリストに並んだSubjectでメールの内容が想像でき、後から検索もできるように特定が効く記載が望ましい。「Question」や「About trouble」や「Please follow up!」などではなく、例えば「Schedule change request for next Wednesday sales meeting」や「Detail of ticket BUG019872 - Edit link not shown」のようにある程度具体的に記載する。 まして「Hello!」だけでは今時 spam と間違えられて届かなくてもおかしくないので気をつけること。

最初の3行以内に要旨をまとめる
実際にどういった内容のメールなのか、なにを期待しているのか。依頼なのか通知や情報提供なのか質問なのか。分かりやすい Subject を付けたら、次は依頼内容も分かりやすく最大でもせいぜい 3行以内で記載する。日本語だと色々と説明を記載して都度その後に依頼を複数書いていく形もあるだろうが、英語のメールでは普通要旨を最初に記載する。読む側はそれを期待しているので、細かい説明から長々とやられると読み続ける気が無くなってしまうし依頼も読み落としがちになる。

例えば「定期メンテナンスの予定があるのでお知らせします」「このメールに記載の内容が間違ってないか確認して連絡を下さい」「下記の質問に明日までに回答が欲しいです」「バグが見つかっているのでそちらでの再現と修正案、修正予定日を教えて頂けますか」など端的な要件を最初に記載し、その詳細を後半に書いていくのがよくあるパターンになる。こうしておくと依頼内容がすぐ目に入るので相手もメールをくまなく読んで探す必要がない。

必要な物には「なる早」ではなく期日を指定する
期限のある依頼には基本的に期日を指定する。特に日本からの依頼で ASAP / as soon as possible を使っているのをよく見るが、急いで欲しいという意向は伝わるが多分日本の多くの人が想像するほど「至急」のニュアンスはない。同義だと as soon as you can や at your earliest convenience などで書き換えると思うが、つまり「あなたの都合のつく限り早急に」くらいの意味になる。本当に急ぎの場合はきちんと by tomorrow afternoon や by morning April 5th のように日時をきちんと指定すること。また時間まで指定する際には時差を考慮し、両方の日時を by 9am Tuesday JST / 8pm Monday EDT などのように併記するのも良い手だ。
それ以上の急ぎ、例えば数時間以内にやって欲しいという場合なら、Please address immediately and I expect it to be done by 4pm at the latest など指定した上で電話などのリアルタイムのコミュニケーション手段をきちんと使う。メールだけで「今すぐに!」と言われても相手だって読んだ時点からしかアクションが取れないのは当たり前のことだ。

依頼の「ゴール」は具体的に設定する
依頼によってなにをして欲しいのかの「ゴール」は詳しく、具体的に記載する。よく見かけるのが何かの問題や障害発生時に Please fix it だけ言ってくるパターンで、fix の定義がわからないと「こちらではちゃんと動いているようにみえるよ」「こっちで直したから動いているはずだよ」のような返答をもらって見てみると直っていない、なんて事が本当によくある。例えば「アカウントID abcdef でこのページからこうログインしようとしたのだがこうしたエラーになる。ログイン出来るようにして欲しい」など、ある程度明確に書く。 また問題解決だけでなく問題の理由も聞きたい場合はきちんとそのように依頼しない限り、「直したよ」以上の情報は出てこないと思ったほうがいい。して欲しいことは漏れ無く、優先順位をつけ、明確に記載すること。

依頼の背景はより高いレベルから説明する
上記「ゴール」に併せ、可能な限り、なぜこの依頼をしているのか、なぜこの質問を聞いているのか、その理由や背景を説明する。 典型的なケースとして、特にエンジニア同士のメールで「このアプリのこの設定パラメータをこう変えたいが問題ないか」というだけの質問が来たりすることがままある。 これに素直に「その設定でも動作は問題ない」と返すと、その後に「その設定ではうまくいかなかった。今度はこの設定を試そうと思うが問題ないか」などと続いたりする。

本来こういう依頼は「こういった目的でアプリの設定を変更することで、こうした挙動を期待している。ついてはこの設定パラメータをこうしようと思うが問題ないか」などまで書けば、聞かれた方も「いやそういう目的であればそこではなく違うパラメータを変更するべきだ」「その目的を達するならむしろ別のアプリで挙動を変更したほうがうまくいく可能性が高い」など、より踏み込んだ返答ができる可能性が高まるし、なんにせよ聞かれる方も「相手も理由があって聞いてきているのだ」「相手はこういう事を目指して仕事をしているのだ」という理解があったほうが仕事のやりがいも増すというものである。 背景は横着しないできちんと書こう。結果として早くて適切なコミュニケーションが取れる。

こうしたメールの構造や書き方を意識して書いていくと、作法としてだんだん慣れて楽に書けるようになると思う。是非お試し頂きたい。

おまけ: ちょっとしたテクニック

• 依頼の際に謝らない: 日本語で「すみませんが」などと書くものの直訳的な意味合いなのだろうが、つい無理を聞いてもらおうという時に I'm sorry but などで始めてしまう人がいる。 これをやられると読む方は「私は謝られるようなことを依頼されているのか?」とあまりいい気分ではないらしい。基本はストレートに感謝する、例えば I appreciate if you can ... や Any of your support would be most appreciated ... 等である。
• 箇条書きや表を活用する: 英語圏の人、特にアメリカ人は文章での説明を好む傾向があるようで、メールなどでも説明が込み入ってくると切れ目のない5,6行にも渡る長々とした文章を書いてくることが少なくない。英語が達者でない身には結構辛いので、こちらが書く場合は箇条書き (bullet item) が役に立つことが多い。特に英文に慣れないうちは無理をせず、平坦な英語を箇条書するのが誤解なく意図を伝える早道だ。

1  米国企業と日本企業での「時間」と「効率」に対する認識の違い

日本企業、特にホワイトカラーの生産性の低さが話題になるのをよく目にするが、その根本原因の一つは「残業」ではなかろうか。この夏の東京では節電のために空調を止めるので残業を禁止している企業もあると聞くが、そのまま残業は一律禁止にしたらどうだろうか。

こんな事を思うに至った理由の一つは、残業という概念が希薄な米国から日本と仕事をしている現状を踏まえてのものだ。 米国で管理職相当の仕事をやっていると気づく大きな違いは「部下の時間・リソースは有限である」というシンプルな認識である。つまり残業を前提としない部下は、1人あたり「1週間に8時間 x 5日 = 40時間」しか働いてくれない。良し悪しはともかくとして、自分の手持ちのリソースは有限であるという事実を常に意識させられるのである。

この認識がどのような状況を生むのか。大きく以下のような事が思いつく。

社員の評価が効率性・生産性で計られるようになる

労働時間が決まっているのだから、当然ながら同じ時間内にアウトプットが多い社員が良い評価を受ける。ましてやチームとしての生産性を向上させる社員は管理職には非常にありがたい。効率改善が強いインセンティブとなるため、これが積み重なれば当然、企業としての生産性も上がっていく。

当然ITシステムやオフィス環境などのインフラも効率向上をサポートする方向に強化される。例えば大画面のマルチディスプレイなどというのはIT労働者の労働効率を大きくあげる安価な手段と認識されるし、また業務を効率化するためのツールやシステム導入も積極的に行われる。

またそもそも日本の従業員も、残業を前提に仕事を薄く伸ばしていないだろうか。例えば午後3時くらいに「夜9時で仕事するならまだ6時間あるし...」などと思って息抜きしてたりしないだろうか。トータルでの実労働時間はそれでも恐らく日本の方が長いだろうが、残業を含むオフィスでの長時間を全て労働に使っている人ばかりではないだろう。

管理職・経営層は「やるべき事」だけでなく「やらなくていい事」を決めなくてはいけなくなる

時間・リソースが有限である事が明確な以上、優先度の低い事に時間を費やす余裕はなくなる。日本で仕事をしていて典型的なものとして、上司が「あらゆる可能性を検討して最善の策を提示しろ」と部下に命じるケースがあるが、これは得てしてリソースの無駄遣いであると共に、ビジネスの決断スピードを著しく低下させ、市場についていけ無くなるリスクを生む。

また例えば会議や打ち合わせに部下を出すことは、部下が本来他にやるべき仕事の時間が消費されるため、米国の管理職は結構ためらう事が多い。これは特に Developer などの高給な専門職に対して顕著になる。

上級管理職、例えば米国での Director ポジションの仕事は、正に「やる事」「やらない事」を「判断・指示 (Direction)」することだ。当然そうした判断を下す以上、成功と失敗があり、失敗すれば責任を問われる立場だからこそ上級管理職は高給なのである。

まとめ

• 残業禁止により、社員の労働時間は明確に有限で計算可能なリソースとなる
• 時間あたりの生産性・効率性の高さが社員評価の基準になり、その向上が強いインセンティブになる
• 使えるリソースが有限な以上、管理・経営層はフォーカスを絞ったビジネス戦略を立てて決断する必要が強くなり、結果として市場に対するスピード感が増す

こう単純に事が進むかどうかは難しいところだろうが、今の多くの日本企業が生産性や効率性にフォーカスをあてるには残業禁止くらいの荒治療が必要なのではなかろうか。

1  Amazon.com のデータ・コンテンツ販売は全般的に好調っぽい

いつものように Amazon.com にアクセスした際にふと左側に表示されるメニューが目に入ったのだが、気がつけばトップカテゴリーの16のうち、7つがオンラインコンテンツになっている。いつの間に、と言う感じである。見てみると今年ラウンチしたサービスが幾つもあるので、ここまで増えたのは最近なんだろうけど。

• Unlimited Instant Videos は、今年2月から始まった、サブスクリプション型(Amazon Prime連動)のビデオ見放題サービス + 非購読者には個別購入もあり。USだとNetflixと言うサブスクリプション型宅配DVDレンタル業者がオンデマンドの映画見放題は先鞭を付けていて、そちらは今じゃ宅配よりオンライン再生の方が多いとか。
• MP3 は日本でも去年後半くらいから始まってたと思うけど、DRM無しの mp3 楽曲販売。最近は曲は殆どこれで買っている。米国では新曲も殆ど mp3 で出るし、DRM無しでどこでもなんのデバイスでも聴けるのは、特に非iPod/iPhoneユーザとしては非常に快適で安心。加えて最近これが何度でもダウンロード可能になった。
• その下にある Cloud Drive はつい2ヶ月程前にラウンチされたサービス。初期無料 5GB から、有料で (ないしアルバム購入時のキャンペーン等で) サイズ拡大できる Dropbox 的なクラウドストレージ。MP3 の横に記載がある Cloud Player と組み合わせると、スマートフォンやPCなど複数のデバイスで音楽をストリーム再生したりダウンロードも出来る。Amazon.com で買った曲は容量がかからないのは先日発表された iCloud とも一緒。つい最近になって Google もクラウド型音楽ストレージをリリースしている。
• Kindle は言わずと知れた電子書籍。先日にはKindleの書籍売上が紙での販売を上回ったと言うニュースも出ていて絶好調。電子ペーパーのデバイスも広告配信ありで $114 が出たこともあり、最近は街中、スタバ辺りでも読んでる人をよく見かけるようになった。もちろんPCやスマートフォンでも読めるし、既読情報やメモも同期される。Kindleでの書籍購入の快適さは過去記事を参照。
• Appstore for Android はその名の通り Android Market の Amazon 版。これも今年3月リリース。正直これって儲かるモデルなのかなと思いつつも、リリース以降ずっと1日1有料アプリを無料提供しているのでなんだかんだでアクセスはしてる (正確にはTaskerで1日1回定時に自動起動してる)。
• Digital Games & Software は、PC と Mac 向けのソフトウェア販売みたい。これは使ったことが無いけど、かなりいろんなソフトがダウンロードで買えるようだ。
• 最後のAudibleはいわゆるオーディオブック。米国では車の運転があるからか読み書きに難がある人のニーズなのか、オーディオブックの需要は結構高いみたいで、Kindleには無料でテキストの読み上げ機能もあるけどそれでも個別のオーディオブックは売れてるらしい。Audible.com はその最大手だったけど、2008年前半にAmazonに買収されて今に至る。

全般的にありがたいのは、デジタルコンテンツはAmazon.com内ではアカウント紐付けで管理できて、再ダウンロードも可能なものが殆どな事 (MP3は最近の Cloud Drive リリース時に対応された)。コンピュータが壊れようがスマートフォンやKindleデバイスを失くそうが買ったものが無くならないというのは精神的にいいし、あるべき姿だ。

また上記のサービスの殆どがスマートフォン、特にAndroid対応している。PCだけじゃなくスマートフォンでどこにでも持ち出せるようになったというのも、これらのサービスをAmazon.comが気合を入れて出してきたことの大きな背景だろう。

あと当然こうしたサービスを支えているのはAWSのクラウドインフラなのだろうし、そうした部分を戦略的に突き進めるAmazon.comのビジネスは本当に恐ろしいくらい。

アメリカでこの手のオンラインが流行るのは、一つには国土が広くて物流のコストがバカにならないし時間もかかるというのがあるんだろうけど、とはいえ日本でももう少しこう言う事が広く出来るようになるといいのにな、とは思ってしまう。特に日本国外にいる身としては、海外からも買えれば最高なんだよなあ。

1  米国と日本の祝日・休日の違い

例によって Tumblr より、 日本の休暇は米国より多いという話が出ていたのでこっちでフォローアップ。端的にはそれは概ね正しいと思うが、詳細はあまり合ってない。

まず、米国の2011年の National Holiday はこんな感じで10+1日間。

• 1月1日(代休12月31日) New Year's Day
• 1月17日 Martin Luther King Jr. Day
• 2月21日 Presidents' Day
• 5月30日 Memorial Day
• 7月4日 Independence Day
• 9月5日 Labor Day
• 10月10日 Columbus Day
• 11月11日 Veterans Day
• 11月24日 Thanksgiving Day
• (11月25日 Day after Thanksgiving)
• 12月24日(代休12月26日) Christmas Day

米国の祝日は企業によって休みでないものもあり、例えば上記でも Columbus Day と Veterans Day は少なくとも弊社は休みではない(ので弊社のHolidayは9日間)。Martin Luther King Jr. Day が休みじゃないところも最近まで結構あったようだ。正月も今年は3日(月曜日)から出てきて働いている。Day after Thanksgiving は National Holiday ではないが、いわゆる Black Friday でもあり、小売店以外は休みの企業が多いはず。

米国は有給（paid vacation days）は大体年間10日程度なので、祝日と足しても年間20日程度である。一応それとは別に病気休暇（paid sick days）が7,8日あるから、足すといわゆる有休 (Paid) は 20日間弱にはなる。sick daysは必ずしも全員が全部取るわけでもないが、定期的に金曜日に病気になる奴とかもいないことはない。

日本は祝日15日 (プラスで「国民の休日」有り)であり、これは先進国最多だそうだ。更にこれに加え、年末年始は1週間近く休みの企業も多いし、お盆休みも有給とは別途割り当てられるところもあるから、年休を入れない休暇だけでも祝日と足して年間20日程度あるところも多いだろう。これに年休を加えたら、日本の休暇は決して少ないものではない... まあ土日も働いている人もいるだろうけど。

ちなみにこれらの休みは基本的に会社全員休みなので、米国から見てると日本はほぼ毎月数度、加えて春(GW)、夏(お盆)、冬(年末年始)とシーズナルに企業の仕事が全く止まる期間があるという、ちょっと不思議な国に見える。

2  米国での祝日、休暇の取りかた

米国の祝日は日本とは違い、百貨店やスーパーなども概ね閉店する。レストランなども休むところも結構多いので、下手に買い物を忘れると非常に切ない祝日を過ごすことになったりもする。まあ普段から日曜日も午前中は開いていない店が多かったりもするので(これは教会の関係だが)、店が閉まっている事には結構すぐ慣れる。

11月の Thanksgiving は日本のお盆休み的な感じで、実家に帰る人も多い。またこの Thanksgiving から Christmas までの間に休みを入れる人も多いため、米国の仕事はこの期間、かなりスローダウンする事が多い。 一方で Christmas が終わると New Year は盛り上がらず (そもそも大体が Merry Christmas and Happy New Year とか一緒くたにされる)、通常業務モードになっている人も少なくない。

上記期間に限らず1週間程度の休みを取る人もそれなりにいるが、なにせ年休も少ないので、実は日本の人が思うほど米国の人は長期休暇を取りまくってるわけでもない。と言うことなので、いやほんと、もう少し休ませてください...

1  英会話の3つのルール: 大きな声で、ゆっくりと、リズムにのって

今回はちょっと趣向を変えて、英語を話すときに意識してほしい3つのルールをあげてみたい。ルールといっても極めて単純なもので、以下の3つだ。

• 大きな声で
• ゆっくりと
• リズムにのって

特に声の通りにくい電話会議ではこの3つはとても重要だ。正直 R と L の発音なんてどうでもいい。とにかくこの3つは常に意識して話をしてみてほしい。さて、なぜこれが英会話で大事かというのはこんな理由だ。

大きな声で

英語での打ち合わせ、特に電話会議で、とにかく声が小さい日本人が多いように感じる。もしかしたら英語を話すことの気恥ずかしさ等があるのかもしれないが、小さい声では正しい発音だの正しい文法だの言う以前に、まず聞き取れない。むしろ自分で大声を出しすぎかと思うくらいに声を張って話してもらうくらいでも概ねちょうどいい。

ゆっくりと

特にエンジニアに多い気がするが、興奮してくると英語ででもどんどん早口になってくる人をそれなりに見かける。早口で話すと単語の繋ぎがおかしくなってますます通じない発音になりがちだし、ゆっくり話した方が英単語を連想・連鎖的に頭からひねり出すのにも余裕が出て、自分の英語能力をフルに使うのが楽になる、と思う。 発音なんて日本語発音英語で構わない。ゆっくりはっきりと話そう。

またこちら側が、相手も意識できるくらいにゆっくり話すことで、早口になりがちなネイティブ英語話者のスピードもコントロールすることが出来る事も多い。体験から言えば Please speak slowly などと頼むよりもよほど効果的である。

リズムにのって

英語っぽく話すのが恥ずかしいからなのか日本語の癖なのか、まったく抑揚を付けずに一本調子で話す人が多いように思うのだが、これは日本人が想像する以上に英会話として聞きづらい。そもそもむしろ英会話では、全ての話した単語を聞いているというよりは、抑揚がついて強調されたところが耳に入って意味をとると言うのが標準的じゃないかと思う。
一般的には動詞や固有名詞、つまり会話においてそれが無いと意味をなさない部分のみが強調され、冠詞や前置詞や助動詞などは軽く流される。この際、スリービートやフォービートと言った感じで声に抑揚がつくのが一般的な英語の会話になる。

前述の「大きな声で」「ゆっくりと」も、実はこのリズムに乗ってを作るのに役立つ。 声が小さくてはそもそも抑揚を付けようがないし、早口になるとえてして一本調子になりがちだ。この3つを合わせることで、それなりに聞きやすい英語を話せるはずだ。

英会話のリズムについて詳しくは、例によって日向清人のビジネス英語雑記帳 英語は「ウーン・パッ」「ウーン・パッ」で話す （上） ／ （下） を参照されたし。

以上のように3つほど頭に置いてほしいルールを書いたが、最大のルールはもちろん「ためらわないこと」だ。そもそも英語圏に知り合いがいたり英語圏を旅したりすれば分かるだろうが、彼らは得意気に「少し日本語を話せる」と言って、実際「こ(ん)にちわ」くらいしか言えなかったりする。単純比較すれば、日本人で Hello が言えない人がいるだろうか。この基準で考えれば殆どの日本人は英語が話せるのである。
標準的な日本人が知っている英単語は恐らく本人の想像以上に多い。単語を並べるだけでもそれなりに通じるのだから、ためらう必要はない。特にエンジニアは「技術」と言う共通語を話せる分だけ難易度は更に低いと思って、あまりためらわず、この3つのルールを頭においてにトライしていただきたい。

1  米国のハラスメント研修が感じさせる異文化共存社会の難しさ

仕事の都合でいわゆるハラスメント研修(Unlawful Harassment Prevention)というWeb研修を受けたのだが、日本で受けたセクハラ・パワハラ研修とは毛色が相当違っていて面白かったのでメモしておく。

• まずハラスメントの種類がとても多い。セクハラ、パワハラ、人種、年齢、宗教、身体障害、ホモセクシャル、体重、などなど。
• 日本の研修だと「こう言うのはセクハラなのでやってはいけません」というのがほとんどだけど、この研修だと「こういうのはハラスメントではありません」とか「こういう場合にあなたにこういう対応をするのは会社の権利です」といった会社側からの線引きが多い。まあ企業側が企業のリスク回避のために研修するんだから当然といえば当然なのだろう。
• 会社主催のパーティにセクシャルな格好で来た人には注意していいのかとか、パーティの後に一夜の関係になったことが会社で噂になった場合に云々とか、微妙に具体的なケースが多いんだが一般的によくあるんだろうか。
• 同性同士でもセクハラになる。共有スペースで豊胸手術の話をして「○カップ以下はダメよね!」とか周りの女性が聞こえるように話したらNG、とか。
• 男同士でレズビアン映画の批評をしていたらレズビアンの女性がそれを聞いていてHRに訴えるとか、センシティブな話題というのはなかなか難しい。
• ハラスメント対ハラスメント、というケースもある。例えばある宗教でホモセクシャルが禁忌の場合にホモセクシャルを宗教上の理由で批判していいか、等。

価値観が多様な社会を構築するってのはこういう事なんだなと実感してしまう研修でありました。

1  技術職と一般事務職の給与を比べてみると − ＠IT

欧州は知らねど、私の知っている米国企業では、確かに技術・研究職の給与が社内の比較で高いゾーンにいる。但しこれは誰が価値を生み出してるかなんて言う話ではなく、単純に技術者の市場価格がそれだけ高いという話である。

米国の労働市場は御存じの通り流動性が高く、人材は市場で取り引きされる「商品」である。市場の中で商品の価値を決めるのは需要と供給だ。そして技術者は一般事務職に比べ、そもそもの供給が少ない。故にその雇用が必要ならば、必然的に高い給与を出すしかない。

では、なぜ供給が少ないのか。米国の技術職、特に開発研究をやるレイヤの人は医者や弁護士といった立場と同様、専門知識を持った専門職であり、キャリアパス的にヒエラルキーの上位にいるからだ。例えば知っている会社の(非管理職の)技術系スタッフでは概ねだが

サポート < セールス・アカウント <= QA << Developer

といった順序で給与に差があり、左側の人はキャリアパスとして右側を目指すという構造になっている(ちなみにマネージメント職はまた別のヒエラルキーであり、マネージメントという専門職である)。米国のIT市場で「技術者」と呼ばれるのはこのヒエラルキーの上位にいる人だけだろう。

これは逆に言うと、半端なレベルの技術者は、そもそもIT人材市場で「技術者」というカテゴリでは商売できない事を意味する。しかもこの「技術者」商品は知識・経験の劣化が激しく、またご存知の通りインド方面等へのアウトソースが激しい分野なので、現在「技術者」として市場に残っている商品は競争を勝ち抜いてきた、品質の良い商品が殆どと言える。

米国では大学で仕事に即役に立つ学問を修めて(もしくは独学でスキルを身につけて)いるか、さもなくばキャリアパスの下から実力で上がっていった結果として「技術者」と言う職についており、採用面接時にはスキルそのものに関する質問を受けている。対して日本の場合、「技術者」は専門でもない学校を出てすぐに「技術者」と言う立場で仕事をすることがままあり、コミュニケーションスキルだ何だと非専門領域の資質が中心になりやすい。

こうした日本型構造では、確かに本当にスキルのある一部の「技術者」は割を食うだろうが、一方でスキルがさほど無い人でも「技術者」を名乗って給料を貰えるモデルと言える。この状態で給与を職種平均したときに、日本と米国で「技術者」を一括りで比較することにはそもそも意味が無いんじゃないかな。まぁ、日本がITに金とコストをかけなさすぎと言うのは同意するんだけれども。

1  シゴトハック研究所：感情的な議論を防ぐには？【問題編】 - ITmedia Biz.ID

これ、感情的な議論云々、伝わる伝わらない云々の話以前に前提がおかしい。

タカフミ君のように何でもかんでもラクに簡単に済ませてしまおうという姿勢が問題だと感じているんです。(中略) そういう姿勢ではよくないから、改めた方がいいと。シゴトハック研究所：感情的な議論を防ぐには？【問題編】 - ITmedia Biz.ID

そもそも、なぜ仕事を楽に済ませてはいけないのか。

もちろん楽をすることで仕事がうまく行かないのはまずい。例えば「何でもメールで済ませる」というのは、即時性や細かい点での双方向の情報交換が必要なシーン等では電話や対面に劣るのだからよろしくないケースがありうる。私もメールを送信した後に電話で「今メール送ったんですけど、その内容で〜」と相談する手はよく使う。
しかしこれは単に「適した場に適したツールを使う」と言うだけの話であって、楽することが悪いという話ではない。「汗をかかないと仕事をしたことにならない」という価値観は唾棄されてしかるべきものだ。

忘れてはいけないのは「コンピュータは仕事を楽にするための道具」である事。これを忘れたら、IT導入に関するあらゆるアクションは本末転倒になる。場合によっては仕事のやり方の方を見直す必要もあるが、それも最終的には仕事をより楽に行うためにどうするかという視点から行うべきだ。社内向け資料に華美な PowerPoint を使うことを問題視した記事も最近見かけたが、道具のために人の労力が余計にかかるなら、それはそもそも本末転倒である。

1  無駄な会議を見える化したい

弊社で仕事をしているとたまに、参加30人 2.5時間で発言 4人なんていう会議があって、26人の時間はどんだけ無駄なのかと問いたくなる。こういうものを「見える化」するために、会議人数と構成を入れると時間経過にしたがって経費が淡々とカウントされていく時計なんて言うのはどうだろう。時間単金はとりあえず役職で固定にする。決まった金額ごとに「現在 5 万円です」などと音声通知してくれるとなおよろしい。

1  職場用 Wiki として MoinMoin を導入

チームの情報共有用 Wiki を、改めて導入。PukiWiki, FSWiki, Hiki も試したが、アカウント管理や編集機能、ナビゲーション系の見やすさ、全般的な使い勝手で最終的に MoinMoin を選んだ。チームの人が使ってくれるように啓蒙を頑張ろう。

職場で情報共有する際に、アカウント管理機能はプライオリティの高い機能だと考えている。文責といわないまでも、誰が変更したかというのは記録しておきたいし、閲覧制御も場合によっては必要なこともあるだろう。また職場 Wiki の場合、「それを書いたのは誰か」という情報が「それを知っているのは誰か」に直結するので、仕事を回す際に貴重な情報になる。MoinMoin は Wiki 記法に頼らない WYSIWYG エディタがあるので、これは特に Wiki 初心者へのとっつきやすさという点でよろしい。

導入に際しては FreeBSD ports, Debian package にパッケージがあるのでそれを利用した。バージョンアップが楽なのも、自分以外がメンテナになる可能性を考えると重要な要素だ。ちなみに MoinMoin のデータはページ毎にディレクトリが作られ、その下に変更履歴の revision が全て残るらしい。ディスク容量的には富豪設計だが、扱いやすいのはありがたい。動作的な重さは、fastcgi として動かす分には今のところ感じられない。しばらく使ってアドオンなどもためしてみよう。

1  佐川急便が不在通知メール機能などを追加

営業店到着通知メールサービス、受領印メールサービス、不在通知メールサービスなるものが追加されたようだ。クロネコヤマトの不在通知メールサービスはとても便利なので、早速佐川でも申し込んだ。その後気づいたのだが、この不在通知は荷物の問い合わせ番号毎に通知申込が必要で、クロネコのように「配送時に不在だったらその場でメール連絡」と言う形では無いように見える。それじゃ殆んど意味がないと思うのだが…。

それと再配達申込の方だが、21時に不在票を見て再配送申込をしようとしたら「現在〜22時」と言うものが選べた。しかし当然のようにその日には届かず、届いたのは次の日の午前中。どうもクロネコに比べるとシステムの出来が悪い気がしてならない。

1  Feel in my bones 『ウェブ人間論』（２）：個と社会／「ダークサイドに堕ちてますよ！」

梅田は人脈というものを結構功利的にとらえていて、それはもちろんビジネスの世界では当たり前のことだと思うのだが、その人脈のとらえ方に対して平野がやや強い拒否反応を示している。Feel in my bones 『ウェブ人間論』（２）：個と社会／「ダークサイドに堕ちてますよ！」

本題からは外れた話だが、何となく世間一般の論調としては、「人間関係での損得勘定、功利性」を否定する向があるように感じる。だが実際問題として、人間関係には「功利性」を持ち込んだ方がうまくいくことも多い、と私は思っている (ベンサム・ミルの功利主義を強く支持すると言う話ではないので念のため)。

例えば「友達が成功していくさまを隣で見ている」と言うケース。聖人ならば嫉妬もなく純粋に称讃とエールを贈るのだろうが、そう素直に思えないこともあるだろうし、相手の失敗を願う等のネガティブな思考を持ってしまうことも無いではないだろう。
だがこれを功利主義的に考えると、身近な人が成功することは自分の周りのコネクションが成長しているということであり、自分の利益として歓迎できることだと気づける。この考え方を進めると、周りの人が成功するように手助けすること自体が自分の利益になる、と言う結論に行き着く。これは日本でもよく言われる「情けは人のためならず」と一致する。

「投資」なのだから必ずしもリターンがあるというものでは無いが、実際に身のまわりを見ても、周りの人から大きく利益を得ている人は、大抵がそれ以上に周りの人に投資をしているものだと思う。

最後に一点付け加えておくが、功利性とは人間関係を金銭上の損得で考えるというだけの話では無く、「一緒にいて楽しい」「リラックスできる」「話すだけでも色々な刺激を受ける」と言うのも「功利」として大きいものであるのは言うまでもない。
人間関係の損得はさほど簡単に足し引き可能なものではないが、相手からどんな利巧が得られるか、相手にどんな利巧を与えることが出来るかを考えながら人間関係を見るのも時には有効ではなかろうか。

1  仙石浩明CTO の日記: なぜ人月見積もりが優れているのか

そもそもこれだけ嫌われ者の「人月見積もり」が なぜいまだに行なわれているか、 そこには「人月見積もり」ならではの「良さ」があるからではないでしょうか？仙石浩明CTO の日記: なぜ人月見積もりが優れているのか

お客様に説明する段では、私も人月であってもいいと思う。客が最終的に欲しいのはあくまで「望んだものが」「望んだ価格で」出てくる事であって、そこに値段の裏づけとしての分かりやすい指標があれば良い。つまり人月というのは金額と同じように、様々なコストを均一化して計るための目盛だと思えばいい。特に決済を取る際等には便利だろう。

問題はお客様側でなく、請負側の企業自身も「人月」と言う価値観を現場エンジニアの評価に持ち込んでしまうことにある。人月では当然ながら「一人が一ヶ月に生産できるもの」を一単位としているので、個人差を考慮していない。最終的にお客様に出すときには平均値を出しても構わないだろうが、個々のエンジニアの生産性が同一であるなんてありえないどころか、ピンとキリでは1000倍の差があるのが現実だ。
また「個人の能力差を考慮しない均一報酬の生産体制」とはある種の社会主義モデルであり、このモデルは特に労働に対するモチベーションの面で欠点があるのは歴史が証明していることだ。

と言うことで、個人的な結論としては「お客様に出す見積りとして『人月』を使うのは必ずしも悪いことでは無いが、社内の開発現場にそれを持ち込んだ途端に破綻する」と言うことではないかと思う。

もちろん本来は客側も「開発側の能力」をきちんと見極められないと、ボッタくられたり具にもつかないものを納品される可能性があるので、いくら人月が便利だといってもある程度の目利き能力は必要なのだが。

1  ScanR - copy and fax with your camera phone or digital camera

Just snap a photo of the card with your 2-megapixel (or better) camera or cameraphone, then e-mail the image to scanR. In short order you'll receive an e-mail containing a completed vCard to import into your contact manager.Use your camera or cameraphone as a business-card scanner - Lifehacker

と言うわけで、200万画素以上のデジカメで取った名刺の写真をメールで送付すると vCard 形式で送り返してくれるというサービス。他にもホワイトボードや紙の書類を PDF にしてくれるサービスも併せて提供している。日本語には非対応だろうが、なかなか興味深い。誰もが持っている携帯電話の機能をサーバ側で拡張する、そんなところにもビジネスのヒントは転がっていそうですね(百式風)。

2  FUJITSU スキャンスナップ FI-S500

ただ昨今の事情を考えると、画像として送った個人情報や社内情報がサービス提供側にも一時的にとは言え渡ってしまうのは微妙かもしれない。もちろん Privacy Policy としては無断利用しない旨がうたわれているわけだけど。その辺りを考えてローカルでこういうことをしたいなら、断然 ScanSnap だろう。最安でも40,000円以上とちと高めだが、机の上に紙書類が積み重なっているようなオフィスなら、そうした書類のセキュリティ的な観点からも電子化しての一元管理はお薦めじゃなかろうか。

3  W-ZERO3[es] Premium version

ついでにもうひとつ。新しく出る W-ZERO3[es] Premium version にはデジカメを使った名刺スキャナが付いてくるらしい。Outlook と同期できるというスマートフォンの特性を考えると、名刺管理が必要な営業職などはこの機能だけでも買いな気がしてしまう。私なんぞは名刺なんて普段殆ど使わないんだけど、それでもちょっと欲しい気分になる。既存ユーザには有償提供らしいが、あまり高くならないといいな。

1  全員が「明るい、楽しい」と感じるチームにしたい @IT

よりよい人間関係の築き方を追求するとそういった結論になるということだと思うが

信頼関係もない相手に対して、どんなアドバイスをしても期待する効果は得られません。まずはあるがままの相手を受け入れるところから始める方が近道なのです。全員が「明るい、楽しい」と感じるチームにしたい − ＠IT情報マネジメント

これはそのまま「七つの習慣」(またか! とお思いでしょうが、ええまたです)の後半、「公的成功」に出てくる「信頼残高」の話だ。また、受け入れるところから始める の部分は、第五の習慣「理解してから理解される」に該当する。

「信頼残高」と言うのは、対人関係での信頼の量を銀行口座の残高になぞらえたもの。例えば今まで信頼を積み立ててきた相手なら、多少の失敗は許してもらえるだろうし、無理なお願いも聞いてみようという気になるだろう。逆に残高がマイナスな時に素晴らしいアドバイスをしても、素直に受け取ってはもらえない。日常から態度・行動・言動等を通して信頼を継続的に積み立てなければいけない、と言う話。当たり前の話なんだけど、「残高」と言う概念はイメージしやすい。

また、そのためのコミュニケーション法が「理解してから理解される」の原則。「評価する」「探る」「助言する」「解釈する」といった「自分を中心に相手を評価する会話」ではなく、相手の言葉を噛み砕いて理解することを主眼にして話すとよいらしい。
実際ディベートでもない限り、言い負かしても良いことはあまり無い。相手に考えさせて相手の言葉で言わせるのが良策だし、そのためにもまず相手に話したいだけ話してもらうのが基本と言うのは、コーチング系の書籍でも散見すると思う。

実は、問題のとらえ方は2つしかありません。2つの問題のとらえ方とは、自分に問題があるととらえるか、他人や外部環境などに問題があるととらえるかの2つです。全員が「明るい、楽しい」と感じるチームにしたい − ＠IT情報マネジメント

更にこちらは第一の習慣「影響の輪」の話。長くなるので詳しくは書籍を見てほしいが、簡単に言えば「自分の外部を直接変える事は出来ない。なにかの原因を外部に押しつけず、自分が自分自身でやれる事をやろう。そうすれば自分の力が広がり、自然に外部へも間接的な影響を与えられるようになる」という事を言っている。

2  Social と Personal

上記の記事は元々こちら経由で読んだもの。

■「Social change is changing yourself」って(あんまり)言うな
(本文略)
■個人に帰着されるべきではない問題に対して個人の努力を奮起させて解決させようとするあらゆるものが大嫌い思っているよりもずっとずっと人生は短い。

ちょっと真意を計りかねるんだけど、まとめて書くと「相手を変えるんじゃなくSocialを変えろ、Socialを変えるには自分が変われ」と言う感じかなと思った。

1  Rondam Ramblings: Top ten geek business myths

yendot.org で拾ったネタ。例によって myths (幻想,迷信) の部分だけ簡単に訳してみるが、これに対しての Reality (現実) の方がなかなか示唆深くて面白いので興味のあるかたは原文をどうぞ。

1. 輝かしいアイディアがあれば金持ちになれる
2. いいものを作ってしまえば自然に人は集まる
3. アイディアは守らないと盗まれてしまう
4. 自分が考えていることは凄いアイディアだ
5. 財政的な事なんてくだらない
6. (自分は)肩書や知名度より知識で評価されるべきだ
7. Ph.D(博士号)は価値がある
8. ビジネスを立ち上げるには500万ドル(約5億円)必要だ
9. アイディアこそがビジネスプランの要である
10. 競合がいないのは望ましい状況だ

概ねのところを一言に要約すると「アイディアだけじゃ金にならんよ」と言う内容か。

1  Alertbox: 画面解像度とページレイアウト

元の記事の本題ではないのだけどあまりに心の琴線に触れたので引用。

大きな画面は、ホワイト・カラー労働者たちの生産性を向上させる、最も簡単な方法だ。そして、年間 5 万ドル以上稼ぐ人は、最低でも 1600 × 1200 の画面解像度を使うべきだ。Alertbox: 画面解像度とページレイアウト（2006年7月31日）

全くだ全くだ。1024x768 1 画面だけで仕事をしろなんて言うのは恐ろしく愚かな行為だ。一応私は職場でも UXGA を使っているので文句があるわけではないが (15インチ UXGA の LCD-A15UR だけど)、弊社の基本は XGA なんだよなぁ。

1  PDA、使ってますか？ - ITMedia

たださんのところより。確かにバトンと言うよりただのアンケートだ。しかしなんというか PDA の復調という記事は嬉しいのだけど、Windows Mobile みたいなクソを使われて「これがPDAだ」と思われるのもよろしくない気がしてしまうな。

1. PDAを現在使っていますか？　使っている方は機種も教えてください

Palm Tungsten|T3 を使用中。W-ZERO3[es] を併用しているが、特に PDA としては利用していない。

2. 過去に使ってましたか？　現在使ってない／使っている理由はなんですか？

PDAを使うようになったのは 1999年の Palm Vx から。以降 Palm Vx → CLIE T600 → Palm Tungsten|T3 (現役) と言う流れで今に至る。その他では Sigmarion, SL-C750, W-ZERO3[es] 程度が所持歴だが、常に PalmOS 機がメイン。

主目的は Datebk[3456] でのスケジュール・Todoの管理や会議メモの作成など。Plucker でのWebサイト閲覧も通勤電車などで頻度が高い。その他資産管理やパスワード管理など、用途は様々。多少古いがPalmとの一日を参照のこと。

3. 上手な使い方を教えてください

肌身離さないこと。手に馴染むアプリを見付けること。利用を習慣づけること。

4. 歴代PDAで最高のマシンはどのマシンでしょうか？

今使っている T|T3 が歴代 Palm では最高。これでやりたい事は通信を除けば殆んど出来ている。どんなソフトを使っているかは T|T3 Current Software を参照。通信機能が欲しいと思わないでもないが、現実には家でも職場でもPCにすぐアクセス出来る環境のため、実際には無くて困ると思ったことは日常では殆んど無い。

次点はハードボタンの透明化&LED発光など、改造もした PalmVx 。

5. 今後どんなPDAがほしいですか？　あなたの夢のPDAを教えてください

現実的な線では Treo700p あたりに無線LANが載ったもの。当然国内で定額データ通信が可能なこと。PalmOS に限定する気はないが、少なくとも「(予定やTodoを見たいなど)何かをしたいと思ったときに2秒以上待たずにそれが出来ること」は必須条件だと思う。現時点では仮に今の T|T3 が壊れたならば、確実にまた PalmOS 機を買う。今ならば TX だろう。

夢の PDA と言う話になると、どちらかと言うと機器としての PDA よりも環境の方が大事だ。どこにいても充分高速な定額通信回線があって、自宅と職場のデータにシームレスにアクセス出来る事。音楽も動画も持ち歩くのではなく「好きなものをいつでも引き出せる」状態が理想だ。
現時点でも PIM に関しては Web 上のツールで近いことが出来るかもしれないが、ローカルアプリと比較するとどうしても起動や動作の軽快さが段違いなので、個人的には (PC上はともかく) PDA では実用にはならない。

ちなみに現状で PalmOS 以外を考えてみると、pdaXrom 化した SL-C750 は小さな Linux としては素晴らしいが、PDA としては使えたものではない。同様に es は素晴らしい面も多々あれど、鈍重な動作と UI の不味さにうんざりする。PalmOS も内部的には(通信スタックなど)相当に腐っている部分があるが、それでも PDA としての使われ方を真面目に考えて作られているのは、私にはこれくらいしか思い当たらない。

1  間違えを恐れるあまり思考のアウトプット速度を遅くしていませんか？：DESIGN IT! w/LOVE

シチュエーションによるとは言え、場が企業の場合、これを素直に「そうだ」とは言いがたい。

完璧さを求めるあまり間違いを過剰に恐れ、アウトプットが遅れてしまうくらいなら、多少、間違いがあるかもと思いつつもとにかくアウトプットを出し、その上で相手の反応を見ることのほうがよっぽど重要ではないかと思います。間違えを恐れるあまり思考のアウトプット速度を遅くしていませんか？：DESIGN IT! w/LOVE

大切なのは「出した情報・意見のケツを持つこと」。不確かな情報を言いっぱなしにされるるほど迷惑なことはない。

更に状況によっては、間違ったことを言う事のリスクが非常に高い場合もある。特に技術者の発言の場合、他の職種よりも「正しいことを言える」可能性が高く、相手もそれを期待していることが多い。また技術的な見解は多くの場合、ビジネスに置いて判断の基礎情報として使われるため、ここに間違いがあるとモデルが前提から変ってしまい、多くの人、コスト、スケジュールに影響を与えかねない。海外など時差のある相手と仕事をする場合は尚更だ。

間違うことを恐れて情報を出さないというのは確かに愚かしく誰の利益にもならないことではあるが、出すからには出した情報に対して責任を持っていくのがビジネスに置いては必要だ。同時に「誰かが間違ったことを言ったときに気付いて修正できるシステム」を持つことも大切だろう。

拙速か巧遅かと言うのは選択肢でしかなく、どっちを選ぶかは状況に依存する。巧速が望ましいのは言うまでもないが、大切なのは最初に書いた通り「発言のケツを持つこと」だろう。

1  プログラマとその他の人々との断絶

プログラムを殆んど書かない人と話していて感じるのは、彼らはソフトウェアをブラックボックスとしてしか扱わないと言うこと。なのでトラブルがあっても「Aの場合はB」「Cの場合はD」と言うケースが統合できない。

せめて情報処理に関わる技術者はある程度のプログラム素養を持つべきだと思うんだが、上流工程ほど本当に知らない人が多い事に悄然とする。本来は彼らこそがプログラマとビジネスの橋渡をすべきで、そのためには両側に立脚点を持っていないといけないはずなのだが。

1  企業における情報化投資額の売上額比

特定業種(情報サービス産業)のやつを調べてたりしたけど、恐ろしく小さい。
0.5%未満のところが最も多く、4%未満までで回答企業の8割強を占めてた…。

セキュリティ対策費は企業規模や業種でかなり違うので何とも言いがたいが、基本的に(特にSMEでは)現状では未だに潜在ニーズでしかなく、リスク啓蒙(金銭込みの話)を絡めてやらないと売れないと言うのが現状だと思う。なんせ直接的には利益を生まない部分なのだから。

更に一方で専任の担当者どころか詳しい社員すらいない中小企業が多いことを考えると、ややこしいことを言わずに「これを買えばあらゆる安全」的なもので無いと駄目というのもある。実際にあまり技術的に詳しいスペックをあげても、そもそも営業に行く人自体が理解出来ていなかったりする。

最終的にはアウトソーシングがお互いに取って一番良い手であることは少なくないが、いかんせんそうした企業にとってはセキュリティと言う言葉の対象になるのが基幹業務である事も多いので難しい所。ともあれ Web やメールサーバといったレベルならばちゃっちゃとホスティングに出してしまえ、とは思う。