1  新ブログへの移行

3年近く更新していなかった当ブログですが、新しいURLで再開しています。

• https://blog.yoosee.net

以前よりは更新頻度高めのつもりです。

なおRSSも Auto Discovery 出来るはずですので気が向いた方は登録ください。またFacebook Pageを作っているので、Facebookで更新を受けたい方はそちらをLikeお願いします。

このURLでのブログは当面削除の予定はないのでこのままで、もしかしたらどこかのタイミングでデータ移行するかもしれませんが、今のところ未定です。

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  SSH + Google Authenticator

最近アカウント乗っ取り系の話がよく出ていてつい先日も Twitter のパスワードリセットを食らったところなのだが、そう言えば ssh は 2 Factors auth に対応しているのかなと思って (秘密鍵とパスフレーズが既に2 Factorsに近い気もするが、そこへの追加認証手段という意味で) ちょっと調べてみると PAM に Gooogle Authenticator による認証を追加する方法が普通にあるのだった。やり方はほぼ Two Factor SSH with Google Authenticator のまま。 Debian だと libpam-google-authenticator は deb があったのですごく簡単。

# aptitude install libpam-google-authenticator 

インストールしたら PAM の ssh 認証に google authenticator を追加する。設定ファイルの最初の方に下記の行を追加。

# vi /etc/pam.d/sshd
...
auth required pam_google_authenticator.so
...

sshd 側で Challenge Response の Auth を有効化する。

# vi /etc/ssh/sshd_config 
...
ChallengeResponseAuthentication yes
...
# /etc/init.d/sshd restart

Google Authenticator のキーを新規生成。コマンドが用意されているので ssh でログインするユーザ権限で実行する。secret key や scratch codes などは ~/.google_authenticator に保存されるようなので特にここでメモる必要はないが、このサーバに入るための緊急用認証情報である scratch codes はどこか別のところに記録しておいたほうがいいだろう。いくつか設定を聞かれるので答えておく。これも後から設定ファイルで変更できる。

$ google-authenticator

[ここにURLかQRコードが表示される]
Your new secret key is: XXXXXXXXXXXXXXXXXXXXXXXXXXX
Your verification code is 492939
Your emergency scratch codes are:
  67136983
  19738098
  69970608
  69623422
  35724953

Do you want me to update your "~/.google_authenticator" file (y/n) y
(設定ファイルを上書きするか)

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
(同じトークンを複数箇所から使えないようにするか)

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
(時計が同期してない環境のために、同期のズレの許容幅を標準の1:30から4:00にするか)

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
(総当たり攻撃を防ぐため30秒位内の試行回数を3回までに制限するか)

元記事だと Google の URL が表示されていたが、手元の環境では terminal 内に QR コードが表示されたので、Android の Google Authenticator アプリから Menu → Setup Account → Scan a barcode で簡単にアカウント追加できる。もしくは同時に表示されている Secret Key を入力してもいい。

なお既に Google アカウントで 2 Factor auth を使っている場合でも、単にアプリ内に verification code が並んで表示されるので特に問題はない。表示識別名は `whoami`@hostname` 相当になるようだが当然アプリ側で変更できる。

$ ssh yoosee@example.com
Verification code: 
...

Verification code に Google Authenticator に表示される対応の数字6桁を入れると認証される。当然この他に公開鍵 (ないしパスワード) による認証が行われる。

ちなみに当然ながらこれ、scp などの認証でも毎回聞かれる上に ssh-agent なども効かないので頻繁に接続を繰り返すようなケースには向かなさそうだ。

1  謹賀新年

明けましておめでとうございます。本年もよろしくお願いいたします。

2008年夏からの米国生活も気づけばもう5年目も半ば過ぎ。いつ帰るのかもよく分からない状況は相変わらずですが、家族も増えて共共元気でやっております。

1  Acer C7 Chromebook を Developer Mode に切り替えて Ubuntu をインストール

前回の続き。Chromebookはそれなりの事ができつつも使い込むと細かい使い勝手が気になる状態であり、まあ元からそのつもりでもあったので Ubuntu に入れ替えることにする。やり方自体は How to install Ubuntu 12.04 on the $199 Acer C7 Chromebook などで既に公開されており、通常のインストールとは異なるもののそう難しいものではない。

Developer mode への移行
通常 Chromebook は最新リリース版 ChromeOS へのアップデートを自動で行う仕組みになっているため、それ以外のものを入れる場合はまず Developer Mode にする必要がある。

過去の Chromebook は物理スイッチでDeveloperモードへの切り替えが行われたらしいが、C7 にはそうしたスイッチはない。ではどうするかというと、電源を切った状態から「ESC + Refresh (最上段のリロードキー) 」を押しっぱなしで電源を入れることで起動時に Repair モードに入る。「Chrome OS is missing or damaged」等と言われるが、ここで更に Ctrl + D を押すことで to turn OS verification OFF, press ENTER という画面に進む。ENTERを押すと OS verification が無効にな状態で再起動され、Developer modeへの変更処理が行われる。

Your system is transitioning to Developer Mode

Preparing system for Developer mode

のようなメッセージが表示され、実際の変更処理に数分待たされる。起動が終わると Chromebook を初回立ち上げた時に表示されるセットアップ画面が表示される。最初の画面でネットワークコネクションを設定、ないし有線でEthernetに接続。Google Account にログインしていない状態で「Ctrl + Alt + → (Fwd) 」キーを押すと Developer Console 画面が表示される（ちなみに Ctrl + Alt + ← (Back) でGUIに戻る）。その画面に表示されている通り、Console からは ユーザID chronos でシェルログインが可能。ログインしたら chromeos-firmwareupdate コマンドを使ってファームウェアを Developer 用のものに書き換える。といってもコマンドを1つ実行するだけ。

localhost login: chronos
 $ sudo bash
 # chromeos-firmwareupdate --mode=todev

これで Developer mode の firmware がインストールされ、標準以外のOSイメージが利用可能になる。この状態で一旦再起動しておく。

 # reboot

2  ChrUbuntu 12.04 のインストール

Developer firmware が導入されたとは言え Chromebook BIOS では Chromebook 以外の OS boot image を起動できないらしい。なので他のOSを入れる場合は Chromebook が動いている状態から直接 partition を切りなおしてシステムをインストールしたり bootloader を書き換えたりという処理が必要になる。そうした一連の処理をスクリプトにまとめて提供している ChrUbuntu 12.04. Now with double the bits! という記事があるため、基本的にはこの方法に従えばよろしい。

Developer mode での起動状態から再度 Ctrl + Alt + → でコンソール画面に移行し、再度 chronos でログイン。コンソールから以下のコマンドを入力する。

$ wget http://goo.gl/i817v; sudo bash i817v

(ちなみに私が導入した際は http://goo.gl/2x8a4 だったのでその後更新されたらしい) 。

初回実行時は ChrUbuntu に利用するHDDのサイズを聞かれるので適当に指定する。私は 250GB を割り当てた。再起動すると Partition 設定がしばらく動作し、その後はパッケージのインストールが進むので 10-15 分ほど待つことになる。インストールが完了すると Chromebook は再起動し、Ubuntu のログイン画面が表示されるので ユーザID user パスワード user でログイン。なお root password も user になっている。ログイン後は新規ユーザを作るなりパスワードを変更するなりしよう。

このままだと再起動した際に ChromeOS が起動する。Ubuntu を起動させたい場合は以下のコマンドを実行する。

$ sudo cgpt add -i 6 -P 5 -S 1 /dev/sda

ChromeOS を起動するには Developer Mode を off にするか、もしくは以下のコマンドを実行する。

sudo cgpt add -i 6 -P 0 -S 1 /dev/sda

ここまで完了してしまえばほぼ普通の Ubuntu であり、ハードウェアの認識なども特に問題なく利用できる。ただ Suspend/Resume 時に dbus 関係のプロセスが暴走するという古来伝わる不具合が発生してしまっており、まだ解決できていない。

1  Nook Simple Touch を汎用Android端末として使う

B&N の電子書籍端末 Nook Simple Touch が Refurbished $59.00 で売っていたので思わず買って早速 root 化し、e-ink 汎用Android端末として使っているが、これが素晴らしい。なにが素晴らしいって様々なファイル形式やサービスに1つのデバイスで対応できて、かつ e-ink であること。pdf も epub も mobi も zip で固めた jpg/png も text も豊富なアプリで読めるし、Kindle はじめ Android 上でアプリとして動く電子書籍リーダももちろん使える。電子書籍のサービスやフォーマットが過渡期である今は特にそうしたコンセプトの端末がありがたい。

Nook Simple Touch のデバイスとしてのスペックはこんな感じである。

• 6インチ 800x600 e-ink タッチ ディスプレイ
• CPU OMAP 800MHz, Memory 256MB
• microUSB スロット (32GBまで対応)
• WiFi, microUSB
• 左右ベゼルに計4箇所のハードウェアキーと、下部中央に N (Nook) キー、背面に電源キー
• 16.5 x 12.7 x 1.2 cm, 212g
• Android 2.1

解像度は1世代前のKindleと同程度。本体のストレージは数百MB程度しか空きがないが、microSDスロットがあるので自炊ファイルを相当詰め込んでもデバイス容量で困ることが無い。また左右ベゼルの上下に合計4箇所のハードウェアキーがあるので、画面タッチではなく物理キーで読み進められるのが素晴らしい (ボタンが多少押しにくいのだけもったいないが) 。重さは他のKindleと同程度で軽く、かつ背面のくぼみに手をかけて親指はハードウェアボタンに置きっぱなしに出来るので大変快適に読書ができる。

OS が Android 2.1 と今となってはかなり古いが、読書に必要なアプリが動けばいいと割り切ればさほど困らない。具体的には下記のアプリを中心に使っている。

• ezPDFreader / PDF ファイル閲覧
• Perfect Viewer / 自炊したマンガや書籍の Jpeg を固めた zip の閲覧
• 縦書きビューワ / 青空文庫などのテキストファイル縦書き閲覧
• Cool Reader / epub や mobi など複数形式対応リーダー
• Kindle / Kindle Store の書籍と Instapaper からの送付用
• JustReader / Google Reader と同期してのRSS購読
• X-plore File Manager / 端末のファイル操作やDropbox, Sambaなどからの転送用

こうしたアプリの多くはボリュームキーでのページ送り設定が出来るので、NSTツールで左右のハードウェアキーをボリュームの上下にアサインするとハードウェアでのページ送りが出来るようになり、大変快適になる。特にPerfect Reader は余白の自動カット機能などもあるため、6インチの画面でも比較的快適な大きさで読むことが出来る。

ほぼ唯一痛いのはKindleで、動くことは動くのだが Android 2.1 上だと Amazon.co.jp への接続ができない。これだけが本当に痛い。しかたがないのでそこは Amazon.com Kindle 端末として使うことにする。

それを除けばやはり e-ink の画面は文章を読むには楽だし、窓際や屋外でもなんの問題もなく読書ができる。電池の持ちも Android 化しても常駐アプリを増やさなければさほど悪くならず1週間程度は使える。汎用性が高く使い勝手のいい電子書籍リーダーとしてしばらく主力になってくれそうである。


なお Nook Simple Touch の root 取得 / 汎用Android端末化は以下の記事を参考にした。

• Turn a $99 Nook into a Fully Fledged Android Tablet in Four Easy Steps
• Touch Nooter 2.1.31
• nookdevs.org Nook Simple Touch Rooting

基本的には必要なイメージファイルをmicroSDカードに dd などで焼いてbootし、後は手順に従ってGoogle Accountにサインアップするだけで、さほど難しいところはない。