2013年12月31日火曜日

冬休み 2013

毎年恒例の年末冬休みのため日本に帰っています。いまの会社では、休みを年末まで一度も使わなければ、3-5週間休める仕組みになっています。今年は4月に一度日本に帰ってきていたので、3週間の冬休みとなっています。

僕は今は自由に使える休暇は日本に帰るためだけに使うと決めています。この世には、待ち人がいる国とそうでない国の二種類しかない。しかし、この世は無常であり、前者もいつかは後者に変わっていく。大切な人がこの世から去ったときに

「あぁ、あのときもっとあの人ともっと時間を過ごしておくべきだった」

などと後悔をしたくないのです。待ち人のいる国が存在する時間は限られている。ならば、そこに時間を費やすのは至極当然のこと。

人が感じる一年の体感時間は1/年齢、だから年を重ねれば重ねるほど一年は短く感じる。それだけ、大切な人があなたの目の前から消えるのも実はあっという間ということ。

来年もその待ち人がどうか健康でいつづけられますように。

2013年11月19日火曜日

今月の読み物晒し

先週手元に届きました。

Ruby 関連の洋書って赤い本が多い気がする・・・

仕事で Ruby を使う機会がないんで、両著の Ruby そのものに関する部分は仕事で生かせないけど、書かれている内容を一歩昇華させてメタなスキルとして自分に染み込ませることが狙い、ということで注文しました。まだどちらも半分くらいしか読んでないので雑感しか書けませんが

Ruby Under a Microscope

半年前に呼んだ電子書籍のハードコピー版になります。電子書籍購入者には半額のクーポンがついてたのでそれなら、ということで迷わず買いました。電子書籍で読んだとき内容もよかったですし。ハードコピー版は電子書籍版のチャプター数の2倍になっており、電子書籍にあったチャプターはより細かくチャプター分けしたうえで例と図を増やして分かりやすくしています。ソースコードにもろにダイブはしないものの、Ruby プログラムがいかに内部で処理されているかをスライドショーのように丁寧に追っていくところに非常に好感が持てます。この本から得たいメタスキルは、内部構造を把握していない人達に本質だけをいかにわかりやすく伝えるか。万人に分かり易くとなれば A picture is worth a thousand words というわけで図の出番なのです。コードを見せすぎず、図を中心にして説明していく筆者の腕はぜひとも今の自分の仕事に欲しい。あとはこういう本を書けるとこんないいことがあるってとこでしょうか。


ところでこの著者の Pat さん、同じ州にいる方だったんですね。しかもボストンで定期的に開かれているボストン Ruby グループにも顔を出しているとか。

Practical Object-Oriented Design in Ruby

こちらは Amazon のレビューの良さとサンプルチャプターに目を通したときにピンときた直感を頼りに購入。著者の Sandi さんも Pat さんと同様、テーマに合う例をよく考えて選んでいる。あと Ruby だと他の言語にありがちな煩わしい syntax がなくてオブジェクト指向の部分だけに意識して読める。ふだんオブジェクト指向の決まりごとを頭に入れてるようでも、仕事だと Law of Demeter (遠くのヤツと話すな、直近のヤツとだけ話せ)や Dependency Injection (お前が勝手に取りに行くな、オレがくれてやる)を無視したコードをカタカタと書いていることがあるので、そういう自分のゆるい部分にストップをかける意味でもこういう具体例とともに、ベストプラクティスを無視するとどういう痛い目にあうかを分かりやすく書いてある本があるといい戒めになる。ちなみに良書を書く人同士はやはり巡り会うようです。


両著とも今月には読み終わるかな。最悪、年末に帰国する際の飛行機の中で読む時間たくさんあるし無問題。

2013年10月17日木曜日

Paint Ball 初体験、その後いろいろ感じたこと

平日ではありましたが、チームで半休をとり会社から程遠くない Ashland にある Paint Ball 場でチームアウティングをしてきました。


View Larger Map

日本にいた頃は一度も体験したことのないスポーツでしたが(そうスポーツなんです)今日の Paint Ball 場でプレイした限り、ルールはプレイフィールドに設置された障害物に身を隠しつつ、色の入ったシェルを銃で打ち出しそれを敵チームのプレーヤーにあてていけば勝ち、逆に被弾すれば自分は退場、といったもの。ルールはシンプルながら実際やってみると色々と難しい。何が難しいのかって、1) 狙いが定まらない、2) 空圧で銃から打ち出されるシェルが高速(被弾すると地味に痛い、素手にあたって血が出ました)、3) 戦略が全く思いつかない。
本格的なトーナメントもあるらしいですし、カタカナで「ペイントボール」と検索してみたところ日本でも幅広く行われているスポーツとなってるようです。Paint Ball を一回やってみて、戦場での兵士がいかに想像を絶する状況下で死と隣り合わせになっているかが、ほん~の少しだけ分かる気がしました。あとは、戦略論の大切さとか。

と、そんな感じでチームアウティングを終え、その後はまた会社に戻りコードを書いてたのですが、Paint Ball で同僚と銃撃戦を交えた非日常感からか、ふと人間関係についてオフィスで考えていました。

上司とか先輩とか
今のチームメンバーにはもちろんそれぞれ肩書きがあるのですが、それは各々の仕事の中身を明確にし効率よく処理するだけのただの窓口にすぎない。ディスカッションが始まってしまえば、上司、先輩など関係なく、自分を出していける。相手もそれを全身で受け止めてくれる。精神的に負担になるような階層はどこにも存在していない。今日の Paint Ball だって、自分のボスや社歴 20 年の先輩にたいしてガチで銃口を向けてぶっ放してるんだから、礼儀はどこへ行ったんだって話です。

そして上記を皮切りにアメリカに5年以上滞在してきて、他にも色々な境界線がなくなってきてたことを職場からの帰途でうっすらと感じていました。

なにじんとか
周りにいる人の国籍がバラバラで、自分の接している方がどこの国の人なのか、そういうことを問いかける脳の部分が麻痺してしまっている。のび太のように「人の幸せを願い、人の不幸を悲しむことのできる人」であれば、なにじんだっていいじゃない。

言葉とか
そういう多国籍の人とは英語で話すため、最近は自分の中で日本語と英語の区別がもうなくなっている。ふたつひっくるめて「自分の意思を伝える言葉」です。

学術分野とか
最近は世界史の本とかを読んだりするけど、芸術や宗教、政治や経済、戦争論と色々な分野の土台になっていることにいまさらながら痛感する。学生だったころは文系科目だからとかいう理由で避けて通ってきたことにただただ後悔ばかり。学びに境界線なんてないことにこの年になって気づく。

様々な境界線を感じなくなっていく一方で、日本語には人に劣等感や不幸を与える線引きワードが、まだまだ日常で普通に交わされているなぁとも常々思うわけで。

 高学歴・低学歴、現役・浪人、文系・理系、正社員・非正社員、新卒・既卒

高学歴・低学歴
真にクレジットを受けるべきは確固たる教育理念を掲げ機関を設立した創設者であって、その創設者らのビジョンに高いも低いもない。その理想の元、レールの上を通っただけの人間がそれに妙な付加価値をつけて何かを高いとか低いとか言っていることがおかしい。先生や学友らを含めた愛校心から、卒業した学校を載せてるのであればそれは納得がいくが、大の大人が「学歴」とやらのためだけに卒業校を列挙してるとしたら、それは大学生がこの幼稚園卒業しましたって言ってるのと変わらないレベルかと。
カリキュラムだけならもうオンラインで好きに学べる時代だし、わざわざ学校に通うなら、尊敬する先生がいるもしくはクレイジーなやつらがたくさんいるっていう理由で選ぶべきでは。

現役・浪人
長い人生のたかだか一年くらい、気にしなくていいのではないでしょうか。

文系理系
個人的には、自分は文系(理系)のこの科目には興味がないから理系(文系)にいるんだ、っていう否定的な枠組みに聞こえることが多いです。経済学にだって数学は必要だし、工学にだって人類史は必要。

正社員・非正社員
会社に貢献してる人の労働そのものに差があるんだろうか。

新卒・既卒
別にその人をあなた色に染め上げるわけじゃないんだし、卒業から時間が空いてたって何の問題が?ほかの人が持ち合わせていない特殊なスキルが”既卒”の人にあるかもしれない。

自分が生まれた、世界で一番好きな国。だからこそ、本質的には何の違いもない上記のような言葉が飛び交って、誰かの気持ちを暗くさせていると思うと無性に悲しくなるわけです。

2013年9月30日月曜日

C++コード書きの3つのゴール

先月同様の手抜き更新です。チームで C++ Seasoning というタイトルのトークを見たので、他にも興味ある人がいるかなと思いつつトークのビデオをここに貼っておきます。

 
トークの中で Sean 氏は、3つのゴールとは、むき出しのループはやめよう、むき出しの同期プリミティブはやめよう、むき出しのポインタはやめよう、であると説明しています。詳しくはトークを見てもらって、以下は僕がビデオを見た(すっごく適当な)雑感を。

最初のゴールのむき出しのループはやめようの Chrome OS のサンプルコードのループの連続、これ結構ヒドいですね(笑)Google は candidate をスクリーニングしてるはずでは??
でもインタビュー質問を突破したとしても、次から次へと舞い込む日々の作業の量ゆえ、こういうコードを書いてしまう気持ちも分からなくはないです。が、極力避けるべきことだと思います。

最後のゴールのむき出しのポインタで shared_ptr とグローバル変数は同じメモリ領域を複数人で叩いてるんだから、つまるところ一緒じゃん言われてギクっしました。あとポインタ経由の継承を避けてトーク内では type erasure を使ってる?のかな。でも自分は現場ではそれはやってないですね。どうしても安易にポインタ経由の継承に走っているので、このトークの観点からすると自分のあまりほめられたことはやってないんだなと。 

また別のトークを見たらここでまた適当に紹介します。

2013年8月31日土曜日

引越し

と言っても職場のオフィスの、という意味です。今年の上半期にキャンパスに新しいビルディング4ができ、それに伴いオフィスの場所を移すグループがありました。自分もその一派だったのですが、僕の場合は新しいビルに移ることはなく、これまでのフロアでしかも窓なしの部屋に移動になりました。入社して3年、初めての窓なし生活で軽くショックです、太陽が時間の経過を教えてくれません。

個室なので集中はできます

2013年7月15日月曜日

Revo さん節にまたもや魅了され

今年の4月は友人の結婚式で日本に一時帰っていました。帰国時に僕が必ずすることは書店めぐり。大手の書店からデパート内の書店まで色々な本屋を一日かけて満喫します。今回、どの書店の漫画コーナーでも目に付いたのが「進撃の巨人」。理科室に置いてある人体モデルのような巨人が表紙にデカデカと載っていたのはインパクトがあり、数巻ほど読んでみたらたちまちハマってしまった。帯にはテレビアニメも放映中とあり、幸い二週間ほど日本に滞在していたので運よく地上波で見ることができた。放映されたのは原作ですでに読んだ箇所だったのでストーリーを問題なく追うことができ、声、美術、構成とどれをとっても文句なしに素晴らしかった。そして極めつけがOP。放映中にOPの作曲者の名前を見てそれが Revo さんだと分かったときは本当に jaw dropping でした。ブレイブリーデフォルトであれだけ素晴らしい曲が書けて、今度はこんなにも中毒性の高いアニメーションのOPも作曲できてしまうのかと。



そして先日公開された新しいOPも聞けば聞くほど深みにはまっていく Revo さん節満載の珠玉のトラック。その曲に合わせて目で追いきれないほど瞬時に切り替わる映像もまさに一級品。


冒頭のファンファーレはブレイブリーデフォルトでも流れそうな感じです

ブレイブリーデフォルトでもそうでしたが、楽曲対象となる作品に対する Revo さんの理解が非常に深いことと、作られた楽曲は何回聞いても全く飽きが来ることなくむしろ中毒性が増していくこと、この二点は本当に特筆すべきことです。特に後者は驚異的で、4月に帰国したときのNY⇒成田の便ではフライト時間の三分の一はブレイブリーデフォルトのサントラを聞いていたと思います。どの曲も素晴らしいのはもはや given なのですが、そのうえで Revo さんの感性は天才だと感じた一曲はラストダンジョンで流れる「闇のオーロラ」


曲の感情を全体的に抑えているように聞こえるのにこれだけ妖しくも美しい雰囲気と禍々しさを同居させられるのは、まさに並々ならぬ才能と懐の深さがなせる業。感情むき出しの曲ではメロディもすぐ拾えるし、大きな音をジャカジャカ鳴らせばそれなりに壮大に聞こえる。感情を抑えてここまで曲のテーマの深さを表現できるのは並大抵のことではないと僕は考えます。そして雰囲気こそ違えど感情を抑えつつそのテーマを見事に表現した天才的な感性をうかがえるもうひとつの曲として、すぎやま先生の「神秘なる塔」を挙げます。

音楽評論家の故黒田恭一さんもすぎやま先生の引き出しの多さについてよく言及しておられました

話が逸れましたが、Revo さんの素晴らしいOP曲と美麗な背景美術、多くの伏線を含んだ目が離せない今後のストーリー展開と三拍子そろった誘惑に抗えず進撃の巨人の Blu-ray を全巻予約してしまいました。Blu-ray だと日本とアメリカのリージョンコードが同じなので助かります。

2013年6月24日月曜日

全体像を把握する目を、己の論理に自信を

職場では年に一度のパフォーマンスレビューがあります。誰にレビューをしてもらうかは自分で指定することができ、僕の場合はその一年で一定以上のインタラクションがあった人に頼むようにしています。2012年を終えて同僚の目から見た僕の仕事における改善点は、
  • バグ修正のときはエラーとしてあがってきたユースケース以外に、それに関連したユースケースにもバグがないかどうかチェック
  • ロジックを自分の口で説明するときは、自信を持つ
不思議なものでこの二つ、僕が自分に向けて書いたセルフレビューでも実は全く同様のことを挙げていました。すなわち、自分から見た己の改善点と他人から見た僕の改善点は一致しているということ。己の視点と他者の視点が一致することは分からないこともなく、というのも「ここをこうするともっとよくなる」とか「この誤りはもう二度と起こさないようにしよう」とかチーム内では普段から直接相手に言うようにしているので、レビューが書かれる頃には自分は何を改善すればいいのかおのずと分かっているという寸法です。レビューで指摘されている己の改善点を読む際にも少なくとも一度は直接言われていることなのでキモを冷やさずに済むと。

上記の二点は言うは易しのようなところもありますが、一点目は2013年になってからは改善できていると自分でも感じます。特定のエリアに限ってユースケースとコードベースのマッピングが頭の中で出来てきたおかげです。逆に初見のコードベースでは、まだまだというところか。しかしそのような状況でもやれる人はやるんですよ。そういう人は、1) 過去の経験からくる類推がわりと効くのと、2) その未知のエリアに明るい人物を探す能力に長けているのと、3) 疑問解決のためにその人物に投げかける質問の内容が実にポイントを得ている。僕はまだ三つのうちどれも未完成で、未知のエリアではしばらく試行錯誤を繰り返す日々が続く。
二点目もまだまだ改善が必要なわけで。自分のロジックを自信を持って説明している人は論拠となっている土台にブラックボックスがほとんど存在していない。もしくはそのブラックボックスを使う上での前提をよく把握している。すなわちその前提から外れた状況下でブラックボックスを使用して己の論理を組み立てていくと、導き出された結果が undefined behavior になることを良く理解している。僕の改善すべき箇所は、まだ年配のエンジニアの説明を鵜呑みにしている部分が多いということ。論拠となる部分で「Aさんからこういう説明を受けたので自分としてはこういう理解のもとに話を進めます」では、説得力に欠けるんですわ。しかし大規模ソフトウェアでは、assumption の上に assumption が重なっていくのでどこかで線引きをしないと、ブラックボックスの中を覗いているだけで一週間が終わってしまう。時間との戦いなのでどこかで探求を打ち切り前進しないといけないのだけれど、そのあきらめ方を工夫しないと説得力のある説明はできないというのが現状。これも日々試行錯誤しないといけないよな。

にしてもレビューで、自分の改善点を指摘するために具体例として挙げる過去のエピソードをどうしてこんなに克明に覚えているのっていうくらい、年配のエンジニアは僕との作業を良く覚えてる。こういうところでもシニアの人はさすがだと思わされるわけです。

2013年5月29日水曜日

読み物まとめ: 4月-5月

  • ちはやふる20巻  
全巻通して読んでいますが、各巻読み終えるたびに背筋が伸びる思いです。登場人物成長モノはジャンプ黄金期から数え切れないほど読んできてますが、これほど日常レベルで劇中の名言を自分に還元できる作品はちはやふるが初めてですよ。原作者の末次先生は過去に大変なこともあったようですが、そのときの経験が活きて、この素敵な作品を生み出す原動力になっているんだなと、各巻の表紙の折り返し原作者コメントを読んでそう思いました。アマゾンJPの海外発送料なんて全然苦じゃないわ、ってレベルで毎巻楽しみにしています。

21巻が待ち遠しい

ハードカバーは今年の11月に出るようですが、僕は20$の電子書籍版を購入して読みました。これはホントいい買い物をした!人にわかりやすく説明する手本といっていい。青木さんの RHG や巷の Yarv ソースコードリーディングブログ に比べてしまうと処理系内部のコードの掘り下げは比較的浅いが、そのぶん具体的なユースケースが Ruby 1.9 にどのように口で噛み砕かれて、食道を通って、胃で消化されるのかが順を追って詳細な図とともに説明されている。そして、実際はもっと複雑なんだけれど今は伝えるべき重要な本質があるのでその複雑な部分の説明は省きます、とその削ぎ落とし具合も絶妙。Scott Meyers の C++11 の Universal Reference  のビデオで便宜上嘘を鵜呑みにしておくことは時として真実を知ろうとするよりも役に立つことがあると言っていましたが、まさにソレ。煩雑な部分は後回し、今は押さえるべき重要なポイントがあるんだ、筆者のそんなスタイルが功を奏しています。

熟知しているのに説明ができない、そういう場面では本当にがっかりします。理解ができているのに、人に説明するのが下手もしくは出来ないのは最大の罪ですよ(お前どの口が言ってんの、という反論は受け付けます)。だったら私には分からないと言ってくれたほうがこっちはよっぽどすっきりする。そうならぬよう、仕事で己の作業分を別の人物に噛み砕いて説明する際は、図をいかに有効活用するかという意味でこの本が非常にためになる。言語処理系という同じ分野なので、処理系内部で起こっていることを図にするときはどう描くと分かりやすいのか、という意味でも参考になりますしね。

うちのチームでもこれくらい分かりやすい図を描く時間があったらいいなと思うんですが、Ruby Under a Microsope の著者はマッキンゼーで仕事をフレキシブルにしてもらいつつこれを書いたと謝辞にあった。自分も頼んだらもしかしてやらしてくれるかなぁとか。無理かぁぁ・・・!

2013年4月12日金曜日

On Master of Software Engineering Part3

愛の日記の古賀さんが MBA 教育について分かりやすい記事を書いておられたので、僕はその MBA よりマニアックなソフトウェア工学修士について、1年半の開発を経たいま改めて書きます。過去の関連記事はこちらこちら

アメリカの大学院の修士には基本的にアカデミックマスターとプロフェッショナルマスターと2種類あります。前者は博士過程の前段階として大学に留まることを前提としている修士、後者は卒業後に industry に戻りその能力を発揮することを前提としている修士。MBA は後者に当たるため、古賀さんの言う、知識の獲得そのものより、決断力を磨くというメタかつ応用の効く能力に重きを置くという記述には納得です。

ソフトウェア工学修士も プロフェッショナルマスターにあたり、いわゆる職業訓練場です。MBA ではおそらく取り扱われない、ソフトウェア工学修士に特化した訓練事項は二つ。第一に、ビジネス要求がどのような過程を経て実際のコードに反映されるか、その決断の連鎖とトランスフォームを理解する訓練。第二、その決断の連鎖の過程に登場する異なるステークホルダー(カスタマー、アーキテクト、デザイナ、デベロッパー、テスタ)に、相手が最も分かりやすい言語(自然言語であったり、図であったり、コードであったり)で決断理由を説明する訓練。カーネギーメロンのソフトウェア工学修士では、コースワークや学期末プレゼンを通して、この二つの能力を訓練する場を設けています。もちろんエンジニアリングの世界も常に There's no such thing as a free lunch。往々にしてパフォーマンスをとればメモリを喰う、セキュリティをとればユーザビリティに影響する。正解などなくMBA 同様「お前ならどうするんだ」なのです。

MBA でもよく訊かれることで、「ソフトウェア工学修士って役に立つの?」という問いに対する”いま”の僕の答えはあえて No です。例えば、過去に CEO をいくつも経験したことのある MBA 卒業生ならまだしも、ビジネス経験のない MBA 卒業生が在学中決断の訓練をしたからといって、就職先の会社でその会社の製品のこともつゆ知らずに経営上重要な決断を下せるわけがない。
それと同様、すでに大規模なコードベースが存在している会社で、メジャーなソフトを開発した経験がない新米が入社したところでビジネス要求とコードのツーエンドを見通せる機会が来るわけがない。そもそも大規模なコードベースがある時点で他の人によって下された、ビジネス要求からコードに至るまでの決断の連鎖がすでに大量に存在してしまっているのである。いまさらその決断基準を掘り返すのは至難の業。ソースコードがドキュメンテーションだ、とまではいかないまでも今の現場はやはりコード主体で回っているので、コード上に見られるエンジニアリングのトレードオフを他の畑のステークホルダーに説明するのがとても難しい。MSE で学んだ多種のステークホルダーとのコミュニケーションの核となるソフトウェアアーキテクチャのアイデアには賛成ですが、実際にそれを現場で運用するには難題が多すぎてはっきりいって現実的ではない(少なくとも CMU で学んだノウハウをこの目で見たことは一度もない、このあたりはまたいずれ)。

ソフトウェア工学修士で訓練して日頃心がけていることは、異なるポジションの人に自分の決断理由を彼らの言葉で説明するということです。自分の実装理由をテスタの観点から説明する、ドキュメンテーションの人の観点から説明する、これらは僕が尊敬するデベロッパーが必ず有している能力です。相手はこれをとっくに知っているだろうから説明しなくていいや、という根拠のない assumption をいかに排除できるかが肝。

上では「ソフトウェア工学修士は役に立つか」という問いにあえて答えましたが、役に立つ、役に立たない、というものさしで学習経験の本質を捉えることは難しい。MBA でもソフトウェア工学修士でも、学校では「さあ、材料だぞ、お前ならどうするんだ」という訓練をひたすら受け卒業していきます。実際の現場に行ったら、「よし、現状は把握した、まずは自分のできるところからだ」になります。僕の中ではソフトウェア工学修士はこの橋渡しをうまくこなしているような気がします。

2013年3月18日月曜日

私的 ポストすぎやま先生 & 植松さん

去年、ほんとうに久方ぶりに RPG をプレイしました。


Amazon のレビューがとりわけ良かったのが作品を知る最初のきっかけだったのですが、作品を購入した決定的な理由は劇中の音楽でした。それまで作曲者のお名前は存じなかったのですが、その作曲者の Revo さんが作曲した本作品のメインテーマがウェブサイトで流れたときには、マウスを操作していた手が止まり、ただただ聞き入ってしまいました。喜怒哀楽、舞台の世界観を見事に表現した数々の曲のメロディとそれら一つ一つを奏でる楽器の組み合わせが大変素晴らしく、久々にサントラを買うにまで至りました。過去10年でこれだけ繰り返し聞いたサントラは、ドラクエ、FF以外 ではこれがはじめて。ストーリーの魅力を何倍にも増幅させる Revo さんの魂のこもった曲は本当に鳥肌モノ。

ゲーム本編、ラストバトルは王道の演出と神懸かった曲のコンボで脳汁が出ます

ED で流れるバラードはゲームをプレイしていなくても必聴

加えて本作品の曲で特徴的なのが、歌詞をつけたボーカライズバージョンなるものがいくつかあるということ。そのボイスとオーケストラの組み合わせをフルにいかしたコンサート Revo Linked BRAVELY DEFAULT Concert が去年11月に横浜アリーナでありました。帰国時期が重なってたら間違いなく行ってただけに会場に足を運べず残念でしたが、コンサートのライブ Blu-ray が出るというので、Amazon で速攻でポチってきました。

 
指揮者は千住明さん、ギタリストにはマーティ・フリードマンが見えます

Bravely Default の続編も是非 Revo さん作曲で頼みます!あとケイ・エム・ピー出版さん「 ピアノ曲集 ブレイブリーデフォルト」をはよお願いします。

2013年2月19日火曜日

Details Will Prevail

お題は細部が大局を支配するといった意味合いです。

米ソフトウェア会社の景気が数年前より良くなったためか、開発のポジションのお誘いのリクルーティングメールが割と頻繁に来ます。なかでもボストンにもオフィスがある Google 先生からのメールが一番頻繁に来ますが、僕は今のポジションを離れるつもりはないので、リクルーティングメールにはただひたすら「ごめんなさい」を繰り返しています。

違う会社からメールが来ると自然とその会社のイメージを僕は思い浮かべます。Twitter とか Amazon とか普段良く目にしているものは、日々利用しているサイトの素敵感が先行して、もしかしたらそこでの仕事も似たような気持ちの高揚を味わえるのではないかと勝手な想像してしまうこともあります。しかし最初はそうであっても最終的には自らの仕事は、設計、コーディング、チームプレイと細かな作業が日々繰り返される日常に落ち着きます。そうなれば入社のときに膨らませていた想像は、己を会社に繋ぎ止めておくにはあまりに微力すぎます。5年、10年と好きでいられるかは、自分の関わる製品の設計の哲学、開発言語を使い倒すその度合い、チームメンバーとの居心地の良さなど、それこそ入社前には知るはずもない細かな要因に大きく依存します。現にその要因が合わずに自分のいまの会社を去った人もこの目で見てきました。サポートにいたとき自分が開発を目指していたこともあり「開発は会社の花形で憧れます」と他の部署の方に言われたことがあるのですが、当時の僕は答えが分からずその場で返答できませんでした。今なら「行き着くところは地道な作業の繰り返しです」と答えます。華やかに見えるものの裏にはたいてい地道な作業の繰り返しがあります。結局はその繰り返される細部が好きでいられるかどうか。世の中どこを見回しても、結局は各々のパーツが細かなレベルで繰り返しをしており、そうして全体が成り立っている、そういう意識があるので僕は隣の芝生が青く見えないタイプの人間です。

リクルーティングメールの段階では、日々職場に向かう前の気分、チームメンバーとの相性、チームメンバーのプロ意識など、日々そこで繰り返される詳細は分かりません。こればかりはそこへ行って時間をかけてみて初めて分かることなので、厄介なことと思います。僕自身は現職のこういった部分のマッチングを破棄して他社へ冒険するメリットがないので、リクルーティングメールへは「ごめんなさい」の一点張りをしているというわけです。

入学、入社など「入○」に代表される第一印象の持つきらびやかなイメージは儚いとつねづね感じています。表層的なイメージは時間とともに取り除かれ、最終的に残るのは日々紡がれる繰り返し。そして一日に処理できる量は微々たるもので、必然的に細かな作業ということになってくる。その細かな作業の繰り返しに穏やかな気持ちで向き合えるかどうか、そこに新しいものに惑わされずに(飽きずに)道を貫いていく本質が隠れていると思います。逆に、新しいものへ憧れはそうした見慣れた繰り返しから逃れるためのあがきなのかもしれません。しかし、その先にはまた繰り返しが待っていることを忘れてはならない。繰り返しと飛翔、その中に成長があるのかな、と最近感じています。

どーでもいいけど先週のブリザード。まじで勘弁してくれ

2013年1月30日水曜日

2012年末の正月休みから戻りました

去年と同様に、年末の4週間休みから戻りました。日本の企業での典型的な働きかたは自分の親を見て十分知っているつもりなので、それを知ると4週間連続で休みがとれる今の会社のカラクリが不思議でなりません。どうしてそれで会社が機能しているのかなと。

箱根の芦ノ湖!

休暇という理由だからだろうか、日本は本当に住み心地がいいと思いました。食べ物もおいしく、店もところ狭しと並び買い物には困らない。知り合いに会うのも電車であっという間。病院ではすぐに診てもらえるし、街を歩いていても銃で撃たれる心配は皆無。これを全部ひっくり返すとアメリカになります。

両国ともに(自分の都合にとって)良いところ、悪いところがありますが、その国にいるときはその国の良いところを感じながら生活していくことが幸せのひとつの形なんじゃないかなと、漠然と考えながらまた今年一年がんばります。

早く直ってくれ、787!