Web標準化の関係者たちが語る、Web標準化の現実と前進のための処方箋（後編）。HTML5 Conference 2013

ふだん私たちが接しているWeb技術は、W3CやIETFといった国際的な標準化団体でさまざまな議論が行われた上で決定された仕様に基づいています。

その標準化団体とはどういうもので、標準化作業に伴う苦労はどのようなものなのか。実際に標準化を行っている、もしくはそれに関連した人たちが議論をするセッション「Spec EditorとContributorが語るWeb標準化と開発者への期待」が、11月30日に都内で開催された「HTML5 Conference 2013」で行われました。

（本記事は「Web標準化の関係者たちが語る、Web標準化の現実と前進のための処方箋（前編）」の続きです）

Webの標準化に貢献すると仕様書に名前が載る

及川　もしもWeb技術の標準化に貢献したい、と思ったときに、どんな方法があるのか。それから、標準化に貢献するとこんないいことがあるよ、ということをこの会場にいる人を説得するとしたらどう説明できるでしょうか。

小松　もちろんスペックを書くことや実装をすることはコントリビュートだと思いますが、ここにいるほとんどの方の開発者目線でいうと、その仕様自体にリクワイヤメントがあるというのを示すのも僕はコントリビュートなんじゃないかなと思います。

新しめのAPIが出たときにデモやサンプルを作るとか、「これは面白いな」と思ってブログで紹介するとか。それによってその仕様に対する要望や、実際にこう使うといったことやここが問題だと書くことが、コントリビュートでありフィードバックだと思います。

そう考えると、コントリュビュートしたことのある人は（この会場にも）結構いるのではないかと思います。

矢倉　例えば仕様にささいなエラー、タイポでもいいですし、アルゴリズムを読んでちょっとこれはおかしいのではと思うところをつついたり、例えばHTMLにRubyという（ルビを振るための）要素がありますが、その例を見たときに日本語がおかしいとか、それをレンダリングしたときにあんまりよくないと思ったら指摘するとか。そこに明るくないエディターもいるので感謝されたりします。

及川　バグをファイルして採用されると、仕様のAcknowledgements（謝辞）に載りますよね。

矢倉　はい。僕もHTML5仕様のAcknowledgementsに乗ってるんですけど、それはタイポを指摘しただけです。

及川　世界の標準化に自分の名前が入るって、嬉しくないですか？

矢倉　タイポじゃなくても「これ、こういう意味ですよね？ 違うの？ それ読みにくいんだけど」って指摘して文章を変えてもらって、それで謝辞に載るっていうテクニックもあります（笑）

安田　新しいAPIを紹介するブログやデモサイトを作るのは、スペックを書いている人にはめちゃめちゃありがたいことで、そういうのがあると、実はスペックを書いていて自分でもよく分からないところがあったりするので、実際に使ってもらうと、ああ間違ってたんだなとか、こういう使い方があるんだなと分かる。

特にデモサイトは言語を越えてシェアされることがあるので、あっという間に広がってエディターの耳にも入ります。Webで「おかしいな」と思うことがあったら自分たちでよくすることに携われるので、ぜひやってほしいです。

標準化をより速く前進させるにはテストが大事

及川　事前にいただいた質問ですが、ある国の言語固有の事柄の重要度を（ほかの言語を話す人々に）分かってもらうのは、どうしているのでしょうか？

石井　ネイティブは当たり前のことって理由を知らないんですよね。「すごく使われてるよ、当たり前だよ」と、それで納得してもらえることもありますが、理由を掘り下げてちゃんと説明しなければいけないこともあります。

英語圏でも（仕様に対して）1000のリクエストがきて、そのうち30を採用しようとか、どこかで足きりをしているんです。だから、日本語でこれが使われている（から仕様で採用してよ）というのも、それは足きりの上にあるのかどうかを説明しないといけない。英語圏のこれに該当するんだとか、相手が重要度を判断できるようにしてあげるのが大事だと思います。

及川　仕様策定のスピード感についての質問も来ています。

小松　スピードが遅いというのは実はあまり感じていないですね。というのも、レコメンデーション（勧告）になるのは遅くても、使えるようになるのはそんなに遅くないんです。

例えばAjaxのXMLHttpRequstって、あれまだレコメンデーションになってませんからね。レコメンデーションになるのが重要だとは思ってなくて、むしろちゃんと使われるようになることの方が重要で、そういう意味ではラストコール前のレベルになるのが開発者目線では重要だと思います。

石井　スピードに関してはテストが非常に大事だと思っていて、いま縦書きがWebKitとIE11で実装されていて、W3Cには縦書きのテストが2つくらい、WebKitに10個くらい。縦書きという仕様に対してテストがこれしかないんです。

ブラウザの開発者がコードを書いていても、これで正しいのかどうかテストできないし。

さきほどラストコールまで行ってくれれば、という話がありましたが、W3Cのレコメンデーションになるには、テストがあって、2つ以上の実装が全部のテストをパスすることという条件があります。ラストコール状態では、普及した後でIEとWebKitで動きが違うよ、ということになるリスクを抱えているわけです。

で、そのリスクがなくなるまでW3Cはレコメンデーションにしない、というルールを定めているので、みなさんがテストに貢献する、あるいは仕様の問題にフィードバックするだけで、スピードをあげることができると思います。

英語の壁はどうやって乗り越える？

会場からの質問　NTTコミュニケーションズの宮川と申します。僕は今日最後のセッションでIP屋さんとWeb屋さんの話というセッションをもたせていただくのですが、ちょうど2年後の2015年11月に、IETFの会議が横浜にやってきます。村井先生が宣言をしていてIETFのアジェンダリストにも載ってるんですね。

それに合わせて、W3Cも慶應大学がホストしていることもあって、TPAC（W3Cの会議。W3C Technical Plenary / Advisory Committee）をその前の週に誘致しようと。これは最近、Webの世界とIPの世界をいろいろマッシュアップしないと行けないことが見えてきました。で、聞きたいのは2年後にWebとIPの世界が日本で盛り上がっているところを世界に見せたいと思っていて、それについてどう思うか。

それからこういう活動はどうしても英語の壁みたいなのがあるので、それをみなさんどうやって解決しているのかについて。2つお伺いしたいと思います。

小松　実はこの人は僕の上司なんですが（笑）。英語を乗り越えるのは勇気を出すしかないと思います。下手な英語でもどんどん発言していくしかないと思います。みんな優しいので、こんな英語でごめんねと思っても、丁寧に聞いてくれるし話もしてくれるし。そこで経験を積むしかないかなと思います。

WebとIPを盛り上げるのは、ぜひコミュニティのイベントを大きくやっていきたいですね。

安田　英語の問題はがんばれば乗り越えられると思います（笑）。スペッックで使う英語はだいたい決まり切っているので、「こうあるべき」と思ったら「must」って書けばいいし（笑）。そんな感じで乗り越えられると思います。

石井　英語を読むのは単語力だと思います。でも、仕様で使われる単語は少ないですし、半分くらいはカタカナで聞いてると思いますし、ちょっと辞書でよく使われる単語を調べればすぐ読めるようになるのではないかと思います。

私は英語で仕事をするのは困りませんが、雑談になると単語がまったく分からないのでほぼ英語が分からなくなります。

英語をしゃべるほうは気合いですね。外国人がきて片言の日本語を話しても意味は分かりますよね、それと一緒で、だいたい単語さえ並べれば通じます。困るのは日本人が3人いてとなりの人の英語が分からないということはありますけど（笑）。相手は分かってくれるので、全然問題ないです。

矢倉　私は海外に住んでいたことはありますのでそのアドバンテージはありますが、自分がなにを考えているのかを説明するのに、僕は日本語でも英語でも不自由さを感じているので、自分が思っていることをを伝えるのは難しいことで、それができるのであれば、言語はそれほど関係ないのではないかと思います。

盛り上げることに関しては、僕は得意ではないのですが、日本も海外も関係なく盛り上がればいいなと思います。

及川　時間となってしまいました。標準活動に参加したいと思う人！（会場から手が上がる）。ありがとうございます。スペックを書いている人にとっては、日本語でも構わないのでそれについて反応してくれるだけでも貢献になります。ぜひ、そういうところからでも参加してみてください。ありがとうございました。