WEB+DB PRESSでは久しぶりとなる連載インタビュー企画。ホストは竹馬光太郎さんが務めます。記念すべき第1回目のゲストとしてお迎えしたのは，Webブラウザ開発者である中川博貴（nhiroki）さんです。

中川 博貴 さん

Webブラウザ開発者
ソフトウェアエンジニア。Webブラウザ開発者。世の中のよくできたシステムのしくみに興味がある。理想のソフトウェアアーキテクチャを追い求めて日々奮闘。

GitHub：nhiroki
Twitter：@nhiroki_
URL：https://nhiroki.jp/

研究や興味の先にWebブラウザがあった

竹馬：中川さんはChromeの機能を作っていらっしゃる立場で，僕は使う立場で，世代も近いのも知って，どんなことをしているか，気になっていました。

中川：中川博貴と言います。今はChromium（注1）のフルタイムコミッターとして活動しています。特に関わっているのがService WorkerやWorkletを含むWebWorker（注2）全般です。最近はリソースローディング周りも担当しています。

竹馬：中川さんがやってるのは僕が追っている技術が多くて，特に高度なアプリケーションを構築するためのファイルシステムやWorker周りですよね。どのような経緯があって関わるようになったんですか？

中川：たまたま最初に関わることができたプロジェクトがそれだったのですが，もとからファイルシステムなどに興味があったので，進んで参加していたっていう感じです。

そのあたりの話をするうえで，私のWebとの馴れ初めを語らせてください。初めてWebに触れたのは小学生のころで，兄のノートPCを使ってオンラインコミュニティに参加していました。そのうち自分でもそういう場を作りたいと思い，CGIを使ったWebページを作ったのがソフトウェアエンジニアになるきっかけでした。その流れで大学は情報工学科に進みました。

大学では2冊の本にとても影響を受けました。1冊目が梅田望夫さんの『ウェブ進化論』（⁠ちくま新書）で，Webの可能性に感銘を受けました。もう1冊が『Googleを支える技術』（⁠技術評論社）で，そこで並列分散システムに興味を持ち始めたのが転機となりました。

大学院ではRubyの高速化やプロセス間通信機構の研究をしていました。最近Ruby 3でGuild（注3）が盛り上がっていますね。RubyのスレッドってGiant Interpreter Lockによって実質1スレッドしか動かないのですが，それを踏まえて新しい並列処理機構を入れていこうという流れがあって，その前身となるような研究をしていました。具体的には軽量で安全なプロセス間通信機構があれば，スレッドじゃなくてもプロセスを使った並列処理が効率的に行えるんじゃないかっていうものです。

竹馬：最近中川さんがやっているService WorkerやWorkletってそういう感じですよね。

中川：ほんとそう（笑⁠）⁠。Webへの期待や大学での研究，システムソフトウェアへの興味が合わさった先，それがWebブラウザだったっていう感じですね。

注1）

オープンソースのWebブラウザ。Chromeの元でもある。

注2）

JavaScriptにおけるマルチスレッド機能群。

注3）

Ruby 3に搭載されるかもしれない並列処理のしくみ。

Chromiumの開発により参加しやすく

竹馬：Chromiumってすごい巨大なプロジェクトじゃないですか。どういうところが大変ですか。

中川：最新動向を把握するのが大変ですね。調べたところ，この1週間で1,800コミットされていました。本当に巨大で動きの速いプロジェクトです。

竹馬：外野として見ていると，機能で検索すればたしかに出てきて，なんとなくはわかるんですが，手もとでビルドするのが大変だからパッチを書くところまで至らないってのが感想です。実際どうやっていますか。

中川：プロジェクトにはさまざまな会社や個人が集まっているのですが，みなさんいろんな高速化手法を使われていますね。たとえばGoogleはGomaというクラウドコンパイラを使っていますし，ほかの会社でも並列分散コンパイルしているようです。最近だとJumboという高速ビルドのしくみが導入されたり，いろいろ工夫しています。

竹馬：読むときの勘所ってありますか。

中川：レンダリングエンジンに興味があるのであればBlinkを読めばよいと思いますし，プロセスモデルに興味があるのであればContent（注4）と呼ばれている部分ですね。たしかに初めての人には難しいと思います。私自身苦労しているので，自分の知見や経験はなるべくブログ記事に残すようにしています。あとは標準化周りのキーパーソンをウォッチするのが一番かなって。私の周りだとDomenicとかですかね。

Chromiumコミュニティはすごいインパクトのあるおもしろいコミュニティなので，できる限りみんなが参加しやすいような環境を整えたいなと思っていますね。

注4）

マルチプロセスのブラウザを構成しているコアモジュール。

新しい一歩を踏み出すことの難しさ

竹馬：ServiceWorkerとかWorkletってブラウザに新しい概念を足す，新しい一歩を踏み出すものじゃないですか。その特有の難しさがありそうだと思っています。

中川：そのとおりで，ServiceWorkerは今までとはまったく違うライフサイクルを持ち込むので，心配ではありました。その分たくさんテストを書いたり，ブラウザベンダ共通のWeb Platform Testっていうしくみがあって，そこにみんながコントリビュートする中で，仕様レベルや実装レベルでの問題が潰されていきました。

竹馬：自分が作った機能が使われているのってどういう気持ちで見ていますか？

中川：反応はいろいろありますよね。称賛してくれる人もいれば，こんな機能はいらないっていう人もいる。そういうの全部ひっくるめて楽しみのひとつではありますね。世界の見知らぬ人が自分の作った機能についてプレゼンしてくれている資料を見かけると，とてもうれしくなります。

竹馬：Chromiumへのバグ報告，どうやってよいかっての悩むことがあるんですが，中の人的にはどう思っていますか。

中川：バグレポートってレポーターの人ももっと讃えられるべきだと思っていて，その人のプレゼンスを上げる方向に働くとよいなと思っています。それが行き着いた先がバグバウンティプログラム（注5）だと思うんですよね。そこまで専門的なものじゃなくても，見つけたものはその人の成果なんです。ただ，自分がバグを見つけたときの立場に立ってみると，やっぱりバグトラッカーに書くのって心理的な障壁が高いと思うんですよね。

竹馬：そうですね。僕もたぶん書けるバグがいくつかあるはずなんですけど，書いてしまうと責任を持たないといけない気がして，ちょっと避けたい気持ちがあるっていうのは正直なところですね。

中川：何も書かれないよりは何か怪しい挙動を見つけたらどこかに書いてもらうのがうれしいです。たとえちょっとしたことでも，みなさんからのフィードバックはとてもありがたいです。

注5）

バグの発見者に報奨金を支払う制度。