ソフトウェアエンジニアとして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”

VIDEO GAME ORCHESTRA ～LIVE AT SYMPHONY HALL～

本イベントのことは、古賀さんブログでも告知されていた飲茶会に行ったときに知りました。ゲームミュージックのオーケストラで、しかもスペシャルゲストが来るっていうんだから行かないわけにはいかないよね、ということでボストンのシンフォニーホールに初めて行ってきました。

二階席バルコニー最前列！

曲目は、 ファイナルファンタジー関連、ストII、God of War、悪魔城ドラキュラ、グランディア、キングダムハーツ、メタルギアソリッド3、クロノトリガーから主にメインテーマを中心に、幅広くカバーされていました。そして最初と最後にファイナルファンタジーVII をもってくるあたり、ゲームファンの作品に対する変わらぬ愛を感じます。なかでもエアリスのテーマと片翼の天使は抜群の人気を誇ります。

僕自身も、当時ファイナルファンタジーVII を繰り返しプレイして、購入したサントラも擦り切れるほどに聞きました。作中でエアリスのテーマが最初にかかるのは、捕らわれの身になった彼女を救いに神羅カンパニーのビルに乗り込む前に彼女の家を訪れるシーン。そのときからずっと心に残る曲になりました。

片翼の天使を初めて聞いたとき、それは同級生の友達の家に泊まりに行って彼と一緒に初クリアを目指していた真夜中でした。第一形態のリバースセフィロスを倒した直後、暗闇のなかから突然この曲がかかります。威圧感のあるイントロに加え、ゲームでコーラスを聞くのは生まれて初めてだったので当時友人家でしびれまくったのを覚えています。

クロノトリガーのサントラも外装パッケージがガバガバになるくらい何度も聞きました。この日に演奏された曲はオープニングでしたが、僕が本作でふと聞きたくなるトラックは、ゲームスタート直後に自分の家で流れる"家族"という雰囲気が色濃く出ているこの曲です。

ファイナルファンタジーの植松さん、クロノトリガーの光田さんは会場にはいませんでしたが、この日かけつけてくださったスペシャルゲストみなさんは、下村陽子さん、崎元仁さん、山下絹代さん、岩垂徳行さん。僕にはもう神様が集まっているようにしか見えません。

舞台中央、崎元さん、下村さん、山下さん、岩垂さん。
この直後にみなさん感謝の意をこめて聴衆にお辞儀をします。
その動作は、他国にはない日本特有の美しさがありました。

山下さんの悪魔城ドラキュラの曲は、幼稚園時代にディスクシステムでプレイしたときからのお気に入り。

岩垂さんの担当されたゲームは残念ながら全くプレイしたことがありませんが、この日に素晴らしいグランディアの曲を聞かせていただいたので、これを機に岩垂さんワールドにも足を踏み入れたいと思います。

崎元さんの曲を初めて聞いた作品は、ファイナルファンタジータクティクス。これもサントラ（パッケージがたしかダンボールのような色と手触りのもの）を買って聞きまくりました。特にオープニングの曲が実に印象的で、プレステを起動してからコントローラのボタンを何も押さずに、繰り返し見てた記憶があります。

下村さんの曲に初めて出会ったのはストIIでしたが、その時は格闘に急がしく作曲者がどなたかまでは気が回りませんでした。そしてのちに音楽と作曲者のお名前が一致したのが、任天堂と当時のスクウェアの合作であったマリオRPGでした。心あたたまる素晴らしい作品で、その世界観にぴったりハマった下村さんの音楽にたちまち夢中になり、これまたサントラを買って繰り返し聞いていました（Amazon で見たらマリオRPG のサントラの現在の値段がえらいことに）。作中ではかわいいこの曲を聴きたくていつもワイン川にコインを取りにいっていました。

感極まって今回の文章はこの日のオーケストラに関する感想というより、各作品の音楽に対する思い出話になってしまいました。思い入れのある作曲家の方々が集まってくださって、素晴らしい奏者のみなさんが演奏してくださる曲を全身で浴びるという、最高のひと時を送ることができました。関係者各位すべての人々にありがとうを伝えたいです。

機会があったらまたぜひ来たいです

ピアノへの情熱、ドラゴンクエストに感謝

僕は筋金入りのドラゴンクエストファン。今回の X はまだやっていませんが、I, II, III は FC, SFC, GBC で、IV は FC, PS, DS で、V は SFC, PS2, DS で、VI は SFC, DS で、VII は PS 、VIII は PS2 で日本版、北米版、IX も DS でやりました。

ドラゴンクエストは、世界観や美術、ストーリーとどれも素晴らしいのですが、最も惹かれるのは何かと訊かれれば、僕にとってそれはすぎやまこういち先生の音楽なのです。本当に大好きで、日本にいた頃はほぼ毎年すぎやま先生のドラゴンクエストファミリーコンサートに行っていました。加えてサウンドトラックと交響組曲の CD を昔から何度も聞いていたため、今では全曲、タイトルを見ただけで頭の中で再生することができます。

最近、同僚のイギリス人との会話のなかで、数学好きの人は音楽も好む傾向がある、なんてやりとりをしました。かくいう彼も集合論、計算論に非常に詳しく、バークリー音楽大学でギターを学んでいたという経歴もあります。不思議なもので、そんな何気ない会話から自分もまた何か楽器を始めたいと思うようになりました。親に始めされられたという理由で小学校時代にやっていたピアノ。まだ幼かった自分は、音色をつくる素晴らしさがわかりませんでした。

曲によっては自然に涙まで出てしまうドラゴンクエストの音楽。頭の中だけでなく、実際に音を奏でてみたいと思うようになり、ヤマハの電子ピアノまで買ってしまいました。

ヤマハの P-155 & ピアノ曲集 ドラゴンクエスト オフィシャルベストアルバム．
編曲の今村さんのアレンジがこれまたうまい．

一ヶ月強練習して一番好きな曲である VIII の「広い世界へ」が弾けるようになりました。

そして今はこの曲を練習中。昔から愛され続けているため、ファミリーコンサートのアンコール時にも結構出てきていた記憶があります。

"音楽は心の貯金" というすぎやま先生のフレーズ、この歳になってようやく実感がわいてきました。

ドップリつかる

ある問題を解こうとすると、一日中頭が回転していたことにあとで気がつく。

一つのことに没頭しているとき、家でそうしていれば人はそれを趣味と呼ぶし、職場でそうしていれば人はそれを仕事と呼ぶ。

何かに夢中になってドップリつかっているとき、趣味や仕事といった境界線は消えてなくなるらしい。広大な宇宙に身をゆだねている感覚だ。


蛇足だが、最近チームで Andrei Alexandrescu のビデオを見た。あの Loki Library の中の人で、このプレゼンは variadic templates のお話。それにしても、... の記法がまたこんなところで出てくるとは。言語の見た目の醜さにますます磨きがかかる。こんなんメンテする日が来るのか・・・テンションが上がるな。

職場に感謝を

開発に移って早9ヶ月が経とうとしています。毎日の仕事では、巨大な C++ のコードベースと向かい合い、舞い込んでくるバグタスクやリファクタリングタスクをひとつひとつ処理していきます。レガシーコードも存在しているので、製品のデザインの歴史を知るエンジニアに助けを求めることも多々あります。自分が関わっている範囲は MATLAB の

• インタプリタ 
• インデックス
• デバッガ
• プロファイラ
• 関数ディスパッチ
• 関数ハンドル
• ワークスペース
• サーチパス

といった部分です。MATLAB ユーザの方であればこれらのうちいくつか触れたことがあるかもしれません。

毎日とにかく楽しく、現状に対する満足度はチームに入る前に僕が抱いていた期待値を上回っています。Great place to work たらしめている要因は複数あり（自分の思い込みも含む）、どれもありがたいものです。

すべてはつながっている
プ ログラミング言語論、計算論、アルゴリズム、ソフトウェア工学といった分野で、書籍で読んだり、大学の講義で聞いたものが現場で駆使されている。学校にいたころは学びの姿勢がなっていなかったため、何の脈絡もなしにただ書籍を斜め読みしたり講義を聞いていたりしただけで、あんまり内容が頭に入ってこなかった。これは何の役に立つのかなとポリポリ頭を掻きながら困惑していた時期もあった。しかし今の現場では、そういったベストプラクティスが実際の製品に組み込まれているところを目の当たりにできる。コンピュータサイエンスやソフトウェア工学で重要だと謳われている知識やスキルを身につけることが、己に大きなアドバンテージを与えるということをはっきりと実感させてくれる職場なのである。

いざというときに救いの手を差し伸べてくれる
直面している問題の全体像を把握することが一人では困難なため、特定の分野を熟知しているエンジニアに助けを借りることがよくある。僕がつまづいている箇所をひとたび説明すれば、彼ら/彼女らは次にどうすべきかそのステップを楽しそうに説明してくれる。エンジニアだからだろうか、みな質問が飛んでくるのが好き、説明するのが好きというのが見てとれる。だからこそ僕も気兼ねなく声をかけることができる。しかしそれは、僕の側で必要なリサーチをすべて終えた後でという条件つきだ。手ぶらで「分かりません」では解決にむけて何も前進していない。分からない部分にも領域があり、分かる部分との境界線を引くことが重要なのだ。今の現場は、みな直面している問題が簡単ではないことをよく分かっており、この「線引き」さえも立派な努力として認めてもらえる。線を引いたはいいがこれからどうしていいか分からないという「いざ」という局面で、同僚は喜んで力を貸してくれる。

発信者によらず意見を尊重する
同僚はみな僕よりも年配で長年の開発経験がある。なかには20年以上の経験を持つ人もいる。そんな人からしてみたら「学校出たてで開発経験も十分にない君の意見など無用だ、ただ黙って言われたとおりにしていればいい、質問も一切受け付けない。」と思っても不思議はない。しかしそんな態度をとられたことはただの一度もない。逆に「このタスクに関連しているコードを一番見ているのは君だ、気づいた点、不明な点、改善すべき点があればどんどん教えてほしい。」と僕のインプットを歓迎してくれる。例えば、僕がすぐにコードの挙動をつかめないような部分を指摘すると、それはもしかしたら初見の者にとって分かりにくい複雑なデザインになっているのかもしれないという、悪いニオイのフラグをあげてくれる。発信者が誰であれ、そこにある意見を真剣に聞いてくれるため、いつも前向きな気持ちで仕事に取り組むことができる。

過ちそのものより個人の成長を重視する
去年の12月に、コードをコミットする際に走らせたテストの結果で分かりにくい記述があり、その部分を明らかにしないまま自分の変更をサブミットして、コードベースを壊したことがあった。そういうときも「前に進むときに間違いを犯すことは一向に構わない。同じ間違いはしてはならないが、新しい間違いはどんどんすべきだ。過ちを恐れて前に進めなくなることが一番問題だ。」と、原因を追究し把握した上でそれを学習の機会とさせてくれる。また、初めてやることは比較的時間がかかるが、それは二度目以降はより短い時間でこなしてくれるだろうという期待を込めて任せているんだ、とよく話をしてくれる。過ちやつまづきはすべてその人の長期的な成長にとって必要な糧なのだ。

和気あいあいとした現場
自分のチームは多国籍で比較的陽気な人が集まっている。前述の僕がコードベースを壊したときも「Yahoo, Yuki's just broken our codebase! 」みたいなノリだった。そんなお気楽で大丈夫なのかと思ったりもしたが、どうやら大丈夫らしい。またチームメンバーのオフィスも一箇所にまとまっているのでお互い気軽に話しをすることができる。とにかくストレスフリーな現場である。

必要最低限のミーティング
進捗のミーティングはほぼスタンドアップミーティング。合計時間にして1週間に30分強。普段から気軽に話しをすることもあって、椅子にどっしり腰を下ろして時間をかけてミーティングをすることは少ない。なので、日々中断が入ることなく自分の作業をすすめることができる。


というような感じの職場です。当面の目標は社内向けに「Ruby ソースコード完全解説」をリスペクトして「MATLAB 実行エンジンソースコード完全解説」を書くこと！
とはいうものの、どれくらいかかるのか・・・実行エンジンと限定したのは、他の製品、デプロイとかグラフィックスとか Simulink を含めようものならもう対象がデカ過ぎて死ねるからだ。実行エンジンだけでもデカ過ぎてやばいのだが・・・

API Design for C++ - a midway recap

半分の第6章まで読んだうえでの簡単な感想です。ある日マネージャーとのミーティングで、この本が面白そうだから注文してみようという話になりました。 

著者は Pixar で Lead Engineer という経歴も

途中までの感想は、とてもいい！Effective C++、Large Scale C++ Software Design、  C++ Templates といった名著で触れられている項目から C++ API を設計する上で特に重要なことを選び抜き、具体的なコード例とともに質の高い C++ API とは？という問いに答えている本です。コーディングのノウハウだけにとどまらず、要求定義やアーキテクチャ設計といった ソフトウェア工学の分野にも踏み込んでおり、開発のライフサイクルにおける C++ だけにはとどまらない API の重要さを明確にしている点もすばらしい。そして何より、著者の writing のスタイルが一番すばらしい。各章の役割をはっきりさせ、読者が各項目を簡単に理解できるよう適当な具体例を選んでおり、各章を抜けたあとに著者の伝えようとしていたことがしっかりと頭に残る。技術に関する優れた知識と伝えるべき点を伝える writing スキルがこれだけ見事に同居している著者もなかなかいないと思います。C++ 言語の ins and outs という意味で内容に目新しいものは特にないが、蓄積されていた知識が API design というテーマを中心に頭の中で整理されていったのは感動もの。集団でC++ の開発を行うとき、メンバーの予備知識のベースラインをつくるには最適の本である。僕もいま仕事で C++ の API を相手にしているので、この本はその際のチェックリストの代わりにもなっている。次の第 7 章 Performance を読むのが楽しみだ。

Amazon.com でのレビューも高い。C++ の API 設計における知識の整理をしたい人にオススメです。といいますか、間違いなく日本語に翻訳されると思います。

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

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

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

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

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

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

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

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

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

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

仕事でミスを犯しました。自分は普段 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) {}; // OK with g++ and with VC++

    void Bar(boost::shared_ptr<Empty> e) {}; // OK with g++ and with VC++

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

#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 の実装と照らし合わせてこれから調べていくところです。