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

• ちはやふる20巻  

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

21巻が待ち遠しい

• Ruby Under a Microsope

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

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

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

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 でもソフトウェア工学修士でも、学校では「さあ、材料だぞ、お前ならどうするんだ」という訓練をひたすら受け卒業していきます。実際の現場に行ったら、「よし、現状は把握した、まずは自分のできるところからだ」になります。僕の中ではソフトウェア工学修士はこの橋渡しをうまくこなしているような気がします。

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

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

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

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

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

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

 

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

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

Details Will Prevail

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

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

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

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

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

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

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

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

箱根の芦ノ湖！

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

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

早く直ってくれ、787!

ソフトウェアエンジニアとして1年働いてみて

日々感じたことがあったので、4点ほど以下の記しておきます。

遅延学習スタイルに足を突っ込んだ
遅延学習の考え方についてはこちらを参照されたし。 中学受験、大学受験を経験した僕の基本学習スタイルは、いわゆる詰め込み型でした。試験前に自分が安心できるまで、様々な項目を記憶したり公式を反復練習したりして、完全武装で試験に臨むタイプ。詰め込みは試験という特殊な評価システムでパフォーマンスを叩き出すには即効性があるかもしれませんが、長い目で見たとき僕はその欠点のほうに目がいってしまいます。1) 普通は詰め込んだ内容を忘れる 2) 想定領域外で問題が発生した場合、脳が即興に訓練されておらず使い物にならない
僕は 1) についてはやや楽観的でした。忘れてしまっても、それをはじめて聞いたというレベルよりはずっと先を進んでいる、再学習するときは一度やったという経験が強く利いてくる、という確信があったからです。しかし 2) については常に自分の無能に頭を抱え、いつもこれができる人を羨望のまなざしで見ていました。応用が利く人は、もしかしたら過去にすでに似たような経験をしているのかもしれませんが、直面している今現在の問題との結びつけあるいは関連性を見出す能力が突出している気がするのです。聞いたこともない見たこともない問題にいつも接するようにすればこの応用力を磨けると僕は思ったのですが、詰め込みの畑から来た人間にとって即興に慣れろというのは正直言って怖い、準備なしで身動きがとれない場合はどうしてくれるという最悪のシナリオが常に頭をよぎるのです（レベル60でラスボスに挑むことに慣れた人がレベル25で行けと言われたらどうするね）。
しかし仕事では自分がコードを変更すると、10年、20年前に書かれたレガシーコードから assert が飛んできて怒られる。大昔に決められたデザインの assumption を知るわけもなく、怒られてから初めて学ぶことになるわけです。こればかりは世の本に書かれているわけもなく、火事場のクソ脳力でその場で対応するしかありませんので、即興を恐れ遅延学習を敬遠する自分にとってはよい背中押しになってくれています。
補足ですが、学習には遅延学習と興味で始める学習、両方のバランスをとるべきと考えます。遅延学習は思うに問題ドリブンであるため、己が出くわさないあるいは関連すらしない問題領域では学習を始められないということに。一方、興味で始める学習は自分の好きなところからツマミ食いしていくので探索できるエリアに制限がない。なので理想のイメージとしては、グラフ理論の Kruskal (手当たり次第にカバーしてくる、興味本位学習？) と Prim (いったんスタートを決めたらジワジワ広がっていく、遅延学習？) を同時並行させたような感じでしょうか。
日常生活の他の部分でも遅延学習ができればいいなとは思います。たとえばやったことのないスポーツに誘われたとき、たとえ初心者が自分ひとりだとしても即興能力に懸けて喜んで参加していってその場で技能を見につけてしまうとか。僕はヒヨってひとりではちょっと難しいです、そういうとき一緒に初心者から学べる友人の存在はデカいです。

会社は会社、自分は自分
僕は今の会社および仕事が好きです。が、そのような状況にあっても自分という個を意識することを心がけます。自分の能力の引き出しから必要なものを毎日オフィスで使い（家で得たことが役に立つときもある）、家では関係のないものを自分で空き放題やる（職場で得たことが役に立つときもある）。例えるならば、関羽になりたい。他国の人間ですら欲しがるほどの人格と技量をそなえながらも常に玄徳に力添えをする。それはもちろん玄徳が力添えをするに値する人徳を備えているから。現代の関羽になれたらかっこいい。

何かを吸収するとき、初回は本筋のみ
初見のコード読むときは例外処理や関数呼び出しに必要な引数のセットアップはすっ飛ばす。Ruby ソースコード完全解説 にも書かれていたことで、僕はそこから最初の教えを学びました。ただ実生活にもそれを適用するようになったのは、実際にその考えを仕事で適用してからです。仕事で毎日読んでいるコードですら初回で全ての情報を吸収するなんて無理なのだから、日常生活でも最初から全部吸収しようとするのは無理だと。
本を読むときに何かの情報を一覧表があったら、5秒くらい眺めて次へ行きます。昔は意味も分からず全て覚えようとしたでしょう。まさに詰め込み型学習の弊害。熟知している項目ひとつひとつが表になっているから意味があるのであって、全くなじみのないものが羅列されているテーブルを覚えにかかるのは時間の浪費。あとで必ず忘れます。
ピアノでも難しい和音が連続して自分には無理そうな場合、初回で一度にすべて押さえることはしません。メインの音となる数音だけをカバーして慣れされるところから始めます。すべてを押さえるようになるのは数音レベルで一通り弾けるようになってから。

必要に応じて適材適所
基本エンジニアが集まるチームだからでしょうか、面白かったのが A さんとその上司である B さんという構図が数年前は逆だったということ。A さんが B さんの上司だった時代があったということです。A さん自身の希望で A さんはエンジニアに戻り今に至っているのですが、このあたり妙な人間関係が介入せずにサバサバいけるところが素晴らしい。だからマネージャーも必要とあらばコーディングするし、僕よりマネージャーが技術面で長けている場面があると正直へこむ。
重要なのはチームのパフォーマンスを最大化することで、そのためにチーム内に能力に基づいた様々なポジションがある。チームパフォーマンス向上につながり両者が同意しているのであれば、肩書きなど気にせずに互いのポジションをスワップするのはなんら問題のないことなのでしょう。

という感じで H1B の最初の一年が過ぎました。今年のお正月は 4 年ぶりに日本です、楽しみ。

追記：
このエントリーを書いたあとふと気がつきましたが、遅延学習のアイデアは他の分野でも普通に見られます。アジャイルソフトウェア開発で登場する略語 YAGNI、これは "you ain't gonna need it" の略で、あらゆる要求を勝手に予想して何か実装したりドキュメントしたりしても結局無駄であると。必要なときが来て初めて何かを実装したりドキュメントしたりしなさいということで、遅延学習の考えに似ていると僕は思います。

Universal References in C++11

去る 8 月 C++ & Beyond 2012 トレーニングカンファレンスなるものがあり、Scott Meyers、Herb Sutter、Andrei Alexandrescu の C++ 界の３巨頭がレクチャーをしました。僕は実際にカンファレンスに行ったわけではありませんが、今年は会場でのすべてのトークが録画され定期的にアップされているので、誰でも当日のプレゼンを見ることができます。見ていて面白かったのが、Scott Meyers の universal references。この用語は Scott 氏がプレゼンの中で使っているものであり、初期化のされ方次第で lvalue references にも rvalue references にもなりうるというもの。C++11 でサポートされる move semantics を指定するときに使う構文 type&& （move semantics のためだけの構文ではないことがプレゼンを見れば分かります）が、どういうときに universal references となりうるのかについて説明しています。それに伴い、std::move と std::forward の使い分けについても分かりやすく説明しています。

要点は構文上 type&& と書いてあるからといって rvalue references とは限らない、ということです。自分で調べた限り、The C++ Standard Library: A Tutorial and Reference (2nd Edition) では深く触れていなかったと思うので、Scott 氏のこのプレゼンはありがたい。

Effective シリーズで見られた Scott 氏のユーモアもプレゼンの随所に見られとにかく面白いです。そして何よりも Scott 氏のプレゼンのうまさに感激しました。ぜひとも同氏には Effective C++11 を書いていただきたい！というわけでオススメのビデオです。面白いので見てみてください。

追記：Scott 氏自身もブログで改めて解説しています

T&& Doesn’t Always Mean “Rvalue Reference”