気づけばFirefoxのコア開発者になっていた。「修正されないバグの報告」から始まった25年間【フォーカス】

ブラウザ「Mozilla Firefox」を、根幹から支える日本人エンジニアがいます。Web技術開発を手がけるBirchill社のメンバーとして、Mozilla Corporationからの委託を受け、Firefoxのレンダリングエンジン「Gecko」の開発を行っている中野雅之さんです。かつては「Mozilla Japan（現WebDINO Japan）」にて技術部国際化担当マネージャを務めていました。

ブラウザの基本動作を担う「Core（コア）」機能のうち「Event Handling（※1）」では共同モジュールオーナー（※2）を、「Editor（※3）」と「Global Key Bindings（※4）」モジュールでは、単独でオーナーを務める中野さん。GitHub上のリポジトリによれば、Firefoxプロジェクトへのコントリビューション数は、世界9位にのぼります。

巨大OSSプロジェクトを舞台として長年活躍してきた中野さんは、その特異なキャリアを「なんというか、運良く『流れ』でこうなっただけ」と笑いながら振り返ります。

その言葉の真意とは？ すべての始まりは、約25年前に出会ったバグ。趣味で始めた貢献が、「天職」になるまでの経緯をお聞きしました。

（※1）Event Handling：Webページ上でのクリック、スクロール、キーボード入力といったユーザー入力に対して、特定の処理を実行するモジュール。
（※2）モジュールオーナー：大規模OSSでは、プロジェクトを機能ごとの「モジュール」に分割することがある。各領域の開発方針や、コード品質などに責任を持つ開発者がモジュールオーナー。
（※3）Editor：エディタ。検索ボックスやコメント欄など、Webページ上のテキスト入力欄の挙動を管理するモジュール。
（※4）Global Key Bindings：ブラウザ全体で機能するキーボードショートカットを担当するモジュール。

• keyboard_arrow_down “自分”のための趣味だったが
• keyboard_arrow_down 任されたモジュール、自ら引き受けたモジュール
• keyboard_arrow_down 「シェア1位でない」ことの思わぬ恩恵
• keyboard_arrow_down 「運が良かった」の真意

――いきなりですが、いつごろから「Firefoxの開発者」を目指していたのでしょうか。

中野：正直、意識的に「ブラウザを開発するエンジニアになろう」と思ったわけではなく、「流れでこうなった」という感覚が強いですね。

――では、どのような経緯でMozillaプロジェクトへの貢献を始めたのか教えてください。

中野：私は大学時代「Netscape」の愛用者でした。そして確か2000年、私が社会人になって少しした頃。Netscapeの流れを汲むMozilla（※5、6）の、開発中のバージョンを使えると聞き、β版よりもさらに試験的な「Nightly Build」版を試してみることにしました。

――実際に試して、いかがでしたか？

中野：悪い意味ですごい状況でしたね。当時は不具合が比較的多く、日本語のページを読み込むだけでクラッシュするほどでしたから。また愛用するうち「特定のエラーダイアログだけ文字化けしている」というような細かなバグも頻繁に目につくようになりました。

当時は、CSS普及の過渡期にありました。CSSを用いずにHTMLを表示するよう設計されていたNetscape由来の設計では、自由度の高いCSSの柔軟なレイアウトにうまく対応できていなかったのだと思います。ましてや、日本語環境特有のバグは、英語圏の開発者にとって対応の優先度が低かったのかもしれません。

やがて「なぜ直らない？  誰もこの問題に気づいていないのか？」と思い、調べていくうち「Bugzilla-jp」（※7）の存在を知りました。そこで初めてバグ報告を行ったのが、Mozillaコミュニティとの最初の接点です。

（※5）かつてブラウザのトップシェアを誇ったNetscape Navigatorは、Internet Explorerとの競争で後退した。このNetscapeのソースコードが公開されたことで、後継プロジェクトとして「Mozilla Project」がスタートし、現在のFirefoxへと発展した。
（※6）このころの「Mozilla」は、Webブラウザだけでなく、電子メールクライアントやHTMLエディタなど複数の機能を統合したアプリケーションスイート「Mozilla Application Suite」を指していた。そこからブラウザ機能を独立させたものが、現在の「Firefox」の原型となる。なお、Mozilla 1.0は2002年6月に、Firefox 1.0は2004年11月にリリースされた。
（※7）Buzilla-jp：Mozillaプロジェクトのバグ追跡システム「Bugzilla」の、日本語ユーザー向けのコミュニティサイト。

――貢献の動機は、Mozillaプロジェクトの理念のような「Webの未来を良くしたい」といったものではなかった？

中野：そうですね。「単純にNetscapeが好きだったから触りだした」というのが大きかったので。バグ報告も「自分のために、ブラウジングを快適にしたい」という気持ちが強いものでした。

そうしてバグ報告を続けるうち、他ユーザーの報告を英語版Bugzillaへつなぐスタッフのような役割を任されるようになりました。

――「自分のため」だったのが、なぜそこまで深く関わるようになったのでしょうか？

中野：やっぱり「末席ながら、Internet Explorerに対抗し得る新たなブラウザの開発に関わっている」というワクワク感も次第に湧きだしたんですよね。旧Netscapeユーザーとしては、圧倒的なシェアを誇っていたIEには苦々しい思いもありましたから。

――Mozilla Japanという公式支部に参画したのは、どういった経緯だったのでしょうか？

中野：確か2003年ごろのこと。この時の私は、キャリアの方向性に色々と悩んで最初の会社を辞め、実家に戻っていました。

ただMozillaプロジェクトには関わり続けており、日本語入力（IME）限定でしか発生しないためか、いつまで経っても修正されないバグの存在に痺れを切らし、C++の勉強を兼ねて自分でパッチを書き始めていました。

すると同時期、瀧田佐登子（※8）さんにお声がけいただいたんですよ。「今度Mozilla Japanを立ち上げるから、そのメンバーとしてパッチを書かないか」と。

（※8）瀧田佐登子：Mozilla Japanの立ち上げメンバーのひとりで、代表理事を務めていた。2017年、Mozilla JapanはWebDINO Japanへ名称を変更。引き続き瀧田氏が代表理事を務める。

――直々に誘われて、どのように感じましたか？

中野：恐々としましたよ。フルタイムでブラウザのパッチを書くという働き方は想像できませんでしたし、「外資系だし成果主義で厳しい世界なんだろうな……」という勝手なイメージもあった。

でも幸い、実家暮らしの身で衣食住には困っていなかったので「とりあえずやってみるか」とオファーに応じることにしました。

――本格的にパッチを書くとなると、また違った難しさもあったのではないでしょうか。

中野：実のところ最も「難しいな」と感じたのは、人間関係の重要性です。パッチを書き始めた当初は、担当のモジュールオーナーにレビューをリクエストしても、後回しにされてしまうことが多かったんです。

ところが、Mozillaが世界中の関係者を集めて開催する「All Hands」というイベントに初めて参加し、英語が話せる同僚と共にあいさつ回りをしてみたら、翌日から驚くほどスムーズにレビューをしてもらえるようになったんですよ。

やはり互いに人間なので、相手の顔が思い浮かぶかどうかで対応が変わる側面はあるんですね。山積みのタスクの中、どこの誰とも知らない人が出したパッチに対し、優先順位を上げて対応するのは心理的ハードルがあるのでしょう。

コミュニケーションの未来を変え得るツールをつくっているのに、開発現場ではFace-to-Faceが効いてくる。これは非常に面白い気づきでした。

――技術的な点では、どうでしたか。

中野：もちろん、困難は山積みでした。何より大きかったのは「クロスプラットフォーム」であることによる難しさ。

Firefoxは、あらゆるOS上で同じように動作することが求められます。特に、私の専門領域となるIME周りでは、各OSが提供するネイティブのAPIをすべて理解していないと、問題の切り分けすらできません。バグの原因がGeckoにあるのか、OS固有の処理にあるのかを特定するため、Mozilla Japanに加わってからはmacOSやLinuxのAPIを一から勉強し直しましたね。

――その後、Event HandlingやGlobal Key Bindingsのモジュールオーナーになっていかれた経緯についてもお聞かせください。

中野：どちらも「巻き込まれた」という表現が一番しっくりきますね。

まず、私は英語圏の開発者からは修正が後回しにされがちな、IME特有のバグを追ってきました。ここに関わっていると「キーボード入力がOSからどうWebコンテンツに反映されるか」というハンドリングの部分や、DOMイベントの仕組みそのものを理解する必要が出てきます。

ひとつのバグを修正するために関連領域の知識を深めると、また別のバグにも対応できるようになる。これを繰り返すうち、気がつくと「ユーザー入力」に関わるモジュール群について、ある程度横断的に理解できるようになっていました。

転機になったのが「Firefox 3」時代のこと。私のせいで、最新バージョンのリリースが数か月遅れたことがあったんですよ。

――何があったのでしょうか。

中野：当時、JISキーボードなどUS配列以外のキーボードで一部のショートカットキーが正常に動作しない問題があり、私が修正を担当しました。ところが、その修正が世界中のさまざまなキーボード環境で意図せぬリグレッションを大量に生んでしまったんです。次々とバグ報告が舞い込み、その対応に時間を要してしまった。

この一件をどうにか収めたことで、私はコミュニティ内で「ユーザー入力のイベント処理に比較的詳しい人」と認識されたのでしょう。そのまま「Event Handlingの共同オーナーもやってくれ」との流れになりました。もともとはOlli Pettay氏という「Mozillaで一番忙しいハッカー」といわれる人が単独オーナーを務めてきたのですが、彼は負担を分散するために共同オーナーを探していたのです。

――Global Key Bindingsのオーナーも、同じような流れで？

中野：割と雑に任されたので、あまり覚えていません。ある日、「このモジュール、最後に真剣に触ったのお前だろ。他にオーナー居ないからよろしくな」という感じでしたね（笑）。

――では、Editorモジュールについては？

中野：Editorの方は10年ほど前に、自分から願い出てオーナーになりました。

IME関連のバグと向き合ううち、Editorモジュール内の「古い設計思想に基づいた実装」が根本原因となっているケースが多いと気づいたからです。それらが解消しない限りは、IMEハンドラ側で表面的な修正を続けてもきりがない。なので、Editorモジュールも本格的に見ていきたい、と。

既存のオーナーも極めて多忙で、他にやりたがる人もいなかったので、そのまま私が引き継ぐことになりました。

――なぜ誰も積極的に関わろうとしなかったのでしょうか？

中野：なんというか、ここはみんな、そんなに触りたくない部分なんだと思います。

――というと？

中野：一番大きいのは「Editorへの貢献は、エンジニアとしてのキャリア形成につながりづらい」とみなされているからだと思います。

いわば「Webページ上で表示されるテキスト入力欄の挙動を担保する」だけなので、何か新しい技術を学べたり、劇的なパフォーマンス向上をアピールできたりするわけでもない。なのに地道な互換性対応や、無数のエッジケースの修正にやたらと時間を奪われるのです。

しかも、技術的な観点でも厄介で、標準仕様が「あってないようなもの」なんですよね。例えば「段落の先頭でバックスペースキーを押したら、前の要素とどう結合されるべきか」という挙動ひとつとっても、そのパターンは「前の要素が何なのか？　パラグラフか、リストか、テーブルなのか？」によって無数に分岐します。厳密に言語化するのは非現実的で、結果ブラウザ間の互換性問題も非常に多く発生しています。これらも解消しなければならない。

――Webの根幹ともいえる「文字入力」の挙動に、統一仕様もなかった？

中野：それは歴史的な経緯も大きいようです。私の知る限り、GeckoのEditorモジュールと深く関わるリッチテキスト編集機能の起源は、HTMLメール作成やウェブページ編集機能を搭載していたNetscape 4にまで遡ります。これはあくまで製品内の閉じた機能で、Web開発者が自由に使えるものではなかった。

一方、IE5.5がページの一部を直接編集可能にするcontentEditableというAPIを公開しWeb開発者もリッチテキストエディタを実装できるようになった。これに対しMozillaはMidasというまた異なる編集機能を提供した。このように、各社で独自仕様が整理されないまま世に出た、というのが私の認識です。

IEはやがて市場から退場しましたが、WebKitと、そこから分岐したBlinkも台頭していきます。これらもまた、エディタの挙動において、GeckoとIEのどちらと比べても多くの差異がある。そして結果的に、歴史の長いGeckoの実装だけが互換性の薄い存在となった。

――複雑でキャリアにもつながりにくい仕事を引き受けた理由は何だったのでしょうか？

中野：「このままだとGeckoの歴史が終わってしまうのでは？」という嫌な予感があったからです。

特にオーナーを引き受けた当時、EditorモジュールはNetscape時代からの名残で、非常に複雑な設計になっていました。

例えば、ユーザーの入力を解釈してDOMをどう変更するか決める「ルール」のオブジェクトと、実際にDOMを操作する「Editor本体」のオブジェクトが、メモリ上で別々に存在していたりと。こうした設計は、ブラウザのように非同期に様々な処理が動く環境では、セキュリティホールの温床になりがちです。ルールが実行されている最中に、Webアプリ側の処理でEditor本体が破棄されてしまい、ブラウザがクラッシュするということもあり得ます。

放置が続けばいずれ誰も安全に手出しできなくなり、修正不可能な領域となってしまうかもしれない。そうなる前に複雑な構造を単純化し、安全に改修できる土台をつくった方がいいと考えたんです。

――ブラウザ市場を見ると現在はGoogle Chromeが大きなシェアを占めています。率直にお聞きしますが、この現状をどう見ていますか？

中野：やっぱりFirefoxのシェアが下がったことに対し思うところはあります。ユーザーが減るとテスターも減るので、バグの発見も遅れがちになりますし。

ただ、私の関心はシェア争いとは別のところにあります。常に「代替品となれるブラウザ」を提供し続けたいということです。

「Webの健全性を守る」との理念を振りかざしたいわけではないのです。ただ現実問題、多くのユーザーにとって、ブラウザが果たすべき役目として重要なのは「自分の使いたいWebアプリが、きちんと動くかどうか」だと思うのです。なのに、例えばChrome上で特定のサイトが正常に動作しなかったとき、代替となるブラウザがないと困りますよね。

なので、Firefoxをその選択肢のひとつとして、最低限「きちんとWebアプリが動く」ようにメンテナンスし続けたい。それが今の一番のモチベーションになっています。もちろん、Firefoxのシェアが伸びればうれしいですけれどね。

――シェアの大小というよりは、品質維持にフォーカスしているのですね。

中野：そうですね。それに、仮にFirefoxがシェアNo.1の座を奪うようなことがあったら、それはそれで困難な状況に陥るのではないかと思います。

――なぜですか？

中野：そうなった場合、世界中のWebアプリはFirefoxでの「バグも含めた」動作を前提として開発されるようになるでしょう。

しかし、歴史の長いFirefoxは独自の仕様を多く抱えています。すると、それらを前提とした膨大なWebアプリとの互換性を維持する必要が出てくるので、より合理的な動作への大幅な変更は困難になり、身動きがとりづらくなる。

――シェアNo.1でないからこそ、思い切った修正もしやすい、と。

中野：そうですね。

その意味では、現状は「幸運」な部分もあります。特に細かい動作仕様のないEditorモジュールにおいては、シェア第1位のChromeの動きが多くの場合で合理的なのです。ゆえに、私たちはあるべき動作に迷ったときでも「とりあえず、Chromeの動作に合わせる」という形で、互換性の観点で安全な選択をしやすい。

また昔と違って、Webアプリの開発において直接ブラウザのAPIを呼び出すことが少なくなったのもラッキーといえます。Reactのようなライブラリやフレームワークが、ブラウザごとの挙動の差異を吸収してくれるおかげで、シェア自体は下がっていても、ほとんどのサイトで問題なく動作する状態を維持しやすくなった。ありがたい時代になったと感じています。

――近ごろは、どんな改修をされたかお聞かせください。

中野：大きめな例を挙げると「beforeinput（※9）イベント」の実装をしました。Webアプリ開発者から「他のブラウザにはあるのに、Firefoxだけが未実装で困る」との要望を受けて着手したものです。しかし実装を始めると、奇妙な問題に直面しました。全ブラウザ共通のテスト基盤である「Web Platform Test（WPT）」に、このイベントのテストがほとんど存在しなかったのです。

「先に実装したブラウザは、一体どうやって品質を担保したんだ？」と不思議に思いつつ、最後発であるFirefoxの開発者の私が、この機能に関するWPTの大部分を整備することになりました。

しかしよく調べてみると、WPTで「ユーザーからの入力」というブラウザの内部設計に深く関わる部分をエミュレートする機能が整備されたのは、最近だったんですよね。つまり、昔はテストを書くこと自体が不可能だった。

今でもドラッグ＆ドロップやIME入力などの挙動はエミュレートが難しく、ブラウザ間の非互換性が生まれやすい領域です。もしもブラウザのバグや非互換性を見つけて貢献したい人がいたら、このあたりは「狙い目」かもしれませんね。長年ブラウザを開発していると、こうしたニッチな勘が身についていきます（笑）。

（※9）beforeinputイベント:ユーザーの文字入力が画面に反映される直前に発生するイベント。Webアプリがこれを検知するとブラウザの標準動作を止めることができ、独自の入力処理を実装できる。

――今後の目標としては、やはりEditorモジュールの改善が主でしょうか。

中野：そうですね。しばらくは、他のブラウザと違う動作をする箇所を、可能な限り潰していくのが目標です。

特に、将来的に深刻なバグを引き起こしかねない根本的な設計の修正は、特定のWebアプリで問題が起きてから対応するのでは遅い。そこで、何か大きな問題で切羽詰まっていない平時のうちに着手するように心がけています。

ただ、こうした予防的な改善はまだ問題が発生していない以上重要性がわかりづらく、マネジメント層から評価されにくい側面もあります。ですから、中長期的な改善ばかりに偏るのではなく、目に見える短期的な成果につながりそうな貢献も行うようバランスを意識しています。そうして一定の貢献度を示すことで、コミュニティ内での動きやすさを保ち、自分が重要だと感じる課題に取り組む時間を確保できると考えています。

――お話を聞いていると、やはり中野さんは非常に重要な役割を果たしているのだと拝察します。最近GitHubに移管されたFirefoxのリポジトリを見ても、中野さんのコントリビューション数は世界で9位となっています。

中野：9位！？　いや、そんなことになるかな……。

――意識していなかったんですね。

中野：初期は修正したバグをブックマークしていたこともありましたけれど、すぐに追いきれなくなってやめました。それに、私の修正はバックアウトされることも多く、単純なコミット数にあまり意味はないんです。やたらと多く見えるのは、取り消されたものも含めて非常に細かい修正を積み重ねてきたのと、単純に長年やってきた結果ではないでしょうか。

率直なところ、私が居なくてもプロジェクトは回ると思います。ただ、一応は「居る方が便利なんだろうな」という立ち位置なのかな、とは感じますね。

――ブラウザ開発の世界で「居る方が便利」という立ち位置に至ること自体も稀なことかと思います。現在のようなお立場は、どのようにして築かれたとお考えですか？

中野：結果的には「誰もやらないところをやる」という姿勢を続けてきたからでしょうか？

単に、やる必要がないから誰もやらないのではなく「誰かがどうにかしてほしいと思っているけれど、面倒だから着手されない領域」に手を付けてきたといいますか。

――その「誰もやらない仕事」を、なぜ投げ出すことなく続けられたのでしょうか？

中野：それはもう「そういう性格だから」でしょうかね。

正直、私はゼロから新しいものをつくるのが好きではないんです。アイデアが思いつかないのもそうですが、それ以上に、すでにある複雑なコードをリファクタリングしていく作業の方が性に合っているんですね。心が安らぐんです。

思えば最初のSIer時代でも、大規模システムのメンテナンスを担当していました。目の前のバグを修正しつつ、少し先の未来を考えて手を動かす癖も、そのころからのものです。

――「誰もやりたがらない仕事」への需要と、中野さんご自身の性質が噛み合った、ということなのでしょうか。

中野：そうですね。その意味で私は「運が良かった」んだと思います。

もし私が今新卒として、この知識と経験を持って米Mozillaの採用面接を受けたとしても、おそらく門前払いですよ。新人を見ていると、コンピュータサイエンスの高度な学位を持っていたり、複雑なアルゴリズムで問題をスマートに解決できるような優秀な方々ばかりですから。かたや私は、社会に出てからようやく真剣にコードを書き始めたような人間です。

そんな自分が、世界的なアプリケーションのメンテナーとしてこれだけ長くやってこられた。それは、会社を辞めていたタイミングで瀧田さんにお声がけいただいたことと、IMEやEditorをはじめとする領域の改修作業が、たまたま自分の性に合っていたというのが大きい。

――やはり今もこのお仕事は楽しいと感じているのでしょうか？

中野：もう、天職のような感じがしますよ。まさか、いちユーザーとして抱いた小さな不満が世界的なプロジェクトを長年支えるお仕事につながるとは。

この先、ブラウザを取り巻く情勢がどうなっていくかは分かりませんが、Firefoxは私が現役である限り関わり続けたいと思っています。Netscapeから一貫して、やっぱり愛着のある製品ですから。そのために、これからもまだまだ改善すべき点の多いEditorモジュールを中心に日々の貢献を続けていきたいです。

取材・執筆・編集：田村 今人
撮影：赤松 洋太