いわゆる転職エントリ、その後
入社して 3 週間、在宅勤務 2 週間目が終わろうとしています。まだ小さめのバグをもらっている段階ですが、前回の記事に続いてその後の経過を少し追記しておきます。
在宅勤務について
在宅勤務、素晴らしいです。いまどきオフィスに通勤とか、ぷっ。品川でサラリーマン大行進の一員だった時代が懐かしいです。
まだ本格的なプロジェクトに参加しているわけではないこともあり、定期的なミーティングは月曜の朝と木曜の朝の 2 つだけです。それ以外のコミュニケーションは Slack のチャットで済ませることが多いです。ツールに関する質問や、修正のアプローチに関する質問もチャットで十分です。いまどき会議室とか、ぷぷっ。
Slack 以外にメールも使っています。Mozilla は G Suite を採用していて、メールは GMail、ドキュメントは Google Doc、カレンダーは Google Calendar です。Outlook、SharePoint なんて要らない子。
時間の縛りは全くないので、好きな時間に PC を付けて、好きな時間に休憩して、好きな時間に寝る感じです。車通勤に慣れると、東京の満員電車に戻れなくなりますが、在宅に慣れると車通勤にも戻れなくなりそうです。渋滞によるストレスや、交通事故のリスクがなくなります。大雪が降っても、電気とインターネットが止まらない限りは何の支障もでません。早朝に目が覚めたときとか、夜遅くにアイディアが浮かんだときに家に開発環境があるのもメリットですね。
人によっては会話する相手がいないと寂しいと感じるのかもしれませんが、私はそういうタイプではないので今のところ支障はないです。車で 20 分くらいかけてシアトルまで行けば共同オフィスがあるので、好きな時に気分転換を兼ねて行くことができます。さらに、交通費は出ないでしょうが、バンクーバーとかポートランドに突然行って作業することもできると思います。
もちろんデメリットもあります。ランチ、ドリンク、その他文房具などが有料。これはオフィス ワーカーの特権ですね。
開発環境について
入社するとラップトップが支給されます。機種は幾つかの選択肢から選べ、Macbook も選べます。私は仕事内容が Windows 向けの Firefox 開発なので、Windows にしました。機種は Thinkpad X280 です。わりと頻繁に機内に持ち込むことを考えるとやはり 12.5 インチがちょうどよいです。
社員用の LDAP アカウントがあり、それを使って社員用サイトほぼ全てに SSO できます。Active Diretory は要らない子。VPN も不要です。したがって、家では入社前に使っていたデスクトップ PC をそのまま開発環境として使っています。申請すればデスクトップ PC も買ってくれそうな気がしますが、今のところ必要性は感じません。ポートランドオフィスにいたときは、多くの人が大部屋でラップトップを使ってごりごりコード書いてました。個人的には開発作業にモニター 2 枚は欲しいですね。ラップトップだと作業効率が落ちます。
PC 本体以外についても、入社時に何が必要かを聞かれて、申請したものは支給されます。私の場合は Webcam と Headset、あと 27” モニターをもらいました。個人で持っていたものよりもグレードが高いものなので有難いです。
Firefox のソースコード、コードレビュー、テスト、バグ管理のシステムなどは全てオープンなので、誰でもアクセスできます。基本的にブラウザー ベースなので、特別にアプリケーションをインストールする必要もありません。私は今まで通り、秀丸でコードを書いて cdb/ntsd でデバッグしています。電話会議だけは、Google Hangout ではなく Zoom というアプリケーションをインストールして使っています。
開発環境のデメリットについて。
バージョン管理が Mercurial。Git 人間には辛いです。大体のコマンドが 1:1 で対応するように見せかけて、例えばブランチという概念がけっこう違ったりします。慣れるまで数か月かかりそうです。
次、Windows ライセンスが有料。まあ当たり前なんですが、Microsoft 特権に入り浸っていた身としてはかなり辛いです。Windows 高すぎ。Microsoft 社員は Visual Studio Subscription (昔の MSDN Subscription) が無料で使えるので、業務目的なら Windows や Office などほぼインストールし放題です。あと当たり前ですが、Windows チームにいると、Windows のソースコードが見れます。ただし、ライセンスや暗号化アルゴリズムに関する部分など、一部見れないところはありました。さらに、Windows だけでなく Office 製品のソースコードの閲覧権限もあります。Visual Studio のソースコードは別途申請が必要だった気がします。ソースコード以外では、社内ネットワークに接続できれば、主要な製品のプライベート シンボルにはアクセスできます。これらがいきなり使えなくなるのは大きなハンデです。辞める直前にソースコードを全部持ち出すという犯罪は魅力的でしたが、バレたときのリスクが高すぎるのでやってません。
開発プロセスについて
まず Microsoft について少し内部事情を書いておきます。
Windows の Servicing プロセスは、規模やインパクトを考えると不可避な部分もありますが、やはり遅いです。ご存じの通り、基本的に修正は Windows Update というチャネルで、毎月第二火曜日のいわゆる Patch Tuesday にリリースされます。が、これは過去のモデルで、実は Patch Tuesday 以外の日にもリリースが行われています。以下のブログで、比較的詳細にリリースの仕組みが説明されています。
Windows monthly security and quality updates overview | Windows Experience Blog
https://blogs.windows.com/windowsexperience/2018/12/10/windows-monthly-security-and-quality-updates-overview/
Windows では、エンジニアが変更をチェックインすると、その翌々月にリリースされる、というのが大まかなタイムラインです。さらに 2019 年 7 月時点では、正式リリース済みの最新の Windows 10 への修正は、他のプラットフォーム経由で修正をリリースして最低でも一ヶ月様子を見てからリリースするという仕組みになっています。例えば現時点で最新の Windows 10 は 1903 と呼ばれるビルドです。この場合、その他の Windows (Win7, Win8.1, Win10 1507, 1607, 1703, 1709, 1803, 1809, そして Insider Preview) への修正がまずリリースされ、早くてその翌月に Win10 1903 の修正がリリースされます。このような奇妙な仕組みは、最新の Windows 10 でのリグレッションを極力避けるためです。それ以前に Windows 10 の種類多すぎ。もちろんセキュリティの場合は、リリースを遅らせることはせず、一気にリリースします。
チェックインまでの大まかなプロセスは、バグが報告された後、1) 優先度やビジネスインパクトを見て、エンジニアをアサインするかどうかを決定、2) エンジニアがアサインされて、修正を作る、3) 修正のリスクや規模に基づいて、どのプラットフォームを直すか、いつリリースするかを決定 (= shiproom approval)、4) チェックイン、という流れになっています。このプロセスは、プログラム マネージャーという人たちが仕切っており、エンジニアリング チームは基本的に彼らの決めたルールに従っている状態です。
次に、これは Internet Explorer の場合に限られますが、チェックインのたびに自動化されたテストが開始され、基本的にはテストが全部通らないとチェックインできません。これは良い仕組みのように聞こえますが、自分でテストを取捨選択することはできず、いちいち全テストが走るので相当時間の無駄です。仮に mshtml.dll の修正であってもなぜか edgehtml.dll 向けのテストも実行されるという頭の悪いシステムになっていました。修正が望まれます。所要時間の目安としては、インクリメンタルビルドが使えない状態で Internet Explorer + Edge を同時にビルドすると大体 3-4 時間、テストが全部実行されるのに 2-3 時間かかります。これは Windows 全体ではなくブラウザーだけの話です、念のため。
一方 Mozilla の場合、まずプログラム マネージャー的な立場の人がいません。毎週のチーム ミーティングの中で、Bugzilla でウォッチしているエリアの新しいバグ全てに対してエンジニアをアサインして終了です。所要時間 5 分ぐらいです。
アサイン後のコードレビュー、チェックイン (Mozilla ではコードをメインのリポジトリに入れることを「check in the code」とは言わず、「land the code」と言います) については、ツールは違うものの、作業はそれほど変わりません。ただし IE と違って、チェックイン前のゲートキーパーみたいなのはなく、レビューが終わったらそれでチェックインの要件を満たしたことになります。
エンジニアの立場としては、余計なことに煩わされることがほぼない Mozilla のやり方が断然楽です。始めに書いたように Microsoft の Windows ビジネスが複雑怪奇になり過ぎているだけかもしれませんが。Windows 内部のエンジニアの不平不満の中で、エンジニア業務を妨げる不要なプロセスが多すぎる、というのは常にトップに挙げられると思います。ただ、Mozilla でももっとバグを直すにつれ、多少は悪いところも見えてくると思います。
諸手続き
アメリカで転職するのは初めてだったので、各手続きについて。
退職願
オンラインで resignation の手続きができて、そこに最終出社日、住所、有給休暇の残り日数を入力して終了です。有給はけっこう残っていて、$20,000 ぐらいに換算されました。まあ Unvested RSU が $214,850 あったことを考えると雀の涙・・・。
401K
管理会社が Microsoft も Mozilla も Fidelity だったので助かりました。Rollover するという手もありますが、とりあえずそのままにしています。ちなみに過去 1 年の運用益は 6% ぐらい。悪くないのでは。
健康保険
結局この 6 年間歯医者以外で病院には行かなかったので、アメリカの医療保険制度は未だに謎です。例えばいわゆる主治医みたいなのを設定しないといけないのですが、設定したことないです。いや、そう言えばグリーンカード申請の際の予防接種で、病院を巡ってかなり面倒な手続きをした記憶がありますが、まあそれはまた別の話。
健康保険も歯医者もともに保険会社が変わるので、特に歯医者に関して今までと同じところに通えるか不安だったのですが、Mozilla で扱っている保険にも対応しているみたいなので安心しました。
スポーツジム
Microsoft では、社員の健康のため、フィットネス費用として指定されたジムのメンバーシップ費用がタダになるプランか、もしくは年間何ドルかの健康関連の出費を経費で落とせるプランのどちらかを選べます。Mozilla でも似たような制度があり、ジムはないですが、年間 $1,700 までの健康関連費用は経費になります。これは Microsoft の上限よりかなり高いはずです。が、私はジム通いを選んで週 2 で通っていて、そのジムが一般人には法外な価格で、まさかの月額 $168.50 でした。高すぎ。$1,700 では全然足りないのでどうしたものか思案中です。
最後に
全く話の流れが変わりますが、Debugging Teams という本があります。
Debugging Teams: Better Productivity through Collaboration 1, Brian W. Fitzpatrick, Ben Collins-Sussman, eBook - Amazon.com
日本語訳もあります。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか | Brian W. Fitzpatrick, Ben Collins-Sussman, 及川 卓也, 角 征典 |本 | 通販 | Amazon
https://www.amazon.co.jp/Team-Geek-―Googleのギークたちはいかにしてチームを作るのか-Brian-Fitzpatrick/dp/4873116309/ref=sr_1_1?__mk_ja_JP=カタカナ&keywords=Team+Geek&qid=1565994389&s=gateway&sr=8-1
もともとはソフトスキルを磨こうと思って買った本なのですが、今働いているチームに不満がある人にはぜひ読んでもらいたい本です。一部サンプルとして無料で読める部分があり、その中に一番印象に残った部分が含まれていたので紹介します。
https://www.oreilly.com/library/view/debugging-teams/9781491932049/ch01.html
Leave Time for Learning
Cindy was a superstar—a software engineer who had truly mastered her specialized area. She was promoted to technical lead, saw her responsibilities increase, and rose to the challenge. Before long, she was mentoring everyone around her and teaching them the ropes. She was speaking at conferences on her subject and pretty soon ended up in charge of multiple teams. She absolutely loved being the “expert” all the time. And yet, she started to get bored. Somewhere along the way she stopped learning new things. The novelty of being the wisest, most experienced expert in the room started to wear thin. Despite all of the outward signs of mastery and success, something was missing. One day she got to work and realized that her chosen field simply wasn’t so relevant anymore; people had moved on to other topics of interest. Where did she go wrong?
Let’s face it: it is fun to be the most knowledgeable person in the room, and mentoring others can be incredibly rewarding. The problem is that once you reach a local maximum on your team, you stop learning. And when you stop learning, you get bored. Or accidentally become obsolete. It’s really easy to get addicted to being a leading player; but only by giving up some ego will you ever change directions and get exposed to new things. Again, it’s about increasing humility and being willing to learn as much as teach. Put yourself outside your comfort zone now and then; find a fishbowl with bigger fish than you and rise to whatever challenges they hand out to you. You’ll be much happier in the long run.
書きたいことは大体書いたので、次からはテクニカルな内容をちゃんと書きます。