ゆうき100%

一冊の本から垣間見える元同僚との友情

2012-02-12T14:57:00.002+09:00

就活のインタビューのとき、もしくは今の仕事でついついやってしまうのが、エンジニアの本棚を眺めることです。その人がどんな分野の人なのか、本棚を見ればなんとなく想像できる。名著と言われた本がずらりと並んでいるオフィスは何度訪問しても飽きることはない。
今の職場では、ほとんど各人に個室が与えられているので、本を手元に置いておくのが好きな人は書物を山のようにオフィスに持ち込んでいます。

オフィスにおもちゃを置く人もいる

僕は共有オフィスですが、オフィスメートが、型システム、計算論、コンパイラのエキスパートで、仕事の合間にちょっと暇ができるとラムダ計算や証明論について語ってくれます。彼の本棚にはゲーデル、エシャー、バッハの第一版も置いてあるので、僕がいつかそれを読破して理解したら、彼と熱く語りたいと思っている。

これがマイデスク、本は自宅で読むのであまり持ち込んでいません

ところで、今の会社に入社が決まったころに書いたこのエントリーで、田中一規さんを言及しましたが、僕のオフィスの隣にいるエンジニアは、田中さんの Quality Engineer 時代の同僚でした。彼のオフィスの本棚を見ると、なんと田中さん著のマンガ「種の起源」が！

洋書の中に紛れた一冊の和書マンガ（撮影は本人の許可を得てます）

このマンガどうしたんですかと聞くと、「彼から直接買ったんだよ。残念ながら日本語は読めないけどね。彼は素晴らしいし、彼との仕事は楽しかったからさ。」と返してくれました。

一冊の本から垣間見える友情に、ふと心が温まった瞬間だった。

見逃していた Windows 上でのコンパイルエラー

2012-01-19T14:25:00.003+09:00

仕事でミスを犯しました。自分は普段 Linux 上で開発をしており、ビルドもテストも自分の環境でパスしたのでコードをコミットしたところ、後で「Yuki、Windows上でコンパイルエラー出てるよ」とメールが飛んできました。これには思わずエッ？となりました。さらにはコードベースを汚してるもんだから冷汗たらたら。エラーメッセージがあさっての方向を指していて調査に時間がかかりましたが原因はこういうことでした。簡単な例ですが、

MyClass.hpp

#ifndef MYCLASS_HPP_INCLUDED
#define MYCLASS_HPP_INCLUDED

#include <boost/scoped_ptr.hpp>
#include <boost/shared_ptr.hpp>

class Empty; // forward declaration

class MyClass
{
public:
    void Foo(Empty *e) {}; // compiles with g++ and with Visual C++

    void Bar(boost::shared_ptr<Empty> e) {}; // compiles with g++ and with Visual C++

    void Baz(boost::scoped_ptr<Empty> e) {}; // compiles with g++ but NOT with Visual C++
};

#endif

Main.cpp

#include "MyClass.hpp"

int main()
{
    MyClass obj;
    return 0;
}

気になって、帰宅してから自分の環境で試してみたところ、Windows Vista、Visual C++ 2008 Express Edition、boost 1.40.0 でも同様のコンパイルできない現象がみられました。Ubuntu 10.10、gcc 4.5.5、boost 1.42.0 ではコンパイルを通してくれました。

Smart Pointers は生のポインタのように使える上、生のポインタにつきまとう面倒を人に代わって管理してくれるという利点があり（基本的には。当然落とし穴も）、それは #include と forward declaration の関係にも通じると思いこんでいました。上の例で、Visual C++ でコンパイルを通すには、MyClass.hpp で #include <Empty.hpp> をしないとダメなようです。それを避けるためにポインタと forward declaration で済ませようとしているのに、うーん、仕事場の Visual C++ と自宅の Visual C++ 2008 Express Edition ではそれを見逃してくれませんでした。

MyClass.hpp のような空の（implicit）inline 関数が並んだ一見用途が不明なクラスが登場するシナリオなんてあるのかと不思議に思うかもしれませんが、テストの際に Mock クラスとして使いたいときに上記のような MyClass を用意することがあります。

どこかで pointee のサイズを調べようとしてエラーが飛んできてるのかもしれませんが、なぜ Visual C++ ではそういう扱いなのかまだ根本のところで分かっていないので、各種の Smart Pointer の実装と照らし合わせてこれから調べていくところです。

日本での休暇から戻りました

2011-12-09T09:37:00.001+09:00

11月は休暇でまるまる日本にいました。2年ぶりの帰国に胸を躍らせ実際に帰国してからというもの、コンビニに入ってその充実っぷりにテンションが上がったり、友人に会ったり、会社の東京オフィスに行ったり、温泉に行ったり、ドラクエ25周年の展示会に行ったり、藤子・F・不二雄ミュージアムに行ったりと、夢のような時間を過ごしました。
こういう素晴らしい国が母国で、家族や友人がそこで自分の帰りを待っているという安心感は、何物にもかえられません。妙に聞こえるかもしれませんが、僕の将来の夢は帰国して日本で暮らすことだと誓い、日本を後にしました。

就労ビザである H1B を正式に取得し、無事に仕事も再開しました。毎日刺激的で、製品を進化させるべく最前線で15年～20年闘ってきた職人たちと一緒に頭をひねるというこの環境は、今まで自分の人生にはなかったものです。年が離れているメンバーもいるため、Mentor/Apprentice のような感もありますが、結局のところは、同じ目標に向かって日々前進するチームメンバーという不思議な関係です。1990年代（当時、僕は中学生です）から製品がどう変化してきたかを目の当たりにし、そのアーキテクチャーの内部を熟知している人たちに追いていくのは一筋縄ではいかない。世の中には自分の周りの人たちのスキルレベルに追いつけばその分野で本物になれる、そういう場所がたくさんあると思っています。そして、自分のいる「環境」もまさしくそういうところです。「環境」とくくったのは、環境が本物なのであって自分自身はそれに程遠い・・・という意味が込められています。本当にずば抜けた人は環境に依存しない、ずば抜けたらもうすでに世界で指折りの人間になっていた、そんな感じなんでしょうね。

なんだか日本には帰国しなかったんじゃないかってくらい元の生活に深く埋まってしまいました。年の瀬、のんびりと時間を過ごすため、今の仕事に合わせて昔なんとなく読んだ本をのんびり読み返してます（↓とか）。

ありがとう Engineering Development Group

2011-10-15T11:58:00.003+09:00

2011年10月14日をもって、一年半所属してきた Engineering Development Group (EDG) を離れることになりました。これまで素晴らしい人々に囲まれ、大変居心地のよい環境で仕事をさせてもらいました。去年は、キャリアフェアでカーネギーメロン大学の学生を相手にインタビューをする機会もありましたし、普段は、国籍、男女、年齢を問わず、技術系の話で盛り上がれる素晴らしい職場でした。この間も、インド人の女の子たち同士で Stanford の Distributed Education でどのコースをとるかの話で盛り上がっていました。

技術サポートしたてのころは、お客さんに「全然サポートになってない、この理論に関してもっと詳しい人はいないのか？」のようなことを電話越しに言われ、ショックを隠しつつも冷静なフリをして対応を続けたこともありました。英語を第二外国語とする者にとって、もっとも困難なコミュニケーション形態は間違いなく電話です。人間は、相手の表情、唇の動き、しぐさから非常に多くの情報を得ています。英語で話していても、これはしかりです。電話で頼りになるのは、音声のみ。さらに MATLAB を使っているお客さんの国籍は様々なので、電話越しの英語のアクセントも同様に様々だということです。この状況で、問題を正確に把握し、できうる限りのソリューションを見つけ、わかりやすく説明する。これは面白く、非常に有益な体験でした。仮にいま就職活動中だとしたら、僕は2年前のときよりも電話インタビューで上手い対応ができるはずです。

最初に開発のポジションにアプライしたときは、「開発の経験をもっと積むように」との返事でリジェクトされましたが、その後の社内の開発プロジェクトで新しいことを吸収することができ、その結果として新しい開発のポジションに就くことができました。そのポジションがあいたとき、自分のこなした開発プロジェクトのスポンサーとほぼ同じチームだったので、そのままスムーズに異動できるかと思えば、そうは問屋が下ろさない。新しいチームのメンバーとそれぞれ 45分から60分かけて behavioral interview かつ technical interview があります。とあるブログで Twitter の面接記があり、話題になりましたが、採用プロセスは本来そうあるべきなのです。今回の社内異動の面接でも再び役に立った

最新版は第5版です。100ページ近く加筆されているので、第4版よりオススメ！

Cracking the Coding Interview にもあるとおり、interviewer が過剰なプレッシャーをかけるのには意味があるのです。この状況下を乗り越えられる candidate であれば、おそらく日々の仕事で降りかかる困難の壁やプレッシャーにも耐えることができるだろう、と。さらに、仕事はチーム単位で行うため、この candidate を加えることで、今のチームメンバーの負担が軽くならなければいけない。そして、現チームメンバーもおそらく同じ採用プロセスを経てきたので、新しく加入するメンバーに対し、お前もよくやった、とねぎらいの気持ちが自然に湧いてくるのです。したがって、将来のチームメンバーひとりひとりと時間をかけて面接をするという採用プロセスは至極普通のもの、ということになります。

アメリカでの経験において、僕が好きなことは、失敗をしても再挑戦できるということです。「今回は駄目でも、傷が回復したらまた挑戦してこい。俺たちはいつでも歓迎するし、こちらもまた全力で迎え撃つ。」といわんばかりの、チャレンジ精神を掻き立てる環境がそこに与えられているのです。

これまでは、大学院を卒業したばかりの年の近い同僚がたくさんいる居心地のよい場所でしたが、来週からは、開発の経験年数が僕の年齢の半分以上というような人が数人だけいる特殊な環境になります。新しい同僚は、全員自分より年配で C++ の魔術師ばかりなので、なにが何でも食いついていかないといけません（MATLAB 本体が C++ で実装されているということは、べつに secret でも何でもなく、運悪く MATLAB が crash してしまった人は、ここを見ればおそらく crash dump が見つかると思います。そして、crash dump の中の stack trace に STL やら boost やらが見えると思います）。本音を言えば、C++ より C の方が好きなんですけど。しかし個人的には、これまでの人生で最高に燃える瞬間が来たと思っています。

EDG がなければこのステップにたどりつくことはできなかったでしょう。EDG の job description に書かれていたことは、まさにそのとおりでした。ドラクエ3のように、ジョブチェンジするとレベルは1に戻りますが、以前に習得したスキルは確実に残る。新しいチームのパーティーのメンバはすでに全員レベル高いので、自分もたくさん経験値を積んでレベルアップしていきます。さあ、来週から開発チームでギア全開でいこう！

ありがとう EDG

僕が直接お会いし、その後の自分の人生に影響を及ぼした人物の引用を最後に。

Life is too short to do a lousy job.

10/12/2006 - Anthony Lattanze, Carnegie Mellon University

You have to love your job just like you love your family.

10/28/2006 - John Vu, The Boeing Company

Choose a job that makes you go "Wow" every morning before you go to work.

7/3/2009 - Anthony Lattanze, Carnegie Mellon University

Defending Champion

2011-10-09T06:24:00.002+09:00

去年の TopCoder Open 2010 に引き続き、rng_58 こと副島真さんが TopCoder Open 2011のアルゴリズム部門を再び制覇したんですね。

しかも、今年の Google Code Jam でもチャンピオン。おめでとうございます。

副島さん、筑駒にいたときには国際数学オリンピックで金メダルも獲得とか。

彼の頭の回転で一度世の中を見てみたいものです。

Stanford の Distributed Education

2011-09-11T08:28:00.002+09:00

が今秋から始まるようです！ Course offering は、

人工知能

機械学習

データベース

Coursework もできるし、本当にいい時代になりました　(´ー｀)

あやしげな回転寿司と伝説の書

2011-09-01T07:22:00.000+09:00

てきとーなエントリ。

先月あたり、Natick Collection に回転寿司がオープンしました。日本人である僕が見ると、なんだかあやしいお店のように見えます。店の名前は Wasabi、回転しているネタにはどれも妙なプラスチックの蓋がされている。突っ込みどころがありすぎて、まだ実際には入っていません。

あと、伝説の名著が届いた。

著者らはこれ以上望めないであろう最高の執筆陣。 はじめて読む486 の参考文献に、この Programming the 80386 が載ってると思ったんですけど見当たらなかったんですよね。著者の蒲地さんは絶対にコレを参考にしたと思ったんですがね、、

来週の月曜は祝日なのでじっくりと読めます。

アホすぎる

2011-08-30T09:02:00.012+09:00

Hurricane Irene 改め、Tropical Storm Irene は Natick 地方には特別に大きな被害を出さずに通り過ぎていきました。自然災害におびえることなく日常を過ごせることのありがたみを久々に味わいました。ちなみに、CNN を見ていると、現在は Hurricane への対応に関してその postmortem が行われている様子。

車のエンジンがスタートしなかった件ですが、室内灯がつけっぱでバッテリーがあがったのが原因でした。アホすぎてもう・・・（泣）　友人が Jump Start Cable で充電してくれて、見事に再起動しました（ありがとう！）。ひとつ油断したのは、ヘッドライトをつけっぱなしで車外に出ようとすると警告音が出るのですが、室内灯は、つけっぱで車外に出ようとしても警告音が出ないのです。ライトに関してはすべて警告音が出るものと思い込んでいたので、室内灯のつけっぱには気付かずに車を出てしまったのが敗因でした。うむ、consistent な振舞いにするためにソフトウェアのパッチを要求したい。でもまぁ、まずは自分のそのお粗末な脳にパッチをあてろと言われそうですが、、

また今回を機に、自分の自動車保険は towing をカバーしていないことがわかったので、さっそく保険を更新しようと思います（もしくは、AAA なるサービスに入るかのどちらか）。

Hurricane Irene

2011-08-26T05:58:00.027+09:00

先日の地震に引き続き、今度はハリケーンが接近中です。今日も仕事帰りに少し風が出ていました。

週末から週明けにかけてボストンエリアを直撃しそうなので、今のうちにみんなが避難できるような地下室を見つけておかないといけません。

また自宅の周りには木々がたくさんあるので、それらが倒れてきたときのことを考えて自動車もどこかに退避しないといけないかもしれません。

友人たちと連絡をとりあって、今後のハリケーンの動きに注意しようと思います。

追記（8/26）：
いま CNN を見ていますが、風の危険性以上に水の危険性が高そうです。ハリケーンの規模がとにかく大きいので、一度圏内にかかると、向こう24時間はその圏内に捕まったまま。さらに悪いことに、反時計周りに回転しながら海岸沿いに上がってきているので、海の水を大量に内陸に巻き込むようだ。
しかし、ハリケーンはある程度、軌道、規模、到達時間の予測が可能（しかも、時間を追ってその予測修正が可能）なので、マシな気もします。予測不能の地震およびそれに伴う津波の方がどれだけ大変なことか・・・

追記（8/27）：
うお、雨がどしゃどしゃ降ってきた！こんな日に限って、車のエンジンがかからなくなるし。ハリケーンをなんとか切り抜けて、月曜日に修理しなければ。
べつに大気圏まで連れていかれて体をばらばらに引き裂かれるわけじゃないしね。なんとかなるっしょ。ちなみに、現在の Irene のサイズはヨーロッパと同じくらいの大きさらしい。

コミッタになります

2011-08-05T07:42:00.139+09:00

MathWorks に入社してから約一年半が経つ。そして最近インタビューがあって、開発チームからオファーをいただき、近いうちにそこに異動することが決まった。したがって、今の部署 Engineering Development Group (EDG) で 50% サポート、50% プロジェクトでこれまできていたのが、100% 開発にスイッチする。

EDG からどの部署への異動するかは、かんぜんに本人の希望次第。設計したり、がりがりコードを書いたりしたい人は、Development や Quality Engineering が待っているし、テクニカルでありながらお客様との直接コンタクトを望む人には、Application Engineering や Consulting というような選択肢がある。以前のエントリーにも掲載したが、詳しくはこちら。

もともと開発系に行きたかったものの、具体的にどのチームに行きたいかは入社当初さだかではなかった。MATLAB の Toolbox の数をかぞえてみても想像できるかもしれないが、社内にあふれるドメインの種類はそれこそ様々。そんな数多の選択肢の中から、自分の異動先を決めるきっかけになったのは、お客様のケースにじかに触れられる EDG での経験、伊藤直也さんのブログエントリー「エンジニアの不安と壁」、書籍 Binary Hacks 巻頭の川合史朗さんの「本書に寄せて」、そしてカーネギーメロン大学のソフトウェア工学修士で学んだこと、などだった（このほかにも、きっかけになったエピソードは多くあります）。これらが常に頭の片隅にあって、入社してしばらくしてから、自分はこの道に進むと心にかたく誓った。そしてその道のスタート地点に立つことができた今、これから自分が考えることは、”やるか、もしくはやれないか”。小飼弾さんのいうところの「エンジニアとは肩書きではない。行為であり行動なのだ」である。

と、いろいろ理屈を並べてみたが、結局のところは「それがクールで好きだから」、ただそれに尽きます。

推薦を蹴って大学受験をすると言い出したとき、カーネギーメロン大学のソフトウェア工学修士にアプライしたとき、米国で就職活動したとき、そして今回、希望の異動先を自分で決めてそこに異動が決まったとき、これらのすべて出来事を振り返ってみて気づいたことは、自分がもの凄くしつこい性格をしているということだった。具体的には、1) 一度こうだと決めたら、その道を貫く。結果を出すまで他人からの誘いやオファーは基本的に受け入れない（もちろん考慮はする）。 2) 最後まであきらめず突っ走って結果を出す。成功であれ、失敗であれ、いつでも自分の手で結末を叩き出しそれを自分の目で見る。

仕事の昼休みは片手でパンをかじりながらいつも技術書を読んでたし、週末もコンピュータ、数学関連のことに明け暮れた。決してまっすぐな道のりではなかったが、これまで人生で下してきた決断を悔いたことは僕はあまりない。自分で道を切り開いていくとき、ターニングポイントで自分に嘘をつかなかったからだろう。

これから長い旅が始まる。オープンソースではない proprietary な世界だけど、ここで全力を出して日々楽しんでいくとしよう。あと当然ながら、外の世界の動きにもアンテナを張ることを忘れてはいけない。いつでも自分のショボさを知るのは半分気持ちがいいものだ。

A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering.

Freeman Dyson

学校で習ったことを身につけていれば、こんな風になれる

2011-07-30T12:55:00.005+09:00

Khan Academy という、様々な分野の講義をたった一人でやってのけている素晴らしいサイトがあります。ひとつひとつの講義時間もそんなに長くなく、何かを説明するときもいくつも段階を踏んでやってくれるのでとても分かりやすい。

ビデオがカバーしている分野を見ると、わりと中学や高校でやったものが多いことに気づく。そのときそのときに教えられたものを忘れずに身につけていれば、こんな風なこともできるんだと、改めて習ったものを身につけるということの難しさを感じている。

言い換えれば学校とかで一方的に人から教わったものは、まずほとんど自分の中には残らないってこと。このサイトが役に立つと思えば思うほど、that's the case なんです。トライ＆エラーで自分でやるしかないんだ、結局。

家族が遊びにきました

2011-07-11T09:42:00.030+09:00

一年のうちで暖かく比較的過ごしやすい7月に、家族にボストンに来てもらうことにしました。父親と直接会うのは約2年ぶり、母親とは去年のサンクスギビング以来です。7月1日、仕事の後にローガン空港まで車を運転して二人を迎えにいきました。前回母親が来たときは車なしだったので、移動するのにいろいろ不便だったなあと、空港に向かう車の中で思い出してました。

その週の土曜日は大手のアジアンマートである H マートに行きました。個人的には日本食の食材の豊富さに驚嘆してほしいところだったのですが、二人とも日本から来たばかりだったのであまり感激していない様子。日曜日はトランスフォーマー3・3D を地元の映画館で観ました。字幕なしの映画はキツかったようです。

月曜日は、去年以来のアメリカ独立記念日。家族でボストンの街に遊びに行きました。ボストン美術館は運悪く休みだったので、

ハーバード

MIT

チャールズ川

を歩いて回りました。途中、川沿いで花火の場所探しをしていた同僚にも会いました。去年と違い、今年は次の日が平日だったので僕たちは花火は見ないでそのまま Natick に戻ってきました。

独立記念日の週の平日は僕は仕事でしたが、両親は引き続きボストンの街を楽しんでいました。

水族館近くのハーバー

次の週末は、毎年恒例の会社の summer outing。夜、豪雨の中の高速を走りぬけて到着した場所は、ブレトン・ウッズ協定が結ばれた Mount Washington Hotel 。去年と同じ場所です。その堂々たる外観に去年目を丸くして、自分が死ぬまでに一度家族を連れてこようと決心していました。そしてそれはマイカーを購入した一番の動機でもありました。

左：ホテル外観

右：ホテル内部

アメリカの他の会社の社員旅行については知りませんが、この会社の社員旅行は基本的に自由行動。好きな時間に現れて、飲んで踊って、統率なんて言葉は皆無。慣れきってしまうと、時間厳守のスケジュールには戻れません。

Mt. Washington はリゾート地で、ゴルフ、ハイキング、乗馬、カヤック、など何かしらやることがあります。僕は去年、同僚のインド人とアメリカ人と一緒に山の奥にある滝を見に行きました。今年は家族とともに、山の上を走る鉄道 Mt. Washington Cog Railway に乗って、Mt. Washington の山頂まで行きました。

左：Railway 外観

右：コンダクターのお兄さん

左：ハイカーも見かけました

右：高度は2000m 近く

左：頂上は濃霧と立っているのがやっとの強風

右：山頂の建設物内

下りの鉄道が出発するまで一時間ほどあったので、「ここワシントン山の山頂」と書かれたサインのところで記念撮影などをしていました。無事に麓に降りてきてから、 Mount Washington Hotel の夕食に向かいました。

左：夕食時の様子

右：去年は見られなかった花火のサービス。独立記念日の代わりになりました

左：最終日も晴天

右：Mount Washington Hotel に向かう途中にある Saco River

左：帰りにもう一度 Mount Washington Hotel に寄り

右：再び 3 時間のドライブを経て

やっとこさ Natick に戻ってきました

家族にも楽しんでもらったようで何よりでした。これまでの親不孝、これで少し帳消しになったか？

どっちの継ショー

2011-07-01T21:55:00.005+09:00

Built-in class から継承したいときってありますよね。ちょっといじってて気づいたんですが、built-in class 側で提供されているオペレータをサブクラス側で明示的に overload せずにサブクラスから使ったときにそれがどう振舞うかはどうも言語によって異なるらしい。例えば、数を扱う built-in class を継承したときに、単項プラスを overload せずにサブクラス側でそれをそのまま使うとどうなるか。

まず、Ruby

class MyClass < Numeric
end

obj = MyClass.new
(+obj).class    # prints "MyClass"

いっぽう Python では

class MyClass(float):
    pass

obj = MyClass()
type(+obj)    # prints "<class 'float'>"

そして MATLAB だと

% class definition goes to myclass.m
classdef myclass < double
    methods
        function obj = myclass(x)
            obj = obj@double(x)
        end
    end
end

obj = myclass(0)
class(uplus(obj))    % prints "double"

まだ他の言語では試してないけれど、この中だと Ruby だけ振舞が違う。サブクラス側でわざわざ overload しなくてもサブクラスのタイプにしてくれるあたり、Ruby は痒いところに手が届いている。機能拡張のため、Built-in クラスを継承して、そのサブクラスのオブジェクト間でオペレータを機能させたい時には、断然 Ruby のほうがよさそう。型互換のために、サブクラス側でわざわざ built-in クラスのオペレータを overload するのは手間がかかりそうだし。

ところでこのあたりの振舞いを切り替えられる言語ってあるのでしょうか。

雑記：沈まないよう泳げるようになる

2011-06-17T09:21:00.032+09:00

いま仕事の時間の半分は開発をしています。手取り足取りなんて言葉はないので、正味一カ月で5000行くらいコードを読んで、そこからノウハウを盗んだ。データ構造の選び方やパターンの使い方がきれいなエンジニアさんを見つけたので、その人のコードを参考にするだけでも勉強になる。コードの見た目とかは Code Complete を横に置いてそれでちょびちょび補足する。カーネギーメロンで学んだことを思い出して、自分の理解をわかりやすく他人に伝える。仕事あがりや週末は本を読む。SICP、Binary Hacks、Rubyソースコード完全解説、The Rootkit Arsenal、はじめて読む486、ふつうのHaskellプログラミング、ふつうのコンパイラをつくろう、文字コード技術入門、C++ Concurrency in Action、Understanding Linux Kernel、JavaScript The Good Parts あたりがワーキングセット。青木さんの本には本当にお世話になってます。そして相変わらず打率が悪すぎる TopCoder だが、とりあえず毎週プラクティスを続ける。物体が加速するのは、時々刻々等しい力がかかっているからだ。力がなくなった瞬間に等速もしくは減速運動になりはてる。ともあれ、間違ったアプローチを正しく実装できるようにはなった。

My Job Went to India で目にした

自分の人生を他人任せにするな。J2EEのアーキテクトになりたい？

だけど、今一番心配してるのはコレ。自分たちのドッグフードを食べるのはもちろん大事だけど食べ過ぎでお腹一杯になるのもよくない。自分たちのドッグフードにロックインされて、外に出て使いものにならない技術者になったらおしまいだ。なんて思う半面、そんなことはとりあえず中で使えるような人間になってから言えと自分によく言い聞かせる。

学生のときよりさらに遊ばなくなった気がするけど、泳げるようになるにはこれくらいのことは最低限やらないとダメかな。自分で決めたんだし、楽しいし。You asked for it :P

改めて分かる自分がショボイ理由

2011-06-01T09:11:00.022+09:00

いつだったか、こんな記事を目にした。TOEICはどれぐらい英語ができないかを測る試験、ホーと思ったわけである。そして次にこんなの。

「GREとかTOEFLとかあるよ」とか言う輩はあちらの事情を知らない。ああいうテストの類は、得体のしれないアジアからの応募者をフルい落とすための言い訳としてしか使われない。「こいつは研究できる」となったらテストの点なんか関係ない。現に俺は、ある意味裏口入学した。 #morePhDless than a minute ago via HootSuite Favorite Retweet ReplyNao Tsuchiya
NaoTsuchiya

また、ホーとなるわけである。これらは僕の受けてきた試験すべてに当てはまる；中学受験、大学受験、留学受験、米国の入社試験。どれもそのときは必死だったが、ゲートをくぐった先の人達から見ればただの sanity check でしかない、残念なことに。自分の場合、学位を取得するなんて行為も、教授陣たちから見ればただの sanity check でしかなかったのかもしれない。

「Rubyソースコード完全解説」を購入して1年ほど経つ。全章を二回読んだが、これだけの宇宙をよくもまあ Matz さんお一人で、ともう惚れ惚れ（著者の青木さんにも感謝！それでも評価器のところがまだ全然把握できなくて。しかもこのあとには YARV が控えているという）。見る者を強引に納得させてしまうこんな芸術を作れるかどうかなんて、sanity check を通るのとはっきり言って無関係なわけで。創作指向の人たちは sanity check のことなんか構うことなく自分の創作物を世に出していく。つくづくカッコいい。

「ドリブルこそチビの生きる道なんだよ！！」ではないが、こんな自分が生きる道もそこら辺にあると信じて、その道を少しずつ歩み始めたところです。

とあるマンガからの名言集

2011-05-24T14:15:00.012+09:00

「いつまでも同じところに止まっていたらダメなんだ。やなことがあるからって、楽な方にばかり逃げてちゃどんどんダメになる。何かを求めて前に進むんだ。自分の足で歩くしかないのさ。」

「才能なんてものがあるとすれば、それはないヤツよりも少しだけ上達する時間が少なくて済むっていう程度のもんだ。努力の積み重ねをひっくり返してしまうほどの天性なんてありえない。少なくともこの俺は一度もそんなものみたことはない。勝ち負けは経験の差だ。」

「どれほどの技術を習得していても、これでいいと思ってしまえばその状態を維持することも難しい。常に上を向いて努力を続けていなければ、その上のレベルに移行することはできない。道を極めるとはそういうことだと思っている。おれはもう若くない、現状維持が精一杯なんだよ。だが君は若い、さらに上を目指していけるはずだ。」

到達できるレベルの差こそあれ、こういう意識のもとで行動することがたいせつ。

壁

2011-05-17T07:55:00.020+09:00

にぶち当たっている。

超えられれば一皮むけるし、超えられなければそれまで。

もがいて乗り越えた人だけが先に進める。

というわけで、自分のこれはとてもいい壁。

ただ、ぬりかべくらい厚い壁だと思いこむと脳がビビッてしまうので、一反木綿くらいぺらんぺらんの壁なんだと自分に言って聞かせる。

なんだかんだで楽しんでいる自分がいる。

追記 (2011/05/19)：
もがいてたら、壁を出口の見えるトンネルにすることができた。出口まで道のりはあるけれど、最後までいけるはず！

Got My Car！

2011-03-27T01:48:00.005+09:00

在米4年目にしてようやくマイカーゲット、Honda Civic EX Sedan (2011) 。 Boston の Honda のお店で購入し、今日 Natick へ連れて帰ってきた。これでようやく行動範囲が人並みになったんだ！車を作ってくれている人に感謝！！

▲ 正面、斜めから

No more walking or biking in snow :)
でも運動のため、晴れの日はチャリンコで通勤します。

無に敏感、有に鈍感

2011-03-18T03:08:00.034+09:00

それすなわち、どの人もおそらく一度は感じたであろう幸福に対する感覚。この世は、奇跡で満ち溢れている。太陽の存在、地球の存在、太陽と地球の距離、大陸の存在、水の存在、空気の存在、食糧の存在、生物の存在、人間の存在、家族の存在、友人の存在、あるいは人間を生かす肉体の存在。マズローの唱える欲求には階層があり、それぞれの層で欲求が満たされたときの幸福感があるならば、幸福も同様の階層構造を成すはずである。前述の数々の奇跡がもたらす幸福は、最下層に位置している最も感謝されるべき幸福といっていい。

悲しいかな、この最下層の幸福は実現されているだけでもありがたいはずなのに、それしか実現されていない状態では、所属・愛の欲求や自己実現の欲求といった上層の欲求しか目がいかなくなる。しかし、ひとたび上層の幸福が実現されれば下層の幸福など見向きもしなくなる。いわゆる「当たり前」というやつである。この幸福段階説では人間の脳の「慣れ」のせいで、さらなる欲求を満たすために下層の幸福を足場にして階層を見上げるのは容易だが、現状を支えているその足場に感謝をするために階層を見下ろすのは困難なのだ。もしも、今回の東日本大震災で自分の地域が被災を免れ、心なしかいつもより自分の状況が良く見えたとしたら、それは日頃から下層の幸福に対する感謝を怠っていたということかもしれない。しかし、普段から下層の幸福に対しはっきりと感謝の意を表すことは難しい。そういった習慣をつけるとしたら

「もし家族がいなくなったら・・・、もし家がなくなったら・・・、もし事故に巻き込まれたら・・・、もし重病を患ったら・・・」、頭の中で big if を想像し、現状がどれだけ幸せかを心の中で感じ取る。

この世の調和をもたらしている存在があることを信じ、その存在に対し日々の恵みを感謝する。

父の実家に帰ると今は亡き祖母が毎日仏様にお経をあげていたり、数学ガールの著者が定期的に感謝の意をブログに記したりしているのは、マリアナ海溝よりも深い意味があったのだ。むやみに新しい欲求に手を伸ばさず（無に鈍感）、そこにある幸せを大切にするのである（有に敏感）。

話が変わりますが、僕がいる department でも呼びかけに応じて大勢の同僚が donation をしてくれました。離れた地からではあるけれど、全力で復興にあたるみなさんの手助けをしたい。どうかこの元気玉が届きますように。

人生初 NBA 観戦

2011-03-06T13:19:00.003+09:00

今週、NBA に詳しい友人と Celtics の試合観戦に行ってきた。

左：ボストンダウンタウンにある TD ガーデン
右：ガーデン 4F

中学時代に数年バスケをやってたから、プロの試合を観るのは楽しみだった。それでも、Red Sox のときと同様選手の名前を事前に知らなかったのは完全に、にわかな証拠・・・

左： Rajon Rondo のパス回し
右： Steve Nash の零角度シュート！

試合は、115-103 で Celtics が Suns に勝利。去年の Red Sox 対 Yankees 戦も Red Sox が勝ったし、自分が観戦に行くときのボストン側のチームの勝率は100%、素晴らしい。

高校からずっとテニスやってきたけど、体力つけてバスケもまたやりはじめよっかな。

今月のボストン日本人研究者交流会

2011-02-20T15:34:00.025+09:00

また行ってきました。参加してらっしゃるみなさんは様々なバックグラウンドをお持ちで、そういう方たちと議論をするのは自分の視野を広げてくれる。馬鹿みたいに単純な計算をすれば、30才の方が10人いれば、300年分の知識に触れていることになる。
　
今回の講演の内容はこんな感じ。会場は個人的に MIT で一番不細工で美しい場所。

▲ Stata Center

以下の Ustream は実際の講演の様子。この日の講演はどちらも強い共感を覚えた。

講演一本目

いっとき脳にハマっていた時期があって、Jeff Hawkins の On Intelligence とか、Francis Crick の Astonishing Hypothesis とか、Steve Grand の Growing Up with Lucy とかいろいろ読み漁ってた。脳の機能は全くもって不思議で感覚や認知、様々な側面があるが、そのメカニズムは思うに依然として謎につつまれたままである。脳の機能すべてを合わせ持ったコンピュータを作るのは、従って困難を極める。例えば、友人が2009年の夏のインターンでも関わってた、IBM の Watson が最近クイズ番組「Jeopardy！」で見事チャンピオンを破った。今のコンピュータにはそんなことができる一方で、犬と猫を瞬時に見極めるという人にとっては簡単なことが正確にできない（そんなアルゴリズムが Facebook で使用可能になったとしたら、気になってる人の写真を撮って、後で Facebook にアップロードして、その画像一致判定&検索アルゴリズムでその人のプロフィールをゲットすることだってできる）。Neuroscience からどのようなアイデアを拝借できるか、Machine Learning の分野からみても脳の働きは尽きせぬ興味の対象だろう。たしか CMU で Machine Learning Department の Tom Mitchel 教授が fMRI をもとに人の考えている言葉を予測するなんて研究をやっていた記憶がある。

講演二本目

普段仕事で、数学、プログラミング言語、アルゴリズムとかに携わっている身としては、二つ目の講演には反応せざるを得なかった。僕としては「数学が役に立たない時なんてないでしょ」と声高にして言いたいが、そんな自分も文科省の無愛想な数学の教科書に高一まで苦しめられた。悟りを開いてくれたのは、Scientific Education Group (SEG) の数学の講義だった。2x + 3y はベクトル(2,3) と (x,y) の内積にも見えるんだよ、と聞いたときの感動は今でも覚えている。この日のプレゼンでも触れられていた通り、残念ながら日本の大学入試の数学は評価すべき複数の側面のうち一部しか対象にしていない。文科省の教科書に載っていない、愛想のいい数学に触れるには、和書であれば虚数の情緒、オイラーの贈り物、数学ガール　などの書籍にあたらなければならない。そんなことに気がついたのは、つい最近になってからだった。

この交流会に参加するといつも何かしら考えさせられるので、とてもためになっています。

彼は熱く、そして鋭い

2011-02-10T08:27:00.026+09:00

去年の5月のカーネギーメロン大学の卒業式のときに初めてその名前を知った上杉周作さんのこのツイートがちょっとした話題になっている。

アップルで働くまで、イノベーションというのは「今にない、新しいものを作ること」だと思ってた。でもそれは違って、イノベーションというのは「未来にある普通のものを作ること」なのです。この違いを理解できるまでかなり時間がかかった。less than a minute ago via Echofonshu uesugi (上杉周作)
chibicode

卒業式のときに SCS の The Alan J. Perlis Undergraduate Student Teaching Award を受賞しており、Diploma Ceremony の冊子の彼の熱いメッセージを読んだときは、凄い人がいると思った。

正直、僕は上記のツイートの内容をまだ肌で感じきれていない。書いてあることはよく分かるのだが、ものを作る側の立場から経験を通してそれを噛みしめることができないのである。自身の経験を通してツイートで上記のようなことがフッと思い浮かぶのなら、Shu さんのからだの奥底に眠る能力と情熱は計り知れない。そんな彼が紡ぎだすツイートは切れ味がよく、見ていると気が引き締まる思いがして心地がよい。そしてシリコンバレーのような環境で、自らが生み出す刺激と周囲からの刺激でこれから先も遙かな高みを目指してどんどん上に昇っていくのだろう。こういう人たちから溢れるエネルギーをもらいつつ、僕も自分の山登りを楽しんでいくのだ。

追記：
ピッツバーグを離れる前、 CMU ニッポン懇親会なるものがあり、その日に一度 Shu さんに会うチャンスがあったのだが、就職先が決まってカリフォルニアに行った友人 S くんが（当時の）僕の部屋に残していった荷物をその日に S くんに向けて全発送しなければならなかった。発送後に体力を使い果たして残念ながら眠りこんでしまった、まったくもって無念。

雪は～外、雪は～外

2011-02-02T10:06:00.010+09:00

明日は今季最悪の吹雪の予報。帰宅したら、現在住んでいるアパートの管理人から「明日は猛吹雪だからバルコニーの雪を落としとくように」との置手紙が。12月から3度にわたる吹雪で積もりに積もった雪を放置してたツケが回ってきた。

▲ツケ


左：凍結して硬い部分はかかと落としで削ぎ落としながら攻める
右：なんかパイプが氷の棺の中に・・・

左：人力の成果を見よ
右：自分の部屋のバルコニーから。まだそんなにひどくないね

明日になったらこれ以上にまた積もるとか、完全にいたちごっこ。春はまだか。

なにかに迷ったら物事の一方向性をたよりに行動

2011-01-22T12:12:00.054+09:00

こんな図を考える。

これは状態 A から状態 B へは移れるが、状態 B から状態 A に戻ることは至極困難だということを示す。日常での例を挙げると、

【状態 A: たばこを吸わない　状態 B: たばこを吸う】

【状態 A: 勉学にいそしむ　　状態 B: 酒におぼれる】

【状態 A: 物を生み出す　　　状態 B: 物を消費する】

【状態 A: 人を褒める　　　　　状態 B: 人をけなす】

【状態 A: もう少し頑張る　　　状態 B: あきらめる】

繰り返すが、状態 A にいられれば状態 B にもいられるけど（たぶんそうはしない）、状態 B に慣れたら状態 A に移ることは難しいという話。こういう状況で、僕はできる限り状態 A に身を置くことを選んできた。そうしたほうが精神的に前向きでいられることが多かったから。たとえば、

【状態 A: 大学受験する　　　状態 B: 推薦をとる】
当時は、せっかく勉強したんだから受験しないのはもったいないと思っただけ。推薦モードに切り替えるなんて楽なことだし。あらかじめ定められたカリキュラムにとらわれずに自分をのばせるモノが見つかってるなら、大学受験なんかしないで推薦をとる方が利口。僕はそうじゃなかったから受験の道を選んだ。センター試験で失敗したけど。

【状態 A: 海外で学ぶ　　　　状態 B: 日本でまず就職】
これは日本での就職活動が始まろうとしてた時のこと。インターンの面接で落ちたときに、どちらの道をとるか迷っていた。たぶん年をとればとるほど、自分を取り巻く状況や人間関係の変化で、海外に行くことは比較的困難になるだろうと思っていた。実際はそういうこともないのだろうけど、自分の性格上そう決め込んでしまうだろうと。ただしこの場合、海外で年をとって日本に戻って就職活動が楽になるかというとそんなこともないが、自分は日本国籍だから母国での方がビザの制約もなくいつでも比較的身軽に動けると思った。悩んだ結果、両者の一方向性を考えて当時は海外で学ぶ方を選択した。

【状態 A: 米国で就職活動　状態 B: 日本で就職活動】
これは米国の大学院卒業間近のこと。やはりビザの制約で米国で就活できる期間は限られている。一度日本に戻ると、物理的に米国にいられないため、米国での就活はしにくくなる。日本での就活なら日本国籍だからいつでもできる。だから、米国で就活することを選んだ。付け加えるとすれば、周りのインド人や中国人も米国で仕事を見つけようとしてるのなら、日本人の自分にできないわけがない、とも思った。アインシュタインと自分ほど頭の出来が違うわけじゃないんだし。

人生で迷ったら一方向性を指針に決断する。キーワードは「迷ったら」。迷わなかったら、もうコアのレベルで行動の判断基準が hard-wired されているから、その判断基準を変える必要もない。その人はそれでハッピーだろう。しかし、迷っているうちはどの道をとるかで葛藤が起きている証拠。そして、直面してる課題をもしもこのモデルに落とし込めるのなら、状態 B にはいつでも移れるんだから（移ったら移ったで大変かもしれんが）まずは状態 A にいることから始めるのも悪くないという話でした。

追記：
コメントで指摘していただいた通り、上記の生産、消費は遷移の対象として捉えるよりも個々の異なる事象と捉えるほうが納得がいくかもしれない。ちょうど個人をタイプを診断する Myers-Briggs Type Indicator のそれぞれの指標のように。僕が5つめの指標を導入するとしたら、あなたは生産者、消費者のうちどっち？ってのを作るかな。

H Mart

2011-01-21T11:59:00.010+09:00

に仕事のあと行ってきた（出発 A 地点、目的地 B 地点）。

大きな地図で見る

OPT で日本に一時帰国できないもどかしさの反動で日本食、調味料、日本のお菓子を $300 分購入した。キャラメルコーンのラムネ味とかカロリーメイトのメープル味とかまで取りそろえてあって、もう辛抱たまらんかった。いま自宅では戸棚を開けるたびに満足感。連れていってくれた S さん夫妻ありがとう！

今冬二度目の blizzard

2011-01-13T08:07:00.002+09:00

これはひどいww

Went Watch Summer Wars ... Again !

2011-01-09T09:12:00.021+09:00

今日、映画 Summer Wars を鑑賞してきた。前回は東京、今回はボストン美術館で。ボストン地方は、昨日の夜あたりから雪がまた降り始め、Commuter Rail も止まるんじゃないかと思ったが前回ほど降りはひどくなかった。

左：前回撮り損ねた Boston Commons の Frog Pond
右：雪の中のボストン美術館、開館前

ボストン美術館の中の Remis Auditorium というところで上映。

左：ポスター
右：Auditorium 内

英語吹き替えだと思って勝手に期待してたら、日本語音声に英語字幕で肩透かしくらった。作品自体は久しぶりに見たけど、相変わらずの爽快感。甲子園とか花札とかこちらの人には馴染みのないものがあっただろうけど、最後は拍手喝采。劇中に観客が笑ってた回数は、一年半前の日本の観客のそれよりかなり多かった。例えば、「人を守ってこそ、己を守ることができる」って下りが「七人の侍」のセリフだっていうシーンとか、健二くんが暗算中に鼻血を出すシーンとかで笑う。笑いのツボに素直なのかもね。ちなみに、そのクライマックスシーンの健二くんの「よろしくおねがいしまぁぁぁす！」の英訳は「Yes, please !!」。自分がアメリカ人だったら、この映画で日本語勉強してただろうなあ。日本のアニメーション作品がボストン美術館で上映されるのは、やっぱり凄いことだと思う。芸術だと fine arts と performing arts の二単語を聞いたことがあるけれど、ボストン美術館は Museum of Fine Arts だから、映像作品は fine arts の扱いになるってこと？

映画の後はもう雪は止んでいたが、せっかくなので館内の鑑賞をしてきた。今日一番インパクトが強かったのは、去年の11月20日から始まった展示 Fresh Ink。2006年に10人の墨絵画家を招き、各々に館内の展示物ひとつをテーマとして選んでもらい、それに対するレスポンスとなる作品を生みだしてもらったそうだ。墨をテーマにしてるからか、2008年の「井上雄彦最後のマンガ展」に行ったときのデジャヴを感じた。

左：ボストンの大学生9人がモデルとなっている
右：ひとつの岩を様々な角度でとらえる



このほかにも見て回ったが、今日は展示物の時代背景をよく読むことを心がけた。ある展示物が、なぜそういう形をしているのか、なぜそういう色を用いて描かれたのか、なぜそのモチーフなのか。歴史的背景を把握すると、展示物が少し違って見える。展示物は黙ってただそこに佇むだけで、何も語りかけてはくれない。人間関係同様、相手を理解するには自分の方から学ばないと。歴史のいい勉強になりそうです。

さらば 2010年

2010-12-31T09:58:00.036+09:00

人生には時として、アルキメデスの支点ではないが小さなテコ入れでその後のパスが大きく変わることがある。今年はまさに自分にとってそんな年だった。2009年末から米国での就活に苦しみながらも、ここまでたどり着いたことに今はただ感謝したい。2005年から数えて人生でこれほど「落ち着いた」と思えたのは、今年が初めて。ただ、周囲はめまぐるしい勢いで日々進化を続けていることを考えると、「落ち着いた」と思えることほど危険なことはない。だから、なんらかの手を使って精神的に自分を追い込むことが日々の課題。

さて、来年のことをふと考えたときに自分がもう around 30 になっていることに気づいた。そこから、むかし学部の理工図書で気まぐれで借りた本のことを思い出した。

自分が読んだのが第何版かは忘れたが、ずいぶんと切れ味のいい目次に面食らったことだけは覚えている。手元に本がないので肝心の中身を覚えていないが、目次だけは手元にあった。自分がどれだけそのノルマをこなせたかを以下に示す。

針路は20代で決まる

20代には人生にかけがえのない灯が二度ともされる。それは、20代前期にやってくる就職と、後期に訪れてくる結婚である。

心は高く持て

尊敬する人物を持っているか

孤独の楽しさを知れ

真の愛を知れ

他人のためにつくせ

恩を忘れるな

良き友を選べ

大学をレジャーランドにするな

心に価値のある職を選べ

新人は最下層なのを自覚せよ

「好き」だけで結婚するな

結婚とは親を取り替える儀式だ

妻を愛すること

父よりも夫であれ

男のロマンを子供に伝えよ

先輩に追いつき追い越せ

後輩に学び、そして蹴落とせ

自然を愛せ

自分に賭けろ

まだ時間があるのでカバーできてないところは来年から始めてみる。

皆様よいお年を！そして来年もどうぞよろしくお願いします。

Blizzar ～ d !!

2010-12-28T09:16:00.008+09:00

ボストンエリアでは、クリスマスイブあたりから雪が降り始め、週末には結構な積雪になっていた。日曜日は一日中吹雪いていて、全米各地の空港で stranded になっている友達もちらほら。今日、月曜日になってもその雪の勢いはおさまるどころか悪化する一方。自分は今日遅めの出社だったので、近所の同僚はすでに出社しただろうと思い、車は頼まず思い切って歩いて会社に行くことにした。

▲家の近く、こんな感じ

日本の歩道の除雪作業を想像しつついざ通りに出ると what the hell !? 車道はきれいに雪かきされていたが、そのしわ寄せがすべて歩道にきていた。仕方ない、こんな中歩いてる crazy なやつは自分しかいないもんなあ、と思いつつズボズボ雪にめり込みながら軽く一時間近くかかって会社到着。

職場に着くと、私を心配したマネージャーや同僚が、連絡すればいつでも家に迎えにいってやるからと親切な言葉をかけてくれた。家族が病気になったりすると早退も許されるし、今朝のような言葉もかけてくれるし、人に対してはホントに温かい。

とある理由で免許取得をしぶってた私だけど、今日はそのしぶりを打ち消すのに十分なブリザードだった。

▲自分のオフィスから。夕方になって少しマシになった

ボストン日本人研究者交流会、初参加

2010-12-19T15:37:00.012+09:00

12月18日（土）、このまえネットで知って登録したボストン日本人研究者交流会に初参加してきた。この日はカメラを家に置いてきてしまったので今回は写真をとれず。残念。

会自体は16時開始だったので、正午に South Station に到着して、スタバに寄ったり、Frog Pond がスケートリンクへと様変わりした Boston Commons を歩きながら、読書をして時間をつぶす。

開始時間直前になり、会場となっていた MIT の一室に移動。会場内には、各席にどら焼きと緑茶が置いてあってもうそれだけで幸福感↑。まわりには日本人の方々が約80人以上ずらりと。それでさらに幸福感↑↑。参加者のみなさん同士は、ほぼすでに知り合いであったようだが、私はどなたも知らなかった。そういう中に自分一人で入っていくのは、思えば大学のサークルに入ったとき以来で、これが結構ドキドキした。

この日の講演は2つあった。前者は精子と卵子、それを用いたバイオテクノロジーのお話。遠藤さんという方が、精子と卵子の神秘のほんの一端を見せてくれた。世の中には自分の知らないことばかりで、この講演でも二つの細胞のその見事な仕組みにただ唖然としていた。どうやってプリプログラムされてるのか全く想像もつかないが、生き物は凄い。もう一つの講演は、このブログの中のひと古賀さんによるもの。内容は、現在のお仕事の内容およびアメリカでの就職活動。詳細はご本人のブログにすべて綴ってあるのでここでは省略。それ以外で感じたことは、古賀さんご本人がこれまたパワフルな方で、私見だけど、ブログやツイッターから想像していた以上に、発せられる言葉ひとつひとつにハートがこもる方だった。ナマのお姿を見られただけでもうこの日は満足。それと同時に、Facebook や Twitter でどれだけネットワーキングが便利になっても、本人と相対する face-to-face には遠く及ばないと感じた。こと古賀さんだけに限っていえば、ご本人のインパクトはそれだけ強かった。

さて、普段は Boston から帰るときは18:00の Commter Rail を捕まえるのだが、この日は懇親会があったので、最終23:00の Commter Rail まで引き延ばした。私は、日本の方とのお酒となると、それが最優先事項になり、その他は基本的にどうでもよくなってしまいます。お酒の席で皆さんと話をさせていただいたら、こちらで仕事をしてらっしゃる方、ポスドクの方、Ph.D の方、語学を学びに来てらっしゃる方、それはもういろいろな方がいた。中には、自分が小学生の頃毎週受けていた四谷大塚の週末テストで、同じ会場になった（だろう）方もいた。当時その週末テストで成績優秀で有名だった子の名前をその方と私が知ってたりして、もうなんと世界のせまいこと。楽しい時間を過ごさせていただきました。

これまで Natick ではほとんど日本の方を見かけなかったけど、少し足をのばせばこれだけの日本の方に会えることを知ってこの日は嬉しくなった。幹事の方もありがとうございました。また次回も行くと思いますので、よろしくです！

追記：
仕事も来週から個人的に強力な助っ人が加わるので、これもまた楽しみ。

職場の同僚と一息

2010-12-11T10:50:00.009+09:00

早くも12月。Holiday season も始まって、忙しさも徐々にやわらいできた。そんな中、今週のはじめに自分のいる department でホリデーパーティーなるものが開かれました。平日にも関わらず、一日の半分の業務を完全にシャットダウンして皆で楽しもうという発想は、自分の人生でこれまでなかったのでかなり衝撃。

形式は potluck party、つまり一人一品何かパーティー会場に持ち寄ってみんなでシェアするというもの。自分は近くの酒屋で日本酒を購入（好評であっという間になくなりました！）以前触れた通り、この department はインド人の割合が50%を超えているので、このパーティー会場ははっきり言ってインド料理ビュッフェ、その品数は半端なかった。

左：このテーブルの大半もインド料理
右：この日の午後は仕事を忘れてリラックス

普段は夕方5時30分を過ぎるとすぐに皆帰宅を始めてしまうし、忘年会みたいなものもないので、こういうイベントは大歓迎。楽しいひとときでした。

そして、今日は自分が初めてチームのリーダーを務めた日だった。チーム全体のアクティビティを統括しつつ、エンジニアひとりひとりの質問に答え、舞い込んでくる案件を他のエンジニアがいち早くさばけるように次のステップを示したり。これだけコンテキストスイッチを強いられたのは本当にひさしぶり。でも、一日の最後に皆から「Thanks Yuki !」とねぎらいの言葉をかけてもらったし、不思議と疲れも全くなかった。

そして仕事の後は、チームの数人、そしてこれまで頑張ってくれたインターンと一緒にメキシカンのお店に行った。

左：海老のガーリックソース和え
右：夕食後、外は摂氏マイナス3度

もうすぐ2010年も終わり。けど、年末だからといって歩みをゆるめることなく、充実した毎日を送れるようにしていきます。

マサチューセッツ工科大学航空宇宙工学科博士課程緒野雅裕さんより

2010-11-30T09:19:00.008+09:00

MIT の Dept. of Aeronautics and Astronautics の Ph.D プログラムに在籍されている緒野雅裕さんから連絡がありましたので、参考までに私のブログにも載せておきます。ツイッターでも RT しました。

********* ここから *********
前略、

私たち米国大学院学生(http://gakuiryugaku.net )
は、海外大学院への学位留学を志す皆さんを支援する目的で、在米日本人留学生
たちにより設立された団体です。学位留学について知っていただくために、12月下旬に全国6大学において「海外留学説明会」を開催します。会場は日程順に、早稲田・慶應・名古屋・東京・九州・京都の各大学です。

皆さんは日々の研究や勉強に、十分な充実感をお持ちでしょうか。もし現状に物足りなさを感じているならば、海外の大学院へ学位取得のために留学する「学位留学」という選択肢を、ぜひ考えてみてください。

欧米のトップの大学院の多くでは、学生はRAやTAによって学費を全てカバーされるだけでなく、生活費としての給料も支給されます。世界中から集まった優秀な学生たちと切磋琢磨する環境は刺激に溢れ、挑戦する目標には事欠きません。そんな素晴らしいチャンスがあること、そしてきちんとした情報に基づいて準備をすれば、そのチャンスは実は手の届く距離にあること。この2つを、米国留学中の学生の生の声を聞いて知っていただくことが、本説明会の目的です。

参加費はどの会場も無料です。各会場の参加事前登録をお願いしています。事前参加登録なしでも聴講いただけますが、万が一、会場が満席になった場合は、参加登録をされた方を優先させていただきます。事前参加登録・説明会の内容・地図などは、米国大学院学生会のHPへアクセスし、各会場の詳細をご覧ください。
http://gakuiryugaku.net

◆早稲田大学　西早稲田（旧大久保）キャンパス
日時：　2010年12月20日（月）　午後6時～午後8時
会場：　55号館 N棟１階　第一会議室

◆慶應義塾大学　矢上キャンパス
日時：　2010年12月21日（火）　午後6時～午後8時
会場：　創想館セミナルーム1（14棟201室）

◆名古屋大学　東山キャンパス
日時：　2010年12月22日（水）午後1時～午後5時（受付開始12:40pm）
会場：　法政国際教育協力研究センター2階　CALEフォーラム

◆東京大学　本郷キャンパス
日時：　2010年12月23日 (木)　午後2時～午後4時
会場：　工学部2号館1階213号大教室

◆九州大学　伊都キャンパス＋遠隔講義システム
日時：　2010年12月24日（金）　正午～午後2時
メイン会場：（伊都キャンパス）センター１号館1308講義室
遠隔講義システムによって、箱崎・病院・大橋・筑紫の各キャンパスで中継を実
施します（詳細はHPを参照下さい）

◆京都大学　吉田キャンパス
日時：　2010年12月28日（火）　午後3時～午後5時
会場：　国際交流センターKUINEP講義室
********* ここまで *********

こういった説明会が、人生の大きな転機になることがあるかもしれません。興味が少しでもあれば是非参加してみることをお勧めします。

世界のどこにいようとすばらしい仕事を成し遂げる人たちが世の中にはたくさんいます。そういった人たちの、物事に没頭する姿勢は目を見張るものがある。留学がそういう物事や姿勢を発見する手助けになるのであれば、トライする価値は十分にあると思います。そして最後は、自分のハートに聞く。そうすれば、母国に留まるにせよ、海外に行くにせよ、自分が探していた答えを導きだしてくれるはず。

ビザの話

2010-11-10T11:15:00.013+09:00

米国の大学院を卒業してからもうすぐ一年が経とうとしています。このブログを始めたのと同時期にこちらでの大学院生活が始まり、今日までずっと学生用のF1というビザでやってきました。現在は、正確に言うと Optional Practical Training (OPT) というステータスで、この OPT の期間は H1 という就労ビザがなくとも、大学や院で学んだ知識を活かす職種であれば米国の会社で12か月間働くことができます。ほかには、無職でいられる期間は合計90日まで許され、H1 になったら支払うべき Tax も OPT の期間中は支払わなくてもよい、といったことも挙げられます。

ダウンサイドもあり、この OPT の期間に母国に帰国すると米国に再入国できなくなるおそれがあります。必要書類（ビザ関連の書類、会社からのオファーレター、EAD カード）を携帯して米国を離れれば、再入国を拒否されることはほぼないと聞きますが、とにもかくにも入国審査の際に No と言われたら、どんな理由があれ米国に入ることは許されません。しかし、実際にこういう状況に陥った人を私は直接は知りませんし、同僚にたずねてもそういう目にあった人はまず聞いたことがないといいます。再入国を拒否された友人がいたと、同僚の一人が教えてくれましたが、その理由は H1 申請したあと H1 を受け取る前に母国にバケーションに戻ったからだとか。なので、これまで聞いてまわった感じだと、職があり必要書類を携帯すれば、OPT 期間中に帰国して米国再入国を断られるケースは非常にまれのようです。

私は今年の3月末に入社しましたが、その時点で会社の今年の H1 の申請分はすでに終わっていました。なので、来年2011年の4月の申請まで待たなくてはいけません。当然、現在の OPT もそれまでに切れるので、OPT の期間を12か月間から29か月間に伸ばす延長申請を先月出してきました。残念ながら、その来年4月に申請される H1 が効力を発揮するのはその年の10月からになるので、それまでは日本への帰国はおあずけになりそうです。来年の10月まで待てば休暇の合計日数は一か月を超えるので、それを楽しみに日本食や温泉を妄想しつつ頑張るっきゃない！

追記：
いつの間にか「クイズ：12匹のねずみとチーズ」の話が盛り上がっていました。みなさん投稿どうもありがとうございます！

いまの仕事

2010-10-20T13:03:00.038+09:00

入社して半年以上が経ち、少しずつ周りのことが見え始めてきました。仕事の中身について突っ込んだことは書けませんが、ここに載っている程度のことや、職場の雰囲気について簡単に触れたいと思います。

上記のリンクにもある通り、今の自分の仕事は主に2つ。全米の Technical Support および社内プロジェクトです。一見すると、MathWorks のプロダクトは MATLAB や Simulink の二本柱にように見えますが、実際には扱っているプロダクトの数は90以上にもなります。例えば、各ドメインに特化した機能を提供する Toolbox や Simulink モデルから自動的に C のコードを生成する Real-Time Workshop など。すべてのプロダクト群に対して、ライセンスを持つユーザさんに Technical Support を提供することがひとつめの responsibility です。問い合わせをしてくださるユーザさんは、学部生、大学院生の方、大学教授、バリバリのエンジニアの方などバックグラウンドは様々で、質問内容も多岐に渡ります。ある電話のコールで、機械学習のアルゴリズムの実装に必要な関数の質問が飛んでくることもあれば、別のコールで金融機関のソフトウェアエンジニアさんから、その道の専門用語で埋め尽くされた、技術的な質問が飛んでくることもあります。単純に関数の使い方を伝えるだけで解決できるものもあれば、ユーザさんの達成しようとしているエンジニアリングの問題そのものについて大局的に理解しないと解決できないようなものもあります。これらについて、電話やメールでなるべく早めの対応が求められるので、シフトのときは刺激の多い一日になります。

もうひとつの responsibility が社内のプロジェクトをこなすこと。これは、社内で自分の将来の専門分野を見つけるために用意されたシステムです。私は今のところ、自分の頭のなかにあるいくつかの可能性をトライしているところです。前にも書きましたが、別のチームに移るときは複数セッションにわたる面接（technical, behavioral）があるので、それにも備えなければいけません。

職場の雰囲気はいいです。とりあえず社内で会う人は自分よりも頭がキレるものと思ってます。問題解決にあたり自分よりも多くの引き出しがあって、手段を柔軟に組み合わせることができる。そしてなにより、周りの人のモラルの高さに感心しました。やはり一番大事なところだと思います。

プログラムを走らせるエンジンだけ見ても、ざっと MATLAB、Simulink、Stateflow、Simscape などが思い浮かびます。同僚で言語好きの人もこのバリエーションが魅力的だと話していました。私は、今は MATLAB まわりの勉強をしています。妙なことをサクッとできてしまうのが MATLAB の面白いところかもしれません。

左：Red Sox のベンチを背景にした私を
右：球体に張りつけました

MATLAB コードは以下:

I = imread(filename); % filename refers to the path to the original image
I = flipdim(I, 1);
[x,y,z] = sphere;
s = surf(x, y, z, double(I));
set(s, 'FaceColor', 'texturemap', 'EdgeColor', 'none');

MathWorks は去年、東京、名古屋、大阪にもオフィスを開設したので、Japan の方と知り合いになる機会も多く、これが私にはとても嬉しいことです。これから進む道はまだ定かではないですが、毎日元気よくやっていきます。

▲ 秋の晴天下のメインビル

Yankees vs Red Sox

2010-10-04T09:47:00.010+09:00

シーズン最終日ということで、Fenway Park に行ってきました。Red Sox は、今年は地区優勝はなりませんでしたが、今日のゲームではホームラン3本を叩き出し、8-4で Yankees に快勝！松坂投手など、日本人選手は見られませんでしたが、天候もよくチームも勝てたので、大満足の一日でした。

▲9回表の 2アウト、 Alex Rodriguez を打ち取って Red Sox が勝利する瞬間

試合後は、なんとフィールドに入ってベースを踏ませてくれるイベントもありました。

左：注意書き。写真に見える赤土にも触ってきました
右：砂がかぶっているけど、ホームベースです

▲追加写真：スコアボードの前で

次は、NBA の Celtics のゲームを見に行きたいです！

++年齢

2010-10-02T11:31:00.009+09:00

ということで、また年齢がひとつ増えました。去年は Salesforce.com のインタビュー前日で、誕生日を迎えた気が全然しませんでしたが、今年は落ち着いて誕生日を迎えることができました。年齢を重ねるのは、木になっているような感じがして好きです。木のように上に向かって成長して、自分のもとに寄り添ってくるものを守る、そんな人間になりたい。Grow and live like a tree :)

▲職場で同僚たちが祝ってくれました

The Social Network

2010-09-23T07:45:00.005+09:00

Facebook 誕生のストーリー。最近、本編前の予告でよく見かけます。
こちらでは10月1日に公開、日本でも来年公開されるみたいです！！

Three Days in Pittsburgh

2010-09-18T11:17:00.015+09:00

CMU でのリクルーティング二日間および一日の休暇で合計で三日間ピッツバーグに戻っていました。5月の卒業式以来でした。

左：9月14日（火）、仕事を終えて空港へ
右：19:55 出発予定だった U.S Airways のフライトが遅れに遅れ、22:40 発に


左：空港に着いたのは 00:10 頃、ホテルに到着したのはもう 1:00 過ぎでした
右：9月15日（水）翌朝は快晴！

左：CMU へ向かいます
右：ブースをセットアップして、リクルーティングの準備です！

左：その夜は MSE の先生が手作りのピザを振舞ってくださいました（写真はピザではないですけど）
右：テーブルを囲んだ先生や友人

▲後方から

9月16日（木）は一日かけてキャンパスの外で次のステップのインタビューを行いました。この日は、Tony 先生にも会え、夜はホテルに戻り、仕事の続きをしました。

▲9月17日（金）、休暇をとったので懐かしの Cave へ。写真に映っている彼とは去年一緒に CMU のテニスの試合に出たとき一緒のチームでした


左：先生や友人の方とも記念撮影。4か月ぶりなのに懐かしい
右：場所を移してスタバで

17:40 発の便に乗るのに、15:30 の空港行きのバスを待っていました。が、なぜかバスが来ない。16:00になってようやく来ました・・・ここから運悪く渋滞に巻き込まれ、空港に着いたのは 17:10。セキュリティゲートを通らないといけないし、終わったーと思ったら、帰りも遅れてくれた U.S. Airways。18:30 発になって今度ばかりは感謝。

左：無事に搭乗できました
右：フライトは快適そのもの。この写真、となりに座っていたドイツの男の子が撮ったもので、後でメールでくれました


左：Logan Airport には 20:00 に到着
右：Natick に戻り、止めておいた自転車と Amazon から届いた「プログラミングコンテストチャレンジブック」を回収しに職場のオフィスへ戻る途中。今のオフィスは、モールの近くなのです

仕事もこなして、先生や友人と再会できた3日間でした。みんな変わらず元気そうで本当によかった。
以上、簡易レポートでした。

Off to CMU Career Fair

2010-09-14T08:05:00.000+09:00

行ってきます！

四角い頭は丸くなるのか

2010-09-12T11:31:00.043+09:00

未知の問題を解くとき、自分を許せる場合と許せない場合がある。許せる場合、それは解法に必要な理論をまったく知らなかったとき。見たこともない数論、アルゴリズム、データ構造などが絡んで、既存の知識を総動員してもこれはたどりつけないと感じたとき。一方で許せない場合、それは解法に必要な武器は全て持ち合わせていたにも関わらず、問題に結び付けられなかったとき。山の手線内で「四角い頭を丸くする」という日能研のキャッチコピーをよく目にしたのを覚えているが、これを当てはめるなら、私の頭はがちがちに四角い。それは、パズルやオンラインジャッジの問題に取り組んでいて、解法に必要な武器は持ってるのに解けないケースが多すぎるからだ。なので、生まれてこのかた自分の脳に瞬発性があると思えたことは一度もない。数学ガールの第二巻「フェルマーの最終定理」でもテトラちゃんが似たような悩みを語っているので、詳しくは第二巻のページ 204 と 255 を参照あれ。

話しの具体性を出すため、例を挙げる。TopCoder の SRM269 の SecurityBunker という問題があり、ここでも自らの脳の反応の悪さを垣間見ることになった。問題は以下の通り。マップに爆弾（*）とシークレットオブジェクト（?）の二種類が配置されている。どの爆弾に着火してもすべてのシークレットオブジェクトに火が届くような火力のうち、最小の火力 D（答えは double 型）を算出してくれ、というもの。ボンバーマンのように他の爆弾の爆発による誘爆も許される。最小という言葉を見て最初に頭に思い浮かんだのは breath first search だったが、答えの火力が double 型だったので、これはおそらく上手くないだろうと判断。SRM187 の DNAMultiMatcher で tomek さんのうまい binary search を思い出して、この問題でも使えるかと疑ってみる。が、爆弾の爆発の連鎖をどう表すのかが思い浮かばずに脳がここで停止する。次の一手がどうしても出ず、ギブアップ。落胆しつつ、他のコーダーのアプローチを見ると、爆発の連鎖に union find を使っている・・・！Kruskal で使っていたはずなのに、状況が変わるともう使えない。かたい頭だ。こういう局面でキーポイントに気づく人と気付かない人の違いはなんなのか。

Andy Hunt 氏の「Pragmatic Thinking and Learning」の第二章に "Experts work from intuition, not from reason." という一文がある。達人コーダーはこの「勘」が凄い。考える前にもう何かが湧いてきてるのだろう。話しは変わるが、自分もテニスやっていてノッてたときはこの勘が冴えていた。これをダウンザラインに打ち込めばネットに出てボレーで決められるとか、このポイントではリターンをスライスで返せば相手のリズムを崩せるとか、理屈じゃない何かが見えていた時期があった。さらに話しが変わるが、すぎやまこういち先生がドラゴンクエストの序曲を作曲なさったとき、依頼をうけて帰りの車に乗り込んでから5分で思い浮かんだとか。曰く「ただの5分ではなくて、僕がこれまで生きてきた人生プラス5分」だそうだ。パンチラインは、経験から繰り出される直感は最強、ということ。問題が解けないのは、どうも私の頭が四角いとかいう言い訳じみたもののせいではなく、経験が圧倒的に不足しているからのようだ。経験が頭を丸くする。中には経験抜きで直感が冴えまくる人もいるだろうが、少なくとも私はその部類ではない。ロジカルシンキング以上に利くのは、経験に裏打ちされた直感ではないかと思うわけである。ただ厄介なのは、この直感というもの、狙って会得できるようなシロモノではなさそうなのだ。なんというか、努力と経験の末に生み出される副作用のような気がしている。脳科学や人工知能の観点からこれをどう説明できるのか、非常に興味があります。

以下、自分で書いた SRM269 の SecurityBunker の解答

#include <algorithm>
#include <cstdio>
#include <cstdlib>
#include <cctype>
#include <cmath>
#include <iostream>
#include <map>
#include <set>
#include <sstream>
#include <string>
#include <utility>
#include <vector>
using namespace std;
#define FOR(i,s,e) for (int i = int(s); i != int(e); ++i)
template<typename T> inline int size(const T& c) { return c.size(); }

int p[200];vector <pair<int, int> > b, so;

int find(int x) { return p[x] == -1 ? x : (p[x] = find(p[x])); }

void joint(int x, int y) { x = find(x); y = find(y); if (x != y) p[x] = y; }

/*
 * This function returns true if all secret objects can be destroyed with
 * a given bomb range.
 */
bool ok(double cur) {
    // initialize each bomb's representative
    memset(p, -1, sizeof p);
    // if two bombs are within the range, merge them into one set
    FOR(i,0,size(b)) FOR(j,0,size(b))
        if (hypot(b[i].first - b[j].first,
                  b[i].second - b[j].second) < cur)
            joint(i, j);
    // if the representative in a disjoint set destroys all secret objects
    // so do all bombs in the set
    FOR(k,0,size(b)) if (p[k] == -1) {
        FOR(i,0,size(so)) {
            bool good = false;
            FOR(j,0,size(b)) {
                if (find(j) == k &&
                    hypot(b[j].first - so[i].first,
                          b[j].second - so[i].second) < cur) {
                    good = true;
                    break;
                }
            }
            if (!good) return false;
        }
    }
    return true;
}

class SecurityBunker {
public:
    double chooseBomb(vector <string> field) {
        FOR(i,0,size(field)) FOR(j,0,size(field[0])) {
            if (field[i][j] == '*') b.push_back(make_pair(i, j));
            if (field[i][j] == '?') so.push_back(make_pair(i, j));
        }
        // binary search on range D
        double lb = 0, ub = 200;
        while (ub - lb > 1e-9) {
            double cur = (ub + lb) / 2;
            // if all security objects can be destroyed with this range
            // look for a shorter range
            if (ok(cur)) ub = cur;
            // otherwise look for a longer range
            else lb = cur;
        }
        return lb;
    }
}

私の答え：12匹のねずみとチーズ

2010-08-28T12:43:00.011+09:00

それではクイズの答えです。使うチーズは全部で5個。

まずは12匹のねずみに A,B,C,D,E,F,G,H,I,J,K,L と名前を付け、彼らを三つのグループに分けます。(A,B,C,D) (E,F,G,H) (I,J,K,L) となり、(A,B,C,D) にチーズ#1、(E,F,G,H) にチーズ#2、(I,J,K,L) にチーズ#3を与えます。議論を簡単にするため、A が特別なねずみだと仮定し、それを知らないふりをしつつ話しをすすめます。

[A は普通のねずみよりも食べるスピードが速い]
このケースでは、A を含むグループが早く食べ終わるので、食べるスピードが速いねずみはそのグループにいることが分かります。そして (A,B,C,D) が食べ終わった瞬間に (E,F,G,H) と (I,J,K,L) からチーズを取り上げます。この二つの食べかけは、おそらく形状こそ違えど、残量は等しくなっています。それぞれ食べかけ#1、食べかけ#2と呼びます。この時点で私達が分かっているのは、次の二つ。特別なねずみの食べるスピードは他よりも速いということと、そのねずみは (A,B,C,D) の中に紛れているということ。次に、(A,B,C,D) を (A,B) と (C,D) という二つのペアにわけ、(A,B) に食べかけ#1、(C,D) に食べかけ#2を与えます。繰り返しますが、これらの食べかけは同じ残量です。A を含むペアがまた早く食べ終わるので、これで A か B のどちらかが犯人だということが分かります。あとは、新品のチーズ#4と#5を取り出し、それぞれ A と B に食べさせます。早く食べ終わった方が特別なねずみということになります。

[A は普通のねずみよりも食べるスピードが遅い]
こちらのケースの方が難しくなります。A は食べるのが遅いため、(E,F,G,H) と (I,J,K,L) が先にかつ同時に食べ終わります。この観測から、特別なねずみは食べるのが遅いことが分かります。(E,F,G,H) と (I,J,K,L) が同時に食べ終わった瞬間に (A,B,C,D) からチーズをとりあげ、食べかけ#1とします。この時点で (A,B,C,D) に的を絞れたので、(A,B) と (C,D) の二ペアに分けそれぞれに新品のチーズ#4と#5を与えます。A が遅いので、(C,D) が先に完食し、また (A,B) に食べかけが残ります。これを食べかけ#2とします。さて、他に手掛かりはないでしょうか？出題時に、目分量で相対的に比較することはできないと書きましたが、食べかけ#1と食べかけ#2の残量の比較を定量的に行うことはできます。計算してみると、食べかけ#1の残量は食べかけ#2の残量の半分であることが分かります（詳細は下記※ を参照ください）。この情報を使いましょう。現時点での手掛かりは三つ、特別なねずみの食べるスピードは遅いということ、食べかけ#1の残量が食べかけ#2の残量の半分であるということ、そして犯人は A か B のどちらかだということ。ここからはこういうアプローチでいきます。A か B のうち一匹を選び、残量の少ない食べかけ#1を与えます。そして、A と B 以外のねずみはもう普通のねずみだと分かっているので、その中から二匹連れてきて残量の多い食べかけ#2を与えます。ここではその二匹を仮に (E,F) にしましょう。この設定でまた同時に食べさせます。食べかけ#1の残量が食べかけ#2の残量の半分であることを思い出しましょう。もしも、食べかけ#1を食べているねずみが遅いねずみ、すなわち A だった場合、(E,F) が先に食べかけ#2をフィニッシュするので、食べかけ#1を食べている遅いねずみ A が犯人だと分かります。逆に、食べかけ#1を食べているねずみが普通のねずみ B だった場合、B が食べかけ#1をフィニッシュするのと、(E,F) が食べかけ#2をフィニッシュするのは同じタイミングになります。なので、食べかけ#1 を食べるのにピックアップされなかった A が犯人ということが分かります。

どうでした、解けましたか？これが5つのチーズを使った答えで、この聞いたことのない問題が、いきなり第2ラウンドの電話インタビューで飛んできたので、インタビュー中に相当パニックになっていたのを覚えています。ですが、インタビュアーも要所要所でヒントをくれたので、それを頼りになんとか答えにたどり着きました。もしも、チーズ4つでいけた方は是非ご一報を！！

[※ 特別なねずみが遅い場合の食べかけ#1と食べかけ#2の残量比較]
普通のねずみの単位時間あたりの食べるスピードを x、遅いねずみの単位時間あたりの食べるスピードを y (x > y) とします。そして、一匹の普通のねずみが新品のチーズひとつを食べるのにかかる時間を t とすると、新品のチーズの残量は、tx になります。(E,F,G,H) がフィニッシュしたときに食べかけ#1ができあがります。(E,F,G,H) がフィニッシュするまでの時間は、tx / 4x = t/4 になります。この時間内に、(A,B,C,D) は単位時間あたり 3x + y のスピードでチーズを食べます（普通のねずみ三匹と遅いネズミが一匹の合計）。なので、食べかけ#1の残量は、tx - (t/4)(3x + y) = tx/4 - ty/4 となります。
食べかけ#2ですが、これは (A,B) と (C,D) が同時に新品のチーズを食べ始め、(C,D) がフィニッシュしたときにそれが出来上がるのでした。上記と同様のパラメタを使うと、(C,D) がフィニッシュするのにかかる時間は、tx / 2x = t/2。そしてこの間に (A,B) は単位時間あたり x + y のスピードでチーズを食べています（普通のねずみ一匹と遅いネズミ一匹の合計）。なので、食べかけ#2の残量は、tx - (t/2)(x + y) = tx/2 - ty/2 となります。
以上、tx/4 - ty/4 = (1/2)(tx/2 - ty/2) から、確かに食べかけ#1の残量は食べかけ#2の残量の半分であることが分かります。

TOC 2010 および就職活動について

2010-08-21T09:58:00.047+09:00

日本を離れて丸一年になりました。さて、去年学生として参加した Technical Opportunity Conference (TOC) に、来月 MathWorks のインタビュアーとして参加することになりました。CMU の学生さんに、今の自分の department でのお仕事を説明したり、最初のインタビューをしたりします。まずは、学生さんの話しにしっかりと耳をかたむけることから始めたいと思います。

就職活動つながりですが、茂木さんの日本の就職連続ツイートや内田さんの日本の人事システムについてを読んで、自分が去年体験した就活とはずいぶん違うなと感じました。日本では、ある外資系 IT 企業のインターンの面接しか経験したことがないため、自分の体験から日本の就活全般について話しをすることはできません。そのインターンの面接では志望動機がうまく説明できずに落とされてしまいましたが（それが理由だと私は推測しています）、そのグループ面接の質問内容は、「なんで私は落ちたんですか」と candidate が後からインタビュアーに聞いたら、その「なんで」にきちんと答えられないようなものが多かった気がします。インターンの志望動機、学生時代何を頑張ったか、なぜその学部を選んだか、当社のイメージ、過去に直面した困難な状況をどのようにして克服したか、など。その人の過去をさかのぼる質問やある事柄の表面だけに触れる質問ばかりで、この瞬間に何ができるかを判断する質問がないように思いました。だからだと思います、この面接の後に「これは受かっても落ちても、どうしてそうなったのかが分からない面接だな」と思ったのは。

内田さんは、

その意味では、受験というのは努力と報酬の相関がかなりの確度で予見される「合理的な」プロセスである。
けれども就活はそうではない。

と説いていましたが、私が経験した13社の米国のソフトウェア会社との面接は、この受験のスコアリングに非常に近かった気がします。まず、その人がこの瞬間何ができるのかを的確に知るため、面接をするのは人事の方ではなく、入社後に一緒に仕事をするであろうエンジニアさんたち。人事の方たちはコンタクトをとることが主な仕事です。 45分から1時間のホワイトボード付きテクニカルインタビューを3から5ラウンドをして、candidate のこの瞬間の能力を測ります。ちなみに、Microsoft もそうらしいですが、MathWorks も社内で違う department に移るときは、この45分から1時間の技術面接セッションが最低3ラウンドはあります。このタイプの面接は受験のスコアリングに非常に近い。私も13社との面接で落ちたケースは、問題が解けずに落ちたので、ここで書いたように落ちたことに関しては何の驚きもありませんでした。ただ不出来だった項目の中で具体的に何がダメだったのかが分からなかっただけで。この点は、米国のソフトウェア会社の面接は非常にクリアです。問題が解ければ通る、解けなければ通らない。志望動機も大事でしょうが、その比重は「この瞬間あなたは何ができるの？」に比べれば遥かに軽いはず。そもそも、志望動機を語るのは「口」です。口を動かすのはとても簡単です。寝ている人だって口ぐらい動かせる。面接で、その部位を一生懸命動かす candidate を見て彼/彼女が真に備えているものが分かるのでしょうか。もちろん職種によりけりですが、口だけを動かすエンジニア、画家、音楽家、スポーツ選手を見てどう思いますか。口は、必要でない限り、体の中で最後の最後に動かす部分だと今の自分は考えています。だからこそ、ここで書いたように、ある技能を瞬時に引き出せるかどうかを見るため、電話インタビューで Google は Google Docs に、Facebook はサイト内のスクラッチパッドのようなページに、candidate にライブでコードを書かせる理由がよく分かります。

ただし、この瞬間に何ができるかの能力を測るタイプの面接では、たまたまそれに答えられずに落ちてしまった非常に優秀な方々もたくさん出てくると思います。だから人事面接やマネージャー面接を織り交ぜて、総合的な判断を下すことが必要なのでしょう。採用は本当に重要かつ難しい問題なのだと改めて思います。それでも、私自身が去年感じたのは、米国のソフトウェア会社の採用システムは非常にわかりやすくていい。能力があるかないか、それだけ。自分の能力のなさを悔んだことはありましたが、システムの理不尽さを呪ったことは一度もありませんでした。全て本音のやりとりが出来ましたし、他社ともインタビューしていることもインタビュアーに堂々と伝えました。テクニカルインタビューも含め、そういうやりとりの末に出された結果はどれもすべて納得がいくものでした。

といろいろ考えたところで、来月の TOC 2010、しっかり仕事をこなしてまいります。12匹のねずみとチーズの答えは次回。実はこれも、とあるソフトウェア会社の電話インタビューで出された問題。その会社の面接もオンサイト一歩手前の CMU キャンパスでの第5ラウンドインタビューで落とされてしまいましたが、それもやはりよい経験でした。

クイズ：12匹のねずみとチーズ

2010-08-13T12:38:00.022+09:00

12匹のねずみがいます。この中で一匹だけ変わったねずみがいます。そのねずみは他の11匹の普通のねずみとは違うペースでチーズを食べます。ただ分かっているのは「違う」ペースというだけで、他の11匹より早く食べるか遅く食べるかは分かりません。手元にあるチーズを使ってこの変わったねずみを割り出したいのですが、以下の条件のもと、最低いくつのチーズが必要でしょうか（必要なチーズの数が少なければ少ないほど、良い答えになります）。

ちなみに知られているベストアンサーがあるらしいのですが、私はどうしてその数で割り出せるのか今でも分かりません。私の答えはしばらくしてから投稿しますが、その答えはベストアンサーよりもひとつ余計にチーズを使います。

時計を使ってはいけないので、時間計測はできない。
複数のねずみが、ひとつのチーズに群がってもよい。
手元にあるチーズはどれも同一だが、その形状はいびつで、食べかけの形状からは残り何分の一というような判別はできない。
変わったねずみ以外の11匹の普通のねずみは、みな同じペースでチーズを食べる。
仮に、普通のねずみ11匹の中から2匹 A, B を選び出しそれぞれにひとつずつチーズを与えた場合、A, B は同じタイミングで食べ終わるものと考えてよい。
好きなタイミングでねずみ（or 複数のねずみ）からチーズを取り上げてよい。その取り上げたチーズは食べかけとして再利用してよい。
食べかけのチーズをねずみ（or 複数のねずみ）に与える場合は、それは新しいチーズとしてカウントしなくてよい。

追記：
以下の大事な条件が抜けていました。すみません。

ふたつの（もしくはそれ以上の）チーズの大きさが等しいかどうかを、目分量で相対的に比較することはできない。

具体的にはこういうことです。最初に12匹のねずみを4つのグループ (A,B,C) (D,E,F) (G,H,I) (J,K,L) に分けます。そして、それぞれのグループにチーズを与えます（この時点でチーズを4つ使っている）。仮にAが遅いねずみだったとすると、(A,B,C) のグループに食べかけが残り、それ以外のグループは同じタイミングでフィニッシュします。ここから次のステップとして、(A,B,C) の食べかけと同じ「残量の」食べかけを作りたいとしましょう。しかし、次のようなことはできません：(A,B,C) だけを再びひっぱりだしてきて、新しいチーズ#5を与えて同じ残量のたべかけを作る。なぜこれができないかというと、目分量で大きさの相対比較ができないため、いつ彼らにストップをかけていいかわからないからです。すなわち、すでに作られている食べかけチーズを横において、今まさにがりがり削られているチーズ#5の大きさを時々刻々観察し、横の食べかけとそろそろ同じ大きさになったかな、なったかな・・・なった、はいストップ！ということができないということです。もちろん時間計測もできないので、それもうまくいきません。

私の外国語習得法 Part2

2010-08-07T09:40:00.031+09:00

今回は留学前の数カ月前、2005年の2月～4月あたりの話をします。さて、覚えたての言語で話そうとすると、この言い方って文法的にはあってるんだけど、普通そうは言わないよなあって、ネイティブの人から指摘されることがあるかと思います。なんでネイティブの脳は「普通そうは言わないよな」っていう判断を下せるんでしょう？私が留学の2,3か月前に抱いた疑問はここでした。私たちは生まれてから膨大な量の言葉のやりとりを知らず知らずのうちにこなしています。親との日常会話、兄弟や友達との喧嘩、スポーツの最中の声の掛け合い、電車に乗って聞こえる周りの人達の会話、飲み会でのバカ騒ぎ、お医者さんに行って自分の症状を説明する・・・どれだけ言語のプールに晒されているか、正直想像すらできないです。こうした言葉のやりとりという training data で訓練された結果、脳内に確固たる言語モデルが構築されていると私は考えてます。では、この脳の驚くべきプロセスに the hard way で対抗するためにはどうしたらいいか。最初のステップとして自分が考えたことは三つありました。1) 自分のレベルにあったスピーキングの教材を選ぶこと、2) 自分自身を幼少時代に戻すこと、3) 心の中のつぶやきは全部英語で、でした。

まず 1)ですが、リスニンピックで24個の映画を英語字幕でディクテーション、シャドーイングしたのはリスニングの役には立ちましたが、スピーキングではリスニングほど効果が出ませんでした。それは映画に出てくるようなシーンは、自分の日常の中ではまずほとんど出くわさないからです。映画で学ぶ英語の名ゼリフなんていうのもありますが、それはその名の通り、セリフにすぎません。そのセリフのあとが続かないのです。パンチラインをため込む時期も必要ですが、それはいわばバラバラになった点。会話のコンテキストに合わせて、それらを操る別の能力が必要になってきます。CNN もいいのですが、アナウンサーの口調で他人に話しかける姿が想像できますか？Times もいいのですが、新聞に書かれてる語り口調で他人に話しかける姿が想像できますか？映画およびこれらの教材は使われている英語が洗練されすぎてかつ場面設定に対する自分の心理的距離が遠すぎて relate できないため、スピーキングの基礎づくりとしてはあまりに難易度が高すぎました。難しすぎるからキーフレーズみたいな「点」しか取り出せなかった。ミーティングやプレゼンでは英語が話せても、会議室を一歩出て、バーでダンスをしながら話す英語やボーリングをしながら話す英語が出てこないのは、上手すぎる言い回しだけに偏っている証拠で、子供が使うようなもっとプリミティブで、それでいて懐の深い骨太な英語を身につけるのが先決だと考えたのは、こんな経験からです。

次に 2)ですが、自分は子供の頃どうやって日本語に馴染んできたか考えました。日常で話すような言葉はアニメやゲームで覚えました。ならば、英語でも同じことをしてやれと思い、日本のアニメやゲームの翻訳版にあたることにしました。ドラゴンボールなら、はっきり言ってほとんどのセリフが頭に入ってるといってもおかしくないほど読んでいましたから、これに対応した英語ならば、CNN で聞こえてくる英語よりもすんなりと自分の核に吸収されるのではないかと思いました。「クリリンのことかーっ!!!!!」の英語なら一発で入って、口から出てくる気がしません？ドラゴンボールを英語で全巻読み、アニメも英語で結構な話数を見て、そのレベルの英語を自由に加工して話せるようにしました。一か月半くらいかかった気がします。ほかにもファイナルファンジー、クロノトリガーなど、子供のころ馴染んだセリフが詰まったゲームの英語版をプレイして、ずっとぶつぶつ唱えていました（クロノトリガーの英語で検索したらこんなサイトもありました）。やはり子供のころに馴染んだセリフだと、それに対応した英語も体にすっと入ってきて、映画英語やニュース英語で覚えた言い回しよりも、加工しやすかったのを覚えています。舞台設定やセリフは小さいときに刷り込まれているので、その刷り込まれた日本語とそれに対応する英語の橋渡しが、映画やニュースに出てくる英語に比べてやりやすかったからでしょう。しかし、問題もありました。映画同様、上記の教材は舞台設定が自分の日常生活とあまりにかけ離れすぎていたのです。そこでまた考えました。自分の日常に近い設定で、かつ子供のころの自分が話していたようなセリフをかけあっている教材はないものか？ありました。

▲ 日本語版放映タイトル　資産家令嬢殺人事件（後編）

▲ 日本語版放映タイトル　コナン vs 怪盗キッド

ご存じ名探偵コナンです。英語のタイトルだと「Case Closed」。留学前にこれを見つけたのは本当に幸運でした。自分に必要なものが全てそろっている。子供同士の登校下校、親との会話、友人とのおしゃべり、殺意を抱くまでになったドロドロした人間関係の記述。さらには、現場検証、推理、トリックの説明がすべて英語になります。とくに推理とトリックは日本語で説明しても難しいのに英語でできたらもう完璧でしょう。論理の組み立ての見本として、もってこいの教材です。Youtube にアップロードされている Case Closed のクリップは英語字幕がなく、音声字幕機能を使ってもかなり外れています。英語版の DVD を買えば正しい英語字幕が（途中の巻まで）見られます。いきなり音声がキツい方は漫画の英語版もあるので、そちらもオススメです。

最後に 3)。日本にいる以上、入ってくる音や目で見る文字は全て日本語で、こればかりはコントロールのしようがない。ならば自分の内界だけでも英語に変えてやれと思い、黙り込んだときは心の中で全て英語で話すようにしました。「お、電車が来た。やばいやばい、早く乗らなくちゃ」とか。心で思って、何て英語で言っていいか分からなかったときは、Case Closed を参照して、自分が直面したのと似たようなシーンを漫画から探し出し、そこでなんて言ってるか調べて自分のものにする。それの繰り返しでした。

以上の 1)、2)、3)が、映画リスニンピックの後、留学前にやっていたことです。アメリカに来てからの学習法はまたいずれ。

あと今回書いたことをいま中国語でもそっくりそのままやろうとしています。中国語版の名探偵コナンもありますしね。自分の中国語のレベルはまだまだ英語には及ばないですけど。まあ、ぶっちゃけてしまうと日本語も英語もまだまだなんですが^^;

あそびごころ

2010-07-25T11:29:00.005+09:00

この前の木曜日の昼過ぎにアイスクリームのトラックが会社の前にやってきました。年に何回かあることみたいです。自分の department ではマネジャーから各位に「13:15～13:45 にアイスクリームのトラックが来るので、アイスを確保したい人は・・・」なんてマメなメールが送られてきました。イベント好きの人たちが多く、楽しく仕事させてもらってます。

Company Summer Outing 2010

2010-07-12T09:59:00.007+09:00

から今帰ってきました。社員のゲスト、家族も参加した大人数のイベントでした。
Thanks MathWorks for this morale event. Awesome trip to Mount Washington!

Fourth of July Fireworks

2010-07-05T15:17:00.011+09:00

アメリカの独立記念日、全米各地で花火のイベントがあります。ピッツバーグにいたときはなぜか一度も行きませんでしたが、今年はここボストンのチャールズ川で開催される花火のイベントに行ってきました。同僚は、この3連休を利用して実家に帰る人が多かったです。

左：この日は地下鉄の乗らずに歩いてチャールズ川まで行きました。写真は Boston Common
右：この前まで干からびていた Frog Pond も、夏になりプール状態に


左：チャールズ川までやってきました
右：この時点で17:45頃。まだみなさんベストスポットを探している様子


左：18:30頃、試し打ちの音が。花火は22:30スタート予定
右：陣取る人が結構出てきました。自分は木を背もたれにできる場所を陣取りました

最近は仕事から帰ると、OS の本、コンパイラの本、CPU の本、Python で学ぶ機械学習など、的を絞らずにあれこれちょっかいを出して遊んでます。今日も、花火開始まで4時間もあったので、C++ のテンプレート、SICP、今週解けなかった TopCoder の問題の復習など、リュックに詰めてきたものをひたすら読んでました。まわりはピザやビールでお祭り騒ぎだったので、一人だけ妙な本を読んでいて、「なにこの人」みたいな目でみられないようにわりとコソコソやってました^^;

左：夕焼けがきれいです。この時間になると、さすがに字が読みづらくなってきました
右：場所も混んできて日もなくなったので、読書はここで打ち止めに


左：22:00頃にサプライズが一発
右：開始時間になると、もう足の踏み場所がないくらいの人数になりました。自分は木の幹にちょうどいいステップがあったので、それに乗りました


左右：最初の一発を皮切りに、色とりどりの花火が次から次へと打ち上げられます


左右：時間にして30分ほど続きました

▲ラストにたたみかけるような連続の花火。ギャラリーのテンションも最高潮で「USA！」の連呼

今回は、事前にチケットを買うともっと川沿いまで行けることを知らなかったので、最後は人混みにのまれてしまいました。来年は折りたたみ椅子を持って、もっと川沿いに陣取ろうと思います。普段は23:00が終電の Commuter Rail も、この日の最終は00:00でした。West Natick に戻ってきたときは、夜中の1時を回っていました。

せっかくの機会なのでフィクション、ノンフィクションを問わずに、Independence Day のいろいろを楽しみましょう。こちらや以下のビデオクリップで！

週末ワールドカップ観戦

2010-06-27T13:08:00.015+09:00

ワールドカップの決勝トーナメントの1回戦アメリカ vs ガーナを同僚と観戦しに、またボストンまでやって来ました。私は、普段サッカーの試合をまったく見ないのに、ワールドカップで世間がお祭り状態になるときだけ試合観戦するとは、なんというミーハー。

左：みなで Red Line の Cetral 駅まで来て
右：Middle East というバーで観戦しました


左：中は結構混んでいて立ち見になってしまったので
右：近くの Indian Buffet に場所を移すことにしました

▲Indian Buffet でワールドカップ観戦もなかなかオツなものでした。試合はガーナがアメリカを延長 2-1 で下しました。頑張れニッポン！

CMU 内にも Indian Buffet がありましたし、ピッツバーグ大学の近くにある Bayleaf Indian というお店も何回か行きました。インド料理はわりと好きで、keer というスイーツにハマってます。

あと、最後の写真見てて気づいたんですが、自分のまわりはインド人の割合がすごく高い。思い返せば、NY にいたときのルームメイトもインド人だったし、MSE プログラムにもインド人がたくさんいましたし（自分のチームにも2人）、就活のときの interviewer や recruiter も結構な確率でインド人でしたし、いまの職場にもかなりのインド人がいます。まるでインド本国にいるような錯覚を受けるくらい、インドの方々に囲まれた生活を送っています^^

私の外国語習得法 Part1

2010-06-21T08:16:00.024+09:00

ちょうどタイムリーな記事があれこれ見つかったので、数回にわけて、私の外国語習得法を説明します。これから書くことは、英語以外の言語でも通用すると考えているので、あえて英語習得法とは書きません。本当に英語以外の言語でも通用するかどうかは、今趣味でやっている中国語を英語のレベルまで引き上げられたら、その答えがはっきりすると思います。言語習得の本は山のようにあるので、このブログでは、この人はこんなアプローチをとったのかという感じで見ていただければと思います。ネイティブ（どんな言語にせよ）の方の「生まれてから知らない間に身についちゃった」というアプローチではないので、確固たる習得法を身につけられるというのは、新しい言語を学ぶときのノンネイティブの強みだと思います。

私は23までずっと日本におり、それまでは海外旅行に行ったこともなければ、飛行機に乗ったこともありませんでした。ただし、父親の映画好きが影響して英語の音を好きになっていったのはプラスだったと思います。

【中学高校時代】
私は中学受験の末、早稲田中学に入りました。高校へはそのまま受験なしに進学。中高を通じての英語の教育はやはり英作文、文法重視と日本の大学受験を視野に入れてのものでした。言語を習得するとは、その文化、歴史、人とのやりとり、ジェスチャー、表現、などすべてをひっくるめた宇宙を自分の体内に取り込むという行為だと思っています。昨日の Beer Fest でインド人と話をしたら、彼は中学から英語での教育がはじまったと言っていました。そう、中学生のときに毎日その言語「だけ」で話したら、それは言語が生活の一部となり、誰しもかなり自然にその宇宙を取り込むことができるはずです。ところが、英作文、文法だけを重視して、ひとたび教室を離れれば日本語を話し出す語学習得法を採用したのでは、とてもその言語の宇宙に対抗することはできないのです。

ただ、そんな英作文、文法重視の中学高校時代に自分がやっていてよかったと思うのは1) 英語の音作りと 2) 英文暗記です。英語の音作りは、ラジオ英会話から始まり、学校で出てきた英文はすべて口に出して音を作っていました。口に出さずに次の問題へ進むのはなぜか気持ちが悪かったのです。発音の基礎はこの時期にできたんだと思います。ふたつめの英文暗記ですが、言語習得には、悲しいかな単語を記憶したりと記憶力が必要になります。私は、中学、高校のテスト対策では、テストに出るであろう英文をすべて暗記していました。具体的には、当時 DUO という単語集が使われていたのですが、毎回100つの例文がテスト範囲だった気がします。そして、そのテストのたびに100の文章を覚え、例文の最初の単語をいわれれば、全文が口をついて出るような学習法をとっていました。当時は、「歩く DUO」なんて呼ばれていた気がします。日本語とは違う言語の音を口に出し、意味のまとまりである文を暗記して、自分の口から出る音の流れを頼りにいま喋っているのはこんな意味なのかなと想像する、という練習法を知らず知らずのうちに確立していたことはよかったと思います。大学受験の英語は、やっかいな文章読解も多く、その練習に結構な時間を割いたため、高校卒業時には自分の中から紡いで英語をしゃべりだすということはほとんどできませんでした。語学習得の私的ポイントその1は、音を主体にした勉強が役に立った。その国の文字で書かれていたら、その文章をかならず声に出すこと。意味はわからなくても、暗記して口から音を出せればなおよしです。

今の中学高校の英語教育で、Youtube、Facebook、iPad などを使って生徒をナマの英語に触れさせる仕組みが出てきたら面白いですよね。

【大学時代】
それまで自分にとって英語は、「英語の音が好き」「試験で点数がとれる」という程度のものでした。そんな自分の英語に対する意識が変わり始めたのは、早大１年の後期の授業の時のこと。その授業で、先生が字幕なしで「マチルダ」という映画を見せてくれました。すごく面白そうな映画だったのですが、英語が分からないため、まったく楽しめなかったんですね。英語で点数をとるということと、英語の宇宙に浸ることに大きな違いを感じ始めたのは、このときでした。英語で笑ったり、悲しんだりという感情表現が自分もできたらいいなあと思うようになって、そのときから映画で英語を勉強する日々が始まりました。スクリーンプレイ社や、アルク社から出てる映画のスクリプトの本を買って毎日映画を見て、台詞を繰り返したりしてました。「こういう場面でそういうのか～」とか「そういうジェスチャーをするのか～」など、映画から学ぶことは多かったです。特にインデペンデンスデイは大好きで、今でも、とあるセリフをしゃべってもらえれば、劇中のどのシーンか一発で当てることができます。この時期に、日本にいながらにして別の国の言語を習得するには、映画学習は最高だとわかりました。登場人物の顔の表情も見え、場面のコンテキストも分かり、怒っているのか悲しんでいるのかといった口調もどう吐き出せばいいのか、目でみて分かるからです。

ある日、スクリーンプレイ社の新しいスクリプト本を買ったとき、中にリスニンピック（リスニングとオリンピックからできた造語です）と書かれたビラが入っていました（今はもうサービスをストップしたみたいで、残念です）。これは何かというと、1ヶ月で1つの映画の台詞全てをディクテーションして、自己採点するというもので、映画が好きで、どれくらい聞き取れるようになってるか正確に測りたかった自分にとってはぴったりのオンラインプログラムでした。リスニングに加えてシャドーイングもするようにして、飲み会があろうが、テニスをしようが、毎日決まった量をこなし、丸2年間続けました。3年目は卒論で続けられなくなってしまいましたが、卒論時も映画で英語を聞きながら作業していました。

修士1年になってから地元でイギリス人の先生が経営する英会話がカフェを見つけました。せっかくの機会だったので話す練習もしようと決めました。あれだけ映画で想像力をかき立てて英語を磨いたんだから、比較的簡単に話せるだろう思っていたら、とんでもない思い違いでした。最初の挨拶のときに英語が全く出てこなかったのです。リスニンピックで毎日2年間聞き続けて24個の映画をこなして、それ以外でも英語に触れていたのに、全く話せずショックは最高潮。話し英語と聞き英語は違うということを思い知らされました。ただし、耳は鍛えていたおかげで、先生の話していることはすべて分かったのです。最悪の状況は、聞けない、話せないなのですが、このときはリスニンピックのおかげで聞けない状況はクリアできていました。なので、私自身も半分落ち着いてなんとか先生と話すことができました。そしてスピーキングという課題も見えたので、これからの学習法を修正していく良いきっかけになりました。英語習得に関して、大学時代にやっていてよかったのは、映画で毎日4、5時間英語漬けになる生活に慣れて、勉強しているという感覚がなくなったことです。おかげで、日常生活の一部として英語と付き合えるようになりました。ここでいう私なりの悟空の解釈、もしもあるものを習得したかったらまずは勉強しているという感覚を無くす、ということを私は大学時代に英語の学習で実践しました。ビジネス英語、CNN なども必要だと思いましたが、何よりこの段階でそれを毎日4、5時間続けるのは苦痛だと感じたので、その学習法は自分には適していないと判断し、それらはもっと骨太の英語の力がついてからでよいと考えました。

語学習得の私的ポイントその2は、その言語を生活の一部に取り込もう。たとえば洋楽、映画、英語版のゲーム、取り込み方は人それぞれ。毎日最低2,3時間は費やせるものにしよう。ただし、英語の音がないものはお勧めできません。例のごとく、その言語の宇宙に浸れないからです。

2005年に初めてアメリカに来てからも、私は英語の学習法を臨機応変に次々と変えていきました。またそれは次のおはなし。

American Craft Beer Fest

2010-06-20T13:43:00.000+09:00

Beer tasting のイベントが6月18日にあり、会社の同僚といってきました。場所はボストンの Seaport World Trade Center という場所で、港の側できれいな所でした。

左：会場入り口です
右：このあと、長い行列が出来ていきます


左：88 ものブースでいろんなビールが味わえます。会場は人であふれ返っていました
右：会社の同僚およびその友人。気さくな人たちばかりです


左：ひたすらテイスティング。種類が多すぎて途中から何を飲んだか覚えていません。この写真のビールは苦味が強かったです
右：お兄さん、写真用に腕を組んでくれました


左：皆で反応「・・・MathWorks？」
右：外に出て、ひと休み


左：このあとは皆で Orange Line の Haymarket 駅へ
右：Mike's Pastry というお店にいきます。人気のあるケーキ屋さんみたいで、結構な人が並んでいました


左：看板はこんな感じ
右：左の子は甘いもの好きで、このお店に来たくてもなかなか来られなかったみたいです。かなり喜んでいました

▲Christopher Columbus Waterfront Park で買ったスイーツを食べました。私はチョコレートムースを食べましたが、親の敵のように甘かった ;-(

ようやくこのエリアでも一緒に遊びにいく友人が出来てきました。ボストンへはいつも一人で来ていたので、この日はうれしかったですね。また、つい数日前まで MathWorks Japan の方たちもこちらにいらっしゃっていました。入社以来、お知り合いになりたいと思っていましたので、希望が叶って嬉しい限りでした。本当にお世話になりました！

世界史講義録

2010-06-02T08:15:00.005+09:00

というサイトがこちらにあります。講義ひとつひとつ語り口調で書かれ、「なぜ」に焦点を当ててくれるのでとても分かりやすい。最近痛感してるのは、ボストンで歴史の名所を訪れても歴史の知識が欠如しているために全く舞台背景のイメージがわかないこと。なんだかものすごく損をしている気がするので、世界史講義録で歴史の流れをつかみたいと思います。日本史でも似たようなサイトも探しています。どなたか、お気に入りの日本史のサイトがありましたら教えていただければと思います。

先々週は　Franklin Park Zoo および Public Library に行き、昨日は Freedom Trail を最初から最後まで歩いてきました。途中 Boston Navy の軍艦の中にも入れました。写真の枚数が多いので、ご覧になりたい方は Flickr からどうぞ。

Get sth under your belt !!

2010-05-28T13:05:00.025+09:00

ふと思いついたので、何かを習得するとはどういうことかについて考えてみます。もちろん、すでに自分のスタイルをお持ちの方にとっては当たり前の話だと思います。

ドラゴンボールで、セルゲームにむけて精神と時の部屋で特訓中の悟空が、パワーに頼った変身を試しにやってみるシーンがあります。しばらく考えてから悟空はこう言います。

これからは寝るときいがいはなるべくいつも超サイヤ人でいて、それがあたりまえの状態にもっていくんだ・・・・・・遠まわりなようだけどそれがいちばんだとオラはおもう

私もそう思います。何かを身につけるということは、それを瞬時に引き出せる能力を持つということだから。引き出そうとするたびに「勉強モード」にコンテキストスイッチしてたのでは、身についているとはいえないと思います。

米国でのソフトウェア会社とのインタビューで感じたのは、大学（undergrad, grad）で学んだ内容をかけ算九九を取り出すように引き出せないと相手にしてもらえないということ。あーそれ大学の授業で学んだけどそれが何だか忘れてしまったは、アウトです。大学での専攻と職種の関係をきびしく問われる米国ならなおさら。見られているのは、大学で学んだことがその人の血となり肉となっているかどうか、あるいは未知の問題が出てきたときに、学んだことを瞬時に取り出し、加工してその問題を解く力があるかどうか。取り出すだけで精一杯になっているようでは、瞬時に取り出せる人とは天と地の差。聖闘士星矢で、天蠍宮のゴールドセイント、スコーピオンのミロがこんなセリフをいうシーンがあります。

星矢とかいったな。確かにお前はセブンセンシズに目覚めつつある。また、お前の拳も光速に近づきつつある。だが、これだけは教えておこう。セブンセンシズに目覚め始めた者とすでに備えている者との間には、想像以上に大きな隔たりがあると。そして、光速に近い拳と光速そのものの拳の差も同じだ。聖闘士同士の闘いは、数千分の一秒の差が生死を決するということはお前でも知っているだろう。

技術を把握し瞬時に取り出せる人と、技術をなんとなく理解している人との間にも想像以上の隔たりがある。そして、大規模なソフトウェアの開発では、どちらのタイプの人を使うかで最終的な製品の品質が決まるのです。だから、インタビューではマッスルタワー方式で技術的な質問を次々と投げかけ candidate の本当の能力を試すんでしょう。「分からない」を連呼して、マスターすることがとにかく大事というのはそういうわけで（以前紹介したこちらも参考になります）。Twitter にも以前書きましたが、変えてほしい思う日本の諺に「聞くは一時の恥、聞かぬは一生の恥」があります。なんで、聞くことを最初から恥と決めつけてるんでしょう？聞くことはいいことなのに。「聞くは一生の誉、聞かぬは一生の恥」なのです。

勉強とは「我慢を強いる」と昔教わった記憶があります。我慢してやっていることだから長時間勉強すると、あぁー勉強したと気持ちよく吐き出したくなりますが、そうやって吸収した人と、三度の飯よりコーディング好き、絵描き好き、野球好きのように吸収した人とでは、やはり大きな開きがあります。一夜漬け後の試験のようなものでは差は出ないでしょうが、5年後、10年後にはっきりとした違いが現れてくるはずです。つまり、あぁ勉強したと感じているうちは、まだまだということ。再び勉強モードにスイッチするまで頭を休ませている人がいる一方で、それが好きでたまらずに休むことなく吸収し続けている人もいるのです。後者みたいな人は世の中にごまんといます。何かを身につけるには、悟空の言うように、当たり前になった状態で吸収していくことです。でなければ、直感レベルで取り出すなんて不可能ですから。

最初から好きなことが見つかってやり続けている人はもう何の問題もなし。ところが、世の中そんなにうまくはいかないという方もいるでしょう。そういう方には、最初は我慢してやっていても、やり続けているうちに好きになるのも素晴らしい能力なんだと気づいてほしい。一日でもそのことをやらないと死んでしまうというレベルまで自分を洗脳できればこっちのものです。

ひとつ例を挙げると、私のいままでの語学学習がそうでした。幼少時に音から自然に外国語を身につけたわけではない私は、英語を習得する際、独自の習得のプロセスを考える必要がありました。それを使って、次の外国語をマスターするのが当面の目標です。このプロセスでキーになるのはやはり悟空の考え方です。詳細についてはまたいずれ。

Commencement 2010 - Carnegie Mellon University

2010-05-19T10:06:00.024+09:00

先週の金曜日から今週の月曜日まで、CMU の Commencement 2010 に出るため、ピッツバーグにいました。ピッツバーグを離れたのは3月22日で、あれから2か月ほどしか経っていなかったのに、もう半年以上離れていた感じがしました。ああ、なつかしや home sweet home。MSE の友人にも再会し、記憶に残る週末となりました。

▲ この写真は借り物です

【5月15日（土）】
卒業式で羽織るガウンをMSE の友人と取りに行き、その足で一緒にキャンパスをじっくり眺めてきました。

左：キャンパス入口付近
右：University Center 1F、卒業式ムードです

夕方、Abhi、Jeff、Jeff のガールフレンドと一緒に Mount Washington にあるレストランで夕食をしました。Abhi、Jeff はチーム Jazz Rockers のチームメイトでした。 Jeff は現在 Alberkerky 在住、Abhi は現在 NY 在住です。

左：空席ができるまで、グビグビ
右：自分が注文した Filet Mignon

左：写真の奥に見える窓の外からは、ピッツバーグの街が一望できます
右：こんな感じの景色です。手前に見えるのは、Duquesne Incline のライトアップ

▲その景色を背景に皆で記念写真

【5月16日（日）】

卒業式当日。

左：朝8時30分から10時まで Newell-Simon Hall で breakfast
右：群衆からやっと MSE の友人を発見


左：Gates Center に移り、MSE の提携校、SSN School of Advanced Software Engineering のみんなと
右：Gates Center から Gesling Stadium に向けて行進


左：ピッツバーグの小町管理会の卒業生の方々と
右：ここでも言及しましたが、Jeff は寝坊する確率が高いのです


左：まさか commencement 当日も遅刻とは（笑）でも昨晩おそくまで、車でいろんな人を家に送りとどけていたらしいので仕方ありませんね
右：一人だけジーパンwww

左：この日は快晴！BGM は威風堂々
右：ベネズエラ出身の Freddy と


左：晴れ姿を見に世界中からやってきた卒業生のご家族で観客席は埋め尽くされていました
右：School of Computer Science のシンボルはドラゴン。強さと賢さと長寿を兼ね備える生き物です

▲今年の Keynote Speaker、Dr. Ian Rawson。ハイチの地震のエピソードをもとに、perseverance の大切さを教えてくださいました

場所を移して、SCS の Diploma Ceremony は Carnegie Music Hall で執り行われました。

左：SCS の教授陣が入場、なぜかライトセーバー？
右：SCS の The Alan J. Perlis Undergraduate Student Teaching Award 受賞者。CMU のページにも載っていますが、一人は日本人の方で Uesugi Shusaku さん。彼の Linkedin を見ると、Apple と Facebook でインターンをしており、卒業後は Palantir で働くとあります。Palantir のCEO は確か Stanford 卒で、インタビューの問題が Google よりも難しいと、就活中に Abhi から聞いたのを覚えています。この Uesugi さんのメッセージが熱いので、いずれこのブログでそのメッセージをご紹介します


左：ISR の Director、William Scherlis 教授から Diploma をいただきました。本物は日本の自宅にあります
右：Ceremony 後、SCS の Jonathan Aldrich 準教授と。MSE では、Analysis of Software Systems のコースを教えていただきました


左：MSE のみんなと
右：ピッツバーグ小町管理会の卒業生 David くんともう一枚


左右：MSE の教授、Eduardo 先生のご自宅で夕食をご馳走になりました

【5月17日（月）】
大学時代の友人に会ってから cave に立ち寄り、現 MSE 生および先生方に会ってきました。Boston には夜9時くらいに戻りました。

MSE および CMU で二つのことを学びました。一つ目は、学力の鍛え方です。ここで私のいう学力とは、自分の中で不安を作り出し、それに向き合い、自ら解決していく力のことのことです。私はとりわけ、なにかに興味を持ってもどこから始めてよいのか分からないことが多く、そのためここでは多少ネガティブなニュアンスを持つ「不安」という言葉を使っています。もちろん、知的好奇心、チャレンジなど、これをどう呼ぶかは人それぞれだと思います。私の言うこの「不安」について言及しているであろうくだりがありました。

身体的、精神的、経済的、そのほかあらゆる不安が今の自分を占めている。不安があるから焦り、不安があるから急ぎ、不安があるから集中できず、不安があるから無理をしようとする。すべてのことが、私の中にある「不安」によって引き起こされている、と気がついた。
平山郁夫－「ぶれない」

この不安は一生消えることがないでしょう。でも、常に不安を生み出し続け、その不安に勇気を持って向かい合い、それを解消することで崩れない足場を作ることができれば、必ず成長していくことができます。自分の築いた内なるプロセスで自らが作り出した不安を次々と解消し、他人が質問してきた時にその人が抱えている不安を理解し、自分の経験を使って少しでもその不安を軽減する手助けができる人であれば、もう胸を張っていいと私は思います。

二つ目は、MSE でともに学んだ友人が全世界のどこかで頑張っているという事実です。彼らの頑張りは MSE および就活を通して見ました。負けるわけにはいきません。

さて、このブログの始まりであった MSE はこれでおしまいです。何かしら熱意はあるんだけどそれが何だか分からない。日本にいたとき、そんな自分を突き動かしてくれたのは、大学時代の友人の熱意でした。そうして、生まれて初めて飛行機に乗って、生まれて初めて海外（米国）に来たのが、2005年。米国に来てもその後の進路はなかなか決まらない。ずっとなにかを考えているんだけど、決まらない。そんな自分を突き動かしてくれたのは、Tony 先生のコンピュータサイエンスおよびソフトウェア工学の教育に対する熱意でした。MSE に入ろうと決心したのは、Tony 先生に出会ったからです。そして2010年、MSE 卒業後の進路を決める上で自分を突き動かしたのは、今度こそ自分の熱意でした。2005年からずっと、数年先がどうなるか分からない人生で、次のステージの準備をするためにいろいろと頭の中でぐるぐる考えてきましたが、ようやく、自分の持っている力を一点集中していく場所が見つかりました。前述した私のいう不安と全世界で頑張る友人がいるという事実、この二つを胸にまたこれから頑張っていきます。そして、これまで支えてくれた家族および親族に感謝します。

とある週末 in Boston　二週まとめて

2010-05-10T11:26:00.017+09:00

最近の週末の過ごし方は、土曜日は IKEA の家具を組み立てるか、Natick の図書館で読み物をするかで、日曜日はボストンに行きます。新しいものを見て仕事が始まる前日に頭に刺激を与えたいのです。先週はガイドブックに載っている徒歩２時間コースを歩破、今週はボストン美術館に行きました。

【先週】
徒歩２時間コースのスタート地点は、Red Line の JFK/UMass 駅。

左：Joe Moakley Park の横を通りながら
右：反対側を見ると、Dorchester Bay のビーチ


左：波も来ています
右：ビーチをある程度歩いたところでビーチ沿いから逸れます。急な坂道を歩いて、Dorchester Heights Monument へ


左：Monument の頂上。独立戦争中、米大陸軍は大砲を運びここを要塞化し、英国艦隊をボストンから撤退させたとのこと
右：Dorchester Heights を下り、またビーチ沿いに戻る。目の前に見えるのは、Lストリート入浴場。ここに戻ってくる途中に「Good Will Hunting」で出てくるパブがあるらしいのだけど、見つからず


左：写真の奥の方に見えるのが出発地点だったところ。ゴールはまだ先
右：Pleasure Bay へと続き、まだまだ歩く


左：歩いて歩いて Castle Island まで来ました
右：ゴール地点の Fort Independence も見えてきました


左：海の護りを固めるために用いられた大砲がまだ残っています。Memorial Day の前はここまでしか入れてくれませんでした
右：Castle Island から見える Boston Logan Airport。日本に帰国するときはここから飛び立ちます。ひときわ高く見えているのが管制塔

歩いている最中は景色を見つつ、数学ガールとプリントアウトした Structure and Interpretation of Computer Programs を手に読書も同時並行で行ってました。風がびゅんびゅん吹いていてページがめくれるめくれる。電子ブックリーダならずっと快適に読めたはず。風の強い日に散歩しながら読書するときは、電子ブックリーダの出番ですよ。ビーチで Kindle で読書していた人もいましたし。ここから歩いて Red Line の Andrew Square 駅まで戻りました。この日はかなり歩きました。

【今週】
今週は外を歩くのをやめ、館内を歩くことにしました。というわけで、ボストン美術館、Museum of Fine Arts に来ました。この時期、エジプトの Governor、Djehutynakht という人物の墓およびそこから発見された日々の生活を表した人形、装飾品、壺などが特別展示されていました。ちなみに、Djehutynakht は je-hooty-knocked と発音するそうです。みんながみんな、どうやって発音するの？って聞いていました。

左：Green Line の Museum of Fine Arts 駅。この駅を探すのになぜか結構苦労しました
右：Museum 外観


左：歌川広重の伊勢海老・芝蝦。説明によると、新年に料理に海老を飾るのは長生きを願うためだとか。海老のまるまった背中を老人のまるまった背中に見立てており、それくらいになるまで生きましょうねということだそうです。知りませんでした
右：インドの神様ガネーシャ。MSE で同じチームだったインドの女の子から、この神様の figurine をもらい今もとってあります


左：古代エジプトの展示セクションの入口
右：館内 2F への階段


左：階段を登りきると、John Singer Sargent の天井壁画が広がります
右：ヨーロッパのアートのセクション、展示品を見ながらデッサンしている方もいました


左：着物に身を包んだ妻をモデルに書いたLa japonaise。モネの作品
右：モネの睡蓮

この日は、エジプト、ギリシャ、インド、日本、中国、特別展示に時間を費やして、ヨーロッパの絵画を見て回る時間がほとんどありませんでした。それと、展示品から流れこんでくる情報を処理しきれず、途中から情報過多の状態に。この道に少しでも通じていれば色々と学びとれるのでしょうが、この日に学びとれたのは芸術作品を味わうための視点が自分に全く備わっていないということでした。まさに豚に真珠 (ﾉД｀)　なんとか作品のメッセージを受け取れるようにせねば・・・

▲帰り、South Station の前。ここ最近の日曜は天気がいいのです

以上、とある週末 in Boston の合併号でした。

On Master of Software Engineering at CMU Part2

2010-05-08T12:49:00.042+09:00

仕事が始まって一か月が経過しました。以前のエントリーを書き終えてから考え始めたことがぼんやり形になってきたので、またここで MSE のことを振り返りたいと思います。

MSE のスローガン「Agents of Change」ですが、これは MSE の卒業生に向けられたフレーズで、ソフトウェア開発を促進すべく、将来の技術の動向をいち早く掴み、組織のビジネスのニーズに合った適当な開発プロセスを取捨選択できるようになれ、という期待が込められています。ただ、20周年の同窓会で集まった卒業生も口々に言っており私も同意していることなのですが、この「Agents of Change」は、いち個人が一朝一夕で実現できるようなことではありません。私も現在、社内のプロセスの一部を学習するだけでヒーヒー言っています。したがって、これはあくまでかなり先のことを視野に入れたキャッチフレーズであることが分かります。え、じゃあデキるかどうかも分からないことを目標に掲げているプログラムなのか、というとそれは違います。その long term の目標を設定したうえで、16か月という短い期間で MSE の先生方が生徒達に体験させたいと考えているのは、ソフトウェアプロセスの守破離の「守」の体得だと私は思っています。それが長い目で見て「Agents of Change」の土台になることを願って。

在学中、Alister Cockburn 氏のアジャイルソフトウェアプロセスに関するプレゼンテーションを見る機会があり、ソフトウェアプロセスの文脈で守破離を使っていることをその時に知りました。「守」は3つの段階の最初のステップで、流派の教えを忠実に守り、それからはずれることのないように精進して身につけよ、という意味です。プロセスの改善のためには、まず何がうまくいっていないのかを知ることから始まります。「うまくいっていない」ことを示すためには、プロジェクトの進捗、チーム全体のアクティビティ、残りのリソースなどの情報を数値化する必要があります。測定できないものを改善することは困難だからです。そこで、適当なプロセスを選び、それに従うことから全てが始まります。「守」では、プロセスに記述されていることを、自分のプロジェクトには無関係のものと分かっていても、entry criteria と exit criteria を定めすべて忠実に遂行します。最初から自分の好きなステップだけを抽出してそれだけを遂行していると、「守」を固める前に「破」を行っていることになり、tailoring と leaving out の違いが不明確になります。それはつまり、プロセスに従って得られる repeatability という恩恵を台無しにしていることになります。狙って外すにしても、上達のためには毎回同じところに外したいですよね。

MSE の学期末プレゼンテーションでは、自分たちのアクティビティについていろいろな質問が飛んできますが、これは分かっているものと分かっていないものに境界線を引くことを求められているためです。そうすることの大切さは、色々なところで目にしています。

自分にとっての≪わからなくなる最前線≫を探そう。
僕 - 数学ガール／ゲーデルの不完全性定理

ある問題を論じるときにはまず
なにが問題なのかを明確にせよ．
それについて確実にわかっているのはどんな点かを明らかにせよ．
よくわかっていなくて、調べる必要があるのはどんな点かを明らかにせよ．
「理科系の作文技術」

すなわち、分からないことが分かるようになるところから始めようということです。チームで行うソフトウェア開発では、メンバーのアクティビティまで把握することが難しいため、役割分担、タスクの担当者、そしてタスクの内容がある程度規定されているプロセスというアイデアを使ってチーム全体で何が起こっているかを把握しやすくします。その上で、何がうまくいっていないのかを知るのです。普通はうまくいかないことを示すのにあまり多くの時間を費やすことはないのではと思います。というのも時間をかけて証明したあげく、明かされたことが「これはできないことだった」とあれば、時間を無駄したという脱力感に駆られるからです。しかし、できない、分からないという、ネガティブに捉えられがちなことを証明するのも重要なこと。そのために MSE ではプロセスに従うという「守」を固め、そのことをはっきり示すことを要求されていると思うのです。何が分からないのか分かりましぇ～んは通りません。

下手糞の上級者への道のりは己が下手さを知りて一歩目
安西先生 - スラムダンク

To prove something, spend half of your time disproving it.
Manuel Blum - Bruce Nelson Professor at CMU

そして、プロセスに従うというベースの上に前回話した5つのコアコースが乗ってきます。これをチーム全体で16か月かけて行い、「守」を徹底し、プロジェクトを成功に導くことをチーム全体で体感することが MSE で学ぶ目的のひとつだと考えています。この成功体験をもとに卒業後は職場等でプロセスの「破」や「離」を体得していけばよいと思います。

MSE は、プロセスに従いソフトウェア開発の枠組みを学ぶプログラムであり、techie じゃない人がいきなり techie になれるようなプログラムではないことをあらかじめ断っておきます。というのも、一度にあまりに多くのことが駆け抜けていくので、16か月間で全てを吸収しきれないのです。なので、MSE で学んだことを使って、CareerCup にあるような会社の就職活動のインタビューに活かすというのは難しいかもしれません。コンピュータサイエンス系の知識や技術を吸収したい人は CMU でいえば CS の undergrad か Information Networking Institute (INI) の方がいいと思います（もちろん、学校に通わずに自分でマスターできればそれはもうカッコイイです）。インド人の元チームメイトから聞いた話では去年の就職活動で、Microsoft、Salesforce.com は INI の生徒を結構採用したそうです。INI では CMU の CS で最凶といわれている OS のコースも選択科目で取れますし、企業側も INI の卒業生を通じてそういうことを知っているんだと思います。とはいったものの MSE の同期も、卒業後は Oracle、Salesforce.com、Qualcomm、Paypal といった企業に進みました。そして何よりも、私は MSE がとても楽しかったです。

さて、来週は CMU の卒業式なのでまたピッツバーグです。半年ぶりにその同期に会えるのを楽しみにしています。

追記：
そういえば、Salesforce.com のオンサイトインタビューに行ったときに、一人のマネージャーが社内で実践されている Scrum / XP の話をしてくださいました。どうそれが社内に広まっていったのかを私が質問したところ、経営陣が押しつけるというよりも、小さなチーム単位で実践し始めそれが後にチームの外にも広がっていったというような答えをいただいた記憶があります。こんなスライドもありました。

悪口、非難はやめましょう

2010-04-30T09:48:00.022+09:00

こんなニュースがありました。

私もかつて人の悪口を言ったことがありました。でもいつからか、悪口を言ったり、非難をしたりしないようにしてきました。だって、他の人のことを悪く言っても状況は何も変わらないのですから。自分で何とかするしかないのです。悪口を言っても状況は変わらないばかりか、「自分が人のことを悪く言った」という事実だけが残り、めぐりめぐってそれがいつか自分に跳ね返ってくるのです。このご時世、メール、ブログ、ツイッター、あるいはボイスレコーディングでそんなことをすれば、悪口が記録として残ってしまいます。そして何より悪口を言った後の、体全身に毒がまわるようなあの感じがイヤでたまりません。

人間である以上、悪口を言いたくなってしまうのはとてもよく分かります。でもそんなときこそガマン。悪口を言ったり、人のせいにしたりする暇があったら、自分で何とかするんだ。これは自分への戒めでもあります。

MIT と Museum of Science

2010-04-25T09:10:00.017+09:00

また Boston に行ってきました。今回の散策エリアは、MIT と Museum of Science です。

前回と同様、出発地点はSouth Station から。 Red Line で Kendall/MIT へ行き、ガイドブックにある "A 45-Minute Walk on the MIT Campus" の通りにキャンパス内を歩いてきました。

最初に MIT Press の本屋に立ち寄って、30分近く立ち読みをしてしまいました。大好きなんですよ、本屋。時間の経過にようやく気づいて本屋を出ようとしたのですが、その1分前に手に取った本の立ち読みが終わってなかったので、つい衝動で買ってしまいました、「The Little Schemer」。竹内郁雄先生の「初めての人のための Lisp」もまだ読み終わってないんだけど、まあいっか。

▲ Frank Gehry 作の Stata Center。これでもかというくらい形状をくずしています。まっすぐ縦に伸びる建築物と比べて、設計時の重力の作用の計算とか相当面倒なのではと思ったりも。

▲ Charles River に面している通りに出ました。景色はとてもきれい。ヨットをしている人もちらほら見かけます。NHK「プロフェッショナル仕事の流儀」で MIT の石井裕教授が出演されていたとき、冒頭のシーンは確かここだったかなと思い出してました。

▲ Walker Memorial。目に飛び込んできたので、パシャリと。

MIT のキャンパスは、外観および作りがモダンな建物が多い気がしました。Harvard のキャンパスは歩いていて歴史をひしひしと感じましたが、MIT のキャンパスは歩いていてなんだかわくわくしました。どちらの大学も勉強するには最高の環境です。

MIT の後は、Green Line で Science Park に行きました。ここには、Museum of Science があります。

▲ The MathWorks は Museum のスポンサーになっており、The MathWorks の社員は入館が無料になっています。ありがたいことです。

▲ これ最高です。正規分布をシミュレートするモデルで、上部にある口から一定の時間間隔でボールが出てきます。ボールは最終的に下部の bin に落ちるのですが、どの bin に落ち着くか、その分布が正規分布に限りなく近くなっています。

写真は撮っていませんが、Apollo 11 の月面着陸40周年の展示もありました。そういえば、宇宙飛行士の山崎直子さんも無事に地球に帰還されましたね。長年の夢を叶えた山崎直子さん、おめでとうございます。ところで、ミッションのサポートにあたっている技師の方たちは、宇宙飛行士の方たちと比べると、ニュースでそれほど取り上げられないと思いますが、技師の方たちの仕事もとてつもなく大変なはずです。展示品の中に、技師の方たちの仕事の一部としてこんな記述がありました。

Keep Congress informed and supplying funds.
Assess the nutritional needs of an astronaut in zero gravity.
Build the Vehicle Assembly Building to house the Saturn V and the crawler to move it to the launch pad.
Pore over the newly created maps of the moon to determine safe, yet geologically interesting, landing sites.
Train the astronauts to be physically and mentally prepared for the trip.
Build the equipment in which to train them.
Manage all the subcontracts and make sure all the parts fit together.

話が逸れますが、MSE の Tony 先生が Science and Technology のキャリアを目指されるようになったのは、確か Apollo space program がきっかけだったと思います。Tony 先生の本「Architecting Software Intensive Systems: A Practitioners Guide」の第9章にもこんなくだりがあります。

Other teams seem to want to perform the perfect analysis. This is only practical in the hallowed halls of academia. In the quest for perfect analysis, these teams will analyze a problem forever. Perfection is the number one enemy of “good enough”and perfection is impractical and not necessary in practice. At ceremonies marking the 35th anniversary of the Apollo 11 Moon landing, Neil Armstrong remarked that when President Kennedy proposed putting a man on the moon "the unknowns vastly exceeded the knowns." This is the nature of technical endeavors. The idea of analysis is not to make every unknown perfectly known, but to identify the important unknowns.

今でこそ、人が宇宙に行くことは十分に実現可能なミッションと考えられていると思いますが、ノウハウが今と比べて蓄積されていなかった昔は、有人宇宙飛行はミッションというより多大な危険を伴う挑戦に近かったのではないでしょうか。何事でもそうですが、前例がないというのは真に大変なことなんだなあと、Apollo 11 の月面着陸40周年の展示の前でそんなことを考えていました。

▲ Green Line で Park Street に向かい、Boston Common を歩いて残り時間を過ごしました。

まだガイドブックには行っていない場所がたくさん載っているので、それらの散策はまたいずれ。

首がががが

2010-04-20T13:02:00.002+09:00

18日、日曜の朝。起きたら首に激痛が走って、とても首を回せる状態じゃなくなっていました。どうやら、モールの中のお店で買った枕が高すぎたようです。寝ていても激痛、起きていても激痛の生き地獄。おかげで、その日に予定されていた同僚の housewarming party に行けずに自宅で療養してました・・・

バスタオルで作った即席枕に取り換えたところ今日の朝にはずいぶんと良くなり、仕事もふつうにこなせたので一安心でした。枕選びは注意が必要です。

P.S.
今頃日本は、花見のシーズンでしょうか。いいですよね。
残念ながら、身近なところでは桜の木は数えるほどしかありません。

▲自宅の近くに立ってる一本の桜の木

3300 / 10990 = ?

2010-04-14T09:32:00.012+09:00

実家の両親と Skype で話をしていて、母から平山郁夫さんの本「ぶれない―骨太に、自分を耕す方法」を勧められました。母は、自分で水彩画や油絵を描き、平山さんの作品を実際に見に行ったこともありました。「この本から学ぶことは非常に多く、ゆうきも読んでみると良い」とのことだったので、Amazon Japan で注文することにしました。

さて、アメリカから Amazon Japan に本の配送を頼むと、エクスプレス便を余議なくされ送料は3300円。送料が普通の本の代金を上回り、 (｀Д´)ｺﾝﾆｬﾛｰとなるわけです。どうせなら他にも本を頼んで、合計額に対する送料の割合を小さくしてしまえということで、今まで欲しくてガマンしていた「Rubyソースコード完全解説」を10990円で一緒に注文してしまいました。青木さんのページで無料で公開していると分かっていても、本は欲しくなるものです。

どうだ、合計額に対する送料の割合は 21% まで落ち込んだぞ。と一瞬勝ち誇るのですが、実際の費用は増加しているわけでorz

送料が1000円以下なら、おそらく「Rubyソースコード完全解説」まで注文することはなかったと思うのですが・・・相対的って怖いです。

iPad 発売

2010-04-06T11:02:00.001+09:00

Natick モール内の Apple Store で、新発売の iPad を見てきました。

左：みなさん夢中です

右：iBook で電子書籍を試し読み

iPod Touch や iPhone で感じた動きやフィーリングが大画面で得られるので、触っていて全然飽きがきませんでした。ただ、個人的にいま欲しいものは ebook リーダーなので、iPad 即購入とはいきませんでした。Amazon の Kindle か、Barnes & Noble の nook か、Sony の Reader か、この iPad か、どれにするか決めかねています。友人に、以前こんな記事も教えてもらって、優柔不断に拍車がかかってしまっていますし。多分、ebook リーダーに対する自分のニーズが自分でも分かってないんだと思います。

・・・しばらくは様子見で。

とある週末の一日 in Boston

2010-04-03T15:15:00.014+09:00

仕事が始まる前に Boston まで行ってきました。

　
左：Commuter rail で、いざ Boston の South Station へ
右：Boston にある5色の地下鉄のうち、まずは Red Line に

　
左：そのまま Orange、Blue と乗り継いで水族館駅へ
右：やってきました New England Aquarium

　
左：館内。元気のいいペンギンがいる一方で
右：やる気のなさそうな（実は、そうじゃないかもしれない）カエルも

　
左：Giant Ocean Tank には推定75歳のウミガメ
右：Tank のてっぺん。海の生き物について説明をするお兄さん

　
左：これから Tank の掃除をするダイバーさんの姿も
右：水族館の外に出て眼前に広がる Boston Inner Harbor

　
左：水族館の前にある Legal Sea Foods 。実は Natick モールの近くにもあります
右：ここでは、いろんなシーフードが reasonable なお値段で食べられます

　
左：この日は、お店の人のおススメ Clam Chowder からはじまり
右：牡蠣をいただき

　
左：その日のスペシャルのサーモンでお腹が一杯
右：昼食後、Red Line の Harvard 駅へ

　
左：足を踏み入れた瞬間に空気が違う気がした Harvard Yard
右：いきなり目に飛び込んできた、ロマネスク様式の Sever Hall

　
左：John Harvard の statue のショットを撮ろうとしたら、なぜかお姉さんまで一緒に
右：Cambridge Common を抜けて

　
左：Harvard University のキャンパスへ
右：ギリシャの神殿かと思いきや

　
左：それは、Law School の図書館。Obama 大統領もここで読み物をしていたのだろうか
右：Cabot Science Center へ足を運ぶ

　
左：ドスンと置いてあった世界初の汎用計算機 IBM Automatic Sequence Controlled Calculator
右：線形代数のカリキュラム。MIT の OCW の Linear Algebra の内容とほぼ同じ？

▲急ぎ足で South Station まで戻り、18:00 の commuter rail で自宅の最寄り駅 West Natick へ

Boston は、歴史を感じるとても居心地のよい街でした。
これまで行ったアメリカの街の中で、一番好きな街かもしれません。

↓ お世話になったガイドブック

On Master of Software Engineering at CMU Part1

2010-03-22T07:46:00.003+09:00

3月13日に MSE の20周年を祝うイベントがあり、それに参加してきました。卒業生や教授陣がゲイツビルの一室に集まり様々なプレゼンを行い、その後に複数の別室で個別のトピックをもとに breakout session が開かれました。去年の12月に MSE を卒業し、今年の2月に就職活動が終わってからこのイベントに出られたので、私としても色々と思うところがあります。ちょうどよい機会なので、複数回にわたって、私自身の MSE プログラムの体験を振り返ります。

▲朝食の様子。中央にいらっしゃるのが Director の David Garlan 教授。こちらから見て教授の右隣に立っているのは 2007年の卒業生で、現在 Microsoft の検索エンジン Bing の Program Manager

▲David Garlan 教授によるオープニングスピーチ

▲CS 学部の Dean、Randy Bryant 教授から、 CS 学部内における MSE の位置づけについて

▲再び Garlan 教授。MSE プログラムの構成を、形式仕様記述言語 Z の schema で記述

▲SEI の Director 兼 CEO の Paul Nielsen 博士から、SEI におけるソフトウェア工学教育の取り組みについて

▲卒業生による、自身の Software Engineering プラクティスについて、その1 （画像はイメージです笑）

▲卒業生による、自身の Software Engineering プラクティスについて、その2

▲CS 学部の Institute for Software Research の Director 、Bill Scherlis 教授から、現代のソフトウェア工学の意義について

▲午後。MSE の Anthony Lattanze 教授（Tony 先生）による、MSE の教育カリキュラムの変遷について

コンピュータサイエンスとは位置づけの異なる、ソフトウェア工学の教育モデルをいかに確立し、時代とともにアップデートしていくか、その難しさの片鱗を感じ取った一日でした。厳しい目をすれば、私はとある方が建てた大学に通い、とある方たちが定めたカリキュラムをこなし、卒業しただけなので、私自身の苦労は、大学やカリキュラムをゼロから作るというものに比べれば、てんで大したことはありません（それでも、私としては物凄い苦労でしたが）。私の就職活動でも同じことが言えます。私はとある方が始めた会社に、その会社が決めたインタビュープロセスを通って入っただけにすぎません（同じく、私としては物凄い苦労でしたが）。大学や会社をゼロから作りあげる人たちは本当にすごいと思います。

一昔前にあった情報専門誌 bit にも、米大学におけるソフトウェア工学の教育モデルについて書かれていたナンバーがあり、MSE もそのなかで取り上げられていました。MSE のコアコースや studio の内容については、私の過去のエントリーを見ていただければ、なんとなく雰囲気はつかんでいただけることと思います。この日のプレゼンでは、なぜそのようなコアコースと studio が導入されたのかについても触れられていました。

▲各コアコースの位置づけ、その1

▲各コアコースの位置づけ、その2

Studio は建築の世界からアイデアを拝借したと言っていました。実際にモノを作りあげていき、その成果物に対してメンターから critique をしてもらう。私は、建築の世界の studio は詳しくないので、建築出身の方で studio の体験のある方はご自身の体験談などをシェアしていただけると嬉しいです^^

MSE には「Agents of Change」というスローガンがありますが、そのスローガンに関する私の見解についてはまた別のエントリで。

就職活動インタビュー反省記録 with Admob

2010-03-08T00:13:00.029+09:00

Admob はモバイル広告の大手の会社で、去年の11月に7億5000万ドルで Google に買収されました。私もちょうど就職活動まっただ中だったので、Admob に履歴書を提出した直後にこのニュースを見て、驚いた記憶があります。MSE の友人から聞いた話では、Google に買収されたあたりから hiring が selective になった可能性があるそうです。もちろん、真偽は定かではありませんが。この5月から Microsoft の Developer になるというインド人の方と話をしたところ、彼の友人のインド人二人が Admob のオンサイトインタビューから自信満々で帰ってきたらしいのですが、結果二人とも reject されてしまったそうです。私の周りでは Admob とインタビューしていた人は一人、オファーを受けた人は一人もいませんでした（インタビューをしていた彼のその後の結果は分かりません）。かくいう私も電話インタビューの 2nd round で reject されてしまいました。

それでは、ここからインタビューの詳細に移ります。

Technical phone interview の一週間前にリクルータの人から電話があり、簡単な会話をしました。専攻は何か、いつ卒業するか、就労ビザは必要か、などなど。会話の最後に、どんなスキルが特に求められるか聞いたところ、「開発言語、ドメインは特にこだわらないから、CS の基礎が備わっていればいいよ」との答えをいただきました。ふむ、Google にも買収されたし、そこと似たような問題が飛んでくるのかなと思い、Google とインタビューをするような気持ちで挑みました。

[1st round interview]
最初のインタビューで出された問題は2つ。私はどちらの問題も CareerCup でおさえていたため、ここは乗り切ることができました。具体的には、

Singly linked list に cycle があるかどうか、どのように判別しますか。また、cycle があった場合、そのcycle の開始点をどうやって見つけますか
100階建てのビルがあります。あなたの手元には同一のたまごが二個あります。たまごは、ある特定の階より上の階から落とすと割れていまいますが、その特定の階およびそれより下の階から落としても割れることはありません。その手元にある二個のたまごを使って、その特定の階を割り出してください。二個とも割れるとゲームオーバーですので、そうなる前に割り出してください。ただし、worst case でたまごを落とす回数が最少になるようなアプローチを考えてください

最初の問題を解くのに、Floyd's Cycle Detection と呼ばれるアルゴリズムがあります。Programming Interviews Exposed の第4章にもありますし、WEB で検索してもすぐに見つかると思います。アイデアとしては、二つのポインタを用意し、list の頭から、ひとつめのポインタを1ノードホップで、もうひとつのポインタを2ノードホップで進めていきます。もしも cycle があれば、それらは cycle のどこかで出会い、cycle がなければ、2ノードホップで進んでいるポインタの方が先に list の末尾に到着するという具合です。cycle の開始点を割り出すには次のようにします。二つのポインタが出会ったら、二つのうちどちらでもいいので、片方のポインタを list の先頭に引き戻してあげます。そうしたら今度は、お互い1ノードホップずつで進めてあげて、次にそれらが出会う地点が cycle の開始点となります。modulo 演算を使うとなぜそうなるのかが分かります。Amazon がこの問題を出したときはその数学的な説明まで聞いていました。

二つ目の問題は正解だけ書きますね。一つ目のたまごを14階、27階、39階、50階、60階・・・と落としていき、それがいずれかの階で割れたら一つ前のステップの階に戻り（50階で割れたら、39階へ戻る）、そこからは一階ずつ増やして二つ目のたまごを落としていきます。これは有名な Brain Teaser の問題ですので、WEB で検索すると「なんでそうなるの？」が見つかると思います（たとえばこちら）。

ちなみに、どちらの問題も Google や Facebook の時のようにオンラインコーディングをすることはなく、すべて口頭で答えを伝えました。数日後に interviewer から "good job!" のお言葉をいただき、2nd round interview に進むことになりました。

[2nd round interview]
このインタビューでは、自分のバックグラウンドを説明するところから始まり、技術的な質問がそれに続きました。

オブジェクト指向プログラミングの概念を説明してください
B-Tree のデータ構造について説明してください。要素を検索するときの実行速度はビッグ・オーで何になりますか？
Model-View-Controller アーキテクチャについて説明してください
4GB のメインメモリで 4 byte の整数 1,000,000,000 個をソートしてください

私が時間内に正しい答えを出せなかったのが最後の問題でした。Mergesort の variant を使って部分的にソートしていくというところまで答えたのですが、そのステップを最後まで正確に説明できませんでした。この合計 4TB にもなる 1,000,000,000 個の整数は 4GB のメインメモリに一度に収まりきらないので、分割してソートしていく必要があります。これには External Sorting というソーティングを使いますが、申し訳ないことに具体的な数値に関しては今計算しているところです（メインメモリに用意する入力バッファ、出力バッファの適切なサイズ、K way merge をする際の multiple pass の数など）。 Database Management Systems の第13章と以下のビデオで勉強中です。

あと、MVC アーキテクチャでひとつ腑に落ちないことがあるのですが、Model と View と Controller の円があってそれらが線で結ばれている典型的な MVC アーキテクチャの図、あの図の view type は何でしょうか。コード依存などを表した static view なのでしょうか、それともシステムの実行時の振る舞いを表した runtime view なのでしょうか？MSE の Architecture のクラスでアーキテクチャの文書化について習ったまず最初のことは、view type をはっきりさせなさい、ということでした。コード依存を表した static view なのか、実行時の振る舞いを示した runtime view なのか、物理的なデバイスの割り当てを示した allocation view なのか？これらをごちゃごちゃにして、アーキテクチャの図を描くと、ソフトウェアシステムの特性の分析が非常に難しくなります。たとえば、変更容易性はコードの変更に関わるということから、static view で議論されるべき特性で、runtime view で議論できる特性ではないと思うのです。逆にパフォーマンスは、runtime view で議論されるべき特性で、モジュールの依存を示した static view で議論されるべき特性ではないと思います。典型的な MVC の図は、データの受け渡しをしているように描かれているため、一見 runtime view なのかなと思いますが、一方で Model, View, Controller の開発、保守を独立に行えるという記述も添えていることがあるため、static view のことを言っているようにも聞こえます。どうでもよいことかもしれませんが、view type をはっきりさせることは、Architecture のクラスで学んだ重要なことのひとつだったもので。"A picture is worth a thousand words" と言われるように図は重要で、一度に多くの情報を与えることができますが、逆に100人のエンジニアがそのアーキテクチャの図を、自分の "a thousand words" で解釈してしまい、その解釈が一致しない恐れもあるわけです。100人のエンジニア全員が同じ解釈をできるよう、アーキテクチャの図を描く際は、箱や線には必ず凡例をつけるなどして、図が示す意味の曖昧さを取り除く努力をしなければいけません。出された問題とは直接関係ないことなのですが、電話インタビューの後にふと思ったことだったのでここに書いてみました。

結果、Admob からは 2nd round の電話インタビューで reject されてしまいました。iPhone 上の開発が活発に行われているとも聞きましたし、Admob とインタビューしていたその友人が興奮気味に語っていましたが今や Google の傘下ですし、もしもインタビューをパスできれば、きっと面白い仕事が待っていることと思います。

他にもインタビューをした会社がありましたが、これにて就職活動インタビュー反省記録を終わらせたいと思います。今後は、Natick や Boston のこと、空き時間に趣味でやっている勉強のこと、その他日々のことなどを書いていきたいと思います。これからもよろしくお願いいたします。

新しい住まいを探して

2010-03-05T16:07:00.012+09:00

日帰りで Natick まで行ってきました。Real estate の方が、新しい住まいを探すのを手伝ってくださったので、こんなところがいいんじゃない？とあらかじめ聞いておいた apartment、condominium をいくつか見てきました。

新しい住まいの周りはこんな感じで、安全かつ静かでとても住みやすそうなところでした。

日本から持ってきた国際免許証の期限が切れており、車も持っていないので、なにかと移動に不便かなと思いましたが、commuter rail の駅がすぐそばにあるのでこれで通勤は問題なさそうです。そして、この commuter rail を使えば45分くらいでボストンに行けるみたいなので、車がない間は public transportation を活用していきます～

住まいの周りは静かでのんびりとした感じなのですが、ルート9 という大きな通りに出ると Natick Mall という大きなショッピングモールもあり、その他 Shoppers World、AMC Theaters といった場所でも買い物をしたり、映画を見たりすることができます。

インタビューの時はバタバタしていて、街を観光する時間がありませんでしたが、今回は自分のペースで見てまわるだけの時間がありました。Natick はとてもいい街で、すごく気に入りました。新しい街に落ち着けるかどうか、最初は若干不安だったもので。気分的には、魔女の宅急便のキキですね。

帰りの飛行機まで時間があったので、AMC Theaters で「アバター」を見てきました。いまさら感が強いですが、これまで映画を見る時間がまったくなかったものでw

新天地が決まりました

2010-02-24T10:09:00.018+09:00

2009年の9月15、16日に行われた CMU でのキャリアフェア Technical Opportunity Conference から始まった私の米国での5か月間にわたる就職活動、やっと終了です。私にとって初めての就職活動だったので、電話インタビュー、オンサイトインタビューとなれないことも多く、景気の悪さも相まって、今までの人生で精神的に一番きつかった体験なのではないかと思います。Undergrad の生徒さんは、長い休みには企業のインターンでしっかり修行をします。そんな経験やコネクションがない私にはさらに不利な戦いでした。

今後の進路ですが、マサチューセッツ州のネイティック（ボストン郊外です）にある The MathWorks という会社で働くことになりました。私にとって生まれて初めてのフルタイムの仕事です。同社は、プログラミング言語 MATLAB およびコントロールシステムのモデリング、解析、シミュレーションを行う Simulink というプロダクトを開発しています。NASA や TOYOTA のエンジニアの方々の中にも MATLAB のユーザさんがいらっしゃるようです（詳細はこちら）。そういえば、早大の理工学部の端末にも MATLAB が入っていたと思いますが、当時はほとんど使った記憶がありません。旧情報学科1年生だったとき、linear algebra の学習でもっとしっかり MATLAB を使っておけばよかったな、と少し後悔です。でも、MSE の最後のセメスターにとった Machine Learning では、課題はすべて MATLAB のプログラミングだったので、MATLAB プログラミングのイントロとしてよい経験になりました。

MathWorks Japan の方ともお知り合いになりたいのですが、こちらの職場にも日本人の方がいないかどうか調べてみたところ、田中一規さんという方を発見いたしました。ハーバード卒業後、物理学博士課程をMITで修了し、現在はフルタイムのマンガ家を目指していらっしゃるという、これまたなんともお会いしていろいろお話を伺いたくなってくる方なのですが、Linkedin を見ると現在は退社され Los Angels の方に移られたようです。あ、ちなみに田中さんの漫画、「マンガ種の起源ダーウィンの進化論」と「よくわかるマンガ微積分教室」を注文しました。早く読んでみたいです！

1月の頭に私にオファーをくださった、ウィスコンシン州マディソンにある会社 Epic Systems には、残念ながらオファーを辞退させていただくと伝えました。KLAS という会社の2009年の調べでは、Epic の医療系ソフトウェアは、さまざまな部門で Best を受賞しています。オンサイトインタビューに行ったときも、熱意があり頭のキレるエンジニアを、私の interviewer を含め、何人も目にしました。そういう環境があるということと、医療という新しいドメインに飛び込むチャンスがあるということを考えると、Epic もとても面白そうなのです。ですが色々考えた結果、今は数学系、工学系のドメインに身を置きたいという理由で The MathWorks に行かせていただくことに決めました。Epic とのインタビュー経験は 100% positive で、体がもうひとつあれば医療系ソフトウェアのドメインもぜひ学ばせていただきたかったくらいです。

就職活動の反省記録はまだ終わっていませんが、現時点でさっと振り返ると、この5か月間は本当に苦しいものでした。そしてそれは 5か月という数字以上に長く感じられました。なんだか、もうひとつ Master を取りに行ってたんじゃないかって思えるくらい。最後のセメスターは、雲ひとつない快晴の日でも世界が灰色に見えていた、なんてこともありました。MSE は宿題の量が多くて大変だったのですが、どちらかといえばそれは息つく暇さえ与えない肉体的なキツさで、計画だててこなしていけば、かろうじてなんとかなると思うのです。評価を下すのも学内の先生なわけですし。これが Ph.D の方ですと、qualification exam の結果、paper が conference に通るか通らないか、thesis の defense、そして CMU の CS だと恐怖の black letter があります。Conference や defense では学外の方からも評価が下されるということもあって、これはもう肉体的にも精神的にも本当にキツイことでしょう ;(

私の就職活動は肉体的に大変なことはなく（ある会社とのインタビューが始まると、インタビューのインターバルはたいてい一週間おきだったので）、キツイのは精神的なものでした。具体的には、インタビューの結果を待っているときのアノ落ち着かない気持ち、会社ごとにインタビュー質問の分野が違うので、種類の異なる問題に短期間で対応するためのコンテキストスイッチの難しさ（ある会社はパズルメイン、ある会社は Servlet の深い知識を問う問題、はたまたある会社はアルゴリズムとコーディングの組み合わせなどなど）、たったひとりの interviewer への第一印象がその会社とのインタビュー結果を大きく左右すること（電話インタビューでは、相手の顔が見えないのでその印象づくりが余計大変でした）、などがありました。そして何より reject されたときに自分のインタビューのパフォーマンスについて一切のフィードバックが得られないことが一番つらかったです。何が上手くいって何が上手くいかなかったのかが知らされないため、そこは自分で推測して次のインタビューに向けて改善していくしかありませんでした。下手をすると、何が悪かったのか分からないまま rejection の無限ループに陥る可能性も。フィードバックがない理由のひとつに、きっと equal opportunity に関わる部分があるからだと友人と話をしたことがあります。たとえば、あるポジションでインド人が5人に必要だったとします。もうすでに5人のインド人をそのポジションに雇ってしまった場合、後続のインド人 candidates には結局 no thank you の通達をしないといけないわけです。でも equal opportunity がある以上、後続のインド人の candidates をある一定数インタビューしなければならないし、reject した本当の理由も伝えるわけにはいかないしで、インタビューのフィードバックでは何も伝えないのが無難というわけです。いわゆる "Sorry, we could not find available positions that match your skill set" という定型文が返ってくるわけですが、色々な事情を考えるとそれも仕方ないんですよね。ただ candidate としては、改善できないからそれはキツイよーということで。

13社とインタビューして、最終的に2社からオファーをいただくことができました。去年は、短期間にいくつものインタビューが押し寄せていたのと、コースワークとの juggling をしなければならなかったということで、結果はもう散々でした。新年になり、就職活動だけに集中できるようになってから風向きが変わった気がしました。また、失敗から学べたことがあったのかもしれません。今回の経験を通じて学べたことは、どんな精神状態にあっても毎日できることが何か必ずある。物事がうまくいっていないときは、ひたすらそのルーチンを続け毎日何かしら学習していくこと。プロのスポーツ選手だって、毎日行っているトレーニングが必ずある。ならば、これからプロのエンジニアになる自分だって毎日もしくは定期的に行うトレーニングが必ずあるはずだ、とずいぶん前から考えていました。オンラインプログラミングコンテストの問題を一週間に決まった数だけ解くとか、数学や CS で馴染みのない分野を本やビデオレクチャーを使って定期的に学習していくとか、そういうルーチンを持つことによって精神的に大変なときでも平常心を持つことできる、と自分に言い聞かせていました。まぁそれでも大変なときは世界が灰色に見えちゃってたりしたんですが・・・

継続が大事なんだと思います。そこでやめてしまったら、成長が止まってしまいます。毎日が無理なら、週に一回。週に一回が無理なら、二週間に一回。二週間に一回が無理なら、月に一回。月に一回が無理なら、二か月に一回。忙しくて自己トレーニングに時間が割けないときは、そのときの忙しさに応じてそうやってインターバルを引き延ばしていけばいいんです。ゼロにしない限り、続けていけば必ず能力は伸びていきます。もちろん、そのインターバルがあまりに長いと、前に学んだ内容をすっかり忘れてしまうなんてこともよく起こります。でも、あんなことを学んだ気がするというインデックスは頭の中に残っているのではないでしょうか。学習において、そういうインデックスがあるとないとではずいぶん大きな差がある気がするのです。二度目にやるときは一度目にやったときよりも若干吸収がよくなりますし。三度目、四度目には、今まで見えていなかった角度から物事を見られるようになるかもしれません。投げ出さずに、またいつか帰ってくるね、くらいに考えていればよいのではないでしょうか。同じことを繰り返すことできっとそれが体に染みついていくはずです。 MSE の同期の方から「直感のレベルに落としこめるまで頑張れ」と教わりましたが、そう、繰り返してそこまで行ければベストですよね。

さて、Tony 先生から去年いただいたお言葉のうち、現実のものになったものがいくつかある気がします：

Yuki、アメリカのいいところは現在あるいは過去のステータスでその人の将来の可能性を否定しないところだ。学歴があってもなくても、今何ができるかで今後道がどう開けるかが決まってくる。やり直しもきく、何度でも。世界でそういうことが許されている国はそんなに多くはないだろう。
Yuki、仕事を選ぶときは follow your head じゃなくて follow your heart だ。毎日エキサイトして職場に行くには、Yuki を "wow！" ってさせてくれるものを選ばないとな。
Yuki、仕事を選ぶときはお金は二の次だ。一番大事なことは、just for fun のアイデアだ。長い目でみたとき自分の成長の伸びに大きな違いがでてくる。

でも Tony 先生、選ばないとな、とおっしゃっても簡単に選べるようになんかならないですよ。゜（＞д＜）゜。

私にとっては、留学の最後の最後で一番厳しい試練が待っていましたが、なんとか乗り越えることができました。今は本当に嬉しいです。そして、今になってやっと卒業の実感が沸いてきました。ここまで支えてくださった方々に対して、深く感謝いたします。私なりにできることがあれば、サポートをしてくださった方々を含め、周りの人たちに何か恩返しができればと考えています。

仕事開始まで少し時間がありますが、残念ながら日本へは帰国できないようです。というわけで引っ越しの準備を少しずつ始めようかと。トータルで2年半慣れ親しんだピッツバーグを離れることになります。新天地は、ネイティックです！！

"Never give up and good luck will find you.”
Falcor - The Neverending Story 1984

【他の方のインタビュー体験記】

就職活動インタビュー反省記録 with Microsoft

2010-02-21T11:05:00.038+09:00

Microsoft とのインタビューも Facebook のときのインタビュー同様、非常にあっさりです。実際に起きたことはこんな感じです。私の履歴書に目をとめたリクルータからメールをいただき、CMU のキャンパスで最初の面接をし、そのあと三週間経っても何のアップデートもなかったので、こちらから現状を教えてくれるように頼んだところ、現状を確認するから一週間待ってほしいと連絡がきました。ところが、四週目の終わりになってもまだ返事が来ないので、再度メールをくださいと催促したところ、五週目の終わりに

In light of our current opportunities, we will be pursuing other candidates whose background and abilities more closely match our needs at this time.

というメールが返ってきました。Reject するだけなのに何でそんなに待たせるのだー、という思いで一杯でした。CMU のキャンパスで Microsoft とインタビューした MSE の友人は他に二人いたのですが、彼/彼女は面接から一週間で rejection メールをもらっているんです。私は、あれ？rejection メールが来てないのならもしかして・・・と思いました。というのも Salesforce.com のインタビューでは、まず reject する candidates に通知のメールを出し、offer を出す candidates に対しては時間をかけて最後の最後に通知のメールを出すという形をとっていたので。Microsoft も同じかな？と思いきや、完全な糠喜びでした orz

Microsoft に履歴書を出したのは、9月10日に CMU で開かれた Company Presentation のときでした。それ以降は、Microsoft の hiring process は非常にゆっくりで、私がリクルータから最初のコンタクトをいただく11月2日まで、Microsoft とインタビューをしている人を他に見たことがありませんでした。通常、最初のインタビューを行う時点で candidate は自分がどのポジションでインタビューをしているかをあらかじめ会社側から通達されています。ここまでの私の反省記録でいえば、Salesforce.com、Google、Facebook、Yahoo とのインタビューでは、最初の face to face もしくは電話インタビューの時点でどのポジションでインタビューをしているか、私はすでに分かっていました。しかし、Microsoft とのインタビューでは、最初のインタビューの時点で私がどのポジションでインタビューしているか、事前にそれは知らされませんでした。代わりに、インタビュー前にリクルータからフォームが送られてきて、自分の希望をそこに書き込む形式になっていたというわけです。Microsoft のオファーまでのインタビューは、CMU でのキャンパスインタビューが一回、Redmond にある本社でのオンサイトインタビューが一回となっていました。Salesforce.com 同様のプロセスですね。

当日のインタビューは CMU の Career Center で行われました。このインタビューの時間が30分と短くかなり驚きました。私だけそんなに短いのかなと思ったら、他の candidates のインタビューのスロットも30分で固定されていました。30分間で interviewer とやりとりしたことは、自分のバックグラウンドの説明と、事前に記入したフォームに関する内容、そして簡単なテクニカルな質問でした。そのフォームで、私が Software Development Engineer (SDE) と Software Development Engineer in Test (SDET) に等しいスコアを与えていたのと、私が過去にパートタイムでテストの経験があるという理由から、SDET がいいのではという方向に話が進み、テクニカルな質問では Salesforce.com のときとまったく同じ問題が出されました。文字の並びの順をリバースするプログラムがあったとして、考えられるテストケースを挙げられるだけ挙げてねという問題です。一度解いた問題だったので、前回の Salesforce.com のときに interviewer に提示した答えと今回新たに考え出したプラスアルファのものを追加して interviewer に説明しました。この30分のインタビューが終わった後、「こんな短い時間で candidate の何が分かるんだろう？」と私は思いました。

ちなみに、この文字の並びの順をリバースするプログラムはインタビューでは典型的な問題らしく、Programming Interviews Exposed の6章にも載っています。Salesforce.com でも聞かれ、Microsoft でも聞かれ、そして Google のインタビュー説明会で私がグッズをゲットしたときに出された問題もこれでした。というわけで、米国で Software Engineer のインタビューをするときは、Programming Interviews Exposed と CareerCup に掲載されているその会社の問題は少なくともおさえておくとよいですね。

結局、五週間後に私は rejection メールをもらったわけですが、その間「もしかしたら」という思いから、最後のセメスターのコースワークをこなすと同時に、CareerCup にある Microsoft の問題を 650 題近く、がむしゃらに解きました（ただし、類似および重複問題がかなりあります。いま見たところ、その問題数は増え続け732題になっています）。これを機に、インタビューで聞かれるテクニカルな問題のパターンを少しだけ把握することができた気がします。

Wikipedia のページをまるまる割いて取り上げられるほど Microsoft のインタビュー形式は有名で、他社のインタビュープロセスのモデルになっているみたいです。本エントリの最後に、他の方の Microsoft のインタビュー体験記を載せておきます。一人の方は offer を受け、それ以外の方は reject されているようです。しかしその方たちは、reject されてもなおこれだけの体験記を残すというのは、それだけ Microsoft が software engineer にとって夢のような会社として見られているということなのではないでしょうか？内情をご存じの方からは違う答えが返ってくるかもしれませんが。まだ未読の SHOWSTOPPER!（日本語版：闘うプログラマー）をちょっと覗くと、NT 開発のプロジェクトは想像を絶するものだったようですし・・・

Microsoft とのインタビューでは一抹の希望を抱いていましたが、冷静になって考えてみると、私はこちらの undergrad の学生さんのようにインターン経験もないし、個人でも impressive な achievement もないしで、Microsoft がまともに取り合ってくれるはずがないのです。やっぱり、なぜリクルータが私の履歴書に目をとめたのかなぁということになるわけなんです。chokudai の名で知られる高橋直大さんのような方は、TopCoder の Red Coder で、Microsoft の Imagine Cup 2008 でも世界第3位に輝いているわけですし、そういう方であれば十分チャンスがあると思うのです。私はもっともっと修行を積まないといけません (*`д´)ｶﾞﾝﾊﾞﾙｯｽ!!

【他の方の Microsoft インタビュー体験記】

就職活動インタビュー反省記録 with Yahoo

2010-02-13T21:08:00.017+09:00

Yahoo とのインタビューは、明らかに失敗だったとインタビュー中に分かったケースです。というのも、電話インタビューの最中に私のプリペイドの携帯の残高がゼロになり、会話が 8 分も途切れてしまったからです。前回残高を追加したのが夏学期の途中だったので、残高をチェックするのを忘れて、電話インタビューをしてしまいました。これは問答無用でアウトです ;( だって、interviewer からしてみれば、「おいおい、こっちは貴重な勤務時間を割いてインタビューしてるのに、残高ゼロで会話できませんってどういうことだよ。スキル以前の問題じゃないか」て思いますもんね、普通。

このインタビューに関しては、反省すべき点は火を見るより明らかなので、以降は Yahoo にアプライした経緯やインタビューで聞かれた問題を紹介したいと思います。

私がアプライしたのは、Back End Engineer、Quality Assurance (QA) Engineer のふたつのポジションでした。Salesforce.com に続き、私が Quality Assurance のポジションにアプライをしている理由は「エンジニアは、その会社が作っている製品のことをまず熟知すること。そのためには製品をテストして内部の構造を理解することから始める」ということをいつも念頭に置いているからです。この言葉は実は受け売りで、私が 2006 年に CMU にいたときに Boeing Company の Technical Fellow、John Vu 博士のレクチャーを受け、そのときに学んだ言葉です。もちろん鵜呑みにしているわけではなく、私なりに自分の能力を考慮して、納得した上でそれを受け入れました。これまで実務経験のない私に特に当てはまる言葉だと思っています。

さて、Back End Engineer のポジションでインタビューを受けるよう Yahoo の女性のリクルータから連絡がありました。上記で述べたように、本当は QA のポジションから始めたいとは思いましたが、Back End Engineer もトライしたいポジションだったので、そのまま OK の返事をしました。

Back End Engineer の電話インタビューは全てアルゴリズムとデータ構造絡みでした。全ての問題をコードにしていると、このエントリーが長くなってしまうので、今回は聞かれた問題を覚えている限り列挙することにします。

配列、リストについて、以下の操作の実行速度の違い：要素の検索、要素の挿入、要素の削除
Singly linked list の途中に要素を挿入するコード、途中の要素を削除するコードをそれぞれ読み上げてください
Singly linked list の途中の要素を削除したいと考えています。ただし、その削除する要素およびそれ以降のノードにしかアクセスできません。その要素をどう削除しますか？そして、あなたの考えたアルゴリズムが機能しないケースがあるとすれば、それはどのようなときですか？
Binary search のコードを読み上げてください
Vector について、capacity と size について説明してください
Vector は capacity いっぱいに要素が格納されると、次の要素の挿入時に capacity が倍になるように実装されているケースが多いです。これはなぜですか？

（プリペイド電話の残高がここでゼロになり、会話ドロップ。インタビュー再開まで8分かかる orz ）
Hashtable を実装するとして、そのアウトラインを説明してください
Hash function の持つべき特性を考えられるだけ挙げてください
文字列の中で、重複のない文字のうち、最初に現れる文字を返す関数を設計してください。"abcbbad" であれば、'c'　が返されます。なぜなら、'c' は first non-repeated character だからです。複数のアプローチを考えて、そのトレードオフを考えてください。そのうちひとつのアプローチをコードで書いて、私に読み上げてください

6つめの問題、 capacity いっぱいの時点で要素を挿入する際に vector の capacity を倍にする理由というのは、他のインタビューではあまり聞かれないものでした。これは Introduction to Algorithms （この CLRS 本、Thrid Edition も出ましたね！）の第17章 Amortized Analysis で取り上げられていますので、そちらを見ていただけると詳しい説明が載っています。つまるところ、長い目で見てその操作のコストをコンスタントにするために、一連の操作の途中でコストの高いセットアップをする必要がある。でも、その痛恨の一撃のようなセットアップはたまにしかやって来ないので、それを操作のコストだ、と決めつけるのは too pessimistic だよね、ということです。Amortized Analysis については、私が去年の春にとったアルゴリズムのクラスにも教材がありますし、MIT の OCW でもご覧になれます。

Yahoo からオファーを受けた友人は二人います。二人ともインド人で、一人は QA のポジションで、もう一人は Developer のポジションでした。どちらも、電話インタビューが二回、onsite インタビューが一回。そして、CareerCup の Yahoo の問題を事前に解いていったら、似たような問題を聞かれてしっかり答えられたと言っていました。ただ、QA のポジションでオファーを受けた彼は、最終的には別の会社を選びましたね。私？インタビューの問題にはきちんと答えましたが、結果は当然アウトですよー。QA のポジションでもインタビューできないかどうか、インタビューの最後に interviewer に聞きましたが、結局スルー ;(
No second chance for a first impression ということでした。

How to Prepare for Google Software Engineer Interviews

2010-02-03T10:09:00.032+09:00

今日、CMU にある Google ピッツバーグオフィスでタイトルの通りのセッションがあったので参加してきました。11月の時点で reject されているにもかかわらず、今日のセッションに私が参加した理由は次の二つです。インタビュープロセスを再確認するためと、以前のエントリーに書いていない追加情報がもしかしたらあるかもしれないと思ったためです。結論からいいますと、新しい情報はほとんどありませんでした。

セッションの対象は、Google の今年のサマーインターン、およびフルタイムにアプライする学生さん。今日集まった学生さんは CMU からと University of Pittsburgh からで、undergrad, master, Ph.D すべての学位が混ざっていました。

すでに CareerCup の Google Software Engineer Interview Guide を購入された方は（このガイドが出たのは私が Google に reject された後でしたが、それでも構わずに購入しました）、今日のセッションで説明されたことはおそらくすでにご存じのことと思います。

以下がプレゼンのまとめです：

全体の流れ
1-2 round phone interviews ⇒ 3-4 round onsite interviews ⇒ offer
インタビューで聞かれること
バックグラウンドの説明、技術面のアセスメント
※パズル問題は出さないそうです (they don't reflect your coding ability)
技術面のアセスメント
"きれいな"コードを書けるかどうか、アルゴリズムとデータ構造の知識が定着しているかどうか、分析能力があるかどうか、ソフトウェアの設計能力があるかどうか
Ph.D 生を対象にした Customized Interview
研究に関する質問、基本的なアルゴリズムとコーディング能力
※ You will write code in interview と書いてありました

コーディングはすべてホワイトボード上で、です。インタビューにむけてコーディングの練習をする際は、コンピュータ上ではなくホワイトボードで練習したほうがよいとのアドバイスもありました（上記の CareerCup のガイドにも書いてあります。syntax highlighter や code complete の機能があるとないでは、確かにかなり違います）。そして「Don't use pseudo code - we want actual code」をものすごく強調してました。シンタックスについては、それほどとやかく言わないから、とにかく working code を書いてくださいだそうです。

プレゼンの最中は、かなーり、clean code, clean code, clean code あるいはalgorithm, algorithm, algorithm を強調していました。私が去年の春にとった undergrad の 15451 Design and Analysis of Algorithms もレビューサイトのおススメとしてプレゼンに出ていましたが、私は、実際のアルゴリズムの実装に関しては、もしかしたら TopCoder のアルゴリズムチュートリアルのほうがいいかなと思いました。15451 は実装よりも理論を重視したコースでしたので。

その後 10人くらいのグループに分かれ、Google のインタビューに出てきそうなサンプル問題を皆で解くというセッションになりました。で、私が一番早く解いて、ホワイトボードにコードを書けたので、Google グッズをもらえました :)　だって、これで解いたことのある問題だったんですもん。

▲やや大きめのバッグ

でも、ふと思いました。candidate にしてみれば、知っている問題であれば早く解けるし、初めて見る問題であれば解くのに苦労してしまう。Candidate の問題を解く際の応用力をフェアに測るのに interviewer はどうやって出す問題を選んでいるんでしょうか。まあ入試でも、出題される問題が変わると合格者の顔ぶれも変わるなんていうのを聞いたことがありますし、問題をすでに知っている知らないも実力のうちなのでしょうか。でも、それだとあまり応用力のチェックになっていない気もしますし難しいですよね。でも、ひとつ言えるのは、本当にすごい人は出される問題に関わらずなんでもかんでも解いてしまいます。

TopCoder で、自分が解けなかったときにいつもコードを読ませていただいている Red Coder の Petr さん、tomek さん、SnapDragon さんなんか、Level 3の問題で何がきてもガンガン解いてます。本当にこの方たちアリエナイ。特に SnapDragon さんアリエナイと思ったのは、SRM 234 - Div 1 - Level 3 の問題 HowUnsorted の解き方。ノートにコードを一行一行書き写してプログラムの動きを追うと、確かにそれで解けてるんですけど、・・ええ！？みたいな感じになります（詳細はこちら）。それでも、私の中で一番アリエナイのはやっぱり Petr さん。どなたか、SRM 245 - Div 1 - Level 3 の問題 SandTimers の Petr さんのコードがなぜそれで問題を解くコードになっているのか、分かる方がいたらどうか教えてください m(_ _)m

Google では、Ph.D の方でも仕事でがりがりコードを書くらしいので、そちらの方面が好きな方は絶対に面白いとプッシュしていました。Ph.D はその専門のエキスパート。その能力をプロジェクトで十二分に生かすため、研究の分野とうまくマッチするプロジェクトで仕事ができる環境があるとも言っていました。

えと、まとまりのないエントリーになりましたが、今日のセッションはそんな感じでした。

就職活動インタビュー反省記録 with Facebook

2010-01-28T10:00:00.046+09:00

さて、Facebook とのインタビューは、わけが分からないまま始まり、わけが分からないまま終了しました。

インド人女性のリクルータが、「ハロー、Software Engineer, Products のポジションでインタビューしてみませんか」と突然電話をしてきたので、私が「はい、ぜひお願いします」と答えると、その場でいきなり問題を出してきました。

リクルータ：「Java で、サブクラスでのメソッドの override を禁止するために、どんな修飾子をつける？」

私：「final ですか？」

リクルータ：「そうね、じゃあ class に final をつけるとどうなる？」

私：「そのクラスからの継承が禁止されるのでは？」

リクルータ：「そう。じゃあ今度は、バブルソートの best case の実行速度と worst case の実行速度は？」

私：「Worst case は O(n^2) で、best case はおそらく全部ソートされているときで、あれ？でもその場合も一応要素同士の比較が生じるから、best case も O(n^2) ・・・だと思います」

リクルータ：「ほんと？」

私：「はい」

リクルータ：「Best case は比較も発生しないから O(n) なの。じゃあ、これが最後の問題。配列に 1000 個の整数があって、ソートされています。ある要素を探したいときに最悪何回 lookup する必要がある？」

私：「えと、バイナリーサーチをしますから、lg(1000) = 3 lg(10) で、最悪10回の lookup が必要だと思います」（lg は log base 2 の略記です）

リクルータ：「はいここまで。いいでしょう、では、次のインタビューに進んでもらいます。電話インタビューのスケジュールを決めますので、あいてる日付と時間をメールしてください」

私：「分かりました」

という感じでイントロが終わり、後日、 Google の 1st round の電話インタビューと同じ日に Facebook の電話インタビューもスケジュールされました。で、リクルータさんとの電話のあとに Software Engineer, Products の job description を見てみると、PHP と Python、Javascript の知識を有していることとあります。あれ？どの言語もかけだしで、実際の開発で使ったこともないから、履歴書に載せてないんですけど。なんでコンタクトしてきたんだろ？と不思議に思いました。

当日、Facebook の newsfeed の開発をしているというエンジニアのお兄さんから電話がかかってきました。履歴書の自分のバックグラウンドを話したあと、お兄さんは「じゃあ、Yuki の PHP の開発経験を聞かせてもらえるかな？」とたずねてくるので、私は「いえ、PHP での開発経験はありません。」と答えました。お兄さんは「そっか、じゃあ Python と Javascript、仕事で使った経験は？」と聞くので、「いえ、それもありません。」と答えると、お兄さんは「あ、そう・・・」と言って「それじゃあ、アルゴリズムとコーディングの問題に移ろう」という感じで話を次に進めました。もうこの時点で、私はなんだか場違いな雰囲気をひしひしと感じていました ;(

アルゴリズムは、配列とリストに関する基本的な問題でした。コーディングはFacebook のサイト上に特別に用意されたページで行いました。自分のアカウントを使ってログインし、お兄さんが関数のプロトタイプを書いてくれました。問題は C で singly-linked list をリバースしてね、ということでした。条件として、iterative と recursive の両方のバージョンを書いてほしい、とも言われました。そのときのコーディングの痕跡が残っていたので、そのままひっぱってきました。

// provided by the interviewer
typedef struct Node {
    int data;
    struct Node *next;
} Node;

// iterative version
Node *iterativeReverse(Node *head) {
    if (!head) return NULL;
    if (!(head->next)) return head;
    Node *curr = head;
    Node *prev = NULL;
    Node *temp = NULL;
    while (curr) {
        temp = curr->next;
        curr->next = prev;
        prev = curr;
        curr = temp;
    }
    head->next = NULL;
    head = prev;
    return head;
}

// recursive version
Node *recursiveReverse(Node *head) {
    if (!head) return NULL;
    if (!(head->next)) return head;
    Node *tail = recursiveReverse(head->next);
    head->next->next = head;
    head->next = NULL;
    return tail;
}

例によって、また再帰バージョンで頭がこんがらがりかけた記憶がありますが、Google との電話インタビューで再帰が絡んだキューの問題を解いた後だったので、この問題は自力で解けました。こうして最初の電話インタビューが終わり、その4日後に rejection のメールが来ました。私としては、むしろ驚くこともなく、そもそもなんで最初にコンタクトしてきたんだろうと頭の中が「？」でいっぱいでした。

というわけで、今回はあまりつっこんだ反省記が書けずに申し訳ないです。Facebook とインタビューしていた友人もほとんど知らないので、具体的なインタビュープロセスすらよくわかりませんが、職場のここが好きここが嫌いをぶっちゃけているこんなサイトやあんなサイトを見てみると Facebook の評価はかなりいいですね。日本法人も設立される予定ですし、興味のある方はチャレンジしてみる価値ありです！

就職活動はもう少しだけ続きます。なので、ピッツバーグにはもう一か月くらいいると思います。

P.S.
完全に時期はずれですが、MSE の Tony 先生から去年の Thankgiving の写真をいただきました。Tony 先生宅にお邪魔したのは3回目で、3回お邪魔した生徒は私が初めてだそうで。毎年お世話になり本当にありがとうございます。

▲恒例の集合写真

ぱずるぱずる

2010-01-22T10:17:00.016+09:00

今回は反省記録から少しはずれて、NY のとあるベンチャーキャピタルとのインタビューで出された質問にタックルします。

CMU には TartanTrak というキャリアサイトがあります。Linkedin や Monster.com 同様、そこに履歴書をアップロードしておくと、会社の側から「あなたの履歴書見つけました」という形でコンタクトしてくる場合があります。12月の頭に、そのベンチャーキャピタルからコンタクトがあって電話インタビューに応じたことがありました。社員数10人強の少数精鋭の会社で、インタビュー質問もやはりタフでした。残念ながら、答えを出すのにかなりの助けを借りてしまい、電話インタビュー 2nd ラウンドで落ちてしまいましたが、質問が面白かったのでここに載せてみます。両方とも 2nd ラウンドで出された問題です。

[問題1]
ここに正六面体の普通のサイコロが2つあります。それぞれ A, B と呼びましょう。A のサイコロは、1つの面が赤く塗られ、残り5つの面は青で塗られています。B のカラー分布は分かりません（ただし色は赤と青のみと考えてよいです）。この2つのサイコロ A, B を使って次の実験を繰り返しました。一回の実験で行うことは、両手にサイコロ A, B を持ち、同時にそれらを転がし、出たそれぞれの色を確認することです。さて、実験の結果、半分の確率で A と B の色は一致し、半分の確率で A と B の色は一致しませんでした（実験回数を限りなく多くしているから半分の確率と言ってさしつかえないと、実際のインタビューでも言われました）。さて、この実験結果から B のサイコロのカラー分布はどのようになっていると思いますか？

[問題2]
ここに100個の文があります。それぞれ 0 から 99 までナンバーが振られており、次のようなことが書かれています。

文 0 「この中に正しい文はたかだか 0 個存在する」
文 1 「この中に正しい文はたかだか 1 個存在する」
文 2 「この中に正しい文はたかだか 2 個存在する」
・・・
文 98 「この中に正しい文はたかだか 98 個存在する」
文 99 「この中に正しい文はたかだか 99 個存在する」

さて、正しい文はいくつあるでしょう？

問題2は、ぱっと見た感じだと結城先生の数学ガール第3巻の冒頭にある問題「正直者は誰？」に少し似てるかもしれませんね。

就職活動インタビュー反省記録 with Google

2010-01-19T11:16:00.061+09:00

まず本エントリーですが、Google とのインタビュー記録を見返してみると、non-disclosure agreement に関する記載があったので、質問された問題をここに書くことはできないようです。なので、かわりにインタビュー問題の分野、あるいはその類題を載せたいと思います。

Google とのインタビューということで、できればたくさんのことをお伝えしたかったのですが、力不足から phone インタビュー 2nd ラウンドで撃沈してしまったため、それほどたくさんのことはお伝えできないと思います。他の方のブログなどをあたってみると、より詳細なインタビュー体験記が見つかるかもしれません。good coders code, great reuse というブログのこのエントリーは Google とのインタビューの準備からオンサイトインタビューまで幅広くカバーしているので私のこのエントリーよりずっと参考になると思います。

いずれにせよ、私自身のインタビューをふりかえってみようと思います。

最初に Google のリクルーターから連絡をいただいたときは、Associate Product Manager (APM) のポジションでインタビューをしないかと言われました。製品の発案や機能設計も非常に面白そうだと思いましたが、開発の方により興味があった私は、リクルーターに Software Engineer のポジションでインタビューができないかどうかたずねました。すんなりOK を出していただき、最初の電話インタビューがその一週間後の11月4日にスケジュールされました。

[1st round interview]
このインタビューでは、履歴書に書いてある私のバッググラウンドの話しを皮切りに、配列から特定の要素を見つけ出す問題、ソーティングアルゴリズムの知識を問う問題、ビット操作に関するコーディングの問題がありました。コーディングは interviewer が送ってきたリンクをたどり Google Doc をシェアし、そのドキュメント上でコーディングを行いました。ビット操作で出された問題は、実際に出された問題とは違いますが、たとえばある正の整数 x が2のべき乗（1, 2, 4, 8, ・・・）であるかどうかを調べるにはどうしますか、というような感じの問題です。いくつもアプローチがあると思いますが、ここでは

if ((x & (x-1)) == 0) {
   System.out.println("power of two!");
}

というようにしてみます。2のべき乗の2進数表記をのぞいてみると、ビットが1になっているポジションはひとつだけで、それ以外のポジションのビットはすべて0になっています。10進数で考えてみても、100や10000といった10のべき乗の数は、全桁のうち1が一か所にしか現れておらず、それ以外のディジットはすべて0ですよね。この if 文はその特性を使っているというわけです。ビット操作は Google のインタビューでわりとよくきかれる問題だと CareerCup （前回の投稿の最後に紹介したサイトです）に書いてあったので、Hacker's Delight などを読みこんでいる方はこの分野に強いのではないでしょうか？携帯電話を肩と耳にはさみつつ、考えていることを声に出しながらのコーディングというのは、非常にやりづらかったですが、最初のインタビューは突破できたようで、次の電話インタビューが翌日にスケジュールされました。

[2nd round interview]
翌日のインタビューは、別のエンジニアとの電話インタビューでした。履歴書の話をすることなく、いきなりテクニカルな質問が飛んできました。スレッドプログラミングの注意すべき点、TCP/IP の基礎知識、そしてまた Google Doc の上でのコーディングでした。コーディングの問題は、集合を取り扱う問題とキューに関する問題でした。集合を取り扱う問題で、私はインデックス i と j を取り違えるミスをしてしまい、それにしばらく気付かずに結構な減点対象になった印象を受けました。そして、キューの問題では、それを解くのに10分近くかかってしまい（電話で考えを口に出しながらだったので、余計考えられませんでした）、もはや interviewer にとってそれだけかかってしまうのは許容限度外のようでした。案の定、3日後に rejection のメールが ;-(

ですが、そのキューの問題というのが非常に面白かったので、ここでは出題された問題に非常によく似た問題を考えます。それは、

スタックをひとつだけ使って、キューに対する操作 enqueue と dequeue をシミュレートしてください。

というものです（実際の問題もスタックひとつという制約つきでした）。以前、スタックを二つ使ってキューをシミュレートというのは解いたことがありました。キューは先入れ先出しのデータ構造、スタックは後入れ先出しのデータ構造です。enqueue は特に問題ないのです。スタックにそのまま要素を突っ込んで、はいこれが enqueue だよ、と言ってやればいいのですから。問題は dequeue の方です。最初に突っ込んだ要素を最初に取り出さなくてはいけません。ですが、スタックが二つ使えれば次のようにして dequeue をシミュレートできます。最初にスタック A に追加した要素 x を最初にとり出すためには、その上に乗っている要素すべてをもうひとつのスタック B にドンドンと積んでいって、最初の要素 x をスタック A から pop できるようにしてあげればいいんですね（積み重なっているお皿の山から一番下にあるお皿をとりたいとき、上に乗ってる他の皿を脇へドンドンと積んでいく感じです）。ところが、この問題ではひとつのスタックしか使えないので、dequeue の際にどうやって底に沈んでる要素を最初にとりだすんだろう、うーんとなってしまうわけです。ふむ、こんな風にしてみてはどうでしょう？


import java.util.Stack;

public class QueueWithStack<E> {
   private Stack<E> stack;
   public QueueWithStack() {
       stack = new Stack<E>();
   }
   public boolean empty() {
       return stack.empty();
   }
   public void enqueue(E item) {
       stack.push(item);
   }
   public E dequeue() {
       if (stack.empty()) return null;
       else return recurse();
   }
   private E recurse() {
       E top = stack.pop();
       if (stack.empty()) return top;
       else {
           E item = recurse();
           stack.push(top);
           return item;
       }
   }
}

21行および24-32行にあるように、再帰を使うと底にあった要素をボンボンと上へ押し上げていけるんですね。こうすると、先入れ先出しがスタックひとつでも可能になります。実際に出された問題もこれに似たもので再帰が決め手となりましたが、10分は長かったんだなぁ・・・

話は変わりますが、私は再帰関数の定義がかなり苦手です。というのは、関数定義の中で自分を呼び出すというのを頭の中で考えていくと、こうロシアのマトリョーシカ人形のように中へ中へと吸い込まれていってしまって関数の全体像がいつも見えなくなる感じがするからなんです。でも、いつだったかこのサイトの問題を解いてみて再帰が少しだけ怖くなくなった気がします。そのサイトに、再帰に関する私の好きな引用があります。

Trust that the recursive calls return correct output when fed correct input -- make the leap of faith. Look at the partial results that the recursive calls give you, and construct the full result from them. If you try to step into the recursive calls to think how they are working, you'll go crazy.

上記の dequeue もこれにあてはまりますよね。再帰が一番底の要素を返してくれることを信じたうえで自分のすべきことは、底の要素を pop できるように脇によけておいた要素を元に戻し、そしてリレーされてきた一番底の要素を今度は自分が返す、ということになります。

かくして Google とのインタビューは無残に散ったわけですが、新たにコンピュータサイエンス力をつけたり、オープンソースの世界で経験を積んだり、Google Code Jam にチャレンジしたりして、またいつかインタビューにトライしてみたいです！ただしオファー獲得までの道は半端じゃなくきついので、これ以上ないくらいの自信がついてからの話ですが。あ、いきなり転職を考えているとかそういうことではないですよ？

CareerCup によれば、Software Engineer のポジションで電話インタビューを受けた candidate のうち onsite に呼ばれるのは約35%で、オファーが与えられるのは、その中の約25%ほどとか。つまりインタビューを受けた人のうち、約9%の人しかオファーをもらえないということになります。APM のポジションで onsite に行ったインド人の友人が一人だけいましたが、やはり reject されてしまいました。APM のインタビュープロセスもどうやら非常に selective で厳しいようです。CareerCup によると、Google の Software Engineer のインタビュープロセスは、interviewer が candidate のパフォーマンスに対し、1.0 から 4.0 のスコアリングをし、それを hiring comittee にコメントを添えて投げるそうです。Hiring comittee も candidate がすべての分野で高得点を取るのは難しいことはわかっているようですが、複数の interviewer が candidate に対して同じ赤旗をあげると（コードが読みづらい、基礎知識がなってないなど）、hiring comittee は直ちに no-hire サインを出すそうです。私もこれにあてはまったのではないでしょうか。あと、突出した能力がある candidate の方が hiring comittee の目を引くとも書いてありました。すなわち、4つのインタビューのスコアが全て3.1という candidate よりもスコアが 3.6, 3.1, 3.1, 2.6 という candidate の方が better ということらしいです。どこまで本当かどうかは分かりませんが、著者は、実際に Google の hiring comittee に属していた経験もあるとのことなので、でたらめな情報ではないと思います。

最近は、こんなニュースもありましたし、本当に Google は超人の集団だなぁと思い知らされます。何度もインタビューをトライしてみたいと思わせてくれる魅力のある企業ですよね。

就職活動インタビュー反省記録 with Salesforce.com

2010-01-13T09:57:00.063+09:00

まず最初に、就活の近況をお伝えします。

クリスマスの直後は、オハイオの会社からオファーを rescind したいとの連絡があり、雇用の件を白紙に戻されるという事態になっていました。どうも経営が芳しくなかったらしく、私がインタビューに行った後、会社に何かしらの変化があったのでしょう。いずれにせよ、少なからずショックだったのを覚えています。なので、年末も正月も自宅にこもり、ひたすらインタビュー対策の勉強をし続けてました。出口の見えないトンネルの中を迷走しているようで精神的にもかなりきつかったです。

ですが今日、ウィスコンシン州のマディソンにあるソフトウェア会社から software developer のポジションでオファーをいただきました。今度の会社は規模が大きく、インタビューのプロセスも何ステップにも渡る綿密なものだったので、いきなりオファーが白紙に戻るというようなことはないと思います。まだ最終決定は下していませんが、とりあえず首の皮がつながった感じです。

では、ここからインタビュー反省記に移ります。

Salesforce.com はクラウドコンピューティングの分野で非常に強く、日本国内でも日本郵政公社をはじめ Salesforce.com のシステムを導入している企業も少なくないようです。MSE の友人達で Salesforce.com から最初のコンタクトがあった人達は、みな行きたがっていたのを覚えています。私もそのひとりでした。

私が Salesforce.com と行ったインタビューは CMU キャンパスでのインタビューが一回と onsite のインタビューが一回で、アプライしていたポジションは software quality engineer でした。Salesforce.com では Apex と呼ばれる独自言語が開発に用いられているようですが、そのシンタクッスやメカニズムが Java に似ているのでしょうか、キャンパスでの質問は Java に関する質問が多かったです。とくに返答に困ったものはありませんでした。それに加え、あるプログラムの入力に対するテストケースを書く質問もありました。そのプログラムは単語の並びを逆転させるプログラムで、逆転の際、単語間のスペースの数は維持されます。たとえば、文字列 "My name is Yuki." が入力として与えられた場合、プログラムの出力は文字列 "Yuki. is name My" になります。私がテストケースとして考えたのは、プログラムが仕様通りにふるまうノーマルケース、入力が null や空文字のケース、入力がスペースを含まないケース（入力が "Hello" のときは　"Hello" がそのまま返ってきてほしい、というのもスペース以外の文字が区切り文字と考えられている可能性があるかもしれないので）、あるいは入力が大文字のみ、小文字のみ、あるいはその両方が混ざった mixed case の文字列（プログラムが大文字から小文字またはその逆に勝手に変換するようなことがないことを保証するため）などをザッと挙げました（ほかにもテストケースを考えましたが、いまはちょっと思い出せません）。インタビューの終わりには、会社やポジションに関する質問をして、キャンパスでのインタビューはとくに大きな失敗もなく無事に終わりました。この時点ではまだ特に反省と呼べるようなものはありません。

数日後にリクルーターから連絡があり、そのまま onsite インタビューに行くことが決まりました。Salesforce.com の本社があるサンフランシスコはとてもきれいな街で、時間があれば観光もしたかったのですが、学期の真っ直中だったため、それはかないませんでした。

Onsite インタビューは 4, 5時間にわたる長いインタビューでした。全部で3つのパートからなり、プログラミングエクササイズ、テストケースを考える質問、アルゴリズムとデータ構造の質問でした。最初のプログラミングエクササイズでは、60分以内に文字列を操作するプログラムを2つ実装し、それぞれに対し JUnit のテストケースを書けるだけ書くというものでした。ただし、String クラスのメソッドは使ってはいけないという制約つきでした。さて、最初に「しまった！」と思ったのが、キーボートの配列が米国のキー配列だったことです。なにいってんの？と言われてしまいそうですが、日本から持ってきたラップトップをそのまま使ってた私はずっと日本のキー配列に慣れてしまっていて、米国のキー配列で (, ), ;, +, = などのポジションになかなか慣れず、コーディングに少なからず影響が出てしまいました。極度に緊張した状況下でこれはあってはならないことでした。Studio で一緒のメンバーだった Jeff からも常々「Yuki、米国のラップトップ使えよ～」と言われてうっさいうっさいと思っていましたが、こんなところでネックになるとは思ってもみませんでした。ホワイトボードの上でのエクササイズであれば問題なかったんですけど。最初の反省、1) 米国のキー配列にとっととスイッチすべしです。

そして、実装するプログラムのひとつは、2つの文字列を比較する compare メソッドでした。Signature は

int compare(char[] a, char[] b)

で、もしも辞書順(lexicographical order)で a が b の前に来るようであれば -1、a と b が同一の文字列であれば 0、a が b の後に来るようであれば 1 を返すメソッドです。具体的には、a が "apple" で b が "orange" だった場合（簡単のため String 型の表記をしています）、compare は -1 を返します。そのまま文字コードを頭から比べていけばよいものを、いま思い出しても信じられないのですが、なぜか私は a と b に含まれる文字をそのメソッドの中でソートしたんですよ。なので、"apple" は "aelpp" になり、"orange" は "aegnor" になってしまうわけです。これでは辞書順もなにもあったものではありません。おそらくこれはもうひとつのメソッドを実装する際に少し効率のよいアルゴリズムを使ってやれと思い、そのアルゴリズムを頭の中で思い出そうと必死だったため、今フォーカスすべきメソッドに集中していなかったせいかもしれません。まあ、それにしてもこれから辞書順を比較しようっていうのに、その文字列の中の文字をソートするってのはナイですよねぇ（笑）

で、そのもうひとつのメソッドというのが String クラスの split メソッドと同等の機能を持つもので、signature が

char[][] split(char[] text, char[] pattern)

です。text の中から pattern を探し出し、pattern をもとに text の文字列を分割します。たとえば、split("My***name***is***Yuki.", "***") の出力は{"My", "name", "is", "Yuki."}　になります(また String 型の表記をしています）。私が非常に愚かだったのは、text の中から pattern を探し出すのに、for ループを二重にネストさせた簡単なものにすればよかったものを、Rabin Karp という文字列探索アルゴリズムを実装したことです。for ループを使ったアプローチより、Rabin Karp の実装には時間がかかりましたし、なによりRabin Karp で終わりではないのですから。そのあと text をスプリットし、例外的な入力がきても正しく振舞うように実装するには、むしろ文字列探索の後のほうの作業の量が多いです（インタビューのあと改めて実装してみてそう感じました）。なので、このアプローチは完全に失敗でした。Software quality engineer にとって重要な JUnit のテストプログラムの列挙も満足に網羅できませんでしたし、Rabin Karp をずっと考えていたせいで、compare メソッドの実装でも意味の分からないことをするし。うーん、なぜこんなアプローチをとったのか。Rabin Karp を実装しきれば、interviewer を impress できると思ったからか。まったくもって interviewer が何を期待しているかがわかっていない者の解答ですよね。教訓としては、2) インタビューなど限られた時間内での実装は、まず簡単なアプローチで攻め、期待されている答えに真っ先にたどり着くこと。改善はそれからです。MSE の Mel 先生もよく「First find a solution. Then make it better.」と言っておられました。まずとにかく動くものを考えろと。よりよいアプローチはそれからだ、ということですね。身をもって学びました。

テストケースを考える問題は、銀行の ATM をどうテストしますかというもの。ここで求められたのは、とにかく頭の中の assumption をできるだけ排除すること。たとえば、どんな人を対象にした ATM なのか？子供？成人？お年寄りの方？目の見えない方？それによって考えるべきテストケースが変わってきます。何をテストするかということを明確にしなければなりません。そして、普段自分はこんなことはしないだろうというテストケースを考えること。たとえば、偽札を入れてそれを正しく ATM が拒否するか、日本の一万円札とアメリカの100ドル札を混ぜて入れてもオーケーか、小銭の代わりに砂利を入れるとどうなるか、バンクカードのかわりに大学の学生IDカードを入れたらどうなるかなどなど。interviewer から指摘されるまで、ずっと ATM の入金や引き出しといった機能テストにばかり気を取られていたので、あまりよろしくありませんでした。このセッションでの反省は、3) テスターはまず何をテストするかを明確にするべき。そして"常識"という概念を排除してテストケースを考えるべしですね。

最後のアルゴリズムとデータ構造のセッションでは、辞書を実装しましょうという問題。辞書に対して考えられる操作としては、検索、編集、ソート、追加、削除などがあります。これを配列、リスト、2分探索木、ハッシュテーブルで実装するとそれぞれの操作の実行速度がビッグ・オー記法で考えてどう違いますかというものでした。それに加え、ある単語のアナグラムを全て辞書から拾ってきたい場合、どういうアプローチをとりますかという問題。アナグラムとは、文字の順序を入れ替えるとまた別の単語になるというものです（rat、art や dog、god など）。アルゴリズムのクラスや日ごろ自分で勉強したものが頭の中にしみついていたので、このセッションは一番よかったと思います。特に反省すべき点はないですね。

大ポカをあちらこちらでやらかしたせいで、onsite インタビューは通りませんでしたが、プレッシャーがかかった状態でアウトプットを出すにはどうすべきかということを学ばせていただき、貴重な経験をさせていただきました。インタビューの連絡も大変スムーズでしたし、Salesforce.com には感謝をしたいと思います。なお、米国のソフトウェア会社のインタビュー問題が知りたい方は、このサイトをご覧ください。有名どころの会社のインタビューの問題は、かなりの数網羅されています。特に Microsoft と Amazon のインタビュー問題が充実しており、私もインタビューの準備をする際は、このサイトを参考にしています。

反省点のまとめ with Salesforce.com

米国のキー配列にとっととスイッチすべし
インタビューなど限られた時間内での実装は、まず簡単なアプローチで攻め、期待されている答えに真っ先にたどり着くこと。改善はそれから
テスターはまず何をテストするかを明確にするべき。そして"常識"という概念を排除してテストケースを考えるべし

今年もよろしくお願いします

2010-01-01T18:43:00.004+09:00

まだ就職活動中で、年始は忙しくなりますが、これを乗り切ればなんとか生活のリズムがつかめると思います。
前回のエントリの続きは、就職活動が落ち着いてからまた再開しますね。

昨年はいろいろな方にお世話になりました。
ここで改めてお礼申し上げます。どうもありがとうございました。

そして今年もどうぞよろしくお願いいたします。
皆様にとってよい年になりますように。

就職活動インタビュー反省記録　イントロ

2009-12-23T06:17:00.007+09:00

数回に渡って10月から12月まで行ってきた6社とのインタビューの反省をつづろうと思います。これは、将来同じ過ちを繰り返さないようにするための自分への戒めでもあります。

インタビューをした会社を時系列順通りに並べると、Salesforce.com、Google、Facebook、Yahoo、Microsoft、Admob となります。この6社とのインタビューのケースを独断で以下3つのカテゴリに分類。

明らかに失敗だったと自分で（インタビュー中、もしくは後に）分かったケース
Salesforce.com、Yahoo

質問の回答に時間がかかり、おそらく落とされただろうと感じ実際に落とされたケース
Admob、Google

エンジニアからみたら全く見込みがないはずなのになぜかリクルータが私のレジメに目をつけたケース
Facebook、Microsoft

と、分類わけしたところで、あとは時系列にいきたいと思います。
次回は、Salesforce.com とのインタビュー反省記。

ジョブオファーをいただきました

2009-12-20T08:27:00.013+09:00

昨日、Ohio にあるソフトウェア会社からジョブオファーをいただきました。Ohio の Youngstown という街にあり今年で創立12年になります。社員数は20人弱という小さな会社ですが、仕事の量は多く一人で設計、実装、テストと幅広くやることになるので、非常に楽しみです。

あと、数件インタビューが残っており、その結果で新天地が決まります。友人には「来年の1月から3ヶ月間泊めてあげるから Bay Area まで来て就職活動続けなよ」と言われましたが、正直、今手元にあるオファーを引き延ばして（あるいは、白紙にもなりかねない）そこまでする勇気が今はありません。

H1Bも出るので、卒業後は米国でソフトウェアエンジニアとして働くことになります。その Ohio の会社に決まれば、住むところは Boardman という郊外の田舎街になると思うので、友人を招待するにはちょっと不向きな場所になりそうです :P

このジョブオファーをいただく前に、インタビューをしてリジェクトされた会社は、Salesforce.com、Google、Facebook、Yahoo、Admob、Microsoft の6社で、大企業相手（Admobは他の5社のような大企業ではないと思いますが、先月Googleに買収されて今も急成長を続けている会社です）にインタビューをする大変さが身にしみて分かったのでこれはいい経験だったと思います。

次回以降のエントリーでは反省もかねて、それぞれの会社でどんなインタビュー質問が飛んできて、自分がどんな受け答えをしたかについて振り返りたいと思います。

(追記)
あ、今期のクラスはちゃんと単位とれてました。Machine Learning は期末で A- の成績がつき、中間で B- がついて絶対死んだと思ってた Ph.D の Algorithms in the Real World でも期末で B がきたのでまずまず。

無事卒業です！

Studio Project Poster Session 終了！

2009-11-21T07:46:00.007+09:00

本日11月20日（金）、15か月間に渡って続いたプロジェクトの締めくくりにあたるポスターセッションが無事に終了しました。8分間で5人全員プレゼンするというやや忙しい感じのものになりましたが、全員が参加できたのでよい形にまとまったと思います。

プレゼン全体を以下の5つに分けて各人ワンパート担当しました（私は最初の Overview & Problem Definition を担当）。

Overview & Problem Definition

Architecture & Design

Implementation & Quality

Status Evaluation

Process

ポスターを見ているとこれまでの15か月間のことが走馬灯のように頭を駆け巡ってきます。大変なときもありましたが最後まで駆け抜けることができました。

あとは、Machine Learning と Algorithms in the Real World の単位をしっかりとれば卒業できます。

就職活動は今のところ on site で1件蹴られ、phone interview で2件蹴られ、まだオファーはありませんが、これから6社とインタビューがあるのでまた頑張っていきます！