サイボウズでデザインテクノロジストをしている @saku です。
サイボウズ株式会社は、2025年4月1日より、Web技術の標準化と推進を目的とした国際的なコンソーシアムである「W3C」のメンバーに加入しました。
今回は、W3CのVP, Technical StrategyであるPhilippe Le Hégaretさんにインタビューをさせていただき、W3Cの起源や、Web標準の作り方、そして来月神戸で開催されるTPACについてお伺いしました。
お忙しい中、1時間におよぶロングインタビューをさせていただいたので、前・後編に分けてお送りします。
W3Cはどうやって始まった?
S(Saku): 私は2、3年前にキャリアをスタートしたので、Web業界には入ったばかりなのですが、Philippeさんはこの業界に長くDOMやHTMLのワーキング・グループでチェアをされていましたよね。
P(Pilippe): そうだね、私は2000年にDOMワーキング・グループのチェアになったんだ。
S: CSSとHTML5にもコントリビュートしてましたよね？
P: 1999年にW3Cに参加して、当時はDOMワーキング・グループに加わり、CSSOM（CSS Object Model）に取り組んでいたよ。1997年にCSS Validatorの最初のバージョンを書いたのがきっかけでね。
P: CSSに詳しく、CSSを中心にコードを書いていたので、1999年にW3Cに「CSSOMの仕様を書くのを手伝ってくれないか？」と誘われたんだ。でもCSSWGよりDOMワーキング・グループで活動していたんだ。
P: そして、2000年末にDOMワーキング・グループのチェアになって、2004年くらいまではDOMワーキング・グループで。そこから2008年まではXMLやWebサービスの分野で活動して、そこからHTML5を担当するようになったんだ。
S: すごい、つまりWebフロントエンド技術の、中心的な部分全部ですね。確か、SVGにも携わってましたよね？
P: そうだけど、そっちは大したことはしてないんだ。
S: そんなPhilippeさんに、まず、W3Cがどのように始まって運営されているのか、どのようにMITでCERNのコラボレーションとして始まったのか。なぜ標準化団体が必要で、W3CによってWeb技術を統一する必要があったのか、などをお聞きしたいです。
P: それだったら、最近Timが本を出したので、それを読めば全部書いてあるよw
P: そうだね、TimはCERNで働いていた。
P: 彼はWebが急成長していることに気づき、コンソーシアムを作る必要があると考えたんだ。でもCERNはあまり興味を示さなかった。
P: でもMITは非常に興味を持ったんだ。だから、当時のMITコンピュータ研究所の所長がスイスに飛んできて、Timと2時間半ほどディナーをした。
P: そうして、1994年の初めにはDARPAというアメリカの機関に、コンソーシアムを設立する資金調達の提案書を書いて、1994年10月1日にW3Cはスタートした。
P: でも当時、TimはMosaicという会社に苦労していたんだ。Mosaicは大人気なブラウザで、「Webはこうあるべき」っていう独自の見解を持っていた。
P: だから基本的にTimは、Webが一企業に支配されないようにしたかったんだ。それがW3Cを設立する動機のひとつだった。
S: なるほど。それで、TimはWebをTim自身の標準、あるいは「みんなのための標準」に則るようにしたかった。彼は一企業のためにWebを作るということはしたくなかったんですね。
P: その通り。一つの会社のコントロールに陥らないようにしたかった。すべての企業が参加できるようにね。
P: そして、Mosaicを作っていたNCSAは95年にコンソーシアムに入ったんだ。
S: そこからNCSAもWeb標準の策定に参加するようになったんですね。
P: そう。当時Web標準として取り組んでいたのはHTMLでCSSはまだ存在しなかった。
S: CSSは1996年でしたよね？
P: そう。1995年当時やっていたのはHTMLだけで、CSSは1996年だった。
S: 一方で、HTTPはIETFに残っていますよね？
P: そう、今日に至るまでHTTPはW3CではなくIETFで策定されている。
S: なぜ別々で作業してるんでしょう？
P: それは、IETFが「インターネット」を担当するタスクフォースだからなんだ。
P: IETFはプロトコルの標準化を専門にしてるので、HTTPをIETFで策定するのは理にかなっているんだ。HTTPは、HTML・CSS・画像などW3Cで標準化されているもの以外にも、あらゆるものを送信できるプロトコルだからね。
P: だから、W3Cではプロトコルは作らず、IETFで策定されたプロトコルに乗せているんだ。
P: そのもうひとつの例がWebRTCだね。W3CではAPIに取り組んでおり、IETFにはプロトコルを担当するグループがある。
S: そうですね。合併しないのは利便性のためですか？
P: というより、プロトコルを設計するのとAPIを定義するのでは、必要な技術や経験が全く違うんだ。
S: なるほど、だから別の場所で策定をしてるんですね。
P: そのとおり。
W3Cにおける困難な「決断」
S: Philippeさんが何十年もWebの進化に携わってきた中で、個人やW3C、ひいてはWeb全体が、しなければならなかった最も困難な決断は何だったでしょうか？
P: ああ、たくさんあったよ。
P: 強いて挙げるなら、それが今日のWebに影響を与えることはなかったけど、2001年にXMLに取り組んでいた当時は、非常に物議を醸した。
P: XMLのnamespaceをめぐっては、仕様にnamespaceのサポートを追加していたDOMワーキング・グループが、namespaceはURLにするのか、それとも単にstringにするのかという疑問をあえて投げかけたんだ。
P: そのシンプルな疑問は、コンソーシアム全体を8カ月か9カ月くらいブロックしたんだ。
S: そんなことがあったんですね。
P: W3C全体を巻き込む議論に発展してしまって。
S: W3C全体をですか！？
P: そう、全てがブロックされた。企業もブロックされたんだ。
S: その時、どのくらいの人がW3Cで活動していたんですか？
P: そこまではわからないけど、XMLやDOMに大きな影響を与えた。CSSやHTMLにはそれほど影響はなかったけど。
P: 最終的にTim Berners-LeeがXML namespaceは単なるstring（※アクセスできる必要はないという意味）だという決断を下すまで続いたんだ。長い間コンソーシアム全体がブロックされ続けたことに腹を立ててた人たちに、2時間くらい怒鳴られたのも覚えているよ。
S: そうなんですね。
P: 当時、あえてその質問をしたのは私たち（DOMワーキング・グループ）だったんだ。
P: 数年後、私たちがビデオ、特に有料動画（Premium Video）の再生に取り組み始めたときにも、大きな議論が巻き起こったね。ビデオコンテンツを暗号化できるEncrypted Media Extensions APIの策定だ。
S: どんな議論が起こったんですか？
P: この技術はDRMに依存しているため、論争の的になりやすい話題なんだ。DRMは、その名前の通り著作権を保護するために、隠された部分がある。そのためにユーザー自身ではコンテンツを復号できない。
S: つまりセキュアじゃないということですね？
P: 自分で制御できないコードを実行せざるを得ないので、その意味ではオープンソースとは言えないし、安全でなくなる可能性もあって、非常に物議を醸したんだ。
S: でも、それが適切でないことをみんなが理解すれば、その提案は反対されて取り下げられるんじゃないかと思うんですが？
P: ここでの議論は、つまり「Web上で人々が映画を見ることを許可するのか」という点だったんだ。
P: これが"No"なら、動画再生のユースケースをサポートしないことになり、代わりにネイティブアプリケーションを推奨することになる。
S: そうなりますね。
P: だから、私たちのモチベーションは、みんなが可能な限り安全な方法でビデオを再生できるようにすることだったんだ。
P: そのため、現在ではWebブラウザを使用すると、Googleが提供するWidevineのようなコードが少しだけ含まれている。
P: これにより、サンドボックスの中で著作権のあるビデオも再生することができるようになった。コントロールできないコードを実行できるようにするコツは、サンドボックスの中で実行し、コードで可能なことを制限することなんだ。
S: なるほど、テクニカルに問題を解決したわけですね。
P: そう。このAPIのおかげで、Webブラウザで有料動画を再生できるようになった。
P: でも、多くの人がこの仕組みに取り組むこと自体を好ましく思っていなかったから、非常に物議を醸したね。
P: 私たちが立ち向かう問題は簡単なものばかりではなく、非常に難しい問題もある。
P: 私たちはWeb上で他のテクノロジーを使い始めるよう、人々に押し付けたいわけではない。
S: 人々を正しい方向に導くためのものですよね。
S: ただ、どうしても強く反対する人々がいる場合、どのようにしてコンセンサスを得ているのですか？
P: 様々な経歴や思想、企業から集まったエンジニアたちと一堂に会する時、結局のところこれは「人間」の問題になるんだ。互いを少しずつ理解させ、協力して働けるようにすることが肝心。あらゆる背景を持つ人々でチームを作り、その課題の解決に向けて協力させなければならないんだ。
S: そうですよね。
P: 大変だけどね。相手側にも意見があることを認識してもらうしかない。
P: その経験の中で私たちが育ててきたのが、「W3Cのプロセスそのもの」なんだ。
P: 例えば、W3Cのプロセスでは、コメントを単に無視することはできない。すべてのコメントには価値があり、寄せられたすべてのIssueには目を通す。
S: 全ての貢献が歓迎されているんですね。
P: そう、その一環として、気に入らないからと言ってワーキング・グループがコメントを無視することも許されない。
P: 「あなたのユースケースに対応するつもりはない」あるいは「あなたのアプローチは受け入れられない」と言うことはあっても、単に「気に入らないから無視する」ということは許されない。
P: 例えば、「あなたは大企業で働いていないから、あなたの意見は聞くに値しない」ということもない。
S: なるほど
W3Cの原則（Principle）とは?
P: あと、特に最近やったことは、特にTim Berners-Leeが2023年にW3Cのディレクターを退任したのをきっかけに、私たちは一連の原則（Principles）を発表したんだ。
S: そう、それについてお聞きしたかったんです!
P: 技術的な決定を下すときに、どのようにして原則（Principles）に基づくのかという指針を公表したんだ。それには、「倫理的なWebの原則（Ethical Web Principles）」と「プライバシーの原則（Privacy Principles）」の2つがある。どちらも今年の初めにW3Cに承認され、私たちが決断を迫られる際の指針となるものだ。
P: というのも、セキュリティやプライバシーが機能性に相反していることは非常に多く、すべてを満足させるのが難しい場面は非常に多いんだ。相反する要件のバランスを取らなければならない。
P: そういうとき、この原則に基づくことで、適切なバランスを見極めることができる。
S: バランスを取るということについてですが、例えばTAG（Technical Architecture Group）はWebのテクニカルな決定をバランスよく行う上で、かなり優れた専門性を持っていると思います。TAGはどのように選出され、どのようにトレーニングされているのでしょうか？
P: TAGはトレーニングを受けたりはしないよ。ほとんどは投票で選ばれていて、コミュニティから選出されている。つまりW3Cに加盟していなくても、TAGに選出されることはできるんだ。
S: そうですね。
P: 唯一の条件は、メンバーの誰かから推薦されること。それ以外には、どのような個人が推薦されるかという制限は特にない。
S: Webの設計の原則を理解している必要があればということですかね。
P: というか、立候補して「私はこういう専門知識を持っていて、過去にWebプラットフォームに貢献したことがあります」とアピールするだけ。あとは普通の選挙と同じ。試験やテストに合格しなければならないとか、そういうことではないんだ。
S: なるほど。
P: 残りは、私を含むW3Cチームが指名している。だから、毎年この選挙を行うときには、私はTAGのチェアと一緒に、今どのような専門家が必要なのかを考え、選挙の結果、W3Cチームは議席数に応じて1人か2人を推薦するんだ。
P: そうすることで、TAGは適切な専門知識を持つ仕組みになっている。
S: そういう意味でTAGは、Web技術において、バランスを維持するための重要な役割を担っていると思いますか？
P: Yesだね。なのでTAGも先程の原則（Principles）の策定作業にも入っているし、アーキテクチャの決定を支援してバランスの維持に貢献している。
S: TAGが最も適切なんでしょうか？TAG以外にもWebのバランスをとるためのグループはありますか？
P: 最も適切かは、誰が選ばれるかによると思うけど、今のところTAGはバランスを取るために、かなりいい仕事をしていると言えるよ。
S: なるほど、理解しました。
P: 付け加えるなら、私はこれまでTAGの仕事に時間を割いてくれた人々にとても感謝しています。
S: 本当にそう思いますね。
S: 先ほどお話しされたこれらの変化は、W3Cの柔軟性そのものを示していると思います。そこで、より大きな概念的な疑問が浮かんできたんです。
W3Cの「柔軟性」の秘訣とは?
S: Webは絶えず変化し、深く人間的で文化的であり、本質的に政治的でもあります。そうでありながら、素晴らしいことにW3Cは30年以上も存続してきましたよね。
S: なぜ、W3Cはこれほどまでに柔軟な組織になったのでしょう？その要因や戦略は何だったと思いますか？
P: うーん...結局はTimがみんなのためにWebを作って、W3Cもそれを大事にしているってことだと思うね。
P: 私がWeb標準について話すとき、必ずコミュニティについて話すんだ。つまり本質的に、誰もが自分の能力の範囲内で貢献したいと常に思っていて、私たちはW3Cへの参加機会を可能な限り提供する。新しいアイデアを持つ人々がそれを発表し、そのアイデアを中心に小さなコミュニティを形成し、Webプラットフォームを発展させることを望んでいるからなんだ。
P: つまり、私たちの機能は、外部から新しいアイデアを迎え入れること、そして人々を惹きつけることなんだ。仕様策定は結局のところ人々によって行われるものであり、企業によって行われるものでも何でもない。実際に誰かが机に向かって作業をした、その結果なんだ。重要なのは、人々にその能力や機会を与え、それを後押しすること。それがWebを柔軟にしている所以なんだ。
S: なるほどです。
P: 私たちは問題の解決に関して、かなりユニークな立場にある。それは、私たちが長年堅持してきた一連の原則のおかげなんだ。
P: それまではTimがディレクターを務めていたので、私たちは原則（Principle）がなくても問題はなかった。しかし、彼が引退したため、原則（Principle）を書く必要が出てきたんだ。2003年、ある人が私のところにやってきて「W3Cの技術的な使命をどうやって達成するつもりなのか？」と尋ねたんだけど。私は「原則に基づく」と答えたんだ。
P: だから私はTAGに対して、「私たちには原則（Principles）が必要だ、それを作ってほしい」と伝えたんだ。
S: なるほど。でも、その原則も「文化」や「政治的」なものにも基づいて進化していくものだと思います。そうやって、原則（Principle）を、「人間」の活動に基づいて進化させるために、何か工夫がされているんでしょうか？
P: コミュニティとの協力こそが最善です。TAGはまさにそこを重視しています。
P: Face to Faceミーティングで集まるたびに、そこのローカルコミュニティと別途ミートアップを開催し、そこの人々が感じている懸念や問題に耳を傾けるようにしている。
P: つまり、Webを利用する人々と可能な限り近くにいることが重要なんだ。結局のところ、私たちはWebを使う「人」のために作っているのだからね。
S: なるほど、よく分かりました。
S: 気づいたんですが、直近で行われたプロセスの改善は、W3Cの柔軟性の維持の一環で、Webのバランスをより良い方向へ持っていくための取り組みの一部なんでしょうか？
P: それは正しいけど、正直なところ、私はそれは全体のごく一部だと思っているよ。
S: なるほど
P: コミュニティが私たちのプロセスにそれほど関心を持つとは思っていないんだ、むしろ私たちが取り組んでいる技術的な作業そのものの方が、コミュニティにとっては重要だと思う。
P: つまり、このプロセスは必要なものだけど、あえて言うなら "必要悪" なんだ。もし、プロセスを使わずにコミュニティとの合意を得られるなら、その方が良い。プロセスが本当に必要なのは、意見が食い違ったときなんだ。プロセスは意見の相違を乗り越え、決断へと導くためにある。無くて済むなら、無い方がいい。
S: みんながどのように進めればよいか最初から理解しているのなら、その方がいいですもんね。
P: プロセスを理解しなくても前進することができるなら、それが理想のアプローチなんだ。
S: わかります
P: 私たちは最近プロセスを更新したけれど、それはコミュニティ全体に直接的な影響を与えない、細かい話だったからなんだ。
P: 多くの人が「W3Cのプロセスは複雑すぎる」と思っていて、その気持ちは十分わかる。でも、私たちが扱っているのも、また複雑な問題なんだ。そのため、プロセスが複雑になってしまうのはしょうがないんだ。
S: そうですよね
P: グループにとってフラストレーションのたまる要因の一つは、セキュリティ、プライバシー、アクセシビリティのレビューをクリアする必要があることだ。
P: 「そのやり方ではうまくいかない、ユーザーのプライバシーを侵害しているからだ」と告げられるのは、それがやりたいグループにとって苦痛になり得る。
P: それゆえ、プライバシーの侵害が発生したり、アクセシブルじゃないマークアップなどが作られないように、APIを改善する必要が出るんだ。
S: 確かに、そういった指摘がAPIをより良い方向に進めるでしょうね。
P: 難しいことで、多くのWGがこれらの原則（Principle）に真っ向から対立するような作業もしている。さっきも言ったように、ここではバランスが重要なんだ。
P: Web Performance Working Groupがわかりやすい例だろう。Webアプリケーションのパフォーマンスを、モニタリングができるような仕様を策定しているんだ。
P: これを使うと、Webアプリケーションで様々な計測を行うことができる。それらをサーバーで収集し、ユーザー体験の良し悪しを把握するために、分析を行うことができる。でも、裏を返せばユーザーが何をしているかを細かく把握できることを意味するんだ。
S: そうなりますよね。
P: プライバシーの観点から見れば、悪夢のような話になる。そして、そういう課題は解決されなければならない。
P: もちろん、今のWebプラットフォームの至るところにプライバシーの問題があるわけではない。でも、それは常に戦いの連続だ。プライバシーに関して言えば、フィンガープリンティングなんかは大きな問題だね。
P: もしフィンガープリントが簡単に取得できてしまったら、それは問題だ。でも、それはユーザーが望むものを実現する要件と、矛盾することにもなる。
S: 確かに、セキュリティやプライバシーのために意見や提案を阻止するようなことをするたびに、Webは前に進まなくなる。だから、バランスを取る必要がありますね。
P: 例えば、Google Mapのような地図アプリケーションは、Mapを開いた状態でGPS機能へのアクセス権を与えなければ、地図上のどこにいるのかをピンポイントで特定することはできない。
S: そうですね。
P: そして、GPSによってデバイスへのアクセスを許可を求めることは、ユーザーのプライバシーを侵害することと表裏一体になりかねない。
P: つまり矛盾しているんだ、自分が地図上のどこにいるか知りたいのなら、サイトに位置情報を提供する必要がある。教えたくないなら、サイトはあなたの正確な位置を把握できない。もちろん、IPアドレス含めある程度の緩和策はあるけれど。
S: とはいえ、もしプラットフォームレベルでそれらが解決されずに、開発者レベルで独自解決されてしまうなら、それは安全性が低く、プライバシーを侵害するような実装を生んでしまうかもしれませんよね？
P: ユーザーは、ネイティブアプリに切り替えるようになるだろう。これもまた問題なため、Webアプリケーションは機能強化が求められることになる。その実現には、より多くの機能へのアクセスを許可する必要があることも理解しているけど、ときにそれは「セキュリティ」と「プライバシー」に反するものなんだ。
S: そうしたセキュリティやプライバシー、アクセシビリティといった壁に対応しながら、Webを取り巻く進化は適応していくことになるんだと思います。
W3Cでの後悔
S: それを踏まえて、これまでを振り返ったとき、W3C内、あるいはWebエコシステム全体において、もう少し異なるアプローチや道筋を取れたかもしれないと思う、技術的決定はありましたか？必ずしも間違いとは言わないのですが、もし技術的な観点で何か「もしも」を思いつくなら、と気になったのです。
P: そうだな、後悔があるとすれば、1つは動画字幕かな。
S: 動画字幕ですか？
P: 動画に字幕をつける仕様として、TTML（Time to Text Markup Language）と呼ばれる仕様に取り組んできたんだ。
P: そして、その仕様におけるスタイルプロパティは、CSSの代わりにXSL-FO（XSL Formatting Object）を使っている。
P: あれは間違いだった。最初からCSSを使うべきだった。
P: 残念なことに、TTMLはXMLが非常にホットな時代に始まったもので、XML-FOはXML用のFormat Objectだから、XML-FOを使うべきだとなったんだ。
S: なるほど
P: そして今、私たちは使いたくもないObject Modelから抜け出せないでいる。そして、広く使われているその仕様も行き詰まっていて、いつかはその仕様を放棄するか、CSSに切り替えるかしなければならないんだけど、マーケットには大きな混乱を与えるだろうね。
S: 難しそうですね。
P: それが16、7年前に私たちが犯した過ちのひとつで、その代償を払うことになる。
S: そこから得た教訓は何かありますか？
P: やはり、Webテクノロジーをデプロイするときには、「10年、20年後にどうなるか」も考える必要があるということかな。
P: Webテクノロジーをデプロイして、それが4年後に消えてしまうということはまずない。デプロイすれば、その技術を使うユーザーが必ず出てくる。だから長期的な視点で考えなければならない。
S: そうですね、後方互換性がつきもの。
P: そこに対して常に注意を払うんだ、なぜなら、下す決断の一つ一つが、10年先、15年先には、後方互換性という観点から悩みの種になりかねないから。
P: だから私はいつも、コミュニティには「手元の小さなユースケースや問題だけじゃなく、大きな視野で考えよう」と勧めているんだ。
S: そのためにも、幅広いコミュニティからのフィードバックが必要なんですね。
P: そのとおり。今日ある問題に対処しているように見えても、その解決策は明日の問題に対処するためにも使われることになる。
P: そして、もし今日の問題のためだけのソリューションしか考えてないのであれば、それを明日どう活用するのかを考えるのに苦労することになる。
S: 数年後、そのせいで苦しむことになりますもんね。
P: そう、そのせいで苦しむことになる。
S: より幅広いコミュニティからのフィードバックを得るための方法や仕組みは、何かあるんでしょうか？
P: 他のグループからレビューを受けることは、私達にとってとても重要なことだと思うよ。
P: 標準の作成には関与していないかもしれないが、その技術に興味を持つ分野に関わっているかもしれない。そして、それらはすべてユースケースになり得る。
S: そうですね
P: だから、Webテクノロジーの専門家ではない人たちからのフィードバックを得ることも、とても重要なことなんだ。
P: だから、そういったことを世界中に広めて、世界中で講演をしたり、世界中の人たちと話したりするんだ。テクノロジーをどう使っているのかとか、直面している課題は何なのかとか、こうだったらいいのにとかを聞くためにね。それは、長期の視点で考える上で非常に良い方法なんだ。
S: Editors Draftのレベルで何か1つのブラウザにShipし、ユーザーからのフィードバックを集めて修正することも、仕様を前進させるための良い方法だと思いますか？
P: ブラウザが仕様を早期に実装し、ユーザーからのフィードバックを得る目的ならそうだ。それはグループへのフィードバックとして上がってくるので。ブラウザからであろうと、道行く人からであろうと、私たちは自分たちの仕様について、得られるすべてのフィードバックを受け止める。
S: 他のブラウザがその仕様に同意していない状況でも、ブラウザでの実装を先行してフィードバックを募るという方法は、仕様を前進させる良い道筋になり得るんでしょうか？
P: もちろんケースバイケースだが、策定に時間がかかる場合もある。
P: その一例として、W3Cはアクセシビリティに関して非常に粘り強く取り組んできた。アクセシビリティに関しては、何年にも渡って非常にアクティブな素晴らしいコミュニティが存在する。
P: 同時に、アクセシビリティには他にはない特有の課題もあることも事実だ。そして、ブラウザベンダーは当初、それに対してあまり乗り気ではないようだった。「配慮すべきユーザーが少ないのであれば、実装の優先度は低い」といった具合に。
P: 開発者に説明してもらうには、往々にして開発者と向き合い、現在の設計で生じている課題を示し、実際に修正が必要だと伝える必要がある。そして修正方法を教えるんだ。なぜなら、Mac上でアクセシビリティの問題を指摘しても、その修正方法が自明ではないからです。アクセシビリティにおける設計上の問題は、修正が非常に難しいことなんだ。
P: それでいうと、WebGPUワーキング・グループの話を聞くと、アクセシビリティの問題が上げられているね。なぜなら完全にグラフィックベースだからで、視覚障がい者の場合グラフィック表現は全く役に立たないからなんだ。では、どうやってそれに対処し、それを補うのか。グラフィックの専門家であっても、アクセシビリティの専門家ではないことは多々あるよね。
S: 確かに
P: だから、課題を理解するのを助け、その課題を解決する方法を一緒に考えることが重要なんだ。
S: ワーキング・グループ間のつながりも非常に重要な役割なのですね。この内容の詳細は後で詳しく聞きたいと思うので、次の質問に移りたいと思います。先程、XMLとTTMLの困難についてお話していただきましたが
S: こうした「何がうまくいったのか」、「何が違う方法を取れたのか」どちらも非常に知る価値のあるものだと思いました。それと同時に、新しい人たちから新しい視点を得ることができれば、それは新しいアイデアにつながる。それも非常に価値あることだと思います。
Webへの「貢献」の難しさ
S: このようなことを考えると、Webへの貢献において多くの人が直面する困難について考えさせられます。Webへの貢献はOSSへの貢献とは異なり、私を含むほとんどの人にとってかなり難しいことだと思っています。そこで、W3Cとしてこの問題にどう対処しようとしているのか、何か考えられる策はあるのか、伺いたいです。
P: ああ、正直なところ、私たちはその点で少し苦労しているんだ。理由の一つとして、Webプラットフォームがますます複雑になっていることがある。20年前と比べて、Webブラウザでできることは格段に増えた。
P: 幸いなことに、COVIDが流行し始めた時点で、WebRTCは十分にデプロイされていたんだ。だから私たちは、COVID中にビデオ会議に移行することができた。
P: それは、私たちが10年前にWebRTCの開発を開始していたからなんだ。最初の会議が行われたのは2010年か2011年頃だった。
P: その取り組みのおかげで、COVIDが来た時には、Webブラウザで実際にビデオ会議ができる状態だった。多くの子供たちが遠隔で学校に通えるようになったのも、そのおかげだ。
P: 本当に、そのおかげで。
P: Webによって世界が便利になる一方で、プラットフォームはもっともっと複雑になる。
P: だから、人々が技術について一歩ずつ学びながら進むのを、サポートするのも私たちがやるべきことなんだ。
P: どうしても、多少の学習曲線はつきもの。でも、誰もがどこかで、学び始めなければならない。残念ながら、ブラウザが近い将来AIで書かれることはないと思っているしね。
P: 今のところ、Webブラウザを進化させることができるのは人間だけなんだ。だから、まだ苦労しているんだけどね。
S: なるほど。
P: トレーニングセッションを開催したりもしているんだけど、それに協力してもらうのも、けっこう難しいんだ。それによって他の作業の時間が奪われてしまうからね。
P: でも、できる限り開催するように頑張っているよ。
P: そして、TPACでもそれができることを願っている。
後編へ続きます。