好きな仕事を、やり遂げること。（1）

「W3Cの、中の人。」シリーズの２人目として、W3CのPrincipalエンジニアとして働くマイケル・スミスさんをお招きしました。W3Cのエンジニアはどんなふうに仕事をしているんだろう？ブラウザの仕様に関わる仕事ってどういうもの？「ぜひお話したいのでなんでも聞いてください」と快諾いただき、Studioオフィスでたくさん話していただきました。

Studio: 今日はマイケル・スミスさんをお招きしていろいろとお話が聞ければと思いまして、Studioのエンジニアにも集まってもらいました。いつもマイクさんとお呼びしていますので、そうしたいと思います。
マイクさん、Studioにようこそ。
さっそくお聞きしたいんですが、マイクさんはエンジニアとして、そしてW3CでWeb ApplicationsのPrincipalとして長いキャリアをお持ちです。現在のお仕事も含め、どのように働いていらっしゃるか、ぜひ聞かせてください。

Mike: 私の仕事には大きく2種類あります。好きな仕事と、好きじゃない仕事。好きなのは、何かを開発したり作ったりすること。好きじゃないのは、長い会議です。

それから、自動化できるような無駄な作業も苦手です。W3Cにも、どうしても人の手が必要なタスクがあって、自動化しようと思えばできるはずなんですが、やらなければいけない時があります。そういう仕事は好きじゃありません。

私は現在、3つのグループを担当しています。1つ目はWebAssembly。WebAssemblyの言語仕様とJavaScript APIを扱うグループです。これが一番好きなグループで、理由は単純です。私は何もしなくていいからです（笑）。みんな自分たちで動いてくれるので、私がやることはほとんどない。

2つ目のグループはまだ立ち上がっていません。本当はもっと前にできるはずだったんですが、まだなんです。W3Cの全メンバーに対して確認を取る必要があって‥それがWeb Extensionsのグループです。

ブラウザ拡張機能を開発したことがある人ならわかると思いますが、どのブラウザでも動くように作るのは、本当に大変なんです。それを楽にしたい、ということで、すでにコミュニティグループが活動していて、そこからワーキンググループへ昇格させようとしています。

W3Cにはコミュニティグループとワーキンググループの2種類があります。コミュニティグループは自主運営ですが、ワーキンググループはスタッフが必要で、設立には正式な合意が求められ、手続きが必要なんです。

3つ目はWeb Applicationsというグループで、その中にはService WorkerやIndexed DBなどの仕様が含まれています。実はService Workerの実装作業や仕様策定は、ほぼ全て日本のエンジニアたちが担ってくれています。

仕様というのは、一度作って終わりではなく、継続的なメンテナンスが必要です。最近も新しいブラウザエンジンが、これらの仕様をゼロから実装しようとしています。そうすると、「あれ、この仕様、このままじゃ実装できない」という問題が見えてくるんです。曖昧な記述があったり、既存の実装者が暗黙の前提を置いていた箇所があったりして、それは新しい目で見る人が来て初めてわかることなんですね。

Studio: つまり、リファレンス実装みたいな役割ということですか？

Mike: そうです。

新しいエンジニアがゼロから実装しようとすると、仕様の修正が必要な箇所が見つかる。なのでService Workerを担当しているような人たちに、Issueを確認して仕様を修正してもらう必要があります。これはどこでも常に起きていることですが、特に顕著なのがCSSです。

CSSの仕様は、何らかの仮定を置かなければ実装できないんです。2ヶ月前くらいに、AIがあるブラウザエンジンをゼロから書いた、というニュースがありました。エージェントを大量に走らせて、何週間も回して、W3Cのテストスイート（WPT）をパスするコードを生成した、と。

でも断言できますが、AIは仕様を実装したわけじゃない。テストスイートをパスできたのは、既存のコードを参照したからです。つまり、ChromiumやWebKit、Firefoxという既存ブラウザのソースコードを何らかの形で参照し、仕様だけでは判断できない箇所に来たとき、「他のみんなは何をしたか」を見て判断し実装したんです。

面白いのは、これって人間も全く同じことをやるんですよ。私自身もそうします。でも、それは本当は間違いです。仕様で判断できないなら、仕様そのものを直さないといけないはずだから。

好きな仕事は、ブラウザエンジンのコードを書くこと

Studio: それは‥多くのエンジニアが注意すべきことかもしれませんね。

Mike: そう、とても注意が必要なことです。さて、これが「私の好きな仕事」の話につながってくるんですが。私が時間を使って楽しんでいることは、ブラウザエンジンのコードを書くことです。これは、別に私の公式な職務として命じられているわけではないんですが、ずっとやっています。実際のところ私が時間を使っているのは、WebKitへのパッチを書くこと、FirefoxやGeckoへのパッチを書くこと、そしてたとえばHTML仕様に変更があった時には、同じ機能をいろんなブラウザに実装すること、などです。

参考までに、Chromeプロジェクトには1,300人ほどのエンジニアがいます。

Studio: Chromeだけで？

Mike: そう、Chromeだけで。Chromium、あるいはBlinkのチームで、1,000人以上います。だから通常、仕様ができる前にChromiumチームがもう実装してしまっている。彼らは先に動いて、誰の助けも必要としていません。

WebKitのチームはおそらく100人くらい。Firefoxはだいたい300人くらいいますが、その300人が何をしているかはよくわからなくて、私が知っている限り、仕様の作業・コアエンジンの作業を実際にやっているのは5人くらいです。なぜそれがわかるかというと、パッチを送る先のレビュアーがいつも同じだからです。彼らは何年も付き合いのある顔ぶれです。Firefoxには何百人もエンジニアがいても、パッチのレビューをしているのは本当に小さなチームなんですよね。WebKitも同じです。私がやり取りするのは100人のうち10人以下です。それが私の仕事の世界のスケール感です。だから、何かを仕様に取り込んで実装してもらおうと思ったとき、Appleのエンジニアリングマネジメントが誰かに指示を出すのを待つこともできますが、それはたいてい機能しない。Firefoxも同じ。だから、優先度の高いものは自分でやったほうが早い。それが私がブラウザパッチを大量に書いている理由です。

マネジメントされるのではなく、自分で判断する。

Studio: でもそれって、ちょっと‥いい意味で「枠を超えた」仕事のやり方ですよね？

Mike: そうですね。W3Cで19年働いてきて、入った頃の文化はこんな感じでした。大まかな職務記述はあるけど、基本的には「自分で何が必要かを考えて動け」という空気。マネジメントされるのではなく、自分で判断する。私はずっとそうやってきました。

ただ、会社というのは変わっていくもので、関わる人が増えて、非技術者が増えると、技術的な仕事の比重が軽くなる。非技術的な仕事をしている人たちは、自然と自分たちの仕事のほうが重要だと思うようになる。それも重要だとはわかってるんですがどうもこう‥まあ私は明らかにバイアスがかかっているんだけど（笑）。

それでも私は、技術的な仕事をやり遂げることが大切だと信じています。だからブラウザエンジンの実装に取り組んでいる。

Yak Shaving

Mike: とはいえ「私にも罪がある」という話をすると‥仕様を実装しようとするとき、同時に5つくらいの異なるオープンソースプロジェクトに関わっています。WebKitで何か進めながら、Firefoxでも何か進めて、最近はLadybirdという新しいエンジンでも何かを進めている。

そういう作業の中でハマってしまう、ハッカー界隈の言葉で「Yak Shaving（ヤクの毛刈り）」というのがありますよね。作業の途中で、別の問題に気づいてしまい、やるはずじゃなかった作業を次々に行ってしまうことです（ヤクは毛深い動物で、その肉を食べるためには毛深い毛を刈り取り続ける必要がある）。具体例を出すと、WebKitのパッチを送ったら、150件ものレビューコメントが来たことがあったんです。GitHubのWebUIでそんなに大量のレビューをさばこうとすると、ページがもう動かない。完全にガタガタになって、使い物にならない。それに本当に腹が立つんですよ。そこで「ヤクの毛刈り」が始まるわけです。「このWebUIは使えない、Webじゃないやりかたでコードレビューを処理しなきゃ」となって、ブラウザ以外でレビューができるツールを探してくる。何か見つけても、どれも気に入らない。そうなると、自分で作り始めてしまう。気づいたら1〜2週間が経って、結局作業の90%がヤクの毛刈りだった、ということがよくあります。

Ladybirdというブラウザの母体である、SerenityOSのメインシンボルはヤクで、しかもヤクが何頭も積み重なっています。「ヤクスタック」って呼んでいて、ひとつのヤクを刈っていたらその下にまたヤクがいる、という状況を表しているんです。これはもうみんなの共通認識で、どうしようもない。私も、ひどいUIに我慢できない性分なので、ヤクがいっぱいになります。

いまみんながコーディングエージェントのUIを使っていますが、正直に言えば、私は我慢できない。誰かが「ターミナルベースのアプリをWebエンジンとJavaScriptランタイムで作ろう、その上にUIフレームワークを乗せよう」と思ったわけですよね。私は納得いきません。フロントエンドのUIはもっと速くあるべきです。

cocはRustで書かれていますが、cocのほうがずっと理にかなっています。コーディングエージェントを使っていても、UIの低さとパフォーマンスの悪さにイライラしてしまう。私はリアルなターミナルアプリに慣れていて、即座に反応が返ってくるものを使っているから余計に。Claudeを使っていると、何をしているのかわからないときがある。「Thinking」などとは表示されているけど、トークンを消費している様子もなくて‥。

Studio: たしかに、いまAIは何してるの？って思うことあります。

Mike: そうですよね。こういったUI上の問題は、私にとっては本当に重要なことです。自分のキャリアを、Webをより良いUIフレームワークにすることに捧げてきた人間として、フロントエンドのパフォーマンスや挙動をちゃんとケアしていないものを触るのは耐えがたい‥。

時間がかかることがわかっているなら、スピナーを出すとか、何かが起きていることを示す表示をするとか、それだけのことです。ユーザーが「なんで時間かかってるの？何やってるの？」と推測しなくていいように。

Studio: ヤクの毛刈りについてはStudioのエンジニアも例外ではないですね。できるだけそれを分散させようと、オーケストレーションするツールを作って、複数のAIを並列で走らせて、裏で連携させながら並列処理しているエンジニアもいます。ヤクの毛刈りをさらに分散して実行してるだけ‥かもしれませんが。

Mike: そうそう。ちょうどそういう話で言うと、Claude Codeはひとりで作ったことで有名ですよね。作者は素晴らしいエンジニアですが、もうひとつ有名なのが、「手でコードを書かない」ということ。Claude Code自体も、すべてClaude Codeで生成されている。

でも彼はUIエンジニアじゃないんですよ。少なくとも、UXエンジニアではない。そしてClaudeもUXエンジニアじゃない。どれだけ賢くて、私が1ヶ月かかる作業を30分でやってのけるとしても、UXはやってくれないし、UXを理解していない。なぜならAIには目がないし、怒りも苛立ちもないから（笑）。

いつかそれも組み込まれるかもしれませんが‥AIシステムに私たちと同じように怒りや苛立ちを持たせたいかどうか、わかりませんね。でもまあ、必要かもしれない。

（つづきます）　後半の記事はこちら