Microsoft Research@シアトルでのインターンから帰ってきました。コネ・社会経験ナシの情報系大学院生が、腕一本で「世界で一番アツい会社」に就職するまでの記録
27 10月
先日、
という記事で書いたとおり、キーロガーを使って自分の仕事状況を記録すると
集中力アップのための監視ツールとして使えるのではないか、という話の続きです。
前回の記事をまとめるとこんな感じ:
- キーロガーを使って、キーボードの打鍵状況+マウスのクリック数状況を全て記録
- キー&マウスイベントのキャプチャにはChucKを使う
- 打鍵数+クリック数の「分速」をリアルタイムで監視
- 「分速」がある閾値を下回ったら、「サボってる」と判断して警告音を鳴らす
- 実際やってみたところ効率が大幅にアップ
という結果でした。
正直なところ、記録さえできればそこからは自分の好みに応じた解析もしくは可視化ツールを作るだけなのでプログラムできる人には問題にならないですし、そこからは各人のニーズによりけりなんですが、今回は、こんな風にして解析してみたらどうですか、というお話です。
ということで、以下のようなツールを作ってみました。
- キーロガーのログを読んで、各時間帯ごとの作業量を計算する
- 作業量は、暫定的に、打鍵数+クリック数x3を分速にたものを「1モッポル」とする。自分の場合、Webブラウズが20〜30モッポルぐらい、パワポ作成が80モッポルぐらい、ガリガリコーディングしてる時が250モッポルぐらいでした。名前はなんでもいいのだけれどもw
- 1日の各時間帯のモッポル具合をグラフにして表示
その結果、こんな具合になりました。
1日の各時間帯(10分間隔)における平均モッポルに応じて色がつけてあります。出力はHTMLで、実装はRuby+ERB、補助としてcolor-toolsを使っていい具合に色を変えてみました。
こうやってみると、自分の1週間の活動具合がおもしろいように丸見えですね。色が薄いところは明らかにWebブラウジングしてますし、今週はミーティングなどが多くて「本当に」集中してコーディングしている時間帯があんまりないこともわかります(反省。
ということでかなり面白い感じで解析できたので、これからもぼちぼち使っていきたいと思います。前にも書いたけど、こんな感じで記録から解析までまとめてやってくれるようなコンパクトなフリーウェアでもあったらいいなぁ。自分でRubyCocoaでも勉強して作るしかないか(どなたか興味ある方いませんか。。。?
22 10月
ちょっと前の記事ですが。
日本で言う百式のインターンが近いかな?おもしろそう。
求められているスキルはこんな感じです。
- ネット、ソフトウェア、技術に対する異常なまでの執着
- Availability(=いつでも動ける力
- 文章力
- スクリーンショット取り力
コメント欄から、telecommuteおkらしい。ようするに、「こんなソフトレビューするからスクショ撮っておいてねー」っていう雑用が山のように降ってくるわけですね。最近、何でもかんでも「インターン」って言って煙に巻く傾向があるようなのでちょっと注意したいです。
21 10月
ライフハックを使って、仕事の効率アップなどを計る際の基本となる考え方に「数値化して記録する」というのがあります。たとえば、営業成績を記録・グラフ化してモチベーションアップや目標設定に使う、というのはこのハックのかなり古典的な手法だと言えます。
ところが困ったことに、仕事の「質」に対する最も大事な要素の一つである「集中力」は、数値化して記録することができません。例えば、ある時点での集中力を「モッポル」とか(何でもいいんですけど)測ることができれば、「やばい、集力が40モッポルを切ったから、ちょっと休憩でもするか」とか、「今日は平均60モッポルで仕事ができた。明日は80モッポル目指して気合い入れよう」とかできるわけです。
で、どうしたものかと考えてたんですが、思いついたのは、自分らみたいに基本的にパソコンの前に座って作業するような類の仕事の場合、キーボードの「打鍵数」が、ほとんどそのまま「仕事量」になるなぁ、ということ。(社保庁みたいに一日5000なんて打鍵数で何ができるんだ。余談ですが。) 特に文書とかコード書く仕事の場合そうですよね。一日の打鍵数は、たぶんそのまま「仕事量」の近似としていいだろうし、ある一定時間内の打鍵数は、その時間の「集中力」に従って単調増加する量だと考えることができます。だって、仕事サボってWeb見たりボーっとしてる時って、だいたいマウスホイールしか動かしてないんですよね(笑。
そこで、キーロガーを使って、自分の打鍵状況を監視することで、この「集中力」が自動で測定できて、さらに、継続して監視し続けて、集中が切れたと判断したら自動的に警告「仕事に戻るか休憩取るかどっちかにせい」を出してくれるようなツールがあったら便利かな、と考えたという次第です。
ということで実際に作ってみました。
まず、Mac用に使える良いキーロガーが無いものかと色々調べたのですが、そもそもこういう類のもの、自分でインストールして使うという需要が無いのか(当たりまえ)、なかなか良いものが見つからず。いくつか試したけど、上手く動かなかったり、でした。
幸い、たまたま興味があってイジっていたChucKというサウンド・プログラミング言語
ChucK => Strongly-timed, On-the-fly Audio Programming Language
http://chuck.cs.princeton.edu/
に、キーボードとマウスのイベントを全てキャプチャするという機能が備わっていたので、これをRubyでラップして、3分クッキング的に即席キーロガーを作ってみました。(ちなみにChucK自体もとても面白いプログラミング言語なので、いつかこれ単体で紹介したいです。)
#! /usr/bin/ruby
require "open3"
kstdin, kstdout, kstderr = *Open3.popen3('chuck examples/hid/kb.ck')
mstdin, mstdout, mstderr = *Open3.popen3('chuck examples/hid/mouse.ck')
Thread.fork {
mstderr.each {|line|
if line =~ /mouse button (¥d) down/
puts [Time.now.format, "mouse", $1].join("¥t")
STDOUT.flush
end
}
}
kstderr.each {|line|
if line =~ /down: (¥d+) ¥(code¥) (¥d+) ¥(usb key¥) (¥d+) ¥(ascii¥)/
puts [Time.now.format, "key", $1].join("¥t")
STDOUT.flush
end
}
(Time#formatはstrftime(”%Y/%m/%d %H:%M:%S”)の自作ショートカット)
こんな感じで、ChucKに入っているexamples/hid/kb.ck, examples/hid/mouse.ckを並行に子プロセスとして動かして、stderrに来たものに時刻情報をつけてstdoutに垂れ流すだけの簡単なものです。
ここでポイントなのは、マウスのイベントも一緒に取得している点。例えばパワポの作成とか、CADとか、仕事してるんだけど打鍵よりはマウス操作主体、っていう作業があって、こういう場合はマウスのクリックも記録してあげないと「仕事していない」って誤認識されてしまいますよね。こういうような「マウス系」仕事の特徴は、ボタンをクリックする回数が多くなるという点なので、マウスボタンのdownを記録しておけば、すくなくともヒマつぶしのWebブラウジングとは区別ができるという仕掛けです。
上のスクリプトを動かすと、こんな感じでひたすらイベントとコードを記録してくれます。
2007/10/21 16:43:18 key 7
2007/10/21 16:43:18 key 8
2007/10/21 16:43:18 key 40
2007/10/21 16:43:19 key 54
2007/10/21 16:43:19 key 40
2007/10/21 16:43:19 key 227
2007/10/21 16:43:19 key 44
2007/10/21 16:43:19 key 57
2007/10/21 16:43:19 key 27
2007/10/21 16:43:19 key 22
2007/10/21 16:43:20 key 227
2007/10/21 16:43:20 key 43
2007/10/21 16:43:20 key 43
2007/10/21 16:43:23 mouse 0
2007/10/21 16:43:25 mouse 0
2007/10/21 16:43:26 key 227
2007/10/21 16:43:26 key 43
2007/10/21 16:43:26 mouse 0
2007/10/21 16:43:28 mouse 0
2007/10/21 16:43:28 key 227
2007/10/21 16:43:29 key 43
2007/10/21 16:43:29 key 43
2007/10/21 16:43:30 mouse 0
2007/10/21 16:43:31 mouse 0
で、手短かに結論だけ書くと。
このように記録されたキー履歴をリアルタイムで監視して、打鍵数+クリック数の「分速」を測定し続けてくれて、それがある閾値(自分の場合、打鍵数+クリック数×3の過去5分間の平均が分速85という基準)を下回ったら、「集中力が切れた」と警告音を「ピピー!」と出してくれるようなものを作りました。試しに作業の手を止めてWebブラウジングをはじめてみると、見事に警告音が鳴って集中力を呼び戻してくれます。詳細はまた後日「解析編」として書きますが、ここまで来ればスクリプト書ける人ならささっと自分で組んでしまったほうが早いかも。自分用カスタマイズもできますし。(ちなみに警告音を出す部分も、上で紹介したChucKを使いました。これだと自分好みで警告音までカスタマイズできるので楽しいです)
で、結果ですが、これ使って仕事にとりかかってみたところ、一日がかりだと踏んでいた作業(具体的には、科研費申請書類のある部分の作成orz)が2時間弱であっさり終わってしまい自分でもびっくりして、興奮してエントリを書いている次第です。自分がいかに普段集中力が途切れがちか、ということと、集中力が切れてから元の作業に戻るまでのオーバーヘッドというのがいかに大きいか、というのをまじまじと実感させられる結果でした。
ということで、自分がこれまでに試したどのLifeHackよりも効果があったので、
だれかこういうのが1つにまとまった使い勝手の良いアプリ作ってください(> < )
Mac OSの上部バーに常駐して監視・記録するようなやつがいです。
ちなみに、エントリ書いた後になって調べてみたらWindowsにはこのテのソフトが既にあるらしいです。
でもこれだと時間単位が1時間と長過ぎるので「集中力監視」には使えないし、マウスをキャプってくれないので、マウス主体作業には使えないという難ありです。やはり自分用にカスタマイズしたLifeHackツールは最強ですね。
あ、あと、ソリティアをすごい早さでプレイしてたり、メッセですごい勢いでチャットしているような時にどうやって警告出すかは今後の課題。
13 10月
mixiのほうにも書いたけど、昨日はRuby作者のまつもとゆきひろさんの講演
中京大学公開講座「世界に広がるRuby」
http://www.rubyist.net/~matz/20070917.html#p01
を聞きに行ってきました。研究にWeb開発に、Rubyヘビーユーザーの自分としてはこれは見逃せないイベントでした。
Matzさんの講演の中でも、特に自分の興味を惹いたのが、”Love/Hate Ratio”というお話です。(もちろん、他の話も全て興味深かったのだけれども。)
これは、「Rubyがいかに愛されている言語か」というものを、ある意味定量的に示した指標で、簡単に言うと、Googleで「”i love ruby”」というクエリで検索したときのヒット数と、「”i hate ruby”」というクエリで検索したときのヒット数との比です。だからLove/Hate Ratio。この”ruby”のところを他の言語の名前に変えれば、その言語のLove/Hate Ratioが求まります。この値が大きいほど、その言語は愛されている、というわけ。で、Rubyはダントツだと。
「愛されてる度」の正確さはともかく、インパクトあって実に分かり易い指標ですよね。で、調べてみると、Matzさんの
[Ruby] Ruby is the “Most Loved” programming language
http://www.rubyist.net/~matz/20050427.html#p01
のエントリから派生して、独自にこのLove/Hate Ratioを求めている記事がいくつか見つかります。
HOW DO YOU LIKE SILICON VALLEY? | まつもとゆきひろさんに会った
http://kaeruouji.jugem.cc/?eid=39
でもこれって、自然言語処理で言うところの評判分析の、すんごい簡略版じゃないですか。今の研究の最先端から言えば、Hearst 1992が”X such as Y”を使って「XはYの上位語である」という関係を抽出したぐらいシンプルな手法です。(分野外の人ごめんなさい。詳細はこのへんを参照→ Automatic acquisition of hyponyms from large text corpora)
ということで、これだけでは「Rubyが愛されている」ことの調査には甘すぎるでしょう、と。これはちょっと改良してみるしかないですね。
よく考えたら、この単純な手法、問題があって、まず一つ目が曖昧性の問題。”i love ruby”というクエリでは、宝石のルビーを愛する人のブログもヒットするかもしれない。その問題はMatzさんの引用元も認識しているらしく、実際には「”i love ruby” programming」というクエリで求めてるそうです。でも、たぶん「”i love ruby” language」でヒットしたページも、「プログラミング言語としてのRuby」を愛する人のページ、としてカウントしていいはず。
もう一つの問題は、他の言い回し。”I love Ruby”は実に分かり易い例ですけど、例えば”I like Ruby”って言ってるのも、「愛してる度」は低いけどカウントしてもいいのでは?他には”I don’t like Ruby”は?などなど、考えられるわけです。
ということで、これらの問題点をふまえて、実際にやってみた。
おそらくこれまでで最も信頼性のあるLove/Hate Ratioです。
以下の8種類のクエリを実際にGoogleで調べて、そのヒット数をカウントします。”x”のところはもちろん言語名。で、最後の計算方法のところだけれど、”i like x”と”i don’t like x”については「愛してる」「嫌い」度がそれぞれ”i love x”と”i hate x”に比べて低いとみなして、重みを半分にします。つまり、”i like x”2回分で”i love x”1回分相当ということです。
1a. 「”i love x” programming」1b. 「”i love x” language」
2a. 「”i like x” programming」2b.「”i like x” language」
3a. 「”i don’t like x” programming」3b.「”i don’t like x” language」
4a. 「”i hate x” programming」4b.「”i hate x” language」
対象言語は以下のとおり。
Ruby
Python
Smalltalk
Perl
PHP
Lisp
Java
C
JavaScript
結果はこんな感じ。Ratio順に並び替えてます。
| 言語 | 1a | 1b | 2a | 2b | 3a | 3b | 4a | 4b | Love/Hate Ratio |
| Ruby | 10800 | 11700 | 914 | 9850 | 3140 | 3970 | 150 | 173 | 7.189 |
| Lisp | 758 | 528 | 7010 | 5650 | 2620 | 8 | 216 | 149 | 4.536 |
| Python | 9420 | 9860 | 9340 | 11600 | 6820 | 5430 | 316 | 388 | 4.356 |
| Smalltalk | 191 | 200 | 2060 | 3020 | 8 | 6 | 116 | 647 | 3.806 |
| Perl | 14500 | 705 | 15600 | 916 | 7060 | 4930 | 801 | 1410 | 2.859 |
| JavaScript | 949 | 1170 | 5410 | 4280 | 1890 | 1480 | 1300 | 941 | 1.773 |
| Java | 813 | 23000 | 955 | 20800 | 13900 | 506 | 800 | 13600 | 1.605 |
| C | 6520 | 6550 | 795 | 651 | 14900 | 12500 | 2450 | 1850 | 0.766 |
| PHP | 852 | 759 | 668 | 652 | 4260 | 5170 | 1110 | 1180 | 0.324 |
ということでやはり断トツです。今回しっかりと計算方法を見直したこともあって、Matzさんのオリジナル記事にあるような100以上なんていうとんでもない数字も出てないですし、かなり信頼性の高い値が出てるのでは。RubyはPerlの約3倍、PHPの約20倍「愛されている」計算です。
ほかにも”x is a good language”とか、”x sucks”とか、フレーズはいくつも考えられるわけですが、本格的にやると素性選びなりスコア付けなり機械学習なりが必要になってくるのでこれ以上は評判分析の専門家に任せましょうか。(誰かやるのか...!?
ちなみに”I like C” としたときに”I like ℃-ute”がたくさん出るのには参った(笑 こういう問題に対処するために自然言語処理の研究者は日々格闘しているわけですね。最初は、Matzさんの言うように「お遊び」的問題でも、しっかりとやろうとすると研究レベルになるという点で良い例題だと思ったので紹介しました。
ちなみに、言語どうしの具体的な順位についてのコメントは差し控えておきますね...。
12 10月
そろそろ2009年新卒の就職活動が本格的にスタートしますね。というか実は自分も2009年新卒(予定)なんですが、日本の「普通の」企業に就職する気も、「普通の」就活をする気もさらさら無いので、冷静に見ています。ただ、回りも慌ただしくなるし、就活がどんなものかウォッチしておく意味で、アンテナは常に張っています。
以下、気になった記事+サイトのクリップです。定番から個人用まで。あとでじっくり読む。
日本で普通の就活をする際に必要となるサイトや記事はほとんど上の記事にまとまってます。参考になる。
広告業界就職ノススメ。: 「内定」と「内々定」の違い。
http://adunion.cocolog-nifty.com/column/2005/04/post_b89e.html
就職活動を迎えている人へ。
http://anond.hatelabo.jp/20071009053641
こちらは定番ですね。
みんなの就職活動日記
http://www.nikki.ne.jp/
FPN-面接で聞かれる可能性のある100の質問集
http://www.future-planning.net/x/modules/news/article.php?storyid=1385
Amazon.co.jp: 就活の王道
http://www.amazon.co.jp/exec/obidos/ASIN/4893469843/
Amazon.co.jp: 内定勝者2008
http://www.amazon.co.jp/exec/obidos/ASIN/456965777X/
以下海外就職用。
CFN|外資系から海外の仕事まで留学生と国際派の就職・転職サイト。バイリンガルのための求人情報はキャリアフォーラムネット。
http://www.careerforum.net/
海外転職エンジニアが得たもの、失ったもの/Tech総研
http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000450
海外就職の基礎知識
http://www.interq.or.jp/tokyo/ystation/world2.html
70+ Tools For Job Hunting 2.0
http://mashable.com/2007/07/21/job-hunt/
こちらは米Amazon.comから注文。郷に入るには郷を知れってか。着いたら読んでレビューします。
10 10月
といっても先週末のことですが。
言語理解とコミュニケーション研究会(NLC) 究会言語理解のためのコーパスからの知識獲得
http://www.ieice.org/~nlc/jpn/kenkyukai/nlc0710.html
メインは、自分の研究分野(類義語自動獲得)の大先輩であるPatrick Pantel氏の招待講演です。講演は2部構成で、前半は類義語獲得の基礎技術のお話。分布仮定(distributional similarity)から始まって、文脈素性の取り方や、相互情報量(pointwise mutual information)など、知っている話がほとんどだったけど、話が整理されてて面白いし、何よりストーリーがあるな、と思いました。分野になじみの無い人でも興味深く聞けるのでは。声だけは録ってきたけど、講演のビデオか何か公開すればかなり有益なチュートリアルになりそうです。
後半は、前半の技術をちょっと応用してもっと面白いことをやってやろう、というお話。例えば、[”apple”, “banana”, “peach”]というクエリを投げると”pear”を返してくれる連想検索?システムや、「なぜこれらの単語は類似しているのか?」に答えてくれるシステム(これらは果物で、食べられて、甘くて...みたいに)。あとは、「仲間はずれ検出システム」等。どれもこれも、適度に応用がありそうで、適度に難しくて、自然言語的な解法が求められる問題ですね。特に連想検索については需要があると思うので、ちょっと自分でも日本語バージョンを手をつけてみようかなと思ったり。
質問したり、講演後に本人とお話できる機会があったので、PMIなどの重み指標と類似度指標についてうかがう。丁寧に答えてもらい感謝感謝です。参考文献を紹介してもらったのでちょっと調べてみよう。
他の4件の発表も、どれも面白い。NLC研に来たのは初めてですが、これぐらいの集まりならちょこちょこ覗いてみたいなと思います。ちなみに参加者の顔ぶれがこの前のNLP若手の会とかなりかぶってました。ポスター発表でお会いしたY社のK林さんとまたお会いできたり。実は同社の研究所には興味津々なので、時間をつくってゆっくり見学でもさせて頂ければなぁと思ったりしてます。でもインターン募集は今んところやってないそうなので(正社員only)、ちょっとしょんぼり。
7 10月
YouTubeには色んな楽器でマリオのテーマを演奏した超絶映像があふれていますが、たぶんJavaScriptで再生したのは世界初ではないでしょうか。(楽器じゃないけど)
という面白げなライブラリが公開されてましたので、練習も兼ねて勢いで打ち込みました。
このピコピコ音、といえばファミコン、ファミコンサウンドといえばマリオ。
昔耳コピしたMIDIがあったので、そこからMMLをシコシコと打ち込みます。(ホワイトノイズのトラックは紛失)
この時代になってEmacsでMML書くとは夢にも思わなかった...。
(追記2007/10/08:ホワイトノイズトラックを改めて耳コピして追加+ちょっと修正。)
ちなみに一番苦労したのはWordPressにJavaScriptを埋め込むところです :-P
再生は以下から。
再生する
MMLはこうなってます。
汚いJavaScriptソースです。
まぁ、要するにMML打ち込んでブラウザで鳴らしただけなんですけど、MMLという死んだ技術(?)とJavaScriptが融合してまた面白いことができそうですね。例えばMMLをラッパして打ち込みを楽にしてくれるJavaScriptライブラリとか。今んところJSMML(というかそれがラッパしてるFLMML)が繰り返しに対応していないので、その辺りをカバーしてしまうのも手。あとは、MMLになった瞬間に音楽が文字列になるので、たとえば文字列操作だけで「音をトランスポーズするエフェクト」「ディレイ」「アルペジエーター(!)」なんかも作れそう。夢がひろがりんぐ。
5 10月
昨日のエントリの続き。
- 4. その場にいる具体的な誰かに向かって個人的に話しているように話す
タイトル通りです。「聴衆に対してパブリック・スピーキングをしている」という心構えだとどうしても緊張してしまうもの。そういうときは、聴衆の中にいる具体的な誰かを決めて、その人に個人的に話しているような気持ちで話すとだいぶ心構えが楽になります。
その「誰か」は、(1)自分の知っている人で、(2)自分の話を「うんうん頷いて」しっかり聞いてくれそうな人、だとベターです。自分は前に出た会議で、発表の途中にこのTipに気づいて、その後だいぶ楽に発表出来た経験があります。
注意点として、このテクニックのせいで、視線が一点に集中しないようにしましょう。聴衆を均等に見渡す感じで。それでもやはり話してる方としては、しっかりと聞いてくれている人のほうをつい見てしまうものですけどね。
- 5. 場を和ませ、自分も和む
欧米人はプレゼンを始める前などによくジョークなどを飛ばします。これは、聴衆の緊張を解き、親近感を増す以上に、「自分の緊張を解く」のに絶大な効果があります。でも、なかなか気の利いたジョークなんて難しいものですよね。
「場を和ませ、自分も和む」ためなら、別にジョークに限らなくても達成することができます。
自分は以前に出た学会で、重要な結論を述べているスライドのところに載っているグラフが、パワポかExcelか何かの不具合により全く表示されないというトラブルに見舞われたことがあります。「Well, there’s supposed to be a very important graph here, but …」とか言いながら困っていたら、なんとなく間が抜けた感じになって、聴衆の一人が「We can look at the results in the proceedings.」などとフォローしてくれたりして、結果的に聴衆との距離が縮まって、その後だいぶリラックスしてプレゼンに望めた、ということがあります。この場合は結果オーライで、再現するのは難しいかもしれませんが。(ちなみに発表は自分のPCに切り替えて事なきを得ました)
ちなみに、自分の分野(自然言語処理)でよくある方法としては、自然言語処理では、手法の説明をするときに「例文」をよく出すのですが、例文をその会議の会場にちなんだものにしておく、などのテクニックがあります。いつも「ぼくはうなぎだ。」では素っ気ないですからね...。
- 6. 誰かに練習に付き合ってもらう
これはTipsというか必須な気がします。日本人でも良いので一度プレゼンを聞いてもらって、よく分からない箇所が無いか指摘してもらうようにしています。話し方のチェックだけなら自分のプレゼンを録音するなりしてそれを聞けばいいのですが、自分の声を聞き直すのはかなり嫌な気分になるのであんまり気が乗らないもの。そういう時に人を使ってしまいましょう。
難点は、理解されなかったときに、それが話し手の話し方の問題なのか、聞き手の英語力の問題なのかの見極めが難しいところ。でも、指摘は真摯に受け止めて、何らかの改善を考えたほうが結果的に(人間関係も?)うまくいきます。
4 10月
最近、会議や国際学会等で英語でプレゼンする機会が増えてきたので、英語で上手くプレゼンするために心がけていることをTipsとしてまとめてみます。
- 1. 本番前に英語を慣らしておく
プレゼンの出来は、自分の場合、プレゼンの内容よりも、「自分の言いたいことの筋道がきちんと伝わったか」「緊張せずリラックスして訴えることができたか」ということに大きくかかってる気がします。そういう意味で、英語がすらすら出てくるように準備しておくことは心理的な意味でかなり重要です。
個人的な経験ですが、プレゼン前に英語のリスニングCDを聞いて耳を慣らしておく、とかいうのはあまり効果が無いです。もし教材でやるとすればリピーティングもしくはシャドウイングの方が効果が高い気がします。
それよりも、できればプレゼン前には普通に英語で会話できるチャンスを作れたほうが良いです。プレゼン前に上司や先輩と相談して、英語で話しましょう、みたいなことができるといいんですが。これが難しい場合、学会発表の場合はだいたい機材の打ち合わせや挨拶などでそのセッションの座長と話すので、そこで軽い雑談でも入れてみると良いと思います。もしくは、自分の前の発表の人に対して、質疑応答で質問してみましょう。これは英語の練習に加え、緊張をほぐす意味でおすすめです。
- 2. スクリプトを書き、練習を怠らない
事前に、どんなに大丈夫だと思っても、発表のスクリプト(台本)を一通り書いてみることにします。もしこの台本を書くときに、英作文で「う〜ん」と詰まる箇所があるなら、そこは口頭で話しても確実に詰まるところ。他には、意外と読み方の分からない単語が出てきたりして焦ることも。どんなに簡単な文でも、実際に書いてみると分かり易い言い方とか、より正確な言い回しを思いついたりします。
書いた後は、それをひたすら読んで暗記すること。だいたい5回通りぐらい練習を繰り返すと暗唱できるようになってきます。もし5回以上練習しても暗唱できない箇所がある場合は、自分の記憶力を疑う前に、その箇所の論理の流れが自然かどうか、飛躍はないかどうか、言い回しは難しすぎないかどうかをチェックしましょう。難しい言い回しを書いてそれをがんばって覚えるよりも、より自分にとって簡単な言い方に置き換えたほうが結果としてうまく行く場合が多いです。
- 3. 本番は、スクリプト通り話さない
前の項目と矛盾するようですが、本番はむしろスクリプト通り話そうとしないほうが上手く行くような気がします。というか、本番にがんばってスクリプトを思い出しているような状態になるということは、そもそも練習が足らないか、英語力が根本的に不足しているか、その両方か、というのが原因だからです。本番までにはスクリプトを「体で覚えて」、そこで使う表現をすべて吸収してしまうべきです。十分緊張がほぐれていれば、少しぐらいスクリプトを外れたとしても、本質が伝わらなくなってしまう恐れは少ないですね。
続きの3つはまた後で書く。
2 10月
英語で論文などを書いてると、特にアブストラクトのところで、単語数の指定(何単語以内というような)がある場合があります。
自分は文書+プログラムを書く時には全てEmacs(Carbon Emacs)を使っているのですが、Emacsにこの機能が標準で付いてないので少し不便でした。Microsoft Wordには単語を数えてくれる機能があるので、わざわざ文章をコピー&ペーストして確認したりとか。1ファイル単位なら、wcコマンドで簡単に数えられるんですが、書いてる論文のこのセクションだけ、という場合には色々と不便です。ちなみに、文字数と行数だけを数えてくれる機能なら、Emacsに標準装備で付いてます(リージョンを選択してM-=を押してみよう)。
調べてみたら、Emacsで文字数をカウントできるEmacs Lispスクリプトを発見したので、それを使わせてもらうことにしました。
word-count-mode
http://taiyaki.org/elisp/word-count/
リンク先のページ、ダウンロード先が404になってしまうのですがアドレスをこのように↓変更するとうまくいきます。
http://taiyaki.org/elisp/word-count/src/
word-count.elパスの通ってるところにおいて.emacsを指示通りに設定すればOK.
M-+を押すとマイナーモードが起動して、M-+を押したところから現在のカーソル位置までの「文字数/単語数/行数」のフォーマットで、モードラインに表示してくれます。
もちろん、日本語の単語は数えることができませんし(そもそもの日本語の「単語」ってなんだよ、ってなる)、数えるときの正規表現も単純ですが、ちゃんとやろうとすると「そもそも単語とは何か」っていう深みにハマるのでこれで良しですね。これからも愛用してみます。