「HTML5 Conference 2013」において行われた「Spec EditorとContributorが語るWeb標準化と開発者への期待」。グーグル及川卓也氏による総合司会のもと、Web技術の標準化に携わっている楽天の石井宏治氏、グーグル安田絹子氏、NTTコミュニケーションズ小松健作氏、矢倉眞隆氏4名の開発者によるセッションの一部をレポートします。

Web技術における「標準化」とは何か？

及川：一般的にWeb技術の標準化の対象になるのは「HTML」「CSS」「JavaScript」「ネットワークプロトコル」「Unicode」といった分野が中心になるかと思います。 まず具体的にどういったテーマの標準化に関わっているのか。またその内容に関して簡潔に教えてください。

矢倉：W3Cにおいて、HTMLやCSS、API等の仕様策定に関わっています。ブラウザに実装される仕様にするために、主にフロントエンド周りの仕様を作ります。ここでは「標準」ではなく「勧告」というレベルにおける仕様。そこで作って決めてから製品を出します。デファクトスタンダードは「使ってなんぼ」という傾向があり、実際に書いて実装してから、よくない部分をフィードバックして仕様を固めてから勧告します。つまり、実装がないと仕様が完成しないということです。


小松：IETF（Internet Engineering Task Force　通信プロトコル標準化）において、具体的にどういう通信プロトコルでやるか？　IETFで勧めたデータフォーマットを標準化していきます。普段はメーリングリストや年3回のワーキンググループミーティングでメンバー同士議論して実装、その後仕様にフィードバック～レビュー～レコメンデーション、といった流れで標準化が進んでいきます。ステークホルダーの多いW3Cと比べると、IETFの方が一般的に仕様化が早い気がしますね。

石井：私は「Unicode」という文字コードを決める団体に関わっています。例えば「お墓に使う文字」を新たに業界標準文字に指定したり、文字単位で仕様を決める場合「どこで改行したらいいか？」といった規則を全部の文字にプロパティとして決めたり。またCSSで縦書きで書こうとした場合、何が横書きで縦書きにすべきなのか考えたとき、「半角は横書き」といった規定をUnicodeで決めます。

及川：標準化には「デファクト標準」「デジュール標準（国や政府が決める）ものがあり、Unicodeはデファクト標準。政府調達でデジュールじゃないとダメ、という規則もありますよね。

標準化に関わることの苦労とは？

及川：実際にWeb標準化に携わることでいろいろ苦労もあると思うのですが、その点はいかがでしょうか？

安田：例えばW3Cのスペックにもいろいろあり、よく議論が紛糾し、調停しないといけないケースもあります。私の場合、主にマイナーな分野を担当しているので、他のブラウザベンダー開発者に担当しているテーマに関する重要性を分かってもらい、実装してもらわないと前に進まず困ることになります。そこでメールや電話、また直接ベンダーとお会いして、「こういうことを考えていますけど、フィードバックいただけませんか」と頼むこともあります。そこで断られることもあるので、結構地道な努力が必要です。

あと、私が実装しているAPIも仕様にフィードバックがあって、慌てて仕様を変えて実装し、改善することもあります。こればかりは実装しないとわからない部分もあるので、実装しながら改善していくスタイルが求められますね。

石井：そもそも標準化する目的は、2つ以上のベンダーがあって、それぞれに対してたくさんのユーザーがいて、その2つが同じように動くことでユーザーや開発者にメリットが生まれることを目指すことにあります。

アイデアを出す部分から、最終的にステークホルダーが全員納得するところまで持っていく苦労がある。そのために、まずは多くの人数が議論する価値があることを、みんなに納得してもらうことが必要。クロームやサファリ、IEなど最低2つが「実装しよう」と言わないと標準化はできない。その機能を要望する声と、実際に使う機能がマッチしているか？そして実装する側のベンダーの合意を全部持っていくことが標準化への大きなカギを握ります。

逆に「こんな中途半端な機能なら日本はいらない」といって突然メールが来ると結構つらいですね。これを俗に「後ろから撃たれる」といいますが（笑）。

標準化に貢献するメリット・やりがいとは？

及川：逆にWeb技術の標準化に携わることで得られるメリットややりがいについて、教えてください。

小松：その仕様自体に何らかのリクワイアメントを示すこと自体が「コントリビュート」、つまり標準化に貢献していることになるんですよね。例えば新しいAPIを使ってサンプルを作る。そうすると「これは面白い」とブログで紹介される。そこで「ここの部分に問題がある」というフィードバックを受ける。その大きな流れの中に参加し、コントリビュートしていくこと自体に、大きなやりがいがあると思います。それにこう考えると実はコントリビュートしたことがある人は結構いるんじゃないでしょうか。より強くコントリビュートする意識があるかないかの違いだけで。

矢倉：例えばW3Cに貢献する場合、「バグをファイルする」「仕様のエラーを報告する」「アルゴリズムを読んでいておかしいところを突く」「HTMLのルビの日本語で、この書き方だとレンダリングしたときにおかしいと伝える」。こうしたことをするだけで、その分野に明るくない人にとってはありがたいことですし、感謝されます。ただ使っただけでは誰にも届かないし、何も変わらない。けれど誰かに伝えるとかなり前進して、2歩も3歩もフィードバックを受ける。それによって仕様に対して一段と深い知識得られるし、その分野のエキスパートになれるメリットはあると思います。

及川：それに実際に自分のアイデアで仕様が策定された時、世界のWeb標準化に自分の名前がクレジットで入るんですよね。これは開発者にとって嬉しい。

これからどのように標準化に携わったらいい？

及川：今回のセッションを聞いて、「私も標準化に携わってみよう」と思った場合、具体的にどのような手段で参加したらいいんでしょうか？

石井：基本的にはメーリングリストに自分のアイデアを書いて、メンバーからの賛成を得られれば、仕様を策定することができます。ただしいざ仕様を策定する場合、誰かが主体になってドライブしなければいけないのと、「エディターコード」が必要になります。一方、ワーキンググループ内で「この人の提案したアイデアはとても有用だ」と認められると、それだけで仕様が決めることもあります。

安田：新しいAPIを公開するブログやデモサイトがあるので、そうした場でぜひ意見を書き込んでほしいですね。そこに書かれた内容は、私のようにスペックを書いている人にとって非常にありがたいこと。「こういう使い方もあるんだ」と思うし、有益な情報はサイトシェアされてあっという間に広がります。基本、普段利用しているWebで「何かおかしい」と思ったら、自分たちでよくしていける一番いい方法を周りの方たちと話し合う。そしてその内容を発信していくことが、標準化に携わる第一歩になるのではないでしょうか。

【講演資料・セッション映像】