ソフトウェアエンジニア
石井 宏治（いしい・こうじ）
1965年生まれ。「Word」の日本語組版プログラムマネージャーや楽天Koboでの電子書籍リーダー開発を経て、Googleに参画。Chromiumのレンダリングエンジンの開発を行う。W3Cでは、縦書きの「CSS Writing Modes」、文字処理系の仕様に関する「CSS Text」、文字装飾の「CSS Text Decoration」などのエディタ（仕様の責任者）を、Unicodeでは、縦書きについて定めた「UAX#50」のエディタを務める。Chromiumへのコントリビューション数は、GitHubのランキングを見る限り世界12位。
一体、誰がどんな思いで私たちにとっての「当たり前」を築いたのか？
現在、私たちがWebブラウザ上で当たり前のように読んでいる日本語の「縦書き」や、美しい「ルビ」、禁則処理などのテキスト表現。もともと横書きのラテンアルファベットを前提に設計されたWebの世界において、こうした複雑な日本語組版は長らく「例外」であり、それをブラウザ上で正しく表示することは極めて困難な課題でした。
この「情報デバイス上の日本語表示」というテーマに対し、20年以上にわたり向き合い続けてきた人物がいます。Google社でソフトウェアエンジニアを務める、石井宏治さんです。
石井さんは、Microsoftの「Word」開発チームで日本語組版の基礎を築いた後、W3C（World Wide Web Consortium）の標準化会議に個人として飛び込み、縦書きの国際標準ルールとなる仕様を策定。現在は、世界最大のブラウザ基盤「Chromium」の開発メンバーを務めています。
なぜ自費を投じてまで標準化活動に没頭し、さらには自らブラウザのエンジンを書き換える道へと身を投じたのでしょうか。
「自分が書いたプログラムがユーザーに届かなければ、本末転倒ですから」
そう語る石井さんに、Web上のテキストレンダリング進化の裏側と、エンジニアとしての歩みをお聞きしました。
文字を追う原点はTeXbook
――石井さんは長年「組版」や「文字」の表示領域に関わってこられましたが、そもそもこの領域に興味を持たれたきっかけはなんですか。
石井：まず、プログラミングとの出会いは、中学生の頃に遡ります。当時はプログラミングについて書かれた日本語の本がほとんどなく、英語の技術書を辞書を引きながら読むしかありませんでした。
どうせ膨大な時間をかけるならと、有名な技術書に触れていたのですが、その過程である日、ドナルド・クヌース氏の『The TeXbook』（クヌース氏が自ら開発した組版システム「TeX」の解説書）を読みました。大学時代だったでしょうか。それが、私と組版との最初の出会いだったと思います。
――そこで、組版のシステムに惹かれた？
石井：というよりは、クヌース氏のものづくりへのこだわりに憧憬を抱いたのです。
彼はもともと、自分の本を美しく出版したかったのですが、当時の印刷会社では彼の指示通りのクオリティが出せなかった。だから、理想の組版システムである「TeX」を自分自身でつくってしまったわけです。しかもTeXをつくるために、プロの印刷技術を根本から勉強し、フォントすら自作してしまった。
自分がやりたいことのために、必要であれば他のレイヤーにまで降りていって、すべて自分自身でつくってしまう。この姿勢に、憧れを抱いたのですね。今思い返すと、あそこがすべての始まりだったのかもしれません。
――それで、文字に関わるお仕事を選んでいったのでしょうか。
石井：実はそうでもないんです。
大学は情報系に進んだのですが、当時はコンピュータグラフィックス（CG）のアルバイトをやってみたくて。しかし、CGの仕事なんてほとんどありませんでした。唯一見つけたグラフィック関係の仕事が、印刷用の「版下作図機」をつくる会社だったんです。
グラフィックの仕事だと思って入ったら、実はガチガチの印刷業界だった。大学卒業後もその会社にエンジニアとして就職し、その後は友人と会社をつくって雑誌のデザインシステムを手がけたりと、気がつけばずっと「文字の周辺」を転々としていましたね。
――そこから、どのようにしてMicrosoftへ入社することになったのですか。
石井：ある日、雑誌のインタビューでビル・ゲイツ氏が「Wordの開発チームには数百人のメンバーがいる」と語っているのを読んだんです。
「そんなに大規模な開発チームだなんて、一体どんな世界なんだろう」と無性に気になり、興味の赴くままMicrosoftに応募したところ、1993年、採用してもらえました。
当時はワープロといえばまだMS-DOSでの作業が中心で、キャラクター（文字）単位での表示が主流でした。しかしWordはWindowsのソフトです。Wordとして成功する以前に、そもそも「Windowsのワープロ」をつくってもらわないと、土俵に乗れない状態でした。
「じゃあWindowsのワープロって何が違うの？」というと、やはり「WYSIWYG（画面の表示と印刷結果が一致する仕組み）」で見られるという点です。ちょうどWord開発チームが「ワープロという域は超えないけど、アウトプットはDTPレベルのものにしたい」と模索していた時期に、私が応募したわけです。
そして入社してみると、上司から「お前、ずっと印刷業界でやってたんだよね。それなら、Wordの組版を改善してくれ」と言われたんです。
印刷関連の知見はあっても、組版そのものに強い専門性があったわけではないのですが、一応、一通りの基礎は知っていたので。勉強しながらですが、引き受けることになりました。
――そこでついに、真正面から文字と向き合うことになったのですね。
石井：はい。
そこで私はプログラムマネージャーとして、Word 6.0を、すでに制定されていた日本の組版ルールである「JIS X4051」に準拠させるための仕様策定を担当しました。
縦書きやルビはもちろん、禁則処理、約物の詰め、さらには割注（行の途中で文字を小さく2行にして割り込ませる注釈）まで、日本語特有の組版ルールを片端から仕様に落とし込んでいきました。
実装面をはじめ、さまざまな人々の助力もあり、結果として「Word 97」の頃には、文書作成ソフトとしては早期から印刷レベルのアウトプットを出せるソフトウェアになっていたと思います。
誰にも相談できずに日本語組版を整備していた異国の有志
――Wordとの日々について、その後を教えてください。
石井：インターネットが広く普及し始めたことを受け、90年代後半、MicrosoftはOffice製品全体をHTMLに対応させるプロジェクトを立ち上げました。
しかし、いざ東アジア版のWordの文書をHTMLに落とし込もうとすると、縦書きやルビといった日本語特有の組版表現がことごとく消え去ってしまう現象が起きたのですね。当時のHTMLやCSSには、そうした概念自体が存在しなかったからです。
――Web標準が、複雑なテキストの表現に追いついていなかったのですね。
石井：ええ。そこで、社内で「全Officeプロダクトのブラウザにない機能を全部リストアップしてCSSに提案しよう」というプロジェクトが立ち上がりました。私と、他のWord開発者と、Internet Explorerの開発チームとで協力し、ブラウザにはない組版機能のリストを洗い出したのです。
そしてW3Cに対して、「International Layout in CSS」というCSSの拡張仕様として提案を行いました（※1、2）。
（※1）W3Cにおける仕様策定の流れ：Web技術の標準化団体であるW3Cでは、仕様を草案（Working Draft）から勧告候補（Candidate Recommendation）、勧告案（Proposed Recommendation）へと進め、最終的な国際標準である「勧告（Recommendation）」を決定する。
（※2）「International Layout in CSS」の仕様は、文字処理系についてまとめた現在の「CSS Text」や、縦書きなどを定義する「CSS Writing Modes」の源流となった。
――ご自身がWordで培った要件を生かし、Webの標準仕様を提案したと。それは順調に進んだのでしょうか。
石井：最初は順調に思えました。実際、提案自体は、2003年に「勧告候補（CR）」という、最終段階の少し手前まで進みました。
ところがその後、差し戻しになってしまいました。
そして私はこのことを、後から知りました。一方の私はといえば、「Microsoft Money」という別製品のグループマネージャーを務めてから、2001年にMicrosoftを退職して自身の会社（Glue Software）を設立し、受託開発などをやっていたので、W3CやCSSの標準化活動からは完全に離脱していたんですね。
――なんと。ではどういう経緯で、再びW3Cと関わるようになったのでしょうか。
石井：2010年ごろ、新聞で「電子書籍の標準フォーマットである『EPUB』（※3）が、縦書きに対応する」という記事を見かけたのがきっかけです。
よく読んでみると、そのEPUBの縦書きは、CSSの縦書き仕様を参考にした建付けのようでした。
（※3）EPUB：米国の電子出版業界の標準化団体、IDPF（International Digital Publishing Forum）が策定する電子書籍のオープンな世界標準フォーマット。
――かつてご自身が関わった仕様が、電子書籍のフォーマットに使われると知ったのですね。
石井：ええ。ただ、この時点では、私の関心は仕様ではなく、電子書籍そのものにあったんです。
なにせ、当時の私にとって、W3Cでの仕様策定は、もうMicrosoft時代に一度区切りがついた過去の仕事でした。
一方で私は、根っからの本好きでもあります。
当時はまだ、一部のニッチな書籍しか電子化されない時代でした。だからその記事を見て、「これでEPUBの普及が進めば、欲しい本がどれでも電子書籍で手に入るようになる。それは便利だな」と期待したのです。
ただ、どうせ読むなら、きれいな組版で読みたいじゃないですか。それに、文字の表示クオリティが悪ければ、出版社側だって本を電子版で出したがらないはず。
そこで、EPUB関係者に縦書きの実装について疑問があれば答える、ぐらいの助力は私にもできるかなと思ったので、まずは「今CSSってどうなってるんだろう。少し議論を覗いてみよう」と、W3Cのメーリングリストにアクセスしてみたのです。
――そうして、Microsoft時代ぶりにW3Cのコミュニティへ足を踏み入れたのですね。
石井：はい。議論を追っていくうち、私のほかにも日本人がいることに気づきました。組版ソフト開発に携わり、W3Cで日本語組版の標準化に携わっていた村上真雄さんです。あまり日本人のいない世界でしたから、こちらから声をかけてお会いすることにしました。
そのようにしてメーリングリストを追ったり、有志とコンタクトをとったりしているうち、私がかつて関わったCSSの拡張仕様が、W3Cから差し戻されていた事実を知りました。
どうやら、そもそも当初の策定にはかなりの穴があったようです。極端な話、「縦書きとは、文字を縦に書くことである」程度の抽象的な説明しかなく、実装に足る詳細な定義が不足していました。その後、CSS2の仕様が安定していく中で、W3C側が改めて仕様を見直した際に、そうした欠陥が指摘されました。
さらに、当時はInternet Explorerがもともとの仕様案に準拠して実装していたものの、仕様をテストするための「2つ目のブラウザ実装」がいつまで経っても現れなかった。その結果、議論が完全に停滞し、差し戻しという結果に終わっていたのです。
しかし、私が何より驚いたのは、実装者がいなくて放置状態だったその縦書きの仕様を、アメリカのElika Etemad（ハンドルネーム：fantasai）（※4）というエディタが、相談する相手もいない中、細々とメンテナンスし続けていたことでした。
私がW3Cから完全に離脱した後も、彼女は「CSS International」と呼ばれていた全部入りの巨大なスペックを、ライティングモードとテキストの仕様に切り分け、少しずつクオリティを上げながら守り続けてくれていたのです。
すべての歯車が噛み合い、再び時は動き出す
――とはいえ、CSSと日本語組版をめぐる議論は停滞してしまっていたのですよね。
石井：そこで、「EPUB」の動向が決定的な転機になりました。
当時、2010年の初頭にAppleから初代iPadが発表され、世間は「電子書籍元年」と沸き立っていました。
電子書籍のオープンな世界標準規格としてすでに「EPUB」が注目を集めていたのですが、その頃のバージョン（EPUB 2）は、縦書きやルビといった日本語特有の組版にまったく対応していませんでした。
このままでは、日本の出版物が世界標準のフォーマットで電子化できないという大きな問題があった。そこで、日本語の組版ルールをしっかりとサポートした次世代の「EPUB 3」の登場が望まれていました。
――そのEPUB 3の策定と、CSSの仕様がどう結びつくのでしょうか。
石井：EPUBは独自のレイアウトシステムを持たず、W3CのCSSを参照してテキストを描画する仕組みになっています。
つまり、「EPUBを縦書きにする」ためには、「大元のCSSを縦書きに対応させる」ことが至上命題だったのです。しかも、EPUB 3の策定期限は2011年と目前に迫っていました。
そんなタイムリミットの中、偶然、Elikaが別件で来日することになったのです。
そこで2010年9月、私や村上さんを含めた日本の有志と彼女とで、新宿付近にあるイーストという会社の「4C会議室」に集まり、10日以上にわたって合宿のようなことを行いました。
ボランティアとして皆で深夜まで泊まり込みをしつつ、急ピッチでCSSの仕様書を書き上げたのです。
――元々EPUBに関わっていた有志の技術者やElikaさんからしても、かつてWordの組版に関わり「International Layout in CSS」の提案メンバーである石井さんが現れたのは、かなりの驚きだったのではないでしょうか。
石井：どうでしょうか。私自身も当時、CSSの最新動向については知らず、W3Cのルールも含めて勉強させてもらう立場でしたから。
ただ、たぶん彼女からすると、私は「今まで想像の世界だった『International Layout in CSS』の要件の意図を、リアルに説明してくれる人」だったのだと思います。日本語の縦組みについて「ここはこうなのかな」と想像するしかなかった部分に対し、「現場の要件はこう。こういう根拠があるから」と説明してくれる人間が現れた、という感覚だったのではないかと。
――ただ、仕様を書き上げたとしても、以前のように「実装するブラウザがない」という問題は残ったままですよね。
石井：そうですね。そもそも、仕様が正式な「勧告（絶対的な国際標準）」になるには、2つ以上の独立したブラウザエンジンが、すべてのテストケースをパスして実装を完了する必要があります。
ですが当時、Elikaが整備していた仕様を実装したブラウザは、まだひとつもありませんでした。
しかもEPUBは本来、正式な「勧告」に達した仕様しか採用しない建付けです。なのにEPUB 3の策定期限は2011年と目前に迫っていました。
――正式な仕様の完成を、待ってはいられない状態ですよね。
石井：はい。そこで、EPUB側が譲歩してくれた。勧告を待たず、まだ「草案（WD）」段階のCSSを、暫定的な「プレフィックス」付きの形で先行して取り込む、という判断をしたのです（※5）。
ただ、それでもCSSの標準化において本当に効くのは、「実際に動く実装が生まれること」です。仕様が絵に描いた餅のままでは、誰も次には進めてくれない。
そこへ、強力な助け舟を出してくれたのがAppleでした。 彼らは自社の電子書籍アプリ「iBooks」のためにも、EPUBの縦書き対応を急ぎたかったのでしょう。自社のブラウザエンジン「WebKit」の開発チームを動かし、「仕様さえ固めてくれれば、うちがWebKitに日本語組版周りの機能を実装する」という方針をとってくれたのです。
私自身、本来はプロダクトをつくるのが好きな人間であり、正直、Elikaのように誰も実装しない仕様をひとりで維持し続ける気力はありません。ですが「Appleが実装するというなら、私も全力でやりたい」と強く思いました。
こうして、いろいろな歯車が、かっちりとはまったんです。
（※5）：当時のCSS縦書き仕様は草案段階で、EPUB 3では、「-epub-writing-mode」といった具合に、プレフィックス（暫定的な接頭辞）付きで先行採用された。勧告候補（CR）到達は2014年、正式な勧告は2019年。
――それにしても、CSSへの関与は「手弁当」から始まったのですよね。W3Cの会議へ参加するたびに国内外を飛び交うのにも、お金がかかりそうです。
石井：まあ、趣味でやりたいことをやってるだけですからね。趣味にはお金、使うじゃないですか（笑）。
自分で定めた仕様を「実装する」側へ
――さまざまな組織や企業の思惑、有志の技術者同士の出会いが重なって、長年止まっていた時計の針が動き出した。その後、どうなったのでしょうか。
石井：縦書きを含め文字の方向などを定義する「CSS Writing Modes」と、禁則処理や改行などテキスト全般を定義する「CSS Text」に関する仕様の第一稿を書き上げ、AppleがWebKitに実装し、EPUB 3という実際に使われる規格にも載った。
そうして仕様がようやく現実に動き出す目処が立ちました。
その後も、私はCSSの仕様策定には関わりますが、本業としてはまた少し違う道へ進むことになります。
私はもともと、純粋な「仕様屋」ではないんです。日本語組版をめぐる仕様が固まって動き出したのなら、今度はそれを使ったプロダクトを世に出す側に関わりたいと思うようになった。
そうして2012年には楽天に入社し、電子書籍リーダー「Kobo」の開発に参画しました。
――標準の仕様をつくる側から、「プロダクトを届ける側」へ回ったのですね。
石井：ただこれは、自分の「本当の欲求」に気づかされる経験でもありました。
Koboに関わっていて思ったのが、電子書籍サービスの本業は、突き詰めれば「書店システム」だということです。
入稿の仕組みがあり、決済システムがあり、買った本を管理するライブラリがある。肝心のリーダーアプリ側の文字のレンダリングは、基本的には既存のオープンソースのブラウザエンジンを内部に組み込んで処理させる構造です。表示に不具合が見つかれば、エンジンをフォークして自分たちで直すこともできました。ただ、そこに大きな時間を割くことはできません。組版は、事業全体で見ると本業ではなかったからです。
つまり、組版の根本的なクオリティを上げようと思っても、電子書籍のプロダクトの側からでは限界がある。そうして、「自分が本当にやりたいのは、文字をきれいに表示するレンダリングエンジンそのものをつくること」だと思ったのです。
――それで、ブラウザエンジンそのものをつくる場へと身を移すことにしたのでしょうか。
石井：はい。
そうして2014年にGoogleにレジュメを送り、採用してもらえたので、「Chromium」やレンダリングエンジン「Blink」の開発に携わることになりました。
――担当は、やはり組版関係でしょうか。
石井：それが、「レイアウトチームは米サンフランシスコにはあるが、日本の拠点には存在しない」ということで、私は最初、DOMや編集機能（Editing）を担当していました。
ただ、Googleには業務時間の2割を自分の好きなことに充ててよい「20%ルール」があります。それを使って、私は別拠点であるレイアウトチームのバグ修正を手伝い始めました。
すると、彼らが大喜びしてくれて。
――なぜでしょうか。
石井：当時のレイアウトチームにとって、複雑な文字や組版の処理は「できればやりたくない、厄介なバグ対応」の連続だったようです。そこになぜか、進んでテキスト周りを触りたがっている奇特な人間が現れた（笑）。
また私の修正により、結果的に日本語関連以外も含むレイアウト機能全体のパフォーマンスが上がるケースもあったので、最終的には上司の計らいで「100%レイアウト担当」になれました。
――その後、どんなお仕事をしたのか教えてください。
石井：大きい事例についてお話すると、100%レイアウト担当になって少し経った頃、チームのリードが「Blinkのレイアウトエンジンを、ゼロから完全に書き直したい」と言い出しました。それが「LayoutNG」というプロジェクトでした。
長年継ぎ足されてきた既存のエンジンは、上下左右の物理座標による配置計算を前提にしていて、縦書きや双方向テキストのような複雑なレイアウトを正しく処理するには、アーキテクチャとして破綻を迎えつつありました。
これを、論理座標をベースにしたアーキテクチャにつくり直す。
こんなチャンス、なかなかないですよね。
――そんなに前向きだったのですか？ いわば、何億人もが使い、無数のWebサイトが依存しているエンジンを、表示を一切壊さずにつくり直さないといけないわけですよね。途方もないプレッシャーかと思いますが。
石井：ゼロからプロダクトをつくるチャンスですからね。かつてWordの組版に関わった時も、英語ベースの既存実装はあり、日本語周りの機能もゼロからではなかったので、そこに手を入れていく形でした。
そんな中、互換性を守りながら、自分の手で世界中で使われるテキストレンダリングの土台を築ける。かつてのWordのときより、より多くのユーザー数に自分が根底からかかわったプロダクトが届く。エンジニアとして、これ以上のチャンスはありません。
社内ではこのプロジェクトについて「飛行中のエンジンを、空中で新しいものに取り替えるようなものだ」などと評されていましたが（笑）。
新旧のエンジンを並行して動かしながら徐々に移行を進め、最終的にはChrome 77（2019年9月）にて正式リリースに無事こぎ着けました。
――並行して、石井さんが関わっていたCSSの標準化はどうなっていったのですか？
石井：結局、実装がWebKitだけではまだ「勧告」には至らないので、他のブラウザエンジンの追随を待つ必要がありました。Firefoxを手がけるMozillaも対応を始めてくれましたが、仕様を正式なルールとして通すには、複数のブラウザがパスするための膨大なテストコードが必要でした。
そこで、2012年以降は、仕様のあらゆるエッジケースを網羅する1,200件以上のテストコードを自分たちで書き、各社にパスしてもらうという作業をしたり、総務省からの支援を受けて「縦書きWeb普及委員会」を通した普及促進イベントに関わったりしていました。
また、縦書きについて定める「CSS Writing Modes」については、2019年にW3Cの最終段階である「勧告」にたどり着きました。いやあ、実に長かったですね。
――そもそもWordは「Word for Windows 6.0」（日本では1994年発売）の時点で、ある程度の縦書き対応は実現していたわけですよね。なぜWebの世界では、そこまで標準化が停滞していたのでしょうか。
石井：結局のところ、ニーズの問題だったのだと思います。
EPUBをきっかけとして、ようやくCSS側の仕様の整備が一気に進んだのもそうですし、ブラウザへの実装も同様かと。Chromeなどのブラウザを利用する人々がまず求めていたのは、スムーズなスクロールや動画、リッチなアニメーションでした。
そちらの機能が優先して発展し、ある程度満たされてきたからこそ、2010年代半ばから「じゃあ今度は文字周りもどうにかした方がいいよね」という段階が訪れた。
振り返ってみれば、私が何かをやりたいと思ったタイミングと、世の中のニーズの変遷が、ちょうど運よく噛み合っていたのだと思います。
良い組版は気づかれない
――今はどんなことに取り組まれているのでしょうか。
石井：レイアウト基盤の刷新など、やるべきことは大方終わりつつあります。Wordで実現していた日本語を美しく見せるための機能の多くが、ようやくブラウザの世界にも備わってきたな、という手応えを感じているところです。
そのため、Chrome開発陣の中からは「そろそろ他の領域も手伝ってほしい」とも言われてまして。最近は、Webページ内に別のページを埋め込む「iframe」のリサイズ処理などに手を入れています。昨今、AIを利用したWebサービスが流行していますが、そうしたツールをブラウザ上で動かす際にこのあたりの制御が必要になるらしく、少し毛色の違う仕事もしているところです。
――それにしても、キャリアのスタートから40年近くが経過し、今なお第一線でコードを書き続けていらっしゃいます。その原動力はどこにあるのでしょうか。
石井：まず、Googleのエンジニアには定年という概念がないことも大きいでしょうね。
あとは、単純にプログラミングが趣味（笑）。土日にコードを書いていても、まったく苦になりません。
遡ってみても、かつてMicrosoftでWordのチームを離れた後のこと。私は「Money」という資産管理ソフトウェアのプロジェクトを担当しました。ただ、当時は私もまだまだ若く、意見が割れた際に上層部の方針に従い続けなければならない状態にフラストレーションを感じたことがあったのです。そこで「いちど、上までいってみよう」と考え、チーム内で昇進できるところまで昇進し、マネジメント職も経験しました。
しかし、役職が上がるほど、仕様の策定やコードの記述といった現場の仕事から遠ざかり、プロダクトを直接見られなくなってしまう。その時「あ、なんか違うな。私は自らの手でつくっている側にいたいんだ」と強く自覚したのです。
――ユーザーに直接届くプロダクトを自分の手でつくることが好き。では、W3Cなどで「仕様」を書くことに費やした長い時間は、苦にはならなかったのでしょうか。
石井：自分の生み出した価値が「ユーザーの体験として実際に届くこと」に一番重きを置いているので、仕様策定自体を苦だとは思いません。必要であれば、W3Cで仕様も書きますし、C++でブラウザエンジンの実装もします。自分がどれだけ美しいプログラムを書いても、それがユーザーに届かなければ本末転倒ですから。
多分、より良いものを確実にユーザーへ届けるために、その時々で「今、自分がどのポジションを取るべきか」を考えて選択してきたのだと思います。
それは、自分の理想の本をつくるために、必要に応じて組版システムからフォントに至るまで、すべてを自分でつくってしまったクヌース氏への憧れが、根底でつながり続けているのかもしれませんね。
――もうひとつ気になるのが、WordやEPUB、そしてChromiumと、石井さんが開発に関わってきた基盤には、数えきれないほどの人々が触れてきたはずです。ご自身がデジタルの世界における「日本語の表示」を長年支えてきたことに関して、達成感や誇らしさのようなものは感じますか。
石井：もちろん、ユーザーからの反響はすべてうれしく感じます。
ただ、タイポグラフィの理想は「誰にも気づかれないこと」だと思っています。本当によくできた組版というのは、目立ちません。そこにはただ、何の変哲もない、普通に読める文書があるだけです。しかし、他のプラットフォームやアプリに行ったときに「あれ、なんだか読みづらいかも？」と違和感を覚える。それが一番の理想形だと思っています。
私が恐れるのは、質の低い組版でも、10年、30年と使われ続けると、いつの間にかそれが「当たり前」になってしまうことです。本来なら読みにくいはずのクオリティの低いものが、デファクトスタンダードのような「トラディション（伝統）」として受け入れられてしまう。私は、それが嫌なんです。
組版の質が変わるだけで、同じ時間で文章を読んだときのスピードや理解度が明確に変わると示唆する既存研究もあります。
だからこそ、ユーザーが良いものを知り、良い環境に慣れる。そんなプロダクトをつくっていたいのです。すると質の悪いものに出会ったとき、「これは読みにくい」と引っかかって、改善を求める声が上がるはずです。そうやって、世界中のタイポグラフィが少しずつ底上げされて良くなっていけばいい、と思っています。
――では現在、組版やタイポグラフィをめぐってやり残していることはありますか。
石井：いくつかありますね。細かいものだと、和欧間アキ（漢字などの和文と、アルファベットや数字などの欧文が混在する際に、自動で適切な余白を挿入する処理）の仕様を、Unicode側で最終版まで詰める作業などがまだ残っています。
CSSの側でも、行末の句読点を版面の外へわずかに追い出す「ぶら下がり」の実装などを進めています。あとは、仕様の面でいうと、文字と文字の間隔を空ける「letter-spacing」というCSSプロパティの挙動をめぐって、まだ勧告候補（CR）段階の「CSS Text」の仕様内でずっと議論を重ねているのですが、いまだに決着がつきません。
――「letter-spacing」ですか。
石井：ええ。これまでの各ブラウザの実装は、例えばアラビア語のような「右から左」へ書く言語の際、文字と文字の間を開けるという仕様の記述とは異なり、文字の右側や左側に余白を付けてしまっていました。長年その状態で動いていたため、この「letter-spacing」の実際の挙動と仕様とのズレをどう解決するかが、W3Cにおいて議論になっているのです。
私の主張は、「もう20年以上、世界中のWebサイトがその挙動を前提につくられている。いまさら厳密に仕様通りに直したら、無数のWebページのレイアウトが壊れてしまう。だから、直すにしてもオプトイン（開発者側が明示的に選択する方式）にするべきだ」というものです。
ところが、その議論の相手であるfantasai――Elikaが、「仕様こそが正しいのだから、SafariもFirefoxもChromeも、3つのブラウザすべてが仕様に合わせて直すべきだ」と、一歩も引かないんです。
――長年の議論の相手は、あの4C会議室で、夜通し一緒に仕様を書き上げたElikaさん？
石井：はい。彼女は仕様の美しさを愛していて、私はプロダクトとして現実に動くものを実装することが大好きなんです。根本からして、考え方がまったく逆なんですよ。
というわけで、今もひとつの細かな挙動をめぐって、もう5年も戦い続けています（笑）。
取材・執筆：田村 今人
編集：王 雨舟
撮影：曽川 拓哉
ピックアップ関連記事 levtech.jp levtech.jp
