以下の内容はhttps://k0kubun.hatenablog.com/より取得しました。

開発環境現状確認 2026

@helloyuki_ さんと @giginet さんがやってて、自分との違いを眺めるのも面白いかと思ったので書いてみる*1。僕の以前の環境は 後悔しているがやめられない開発効率向上術、Neovimを一瞬でVSCode並みに便利にする、自作PC2023: Ryzenをやめた あたりで書いた。

OS

Linux、macOS、Windows の3つを、この順に多く使用している。使っている環境が多いほど面倒毎が増えるので、本当なら3つも使わない方が良い。

LinuxはUbuntu 24.04を使っている。よく使うDockerイメージやGitHub Actions環境と同じパッケージ名が使えたり、デスクトップアプリのLinux向けの配布が.deb か .rpm がメインなことが多かったりと、Ubuntuにしておく利点は多い。ただ、手元の Framework Laptop でUbuntu 24.04のGNOMEの調子が良くないという背景もあり、その辺のいじり易さからまたArch Linuxに戻したい気持ちもある。

macOSは、ペアプロアプリTupleがLinuxだと使いにくいのと、arm64向けのコンパイラ開発がApple Siliconマシンだと楽なので、渋々使っている。デスクトップ環境としては多分一番安定していて快適で、Apple Siliconの性能にも助けられているが、Rubyのビルドが何故かLinux環境の2倍くらい遅く、1日に何度もRubyをビルドする私の仕事には向いていない。 大体Linuxにsshして作業している。

Windowsは、Windowsでしか動かないアプリを起動することがあるのでまあ使う。開発環境は少し前に mintty + msys2 + mingw から WezTerm + WSL2 に切り替えたが、これは大分快適になったと思う。ただ、後述する修飾キーが押しっぱなしになる問題と、IME周りの挙動が突然変になりがちなのが不便で、単純にデスクトップ環境としてLinuxより不快なので、あまりこの開発環境には出番がない。

エディタ

Neovim を使っている。フロントエンドとしては、VSCode NeovimというVSCode拡張か、ターミナル上でCUIのNeovimを使っている。個人的にはGUIのエディタはあまり好かないのだが、マウスホバーでLSPの何かを出す設定をするのがCUIだと難しく、LSPのごちゃごちゃした出力を文字の寄せ集めで作られた貧弱なUIで見るのは大変しんどいので、Rustのような言語サーバーの補助なしで書くのが難しい言語ではVSCode Neovimを使っている。素のNeovimのLSP環境には今もcoc.nvimを使っている。

コーディングエージェント

Claude Code を使っている。AIに何かをやらせて放置したまま自分は別のことをやるという使い方をするので、ターミナル (というかtmux) の1タブで省スペースな管理ができるのはCLIの強みだと思う。同じプロジェクトに対して全く別のタスクを並列にできるよう、Claude Code用のソースディレクトリやビルドディレクトリを別途用意して作業させたりしている。SonnetとOpusを自分で考えて使い分けなくとも、デフォルトでいい感じにOpus 4.5に切り替えてくれるっぽくなったのは楽になった。

検索エンジンで答えを得るのが難しい問いは前からの癖でChatGPTに投げることが多いのだが、GPT-5になった現在、ChatGPTにプログラミング関係の質問を投げて質の低い返答を得た経験が度々あるので、Codexもそのうち試したい気はしているがあんまり期待していない。

ターミナルエミュレータ

WezTerm を使っている。以前はTerminal.appを使っていたくらいなので一番こだわりがない所なのだが、macOSからLinuxにsshして作業をする時、ssh先でクリップボードにコピーした内容を手元の環境にもコピーしてくれるエスケープシーケンス (OSC 52) があって、これがある程度モダンなターミナルじゃないと動かないので、常時ssh状態で仕事するようになった時WezTermに乗り換えた。GhosttyはWindowsだと動かないし、乗り換えるモチベーションもない*2。

ターミナルマルチプレクサ

tmux を使っている。ターミナル側でタブ管理や画面分割ができるのでtmuxを使わないみたいな人がたまにいるが、それに加えてセッションの永続化やアタッチ/デタッチができるのが本質だと思う。コピーモードで上述のOSC 52がシームレスに動くので、ssh先でtmuxを開くと、まるで手元のターミナルかのように快適に作業ができる。Lemonadeみたいにそれ用のプロセスを立てておく必要もない。

シェル

zsh。周りだとfishを使っている人もいるが、僕はシェルスクリプトプログラミング環境としてbashが一番慣れていて、それと互換性のないシェルを試すのは腰が重く、ずっとzshのままになっている。

ランチャー

後悔しているがやめられない開発効率向上術 で一番最初に書いた話だが、よく使うアプリケーションへのショートカット割り当てをキーリマッパで実現していて、今の設定は以下の通り。

  • C-h: WezTermにウィンドウ切り替え
  • C-u: Google Chromeにウィンドウ切り替え
  • C-o: Slackにウィンドウ切り替え
  • C-y: VSCodeにウィンドウ切り替え

10年以上やっている手癖なので今更やめられないのだが、EmacsバインディングのC-uを潰したのは悪癖だったなという気がしている。別物だが、かわりにC-a C-kを使うことが多い。

ウィンドウマネージャー

LinuxではGNOMEを使っていて、他のOSでもタイリングウィンドウマネージャーの類は使っていない。マシンを起動した後多少ポチポチしたら後は標準または上述のショートカットだけでウィンドウ管理が完結するので、3つのOSに対して同じ操作ができるタイリングウィンドウマネージャー環境を用意したとして、あんまり生産性は向上しない気がしている。OmarchyのHyprlandセットアップはいい感じだったので、Linuxで試したい人はOmarchyから入るのも良さそう。macOSだと、次試す時はAeroSpaceとyabaiあたりを触ってみたい。

フォント

Monaco を使っている。macOSだと最初から使われてる奴。fallbackにはHiragino SansかNoto Sans CJK JPをいれている。以前はInconsolataやそれベースのRictyを使っていたりしたのだが、Monacoにわざわざ変えた理由は忘れてしまった。VSCodeでmacOSとLinuxで設定を共有した上でフォントを同じサイズで見せるみたいな動機が最初はあったような気もするが、VSCodeの設定は結局OSごとにプロファイルを分けたので、それは関係なくなった。

ブラウザ

Google Chrome を使っている。会社ではこれ以外のブラウザの使用が実質禁止されているし、僕は使っているGoogleのサービス*3が結構多め (ストレージに課金もしている) だし、認証をGoogleログインに寄せて使っているサービスも多いので、その辺が何かとシームレスに動く(気がする)ブラウザを離れることはない気がする。

開発環境のセットアップ

mitamae というシングルバイナリで動く自作のプロビジョニングツールで環境設定を長らく自動化している。全てのOSで動き、レシピも腐ることがあまりなく安定して使い続けられている。

dotfiles

github.com

config/ に設定ファイルを置いておき、それらの配置やその他のセットアップをmitamaeにやらせている。単なる個人の設定ファイルリポジトリなのに割とGitHubスターがついていてちょっと嬉しい。

ノートテイキング

僕しかやってない気がするが、Slack でのセルフDMを主なメモ置き場として使っている。これは上述したウィンドウ切り替えショートカットの設定が関係していて、切り替えが簡単なデスクトップアプリ4種のうち、メモ取り対象になりやすいブラウザやエディタではないアプリがSlackで、かつSlackのログのメモ取りはSlack上でやるのが便利なので、僕の環境だとこれが開きやすく便利な気がしている。

Google Docs も使っていて、Slackでは短期的なタスク管理や簡易バックログ管理をし、Google Docsには中長期的なスケジュールや何度も見返したいメモを置いている。

キーボード

JIS配列のHHKB Hybrid Type-S (雪) を使っている。僕はErgoDoxを使っていた時期に自分は分割キーボードが好みではないことを学び、Kinesisは好きだったが外で使うには持ち運びに不便で、13インチのMacBookに綺麗にマウントできて持ち運びも快適なHHKBに落ち着いた。

僕は昔Emacsで小指を破壊した経験から、全ての修飾キーを親指で押すのだが、非分割キーボードでそれを快適にやるにはスペースキーの短さが必須で、HHKBのJIS配列はその点非常に優れている。ただ、スペースの横に並んでいるキーの傾きがデフォルトだと親指に角が刺さる感じになっているので、無刻印のキーを別途購入してFやJのある列の傾きのものに差し替えている。

キーリマッパー

Linuxでは拙作xremap、macOSではKarabiner-Elements、Windowsではのどかを使っている。どれも機能的には申し分ないのだが、Windowsでは前述の通り修飾キーが押してない時も押しっぱなしになる現象に悩まされていて、キーリマッパーを変えて直るならそうしたいが、特に何も試せていない。

SKK

Linuxではibus-skk、macOSではAquaSKK、WindowsではCorvusSKKを使っている。ibus-skkはメンテが終了しているのだが、バグを1つだけ自分で直したものを使っている。fcitx-skkへの乗り換えを試みたこともあったが、挙動がibus-skkに比べてモッサリしているのでやめた。AquaSKKは最高。CorvusSKKは、Windowsで突然IMEがCorvusSKKじゃない何かに切り替わってしまう問題は以前どうにか解決したのだが、IMEがSKKにセットされている時でも日本語入力が謎の亜空間に飛ばされることがあるので、Windowsを使いたくない理由の一つになっている。

まとめ

AIコーディング全盛の今、コードを書くための知識をつけるより、AIコーディングでも変わらず使われる開発環境を快適にすることがより大事になっているんじゃないだろうか。というのは建前で、いつまで経っても自分はdotfilesいじりをやめられないオタクだなと思ったので、今後も盆栽として続けたい。

*1:比較用に、順番は極力 @helloyuki_ さんの記事に合わせました

*2:あと、ベータ配布をやっていた時に、それがもらえるDiscordに招待してもらった後、ずっとmitchellhに無視され続けて試せなかったのを根に持っている

*3:Gmail、Google Photos、Google Drive、Google Docs、Google Sheets あたり

2025年にやったこと

社会人11年目、在米7年目。今年は

  • ZJITの開発を始めた
  • エスプレッソマシンを導入した
  • 子供がUSの小学校に通い始めた

という感じの一年だった。

仕事

YJITでできる性能改善の幅が構造的な理由で頭打ちになりつつあるという問題意識から、新メンバーのMax (@tekknolagi) を交えて2025年2月にチームで集まった時に次世代YJITのデザインの議論をし、ZJITの開発が始まった。1月の段階ではMaximeはRubyの動的な機能をある程度制限したサブセットに対してAOTするようなデザインを推していたが、Rubyのセマンティクスを制限するべきではない & しなくても高速化できるという僕のpushbackもあり、普通にJITを作り直す方向で話がまとまった。

YJITのどの最適化がRailsアプリに対して大きな影響があったかは大体覚えていたので、リリースするころまでにそれらを全て移植しYJITと同じくらいの速度にすることを個人的に目標にしていたが、間に合わなかった。ローカル変数や脱最適化の扱いがかなりアグレッシブになっているおかげで、新しく考えたSSA IR上で実現したいセマンティクスを成立させた上でテストを全て通すことに半年かかり、レジスタアロケータへの負荷も大幅に増えたコード生成に対応するべくバックエンドの作り直しとデバッグにも2か月、YJITに実装済みの最適化をZJITに全て移植しきるには時間が全然足りなかった。

その目標をどうにか達成しようとして時間の使い方をZJITの実装にかなり振り切った生活をしていた関係で、本番環境もあまり触らなくなり、チーム外とのコミュニケーションも大分おろそかになったためか、今年上半期の査定は過去最低の評価であった。下半期はJITチームに新人がかなり流入してきて、半分以上のメンバーがオンボーディングが必要な状態になったのだが、その方面での貢献が認められたのか、下半期の査定ではかつてないほど昇給した。このまま円安が続くなら、いつか年収1億円になるかもしれない。

発表

子供ができて数年はオンラインの登壇以外はRubyKaigiしか行かなくなって、コロナも収まってきてオンラインの登壇機会も途絶えてからはほぼRubyKaigiでしか発表しない人間に2022~2024年あたりはなっていたのだが、子供が大きくなってきた & 学校に預けている時間が大幅に伸びたのもあり、今年は発表の回数がここ数年よりは少し多くなった。

RubyKaigiでYJITの話をした後、他の3回はZJITの話をした。REBASEはシンガポールで行なわれた言語処理系関係の国際会議内で開催されたイベントで、オーガナイザから招待してもらってトークをしたのだが、アカデミックな国際会議で登壇の機会をもらったのは初めてで、良い経験になった。Rubyを知らないオーディエンスに対して話をするのが思ったよりうまくいかず、内容は散々な上に時間も余らせてしまった。サンフランシスコでRubyistに対して同じトークをした時は、時間の使い方も完璧で、ウケも良かった。東京で4年ぶりに日本語で話したら、盛り上がりすぎてどんどん早口になり、これも時間は余ってしまった(内容的には満足)。

執筆

去年の記事の最後で「まだ世に出せてない活動」と言及したのはとある執筆活動のことで、今年も進捗はしたのだが、プライベートの時間でやらないといけない雑務や他にやりたいことが当初想定していたよりも多く舞い込み続け、期待していたほど進んでいないというのが実情である。今年ブログの記事がこれだけなのも、何か書くならそっちを優先したかったからである。ここ数ヶ月は登壇やらRuby 4.0のリリースやらで何かと忙しくしていたが、それらは一旦落ちついたし、締切は2026年上旬に設定されているので、ここからがんばりたい。

OSS

現在もGitHub Sponsorsが20人ほどいる(本当にありがとうございます)ので、Shopify業務外でのOSS活動も仕事のカテゴリにいれておくが、上記のような理由からここに時間をかける余裕はあまりないものの、いただいている費用に見合うだけのメンテナンス活動はやっていた気がする。主にxremap、たまにhamlでパッチをマージする作業をせっせとやっていて、その2つは僕への依存度が高めな状態が続いている。sqldefは元々アクティブなメンテナが他にいたが、今年は @gfx さんが加わり、ものすごいペースで開発を継続してくださっているので、僕が見ていた時よりもかなり良い状態になっている。ありがとうございます!

生活

ダイエット

ほとんど運動せず食べたいものを食べる生活をしていたら、7月頭に体重が瞬間風速で98kgに達してしまい、近所に独立記念日の花火を見に行った時に @nahi さんに「ちょっと痩せた方がいいんじゃないか」という趣旨のことを言われ、そこから健康のためにダイエットを始めた。今回日本に帰省する直前は75kgを切った状態で安定していたので、一番太っていた状態から半年で23kgは痩せたことになる。

始めた当初、家族が少しの間留守にしていた関係で運動を自由にすることができ、定期的にランニングをしたりしていたのだが、家族が帰ってきてからは運動は難しくなり、食事制限だけでダイエットを継続した。最終的には、朝ご飯を抜き、家で飲むコーヒーにはミルクや砂糖は入れず、ソフトドリンクもゼロカロリーのものだけを飲み、間食は1日0~200kcal目安に抑えれば、毎週安定して痩せる状態になった。旅行などで少し良いものが食べられる環境にいる時は食事制限を解除して太ったりしたのだが、帰ってから元の食事制限を再開すると、割とすぐ体重が戻ることがわかったので、日本に一時帰国している今も好きに外食をしている。

エスプレッソマシン

今年になるまでエスプレッソマシンを触ったこともなかった僕だが、@draftcode さんが引っ越しをする際にエスプレッソマシンを譲ってくださり、そこから家でエスプレッソマシンでコーヒーを作る生活になった。一式譲っていただいたので、何も買い足さずとも使える状態だったが、もらったグラインダを故障させて買い直したり、自分好みのガジェットを買い足したりしているうちに、5~10万円くらいは自分でもコーヒーにお金をかけたような気がする。でも本体であるエスプレッソマシンは自分で買ったらその10倍の金かかるので、買ってる人たちはすごい。

最初はカフェラテだけを作っていたが、上述の通りダイエットを始めてからはコーヒーにミルクをいれなくなった。たまにエスプレッソそのままも飲むが、基本的にはアメリカーノにして飲んでいる。ダイエットコーラは家にあると飲みすぎる関係で買ってくることを妻に禁止されたので、家で飲める低カロリーの飲み物としてはアメリカーノが一番おいしい。

歯科矯正

2023年に始めた歯科矯正が、今年の早い段階で終わり、そこから夜はリテイナーをつけて暮らしている。歯科矯正をやることを決めた段階では、歯科矯正が終わった後も一生リテイナーをつけ続けないと歯列が維持できないことは全く把握しておらず、思わぬところで不便な生活になってしまったなという感じがある。とはいえ、リテイナーを使う生活にも慣れて、あまり気にならなくはなった。

レーシック

ひげの永久脱毛と歯科矯正で、見た目に影響のある人体改造を2つ経験したが、それはどちらも妻の希望があって選んだ選択だった。たまには純粋に自分の欲求だけで改造を施したいという気になり、日々の不便を解消できるレーシックをやることを決意した。事前の検査はもう済ませて、今は手術日を待っている段階で、年明けの頭に実際の手術を行なう予定。あと2週間もせず眼鏡生活も終わりである。

子供

今年夏に5歳になった子供は、4月に年度が始まる日本では幼稚園年中の年齢なのだが、8~9月に年度や学年が切り替わるアメリカでは1つ上の学年になっており、かつアメリカでは日本の幼稚園年長にあたるkindergartenは小学校の一番下の学年で行なわれるため、今年から小学校に通っている。元々週3の午前中だけ預けていたプリスクール生活から、週5で午後まで預けられる小学校生活に変わり、子供が家にいる時間が一気に短くなった。

学校の関係で英語に触れる時間の方が長くなっても、英語と日本語両方使える状態にしてあげたいという思いから、これまでは家で日本語だけを喋っていたため、kinderに入学した8月の段階では、英語はかなり遅れている状態だった。そこから4か月経った今は、英語を話す学校に長く通うようになり、それとは別にくもんでも英語の読み書きを勉強するようになってからは、英語はかなり上達している。くもんの宿題は毎日親が付き添って消化しているが、英語の発音をフォニクスで説明したりしていると、親も結構勉強になる。これからも親子でがんばっていきたい。

2026年は

今やってる執筆やZJITが、世に出す段階では自分が納得できる形にできるといいなと思う。来年もよろしくお願いします。

過去ログ

2024年にやったこと

社会人10年目、在米6年目。今年は

  • 家を買った
  • Rubyのブランチメンテナになった
  • 子供が日本語のプリスクールも行き始めた

という感じの一年だった。

仕事

Ruby 3.4でも引き続きYJITの開発をがんばった。いろいろやったが、予告通りローカル変数へのレジスタ割付をサポートしたのがメインの仕事で、これは今年の前半からリリース直前まで作業が続いた難産であった。 Ruby 3.3ではコンパイル時のメタデータを固定長のstructに保管していたのが、3.4では可変長のバイト列で保存するようになったため、レジスタ割付に使うメタデータも妥協のないものにでき、性能的に妥協のないものが出せた。 一方、YJITは現在のデザインでやれる最適化はかなり出しつくした感があり、Ruby 3.5ではYARV命令やbasic blockの境界を超えた最適化がもっと簡単になるべきだと思う。

Ruby 3.4は、it という機能を長年かけて提案し続けた結果ついにリリースできたバージョンでもある。 僕は _1 が入る前からこっちが欲しいという主張をしていて、実際 _1 が入った後も使ってみて違和感があったので、it が入ったことで気持ちよくRubyが書けるようになって嬉しい。

それから、RubyKaigi 2024に行った時にRuby 3.3ブランチのメンテナをやらないかというお誘いを受けて、現在まで継続している。 今も .0 や .1 のリリースはなるせさんが担当しているのだが、.2 以降は安定版ブランチメンテナに引き継ぐことに元々なっていて、安定版ブランチが3つあるうちの一番新しいのを僕が担当することになっている。 僕が入ってから変えたポイントとしては、最新の安定版ブランチは原則2か月おきリリースでかつリリース予定日もあらかじめ告知するようになったところがある。 半年くらい前から日付を決めた結果、その後に決めた年明けの休暇と被ってしまって僕がやや困ってはいるのだが、ユーザー的にはバグ修正の頻度が期待と外れにくくなって嬉しいといいなと思う。

家

買った。厳密には家 (一軒家) ではなくcondominiumで、要するにアパートの一室を買っているような感じなのだが、住所は部屋番号じゃなくて番地がまるごともらえるので、その点は何か家所有している感が出ている。

前住んでいたマンションは、その綺麗さと新しさの割にはとても安い物件で、ほとんどの条件であれ以上のものは望めないと思っていが、学区という一点にのみ問題があった。 今回買った物件は、すごいガチガチのお受験地域とまではいかないが、そこそこいい学校に通える地域で、綺麗でお安く、十分な広さの物件だったので、見た瞬間自分の中では即決という感じだった。

今家を買うのには問題があって、アメリカではローンの金利が7%くらいが相場なのでとても高いのだが、全部キャッシュで出すという力技によりこの問題に対処した。 結果的に資産の大部分が不動産になってしまい、そこそこのオポチュニティコストがかかっているが、それ込みでも同条件の賃貸に住むよりお得そうな計算になるくらい良い条件であった。

IoT

IoTというものにそこまで興味はなかったのだが、賃貸ではない自分で改造し放題の家を手に入れた結果、目の前の不便さを解消し続けるうちに、気がつけば家がIoTガジェットだらけになっていた。

一番便利なのはスマートロックである。Apple HomeKeyに対応していて、iPhoneやApple Watchをかざすだけで鍵が開き、スマホのロック画面で鍵の閉め忘れにすぐ気付け、誰がいつ鍵を開けたかも見れるので大変便利。 このスマートロックが我が家のIoT第一号なのだが、Apple HomeKeyを使うためにPixelからiPhoneに乗り換え、Apple HomeKitのためにApple TV (Fire TV Stickの方が便利なのでTV機能は一切使ってない) も設置するはめになった。

あとはまあガレージのドアを開閉する奴が便利。最初レイテンシを懸念してBluetoothで直接通信する奴を使っていたが、Wi-Fiで通信する奴の方がHomeKitの連携などが便利で、特にレイテンシの問題もなく、便利だった。 スマートロックと同じく、iPhoneのロック画面でガレージのドアの閉め忘れに気付けるし、15分くらい開けっぱなしだと通知も送れる。

他にはスマートスイッチやスマートプラグとかが入っていて、リビングが2つ独立した照明がないと明るくならず、それを同時に操作するためにスマートスイッチを押すと二つの照明がつき、 他の照明を直接操作しても残りのスイッチと照明に状態が同期される地獄の分散システムになっている。 自分の部屋の照明もスマートスイッチでコントロールしていて、寝る前に部屋の照明を切るのをスマホからやったりしている。

それから、最初から家にあった洗濯機と乾燥機が小さい上にやや汚なめだったので買い替えたのだが、これもスマホと連携できるやつにして、洗濯や感想の終了後にスマホに通知を送ることで洗濯物の乾燥機への移し忘れ、たたみ忘れなどを防いでいる。 クーラーやヒーターもスマホに連携していて、家の外でつけたり、スケジュールを細かく指定できたりする。

子供

子供は英語のプリスクールに1年くらい通って、英語の環境にはある程度慣れたということで日本語のプリスクールにも通い始めた。 元々通ってた英語のプリスクールでも学年の変化後に仲の良い友達ができて、日本語の方でも友達を作ってきたので、親に似て内向的なのに友達と楽しく過ごせているようで嬉しい限り。

アメリカの小学校は幼稚園の年長にあたる年齢からKindergartenという形で始まるのだが、うちの子も来年それに入れる年齢なので、今月その申し込みを終わらせたところである。 日本とアメリカでは年度の区切りの月が違う関係で、日本の学校ではまだ年少の年齢なのだが、アメリカの方の学校だともう小学校に入るかと思うとすごい違いを感じる。

子供はテレビを見るのが好きで結構いろいろ見ていたのだが、長く見ていた奴では パウパトロール→おしり探偵→リラックマ(Netflix)→チキップダンサーズ→プリキュア→妖怪ウォッチ という感じだった気がする。 怖がりなので怖いシーンがあると試聴をやめており、例えばポケモンは戦闘シーンが怖くてすぐ見るのをやめ、プリキュアは割と試聴が続いたものの後の方で怖い悪役が出てきてやめたが、 妖怪ウォッチは戦わずに友達になって終わるし、怖い雰囲気のキャラも少なくて子供にやさしい。 この手のアニメはNetflixがラインナップが充実していて頼りにしていたが、U-NEXTの方がもっと充実していることに気付いて今はそれをメインで使っている。

2025年は

今年は新居での生活、税金、子供の学校などのための事務処理や、家で必要なものの選定などをやっていたらそれが思ったより時間を使ってしまい、 それ以外の活動の予定がズルズルと先延ばしになりがちだったのを来年はどうにかしたいと思う。 まだ世に出せてない活動がある(その関係でこのブログの更新も滞っていた)のだけど、それに使う時間管理をちゃんとやって、2025年中にある程度形になればいいなと。

他にも書けることはある気がするけど、年末に日本に一時帰国してからの日が浅く、時差ボケで眠いので今年はこの辺で。良いお年を。

過去ログ

AIにプログラミング作業を奪われている

せっかく10年以上かけて学んだプログラミングだが、人間がコード書くよりChatGPTにやらせた方が早いなということが度々あり、だんだん自分でプログラミングをやる時間が減ってきた。AIにコードを書かせてそれをGitHubにコピペして残りの時間は遊んでるだけで成果が出てお給料ももらえる日は近いし、段々会社もそのことがわかってきて失職する日も近い。

残念ながら現時点では全ての仕事がAIで上手くいくわけではないが、どういう時に使えるかを知っておくと楽をしやすくなるので、僕がどう使っているかをまとめておく。

失職できるケース

簡単なスクリプトを高速に書かせる

僕はRubyが全ての言語の中で一番慣れており、StackOverflowやドキュメントをほぼ見ずに大抵のプログラムを書き切れるため、Rubyを書いている時がプログラマとして一番生産性が高いのだが、それでも最近AIにRubyを書かせたことがあった。

数行で書けるほど単純ではないが複数ファイルが必要なほど複雑でもないみたいな時、欲しい仕様を入力する時間が十分に短ければAIにやらせた方が生産性が高いことになる。人間が次に何を書くかを考えながらキーボードタイプするより、言語モデルがテキストを出力する方が圧倒的に高速なので、当然そういうことになる。

具体的に何に使ったかというと、本番環境で走っているアプリケーションサーバーのワーカーのメモリ使用量に各コンテナ内で偏りがあり、アプリ内から取っているメトリクスはリクエストが来た時にしか飛ばないので、メモリ使用量の分布をプロセスの外から調べて綺麗に整形するスクリプトが欲しいということがあり、それを書かせた。

成果物はこれなのだが、要件を伝えて、何度か出力の整形方法に関してフィードバックするだけで完成した。まあこんなのは書いてても楽しくも何ともないので、AIにやらせたらいいと思う。

書くのが面倒な言語を書かせる

どこでもRubyが使えたら僕は楽なのだが、世の中には主なスクリプト言語としてPythonを採用しているツールがそこそこある。仕事で長い間使っていたこともあるし僕も普通に書ける言語ではあるのだが、たまにStackOverflowを見に行かないといけない程度には不慣れなのでそういう点で面倒くさい。

そういったツールの一つがLinux perfというプロファイリングツールで、これはプロファイル結果をスクリプトに集計させるperf scriptという機能があるのだが、Pythonなどの言語で書かないといけない。perf scriptは何度も書いたことがあるが、Pythonは僕はStackOverflowを開かないと書けないのが面倒くさいのでAIにやらせることにした。

とりあえず書かせてみたら、perf scriptのインターフェースを何故か知らなかったようなので、以前書いたスクリプトをコピペしたところ仕様を理解してもらえた。その後は欲しい仕様を伝えて、必要な仕様が変わる度にそれを伝えたら都度欲しいものができた。成果物はこれ。

自分が詳しくない環境を扱わせる

僕は私用にはLinuxを使い、仕事ではmacOSを使わされているのだが、Windowsはあまり触らないため詳しくない。ruby/rubyのCIでVisual Studio 2019上でVisual Studio 2015相当のC言語環境をセットアップする必要があったのだが、まるでやり方がわからなかったので、当時使っていたGitHub ActionsのYAMLを貼り付け、書き直してもらった。

例えば vcvars64.bat -vcvars_ver=14.0 と書くとVisual Studio 2015相当で、その結果 C/C++ Optimizing Compiler Version 19.00.24247.2と出たら2015で、19.29.30153だと2019なのだが、こんなわけのわからないバージョンスキームを採用しているWindows環境を理解するのは人類には不可能なので、AIにやらせると良い。

他には、会社のKubernetes環境で特定のラベルを持つPodを探して中に入る必要あったのだが、Kubernetesを採用していないインフラを触る期間が続いたため全然使い方がわからず、一連のコマンドをAIに書かせたりした。エラーにも遭遇したが、エラーを貼りつけたらAIがデバッグしてくれた。 Kubernetesも人類には難しすぎるので、AIに使わせると良い。

自分でやった方がいいケース

必要な入力が大きい

僕がLLMを使う時は基本的にChatGPT (GPT-4) を使っているのだが、インターネット上のこのファイルを読んでくれとか、コンテキストに収まらないほどでかいファイルを貼り付けてこれを読んでくれみたいなのは少なくともデフォルトのチャット画面からはできないので、ChatGPTに渡す情報量がある程度小さくないとワークしない。

例えば膨大なRuby処理系のコードを読み込んでそこに最適化を実装するみたいな作業は、それを任せるのに必要なコンテキストが大きすぎて伝えるのが難しいので、自分でやっている。目的のコードに似た実装を持つ関数を1つ渡して書かせてみたこともあるが、自分で書いたヘルパー関数の定義なども渡さないと正しく使ってくれない。

そういう状況だとGitHub Copilotの方がインターフェース的には向いてるような気がするが、なんというか所詮コード補完だなという感じの結果になることが多くて、AIに渡すコンテキストを自分でコントロールしないと、読んで欲しいところを読んでくれてない感じになる。

大体書けていて細かい手直しだけ必要

チャットでAIにコードを書いてもらうと、何か修正が必要になった時に全て書き直しになるため、コードが長ければ長いほど再生成に時間がかかる。何十行もあるコードで、自明な変更を一行足すくらいだと、AIにやらせる方がかえって生産性が低くなる。

また、何度もやり取りを繰り返すと、それ自体大きなコンテキストになってしまい、最初の方に言ったことを忘れてしまう。これ忘れとるやんけ、と伝えると、その前に伝えた別のことを忘れてきたりする。ある程度できてきて簡単な修正で完成する状態になったら、人間がやってしまった方がいいこともある。

まとめ

いかがでしたか? 人類はまだ失職できないことがわかりました!

2023年にやったこと

今年で30歳、社会人9年目、在米5年目になった。今年は

  • 趣味でRJITを作り、仕事でYJITを超高速化した
  • 初めて論文を国際会議に投稿し、採択された
  • 子供とプリスクールに行き始めた

という感じの一年だった。

仕事

大変ありがたいことに、自分が今一番興味のある仕事であるYJITの高速化に集中できた一年だった。 いろいろやったが、代表作は以下の三つかなと思う。

どれもベンチマークがかなり速くなった。 特に二つ目と三つ目は、自分で発案してかつ主に僕が重要性を訴えていた奴で、 それらで大きな成果が出たときはかなり達成感があった。 単独のPRでRailsベンチが7%速くなった時はこりゃ昇給するわと思ったが、実際めちゃくちゃ昇給した。

ベンチマークも速くしている一方、僕は本番アプリの最適化を主戦場にしていて、 最適化のヒントになるメトリクスをひたすら追加し、 毎週のようにRuby masterを本番にデプロイし、効果を計測することを繰り返した。 Ruby 3.2ではYJITによる高速化が10%程度だったのが、 Ruby 3.3では弊社最大サイズのアプリ(モノリス)と最大トラフィックのアプリ(StoreFront Renderer)がどちらも YJITで17-18%くらい高速化する状態になった。 チーム全体での成果であるが、上記の変更は目に見えて効果があった。

論文

YJITに関する論文を業務で書き、MPLRという査読付きカンファレンスで採択された。

僕は去年修士を卒業したばかりで、在学中に論文形式のものは何本も書いたのだが、 そもそも修士論文なしで卒業するプログラムなこともあり、論文をどこかに投稿するようなことはなかった。 チーム内にYJITの作者がいるため僕はファーストオーサーではなかったが、 執筆的にも論文のトピック的にもそこそこ貢献したため、セカンドオーサーであった。 学士でも論文を投稿することはなかったので、これが初めての論文投稿経験となった。

修士で取った授業のうち一つは研究の仕方そのものや論文の書き方を学ぶためのものだったので、 論文の執筆には少なからず興味があったし、個人の時間で書くほどの余裕はなかったので、業務で経験できて良かった。 ポルトガルでのカンファレンスだったが、学部時代にお世話になった先生にばったり会ってご挨拶できたのも良かった。

子供

子供が三歳になり、プリスクールに行き始めた。 三歳だとオムツが外れてないといけないプリスクールがほとんどで、 娘はまだオムツをしていることにより選択肢が限られているのと、 あと単純に費用が安いので、Co-Opのプリスクールを選んだ。 Co-Opというのは親参加型の奴のことで、当番制でお手伝いをすることになっている。

月に一回有給を取って子供と一緒にプリスクールに登園してそのジョブをやっている。 あと不定期に資金調達のためのイベントが行われいて、その手伝いもやっているし、 休日の午前を使って大掃除するのも何回かやっている。 プリスクールに行き始めれば子供を預けられる時間ができると最初は考えていたが、 子供が一人で登園するのを嫌がるため常に妻か僕が一緒に行っていて、 今のところ育児の負担はむしろ増えている。

資産

僕のポートフォリオはThree-fund portfolioという奴で、 資産のほとんどをUS株72%、(US以外)全世界株18%、US債券10%で持つ状態を3年くらい維持している。 US株以外の資産は去年の下がりをようやく取り戻したくらいの状態だが、US株が好調なのでトータルではものすごくプラスになっている。 巷ではいわゆるオルカンが流行っているが、 これもUS株を60%持つインデックスなので良い利益が出るんじゃないだろうか。

USでは総資産が$2M (2億8000万円) 以上あるとグリーンカードを放棄する時にExit Taxという税金が取られることになっていて、 今はその半分くらいまで進捗したのだが、 僕は全資産に対して何割か課税されるという勘違いをしていたのでこれまで結構ビビっており、 $2Mに達する前に日本に本帰国するのを検討していた。 よく調べてみると、実際には資産ではなく未確定のキャピタルゲインに対して課税されるということだった。 自分が覚悟していたほどは課税されなそうなので、帰国は完全に家族の都合だけ見て決めればいいなと思った。

散財

テスラ

ここ数年値上げを続けていたテスラの値段が、電気自動車の税制優遇の関係で今年何度か下がった。 一番最初に大きく下げた直後に、中古の2015 Mazda 3から新車の2023 Tesla Model 3 RWD ($43,990) に買い替えた。 僕は自動運転が欲しくて買っていて、普段は無課金のAutopilotを酷使し、連休中の現在は一時的にFull Self-Driving (月額$199) を試しているのだが、どちらも便利だし、乗り心地も良い。 妻も満足しているようでよかった。

歯科矯正

アメリカのママ友に歯並びの良い人が多いようで、妻が歯科矯正をやり始めた。 僕はあまり興味はなかったのだが、妻がやって欲しいと言っていたのと、 歯並びが良い方が歯磨きがしやすくなるという話に説得され、僕もやり始めた。 一人 $5,000 以上かかっていて高いし痛いのだが、終わったらどうなるのかは楽しみである。

登壇

以下の2回登壇した。 今年は社会人になってから最も登壇数が少ない一年だった。 リモート登壇はもう少し自分から応募するなどしても良かった気がするが、 物理参加枠はRuby Infraチームでニューヨークに集まった奴と、YJIT論文でポルトガルに行っていた分で家族に負担をかけたので、 これが限界と思われる。

ポッドキャストでは初めてRemote Rubyに出させてもらった。 同僚が結構出ているシリーズなので、入社したころに結構聴いたのだが、自分も出れて良かった。

ブログ

今年は日本語では9記事ほど書いた。 書きたいネタを思いついた時に衝動的に書いていたのだが、 おおむね例年くらいのペースで投稿し、ブクマもそこそこ集まった。 どれも楽しく書けたので、そういう感じで続けたい。

Hacker News上でアクティブな同僚が多いので僕もHacker Newsのフロントページに乗るかどうかということを気にするようになったが、 英語で投稿したものは2回ほどランクインし、英語圏でランキングを上げる経験も積めるようになってきた。

OSS活動

RJIT

今年の新作はRJITだけである。 最初いくつかのベンチマークでYJITを抜いてしまった結果、 YJITを仕事にしている都合これはconflict of interestになり得ると言われたり、 RJITの話ばかりしているのがお気に召さなかったのかTwitterでリムーブされたりしたため、 その辺を丸く収めるべく、出した直後は意識的に開発速度を落としていた。 とはいえ、やりたいことはいろいろあるプロジェクトなので、来年もほどほどのペースでいろいろやれたらいいなと思う。

RJITとYJITを両方開発していた関係で、 今年は過去1年間のコミット数がnobuさんを超えた瞬間もあったのだが、 上記のRJITの件と、論文執筆やリリース前のバグ修正で失速し、 Ruby 3.3もnobuさんの方がコミットが多かった。 nobuさんはすごい。

sqldef, xremap

去年に引き続き、 個人でやってるOSSではsqldefとxremapが一番盛り上がっている。

sqldefはmssqldefで@odzさん、psqldefで@hokacchaさんが新たにメンテナに就任し、 大変心強い。メンテナ5人体制になったので、 リポジトリも個人アカウント下からsqldef orgに移管しsqldef/sqldefとなった。

xremapもスターが☆1,000を超えた。mrubyで書いていたころはhanachinさんもメンテナだったが、 Rustに書き換えてからずっと僕だけでメンテしている。 普段のissueのやり取りでも、sqldefはGoだから皆書いてくれるが、xremapはRustなので書けないと言われることが多い。 正直sqldefもRustで書き直してenumやパターンマッチを使ったりしたいのだが、 人類のほとんどはRustを書きたがらないため、sqldefの方はGoのままにしておくか…という気持ちである。 「は? Rust書くの簡単やろがい」と思った人には、xremapの共同メンテナとして無双していただければと思う。

2024年は

今年はYJITが大幅に速くなるアイデアを運良く複数思いついたが、 来年はそれに再現性を持たせられるようにして、 誰も想像していなかったような方法でYJITを無限に速くし、無限にお金を稼ぎたいと思う。

過去ログ

Ruby 3.3でYJITを今すぐ有効にすべき理由

Ruby 3.3がリリースされた。YJITには非常に多くの改善が含まれたリリースだったが、 NEWS解説記事やリリースパーティーでは 2点しか触れられなかったので、この記事ではRuby 3.3でYJITがどう改善されたかについて解説する。

YJITは既に実用段階

YJITはRuby 3.1で導入されたが、Ruby 3.2の時点でexperimentalのマークが外れ、実用段階となった。 Ruby 3.2では、以下のような企業で性能改善が報告された。

弊社Shopifyで最もトラフィックが多いアプリでは、 Ruby 3.2の時点でのYJITによる高速化は10%程度だったが、 Ruby 3.3では17%高速化まで改善した。 YJITを本番で使っている全ての人にRuby 3.3へのバージョンアップをお勧めしたい。

我々はRuby 3.3.0のリリースを安定化させるべく、リリース前からRuby masterを本番のモノリスに全台デプロイしていた。 現在はリリース版Ruby 3.3.0が走っており、YJITも有効になっているが、Ruby masterを使っていた段階で数多くのバグを弊社が発見・修正したため、 Ruby 3.3.0は比較的安定したリリースになっているはずである。

YJIT本番運用のための手引き

ここまで読んで「YJIT使うぞ!」となって使ってみたが思うように性能が改善しなかった人のために、 本番運用のためのドキュメントへのリンクを貼っておく。

Ruby 3.3で本番運用に便利なツールが増えたため、バージョンごとに少し内容の異なるドキュメントを管理している。 Ruby 3.2時点での日本語の記事としては YJITの性能を最大限引き出す方法 がある。 Ruby 3.3で便利になった点は以下で解説する。

Ruby 3.3のYJIT改善点

前置きが長くなったが、ここからNEWSで触れられている改善点について解説していく。 運用方法に影響がある点から順に書いていく。

Code GCのデフォルト無効化

YJITが生成するコード量は --yjit-exec-mem-size でコントロールできる (デフォルト64MiB)。 生成コードのサイズが --yjit-exec-mem-size に達すると、YJITはデフォルトで以下のような動きをする。

  • Ruby 3.2: 全ての生成コードを破棄し、以降呼ばれたメソッドをコンパイルし直す。
  • Ruby 3.3: 新たにメソッドをコンパイルしなくなる。未コンパイルのメソッドはインタプリタ実行される。

Ruby 3.2のこの挙動をCode GCと呼んでいる。 数時間に一回Code GCが走る程度なら大した性能影響はないのだが、 --yjit-exec-mem-size が小さすぎると、頻繁にコンパイルし直すコストによってアプリがむしろ遅くなる場合がある。

こういった問題にヒットしにくくなるよう、Code GCはデフォルトで無効になった。 これの最大の利点は気軽に --yjit-exec-mem-size が下げられるようになった点で、 RubyVM::YJIT.runtime_stats[:code_region_size] を参考にしつつ、 --yjit-exec-mem-size=32 のような設定を使うのが現実的な選択肢になった。

もう一つの利点にCopy on Write フレンドリになる点がある。 弊社ではモダンなUnicornフォークであるPitchforkを使っているが、 これは既にリクエストを捌いているワーカーを定期的にフォークし直すことでプロセス間のメモリ共有を目指すリフォーキングという機能が備わっている。 リフォーク対象のサーバーが既にYJITのコンパイルを停止済みなら、 YJITが使うメモリは全ワーカー間で共有し続けられることになる。

RubyVM::YJIT.enable の追加

YJITはこれまでコマンドライン引数 --yjit や環境変数 RUBY_YJIT_ENABLE=1 で有効化するしかなかったが、 それらを使わずとも、Rubyコード内で RubyVM::YJIT.enable を呼び出すだけでYJITが有効化できるようになった。

開発中のRails 7.2ではこれを呼び出すイニシャライザがデフォルトで生成されるようになった。 つまりRailsではこれを使ってYJITがデフォルト化されたということになる。

もう一つの利点は、YJITの起動を遅延させることで、 アプリ初期化後は使われないコードのコンパイルを避けメモリ消費量を削減できる点である。 Railsのイニシャライザでも効果はあるが、理想的にはUnicornのafter_forkやPumaのafter_worker_forkから呼び出すと良い。 これにより、起動するワーカーの半分だけYJITを有効化し、インタプリタと性能を比較する基盤として利用することもできる。

なお、--yjit-exec-mem-size などのチューニングオプションも指定するだけでも起動時にYJITが有効化されるため、 その場合も遅延起動するには --yjit-disable を明示する必要がある。

一部YJIT statsのデフォルト提供

RubyVM::YJIT.runtime_stats[:yjit_alloc_size] がデフォルトで提供されるようになった。 これはYJITがRustのヒープにアロケートしているメタデータのサイズで、:code_region_size と合わせると、 YJITが使っているメモリをバイト単位で監視できる。 YJITを運用する際は、この2つだけでも見ておくと --yjit-exec-mem-size のチューニングの参考になる。

また、RubyVM::YJIT.runtime_stats[:ratio_in_yjit] が --yjit-stats 時にデフォルトのビルドでも提供されるようになった。 これはRuby VM上で実行される命令のうち何%がYJITで実行されたかを示すもので、 理想的には最大99%くらいが望ましいが、アプリによってはこれが平均90%とかでも18%高速化したりする。 速度を妥協して --yjit-exec-mem-size を下げる場合は、これがあまり下がり過ぎないように気をつけると良い*1。

NEWSにはないが RubyVM::YJIT.runtime_stats[:compile_time_ms] も追加されており、デフォルトで使える。 これはYJITがコンパイルに使った累計時間を出すもので、例えばリクエスト前後で呼んで差を取ると、 そのリクエストでのYJITのコンパイルのオーバーヘッドを見ることができる。GC.stat(:time) に似ている。

YJITのメモリ使用量の削減

Ruby 3.2の時点でRustの省メモリ化の努力はあったが、 Ruby 3.3でもRcのかわりにBoxを使ったり、ひとつのu8に様々な意味のビットを詰めまくるといったチューニングが行なわれ、 YJITが使うメタデータのサイズは大幅に小さくなった。 Ruby 3.2とRuby 3.3で :code_region_size が同じ程度であれば、:yjit_alloc_size にあたる部分は大きく削減されるはずである。

それから、--yjit-cold-threshold という概念が追加され、あまり使われないメソッドのコンパイルをスキップするようになった。 また、--yjit-call-threshold がデフォルトで30なのが、メソッドやブロックが4万以上あると120に自動で引き上げられるようになった。 これにより、コンパイルしてもあまり性能に貢献しないメソッドがコンパイルされなくなり、メモリ使用量が節約される。

高速化

Ruby 3.2の時点では、YJITがコンパイルに対応していないパスがそこそこあり、 --yjit-exec-mem-size が十分でも :ratio_in_yjit が90%程度に留まることがあった。 記事が長くなってしまったので詳細は別の機会に語るが、 Ruby 3.3ではこれらの問題をほぼ解決し、ほとんどのアプリで :ratio_in_yjit が99%に達するようになった。 Ruby 3.2だと運悪くYJITの対応率が低かったアプリでも、Ruby 3.3なら速くなることが期待できる。

あとは、特別な最適化が実装されたCメソッドの数が増えており、 NEWSで言及している奴のことだが、 それらはインライン化もされる。 また、単に即値を返すRubyメソッドのインライン化も実装され、具体的にはRailsのblank?とかがmov命令一発になるのだが、 present?の方もRails 7.2では同じ最適化が期待できるようになった。

まとめ

あなたとYJIT、今すぐ RUBY_YJIT_ENABLE=1

参考文献

*1:--yjit-stats のかわりに RubyVM::YJIT.enable(stats: true) でもstatsが有効化できるので、これを使ってPumaやUnicornのワーカーのうち1つだけstatsを有効にしておくと、比較的楽にratio_in_yjitが監視できて便利かもしれない。

エンジニアが給料を12倍にする方法

はてブの人気エントリーに日本のエンジニア達は海外に出なければいけないという記事があった。 カナダ在住で経験年数4年のソフトウェアエンジニアで年収1600万円の方らしく、 日本より海外の方がソフトウェアエンジニアの給料が一般に高いので海外に行くべきという話が書かれている。

実際僕も居住地域による給与差を利用すべく渡米し、先月の記事 では新卒から数えて8年で年収が12倍になっていた話も紹介した。 一方、年収1600万円であれば海外に出なくても稼げると思っているので、 国内にいてもできそうなものも含め、ソフトウェアエンジニアとして給料を上げる上で過去に活用したハックを紹介していきたい。

昇給履歴

新卒入社

僕が新卒で入社した会社の当時の初年度給与は450万円だった (公開情報)。 大学の4年間はずっとアルバイトとしてソフトウェアエンジニアをやっていて、 3社を渡り歩いて時給は800〜1350円という感じだったが、それに比べると正社員というのはすごい額の給料がもらえる。 経験年数というのはビザの取得とかにも影響してきたりするので、正社員にはさっさとなってしまうのが良い。

外資転職

新卒社員として1年11か月働いた後、外資の会社に転職した。 東京のエンジニアポジションだと、この会社の最低年俸は800万円とかである (公開情報)。 新卒2年目の間に年収800万円に達していたら昇給RTAとしてはまあまあという感じがする。

転職の前に転職ドラフトに参加していたのだが、 ありがたいことに外資ではなくともこれくらいの額の指名が結構いただけ、 1000万円で指名していただけた会社もあり、そのあたりを根拠にこの転職での給与を交渉した。

外資なら、日本にいて年収2000万円の人もざらにいるので、 年収1600万円は外資であれば日本でも割と有り得る話だと思う。

買収

僕はこの会社にシリーズCの資金調達直後に入社したのだが、その1年後に会社が買収された。 この時社員からミリオネア (つまり1億円もらった人) が50人以上生まれたらしい (公開情報) のだが、多分僕もそれにカウントされてそうな程度にはお金をいただいた。 この額がどう支払われたかは公開情報ではないが、買収後は4年間在籍してるわけで、 4年で1億円以上もらえてる場合の年収は…まあそういうことだ。

有望そうなスタートアップを見つけたらなるべく早いうちに入っておくと、 日本でも一発で大金を得られるチャンスになるかもしれない。

渡米

買収で得られる収入はボーナスのようなもので、基本給にあたる部分は東京のエンジニアらしい推移を続けていたが、 渡米した段階で年収が増えて $151,491 になった (公開情報)。 当時の為替で1600万円。アメリカの就労ビザであるH-1Bビザを申請する時、 給与は最低このくらいないといけないというガイドラインがあって、 僕の地域のSenior Software Engineerの当時のPrevailing Wageがこれであったと記憶している。 なので、シニアエンジニアがH-1BでSFベイエリアに渡米すると、最低でもこの年収はもらえることになる。 今の為替だと2200万円になる。

僕の経験上、どこの会社でも従業員の現在の住所に従って給与には傾斜がかかる。 例えアメリカの会社に勤めていても、 例の記事の人のようにカナダ在住であればアメリカのNYやSFから勤めるのに比べたら給与は劣るはずだし、 日本からだとそれより更に低くなる。 逆に僕はカナダの会社にSFベイエリアから勤務しているが、多分カナダの本社周辺の人たちより良い傾斜がかかっている。

つまりニューヨークかサンフランシスコに住みましょうという話になるのだが、 どっちも治安は最悪である。その点、サンフランシスコから少し南のシリコンバレーのあたりは、 田舎なので治安が少しマシで、給料はサンフランシスコより若干劣る程度で、日本食も豊富なのもあり、 いいバランスだなと思ってそこに住んでいる。

昇進

外資だと、マネージャーにならなくてもIndividual Contributorとしてそこそこ昇進し続けられるのが普通である。 Senior, Staff, Principal, Distinguished あたりが割とメジャーなタイトルで、 タイトルがインフレすると間にSenior StaffとかSenior Principalが挟まってくる。 目の前のタスクに集中するのではなく、多くのチームをまたいだデザインやリードをやるようにしていると、 タイトルが上がる。

これらのタイトルはそれぞれ役割が異なるので、単に別の仕事として位置づけて給与に連動させない会社もあるが、 まあ普通はジョブタイトルごとに給与のレンジがあり、それはlevels.fyiを眺めればすぐにわかる。 なので、なるべくビジネスインパクトの大きいタイトルにポジションチェンジを続けると、ついでに給与も上がる。

この会社では僕はStaffまで昇進した。 その際の給与交渉の額の参考にするために他の会社のリクルーターと話したりしていたが、 このタイトルでのSFベイエリアでのスタートアップの基本給の相場は $180,000 みたいな感じだった。 今の為替で2700万円。

大企業転職

この会社で2度目のEXITチャンスが見えてきて、 僕は2億円欲しいと公言していた。 これは在籍し続ければ実現する可能性は十分にあったが、 コンパイラが書きたくなったので転職した。 それができる会社がたまたま社員1万人だっただけなのだが、 スタートアップから一転、上場済みの大企業に移ることとなった。

スタートアップだと一発当てない限りは前述の $180,000 からそれほど年収が増えないイメージだが、 大企業だと2億円みたいな夢はないかわりに、安定して高い年収が得られる。 例えばAmazonのSeniorにあたるポジションは年収 $360,300 くらいらしい (ソース: levels.fyi) ので、大体倍くらいになるということ。 ちなみにこのポジションはリクルーターに話しかけられて受けたのだが、もらったオファーも実際そのくらいの額だった。 実際にはこのオファーは蹴ったわけだが、今の為替だと5400万円で、新卒の450万円の12倍ということになる。 円安じゃなかったとしても8倍はある。

こういった相場感を適切に調べておき、複数の企業からオファーをもらっておくと、 このくらいの額がもらえるような交渉ができる。

この辺は日本にいても当てはまる話で、例えばGoogleでSeniorまで昇進できた場合、 日本オフィスでも $265,266 (4000万円) とかもらえるようだ (ソース: levels.fyi)。

Q&A

お金に執着しすぎでは?

そう思う人は多分お金に困ったことがないのだろう。 学生時代に貯金を全て親の借金の返済に使われ、 大学院進学を経済的理由により諦めたといった経験から、 貧乏に対して常に強い不安を感じ続けている。 実家は家のローンの返済に苦労しているが、 自分の家族は家も教育も不自由なく得られるようにしたい。

起業した方が稼げるのでは?

それがそんな簡単に上手くいくかはおいておいて、 僕はやっぱりコンパイラが書きたいというのが最初にあって、 経営ではなくコードを書くのに集中できるロールのままお金もいっぱいもらえる状況を望んでいる。

海外だと物価も高いのでは?

これはよくあるエアプコメントだと思う。例えば給料と出費が両方4倍になる時、手元に残るお金も4倍になることになる。 実際には、給料が12倍になった期間、例えば家賃はせいぜい4~5倍にしかなってないので、もっと残る。 僕の場合は老後は日本に帰るつもりなので、その残ったお金は低い物価の国で消費することになる。 もっと話を単純にすると、これくらい収入があると1年で数千万資産が増えるのだが、 日本にいたらそもそも額面で数千万受け取るのが大変だと思う。

海外だとレイオフされるのでは?

ビザの状況によっては割と深刻な問題だと思う。 僕の場合はもうグリーンカードを持っているのでそこは安心。これを書いた次の日にレイオフされるみたいなリスクはあるが、 普通は数ヶ月分給料がもらえるし、その間にまともな転職ができそうな程度にはリクルーティングメールは来続けてるので、 少なくとも金銭的な心配はない。個人的にレイオフされたら困るのは、自分がやりたい仕事ができなくなることくらいである。

まとめ

海外に住むと、日本語は使えないし、趣味や食事や医療などの選択肢や治安などが変わってくる。 家庭がある場合は家族にも影響がある。

「日本のエンジニア達は海外に出なければいけない」と結論づける前に、 海外に行くことで得られる給料が本当にその変化に見合うものなのか、 またそれは日本では達成できないものなのか考えておくと今後のためになる。



以上の内容はhttps://k0kubun.hatenablog.com/より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14