この十数年間のちょっとした覚え書き

最後にブログを書いたのは2013年、もう十数年も前のことです。最後に個人のウェブサイトを更新したのも2016年で、それももう10年近く前になります。その時には、当時のブログを「Retired blog」としていました。しかし、最近になって記録し、共有する価値のあることもあると感じるようになり、再びブログを書き始めようという考えが浮かびました。

しかし、なかなか適切なプラットフォームが見つかりませんでした。MediumやSubstackのような商業的なプラットフォームに依存したくはないし、かといって自分でブログを構築するのは面倒です。それに、近年は英語と日本語にも自信がついてきたので、多言語ブログにも挑戦してみたいと思っていましたが、満足のいくサポートを提供してくれるブログシステムはありませんでした。少し前に、ブログのような静的コンテンツに適したAstroというフロントエンドフレームワークを知り、このフレームワークを使って一からブログを構築してみようという考えに至りました。

この十数年間、多くのことがありました。この最初のブログ記事では、まずは簡単な覚え書きを記し、このブログの構築過程についてはまた別の機会に話すことにします。

2013年に大学を卒業してからオーストラリアに来て、シドニー大学でソフトウェア工学の修士課程を履修しました。しかし、授業が退屈に感じられたため、一学期を終えた後、就職を考え始めました。偶然にも、以前Firefoxに貢献したこと、特にCSS Counter Stylesモジュールを実装したこと¹がきっかけで、Mozillaから誘いを受け、2014年の後半に大学を中退してMozillaに入社しました。

正直なところ、Mozillaで働き、オープンソースソフトウェアに貢献することは、まさに私の理想の仕事でした。キャリアのスタートでいきなり理想を叶えてしまったことは、当時の私には全く予想もしていませんでした。

Mozilla

Mozillaはオーストラリアにはあまり人がおらず、オフィスもありませんでした²。しかし、当時からMozillaにはリモートワークの文化があり、エンジニアの半数以上が在宅勤務だったと聞いています。私も最初の週にサンフランシスコのオフィスで簡単な入社研修を受けた以外、その後はずっと自宅で仕事をしていました。会社はDell U2413モニターを2台支給してくれ、Herman Miller Embodyのオフィスチェアも経費で精算させてくれました³。これらは今日でもまだ使っています。

当時は出張の機会も多く、年に2回の全社会議（All Hands）のほか、Web標準の実装に直接関わっていたため、毎年W3CのTPACやCSSワーキンググループのF2F会議に参加する機会もありました。時にはチームがオフサイトでのワークウィークを企画し、皆で集まることもありました。その数年間で、アメリカ、日本、台湾、カナダ、ニュージーランドなど、多くの国に行きました。最も遠かったのはイギリスです。当時は若くて、会社のお金での旅行のありがたみが分からず、ほとんどの場合、一週間仕事をしてすぐに帰国してしまいました。現地でもう少し散策したり遊んだりしなかったことを、今思うと本当に残念です。

Mozillaに入社して最初のプロジェクトは、CSS Ruby標準の実装でした。ちょうど大学時代に日本語を少し学んでいたことと、母語が中国語である背景から、このルビという注釈形式について多少の知識があり、この標準の理解と実装に大いに役立ちました。もちろん、この標準の実装には多くの課題もありました。例えば、改行の正しい処理、異なる位置にあるスペースの正しい処理⁴、複数レベルのルビの同期の維持などです。rubyのサポートがデフォルトで有効になった後、Mozilla Hacksで紹介記事も書きました。この標準には、当時難しくて実装できなかったものの、今でも非常に重要だと感じている部分、例えばoverhangやmergeのサポートなどがまだ多く残っています。いずれにせよ、Firefoxのrubyサポートは、少なくとも機能カバレッジの点では今でも最高のはずです。

ruby以外にも、圏点（text-emphasis）や縦中横（text-combine-upright）など、他の東アジア言語、特に日本語でよく使われる機能も実装しました。

その後の主要なプロジェクトは、フルスクリーン（Fullscreen API）サポートの改善でした。これには、ユーザーの許可を求めるプロンプトを廃止した新しいフルスクリーンフローの設計、top layerメカニズムの実装、そして最も重要な、フルスクリーンへの移行と終了の速度の最適化が含まれていました。

Fullscreen APIの主なセキュリティ上の懸念は、ウェブサイトがユーザーの画面を模倣し、ブラウザやOSのすべてのセキュリティ対策を回避して、ユーザーを騙して機密情報を入力させる可能性があることでした。セキュリティとユーザーエクスペリエンスのバランスを取った結果、フルスクリーンウィンドウに切り替わるたびにフルスクリーン通知を表示し、フルスクリーンへの移行と終了時に画面全体がフェードアウト・フェードインするという設計になりました。画面のフェードアウト・フェードインは非常に議論を呼んだ設計で、多くのユーザーに好まれず、またLinux上ではすべてのウィンドウマネージャと上手く互換性がなかったため、最終的にこの部分はLinuxではデフォルトで無効になりました。

フルスクリーンの速度を最適化する開発では、Youtubeのフルスクリーンを指標としていました。フルスクリーンの過程で、ページ全体が何度も再レイアウトされることに気づきました。例えば、:fullscreenが有効になった時、フルスクリーンイベントが発生した時、ページの領域がウィンドウサイズとフルスクリーンサイズの間で切り替わる時などです。解決策は、フルスクリーンの変更が始まった後、ページのレイアウト更新を凍結し、関連するすべてのイベントのディスパッチを停止させ、すべての変更がフルスクリーン完了後に一度に適用されるようにすることでした。必要であれば、予想される最終的なビューポートサイズを事前に提供し、レイアウトの回数を最小限に抑えるようにしました。

フルスクリーンサポートの改善におけるもう一つの挑戦は、当時進行中だったe10sプロジェクトでした。これはFirefoxをChromeのようなマルチプロセスアーキテクチャに改造し、UIプロセスとコンテンツのレンダリングプロセスを分離して、セキュリティと安定性を向上させるものでした。しかし、フルスクリーンへの移行と終了にはUIとコンテンツの間で多くの調整が必要であり、それらが異なるプロセスにある場合、多くのフローがメッセージパッシングに依存し、同期処理が非同期処理になるため、複雑さが大幅に増しました。それに加え、OSのフルスクリーンサポートも厄介な問題でした。例えばLinuxでは、ウィンドウのフルスクリーンイベントとそれによって引き起こされるウィンドウのリサイズイベントの順序が保証されていないだけでなく、そもそも発生するかどうかも保証されておらず、安定性に大きな課題をもたらしました。

その後、Styloプロジェクトチームに参加し、ServoのスタイルエンジンをGeckoに移植してスタイル処理を高速化する作業を行いました。これは私がプロジェクトチームで多くの人と協力してプロジェクトを完成させた最初の経験であり、また仕事でRustコードを書き始めた最初の経験でもありました。ServoのスタイルエンジンをGeckoに導入するためには、既存のすべてのテストスイートをパスさせる必要がありました。そのために、私は拙いDSLを作成してテストを分類し、Styloがまだパスできないテストを特定し、それに基づいて新旧エンジンの差を徐々に埋めていきました。

Mozillaでの日々は、総じて楽しいものでした。良い給料をもらい、毎年世界中を旅行し、広く使われている有名なオープンソースソフトウェアに貢献し、Web標準の策定にも関わっていました。

MozillaでFirefoxを開発することは私の理想の仕事でしたが、理想と現実はやはり異なります。以前のプロジェクトでの協力関係から、台北オフィスの多くの同僚と交流があり、イギリスでのAll Handsの前には、台湾の同僚数人と一緒にイギリスを一周観光したりもしました。それだけに、Mozillaが台北オフィスを閉鎖し、台湾の同僚全員を解雇したことは、私に大きなショックを与えました。そのすぐ後、私をMozillaに誘ってくれたマネージャーも会社を去りました。それに加え、Firefoxのマーケットシェアが低下し続ける一方で、ネット上でのFirefoxへの批判も絶えず、それらは私の耳には非常に痛く、多くのプレッシャーをもたらしました。これらの様々な理由から、私は会社を去ることを考え始めました。

ちょうどその時、Canvaのリクルーターから連絡があり、当時すでに評価額が10億ドルに達していたオーストラリア発のユニコーン企業である同社を紹介され、見学に誘われました。そして、そのままフロントエンドエンジニアとしてCanvaに入社し、4年間働いたMozillaを去りました。

Canva

多くの人は転職で給料を上げますが、私がMozillaからCanvaに転職した際、給料に大きな変化はありませんでした。基本給は同じで、ボーナスがストックオプションに置き換わり、手取りの現金は実質的に減りました。しかし、私がCanvaに入社した理由は多岐にわたります。一つには、長年ブラウザを開発してきて、ブラウザが処理するフロントエンドのコードが日々複雑で難解になり、かつて自分が書いていたものとは全く異なるものになっているのを見て、フロントエンド開発が実際に何をしているのかに興味を持ったこと。二つ目には、この4年間ずっと在宅勤務だったので、オフィスでの生活がどんな感じなのか試してみたかったこと。三つ目には、否定できませんが、スタートアップに入社し、株価が上がって経済的自由を達成することへの幻想を抱いていたこともあります。

Canvaに入社後、私はEditingチームに参加し、そのエディタの開発に携わりました。ある意味、最もコアなチームと言えるでしょう。私が入社した時、ちょうどエディタ全体をReactで書き直すE2プロジェクトが完了したばかりで、主なタスクは小さな機能の実装が多かったです。印象に残っているのは、Intersection Observerを使ってエディタを最適化し、エディタのビューポート外のページをレンダリングしないようにしたことです。この最適化により、エディタは1つのドキュメントあたり20ページしかサポートできなかったのが、徐々に100ページまで増やせるようになりました。

Editingチームはコアチームと言われていましたが、一度解散され、メンバーはそれぞれ異なるチームに分散されたこともありました。それでも、調整や議論のための定例会議は続いていました。その期間、私はCollaborationチームに配属され、素材のロック機能、エディタ内コメント機能、オンラインの共同編集者のアバター表示などの開発に携わりました。もちろん、会社はすぐにEditingチームなしではやっていけないと気づき、半年後にはこのチームは再結成されました。

私が最初に参加した主要なプロジェクトの一つは、おそらくEditorXでしょう。これはより大きなWebXプロジェクトの一部で、Webページをモバイルデバイスで実行できるようにし、モバイルクライアント内でネイティブコードで実装されたエディタを置き換えるものでした。これにより、より一貫した体験を提供し、実装コードも統一され、多くのiOSおよびAndroidエンジニアがそれぞれ編集・レンダリングのコードを別途メンテナンスする必要がなくなりました。多くのモバイルエンジニアは、フロントエンドまたはバックエンドエンジニアとして再トレーニングされました。このプロジェクトの大きな課題は、異なるプラットフォームとの戦いでした。iOSとAndroidのWebViewには多くの違いがあり、その中でも重要なのがソフトウェアキーボードです。そのサイズ、表示タイミング、ページのレイアウトへの影響、そして副作用（ページ全体を上に押し上げるなど）はそれぞれ異なります。多くの時間が、それらの挙動を理解し、可能な限り共通の技術的解決策を見つけることに費やされました。

もう一つの主要なプロジェクトはホワイトボードでした。ホワイトボードプロジェクトの最大の課題は二つあり、一つはパフォーマンス、もう一つはページに固定サイズがないことでした。既存のコードがホワイトボードページをサポートできるようにするため、内部コードは大幅にリファクタリングされ、多くの技術的負債も導入されました。その後何年もの間、私たちはこの負債を返済し続けることになりました。ホワイトボードである以上、パフォーマンス問題は避けられません。ホワイトボードには無限のスペースがあるため、ユーザーは自然とより多くのものを置く傾向があります。Canvaの主要な技術的アプローチの一つは、React+HTMLを使用してデザインをレンダリングすることです。Webの特性のおかげで、このアプローチは多くの実装上の利便性をもたらします。例えば、テキストは自然に選択でき、<iframe>を使って外部コンポーネントをシームレスに埋め込むことができ、複雑なテキストレンダリング機能（縦書きなど）や動画再生も比較的容易にサポートできます。しかし同時に、ブラウザの実装に制約されるため、クロスプラットフォームでのレンダリングに差異が生じるなどの限界も存在します。このアプローチのより重要な問題はパフォーマンスです。デザイン内の各素材は、様々な理由から多くのReactノードとDOMノードを必要とするため、要素数が増えるにつれてパフォーマンスは急激に低下します。そのため、多くの最適化を行ったにもかかわらず、リリース当初、私たちはホワイトボード上の素材数を1000個に制限しました。これは<canvas>ベースでレンダリングする競合製品よりもはるかに少ない数でした。

その後、私はリードアーキテクトとしてDoctopusプロジェクトに参加しました。このプロジェクトは今年の初めに「Visual Suite 2.0 in one design」として外部に発表され⁵、一つのドキュメント内に異なるサイズやタイプのデザインページを埋め込むことを可能にしました。Canvaの内部では多くの機能が「doctype」という概念に結び付けられており、これは例えばドキュメントがスライドなのかA4の印刷物なのかを示します。長い間、Canvaのエディタはそのライフサイクル全体で一つのdoctypeしか存在しないことを前提としていたため、多くの機能はこの固定されたdoctypeに基づいてページ読み込み時に挙動を決定していました。しかし、Doctopusはこの前提を完全に覆し、doctypeをドキュメントレベルからページレベルに移行させたため、これらの挙動も動的に決定できるようになる必要がありました。そのため、多くの機能がある程度のリファクタリングを必要とし、一部はプロダクトのレベルから再考する必要さえありました。会社全体の多くのチームがこれに関わりました。しかし、アーキテクトとして、私は最初の技術文書と初期のいくつかの基本コンポーネントのコードを書いた以外は、基本的には他の人々とコミュニケーションを取り、アイデアや方向性を提供するだけで、本当に大変な実装作業はチームの他のメンバーやさらに多くのチームの同僚が完成させてくれました。

Canvaで6、7年働き、Mozillaでの時間を超え、大小さまざまなプロジェクトに参加しました。会社の組織が変化し、自分の役職もよりシニアになるにつれて、コードを書く時間はますます少なくなり、コードレビューや様々な人々とのコミュニケーション、彼らのニーズを理解し技術的な指針を提供することに多くの時間を費やすようになりました。この時になって初めて、ソフトウェアエンジニアの仕事は実はコードを書くことではなく、コミュニケーションなのだと本当に理解しました。過去と未来の自分とのコミュニケーション、他のエンジニアとのコミュニケーション、プロダクトやデザイン担当者とのコミュニケーション、コンピュータとのコミュニケーション⁶、ビデオ会議でのコミュニケーション、対面でのコミュニケーション、インスタントメッセンジャーでのコミュニケーション、ドキュメントやコメントを書くことによるコミュニケーションです。

Canvaは素晴らしい会社です。この会社に入社できたことは非常に幸運だったと感じており、当時私を連絡してくれたリクルーターには感謝の念でいっぱいです。

会社にはプロダクトを非常に重視する文化があり、継続的に詳細なユーザー調査を行っています。アンケートやデータ収集・分析だけでなく、直接ユーザーにインタビューし、一対一でユーザーの行動を観察し、彼らの考えを理解することもあります。また、ユーザーフィードバックを追跡する専門の担当者もおり、直接の報告であれソーシャルネットワーク上のコメントであれ、整理されてプロダクトチームにフィードバックされ、参考にされます。この点は、おそらくMozillaに欠けていた部分だと思います。Mozillaには非常に優秀なエンジニアがたくさんいて、素晴らしいエンジニアリング文化もありますが、プロダクトに対する姿勢やアプローチ、そしてトップ層のユーザー理解やプロダクトの発展方向の舵取りについては、少なくとも私が観察した範囲では、大いに欠けている部分がありました。

素晴らしい福利厚生もその長所の一つです。毎日、バラエティ豊かな朝食と、日替わりの美味しくて温かい昼食があり、さらに様々なスナック、飲み物、アイスクリームが常に提供されています。チームも時々イベントを企画し、目標達成を祝ったり、単なるチームビルディングを行ったりします。イベントの形式も多様で、リモートチームで一緒にゲームをしたり、工作をしたりすることから、オフラインで集まってリアル脱出ゲームに行ったり、ゴーカートに乗ったりすることまであります。社内には、チームに参考として提供するために、様々な面白いアクティビティを探す専門のチームがあります。それに加え、一定の条件を満たすクラブには、毎月会社から人数に応じた活動費が提供されます⁷。また、会社は全員に年間3日間の「Force For Good」休暇を与えており、ボランティア活動に使うことができます。会社も慈善団体と協力し、これらの休暇を使って参加できる集団ボランティア活動を企画しています。

私が入社してからの数年間で、会社は急速に発展し、人数は私が入社した時の約10倍になり、評価額も入社時と比較して40倍になりました。人員の拡大に伴い、組織構造や管理方法も当然ながら絶えず変化しています。私が入社した当初は、基本的に皆に役職もレベルもなく、ソフトウェアエンジニアはただのソフトウェアエンジニアで、私のマネージャー（Canvaの言い方ではコーチ）もソフトウェアエンジニアでした。その頃は組織構造もあまりなく、ただ各チームがあるだけだったように思います。私たちのチームでは当時、毎週金曜日の午後にShow & Tellという定例会議があり、その週に実装した新機能や修正を報告していました。最初の頃は創業者も参加して、私たちの成果を称賛してくれました。その後、チームの上にグループができ、次にスーパーグループとサブグループができ、最近ではさらにorgという階層が追加されました。仕事内容から見ると、当時の私たちのチームは今では2つのグループになっています。役職にもレベルが導入され、その後、異なる役職を通じてすべてのエンジニアとエンジニアリングマネージャーのレベルも公開されるようになりました。

Canvaでのこの数年間で、私は自分の成長を実感しました。ただ黙々とコードを書くだけでなく、大規模プロジェクトにおけるアーキテクチャ上の考慮事項についてより深く理解し、プロダクトや運営の多くの側面に触れ、より多くの人々と交流し、責任と影響力がますます大きくなりました（もちろん、プレッシャーやバーンアウトもありましたが）。

仕事以外

この十数年間、ほとんどの時間を仕事に捧げてきたため、仕事以外にできることは非常に限られていました。社会人になってから時間が経つのがとても速く感じ、一年一年があっという間に過ぎていきます。学生時代が懐かしくなります。少なくとも毎年2回の長い休みがあり、自分のことを計画できました。もちろん年次休暇もありますが、いつも取るのがもったいなく感じ、取ったとしても有効活用して遊びに行くべきだと考えてしまうので、結局他のことをする時間がありません。

この十数年間、私の主な娯楽は日本のアニメを見ることでした。ほぼ毎日3話というペースで見ています。見たい新作アニメがあればそれを見て、なければ旧作を補完します。この娯楽には非常に満足しています。特別な準備もいらず、失敗することもあまりなく、時間をコントロールしやすいからです。時々ゲームをしたり、漫画やライトノベルを読んだりもしますが、これらはアニメのように一話一話という明確な区切りがないため、投入する時間をコントロールするのが難しく、夢中になって抜け出せなくなりがちです。

安定的かつ継続的にアニメを見続けたことによる副次的な効果として、日本語にもますます慣れ親しむようになりました。数年前に、もしかしたら日本語能力試験（JLPT）を受けてみようかと思った時、最高レベルのN1の難易度が、なんと対策なしでも楽に合格できるレベルであることに気づき⁸、その年の試験に申し込みました。対策なしでも合格できるとは思っていましたが、試験を機に日本語をさらに磨きたいと思い、語彙と文法の本を買って、試験前の半年間、積極的に復習しました。結果はもちろん、問題なく合格しました。私の日本語は主にアニメから、英語は主に仕事上のコミュニケーションから来ているため、日常会話の理解においては、日本語の方が英語を上回っているかもしれないとさえ感じます。

Rust 1.0がリリースされた頃から、私はRust言語のファンであり、今でも個人プロジェクトのデフォルトの第一選択言語はRustです。Mozilla時代にStyloプロジェクトに参加して仕事でRustを使い始め、Canva時代は長い間Rustで開発することはありませんでしたが、同僚と一緒にRustのトレーニングを開催したり、会社を説得してC++でプロトタイプが書かれたプロジェクトをRustで実装し直したりしたこともありました。過去何年もの間、私はTelegramで「Rust众」というRustコミュニティを運営していましたが、以前、仕事でのバーンアウトやメンバーとの意見の不一致から、このグループを閉鎖することにしました。振り返ってみると、このグループには多くの時間、エネルギー、そして感情を注ぎ込みました。evalbotを開発したり、FAQを編纂したりしました。グループのユーザー名rust_zhが一度Telegramに回収されてしまい、そのためにToncoinをお金で交換してオークションで競り落とし、買い戻さなければならなかったこともあります。しかし、このグループを閉鎖したことは、私自身にとっては悪いことではなかったかもしれません。少なくとも、大きな精神的負担が一つ減ったように感じます。かつてはかなりの期間、毎朝起きるとまずグループで夜中に何か問題が起きていないかチェックしていましたが、解散してからはもうその心配をすることはありません。やはり私は、たとえ一つのグループであっても、管理系の仕事には向いていないのだと思います。

2020年頃、Beancountプロジェクトに出会い、簿記を始めました。以前にもいくつかのスマホアプリを使ったことはありましたが、続きませんでした。Beancountを使った複式簿記は、売掛金は資産であり、買掛金は負債であることや、費用の按分など、会計の概念や考え方に触れる機会を与えてくれました。自分の支出状況を把握してより良い予算を立てるために記帳する人もいますが、私は主に自分の財務状況をより包括的に理解するために行っています。しかし、帳簿があることで、毎年の確定申告の準備や、投資ポートフォリオの管理にも役立っています。この数年間、この帳簿のために多くのプラグインを書きました。例えば、クレジットカードのキャッシュバックを自動計算するプラグイン、クレジットカードの取引を請求日まで遅らせるプラグイン、キャッシュフロー計算書を表示するプラグインなどです。もちろん、使い込むうちにBeancountの設計に不満な点も出てきましたが、それについてはまた別の機会に議論することにしましょう。

2年前に引っ越した後、新しい家に大きなソーラーパネルと蓄電池を設置し、Amberに接続してリアルタイムの卸売電力価格を使い始めました。⁹これにより、電力市場や再生可能エネルギー発電に関する情報にもより関心を持つようになりました。オーストラリアでは実際、屋根置きの太陽光発電がすでに多すぎて、卸売電力価格がマイナスになることがよくあります。つまり、電力を送電網に供給すると、逆に料金を請求されるのです。そこで、太陽光発電を制限するためにHome Assistantを導入し始めました。しかし、このシステムを一度導入すると、ますます多くのデバイスやデータを接続したくなります。最近の個人プロジェクトの多くは、これを中心に構築されており、自分で設計・実装したダッシュボードや、いくつかの端末デバイスの情報報告サービスなどが含まれます。

この十数年間、多くのことがありました。ここに書いたことも、そのほんの一部に過ぎません。多くのことはもう忘れてしまいましたし、覚えていても書く価値がないと思ったり、書きたくないと思ったりすることもあります。しかし、いずれにせよ、ここまで書いただけで私にとっては非常に長くなりましたので、この辺で筆を置くことにします。