以下はYoav(Webサイト / GitHub / X)による記事、So, you don't like a web platform proposalの紹介です。
So, you don't like a web platform proposal
そうか、君はこのproposalが気に入らないというわけだ。
ある朝、コーヒーを飲みながらWebを見ていると、本当に気に入らないWeb APIの提案が目に入りました。
悪いことに、もしこれが通ったとしたら、Webに決定的な悪影響を与える可能性があります。
そしてあなたは、プラットフォームが大きな間違いを起こすことを防ぐに足る知識と経験を自身が持っていると自負しています。
素晴らしいことです。
Webプラットフォームは全ての人に開かれているので、Webプラットフォームの議論にはだれでも参加することができます。
同時に、議論に参加するのであれば避けたい落とし穴もいくつか存在します。
それらは私の身にも降りかかったことがあります。
ブラウザベンダーに就職する前とした後で、私がWebプラットフォームに携わる中で学んだことをいくつか挙げてみます。
Things to bear in mind
心に留め置くべきこと。
Don't assume consensus nor finished state
そのproposalは最終形ではない。
大抵の場合、proposalは、何らかの問題を解決するために作られた技術的な提案です。
公開フォーラムにproposalを持ち込んだ時点では、必ずしもproposalの提出者の雇用企業がそのproposalを支持しているとは限りません。
そもそもproposalは提出された段階で完成されているわけではなく、proposalの改善提案を受け入れないことを意味しているわけでもありません。
各proposalは提案の様々な段階にあり、特に初期段階のproposalは特に多くの修正を受け入れる余地があります。
つまり、適切なタイミングで適切なフィードバックを行うことで、懸念を早期に発見し、適切に対処できる可能性が大幅に高まるということです。
Don't assume a hidden agenda
新しいproposalが提出される理由は、大抵の場合、それを提案しているチームが、その提案を扱うユースケースに取り組む必要があるからであり、必要以上の悪意を見いだす必要はありません。
法的だったりその他の理由で、その提案を扱うユースケースに取り組む動機の全てが常に公開されているわけではありませんが、ユースケース自体はそのproposalによって何が解決されるのかを明示的に示す必要があります。
Avoid legal language
法律用語を避ける。
大企業に勤めている人を議論から離脱させる最も手っ取り早い方法は、法律的な言葉を使うことです。
これによって、彼らは企業の法律顧問に相談することなく回答することができなくなり、おそらく彼らは何も言わなくなるでしょう。
proposalの提案者と生産的なやりとりをしたいのであれば、弁護士のふりをしないべきです。
逆に言うと、彼らを黙らせたいのなら、弁護士のふりをするのが最善かもしれません。
We're all humans
我々みな人類。
Webプラットフォームで働いている人はみなそれぞれ、人間としての感情を持ち、自分の仕事をよりよくしようとしている人間です。
たとえあなたが彼らの選択、技術、決定に同意できないとしても、その事実は変わりません。
はっきり具体的に言うと、プラットフォームで働いている人たちへの個人攻撃や脅迫は許可されていません。
そうすると、あなたは自分の声を届けるかわりに、自分の声をどこにも届けることができなくなります。
What should I do then?
何をすべきか。
Be the signal, not the noise
ノイズではなく、意味のあるメッセージになろう。
物議を醸しそうなproposal、あるいは人々の望む機能が入っていないproposalには、何十何百もの善意のコメントが集中することは珍しいことではありません。
proposalのチームに影響を与え、考えを変えようと働きかけているのです。
私は長年Webプラットフォームで働いてきましたが、この働きかけが成功したところを見たことがありません。
一度たりともです。
proposalの提案者には大量の通知が届き、それらの中から意味のあるメッセージを選別するだけでも一苦労です。
その中には鋭い技術的指摘があるものも含まれるかもしれませんが、ゴミの山からそれを区別して取り出すことは限りなく困難であり苦痛です。
古き良きインターネット炎上に参加することは気分がいいことかもしれませんが、それが望む結果につながる可能性は非常に低いものです。
かわりに、技術的に有意義なフィードバックを、ノイズに埋もれる可能性の少ない選ばれた場所で行う必要があります。
Provide technical arguments
技術的なフィードバックを行う。
その際には、注意すべきことが幾つかあります。
Use cases
proposalが取り組むユースケースは、proposalを推進するチームが解決しようとしている問題の中核です。
他の全てはそこから派生するものです。
ユースケースを考えることでproposalの本質を取り出し、有害だったりリスキーだったりする部分に対処する代替案を提案できる可能性が高まります。
場合によっては、ユースケースそのものがWeb上でサポートされるべきではないと考えられることもあります。
その場合は、より厳しい戦いになることでしょう。
しかし、それらのユースケースがサポートされるべきでない理由について、ユースケースが採用されなかった場合とのトレードオフを考慮しながら、しっかりとした理論を構築して主張を行うことはできます。
それによって、proposalの提案者と対等に議論する立場を確立することになるでしょう。
また一方で、あなたが関心を持つユースケースがそのproposalではサポートされていない場合もあるかもしれません。
その際はそのような提案を行うことで、ユースケースをカバーするようにproposalが拡張されるか、あるいは少なくとも将来proposalを拡張できる余地を作ることに役立つでしょう。
Risks
proposalに互換性や相互運用性に関する問題がある場合、あるいはWebプラットフォームの安全性に対するリスクが存在する場合、それは指摘する価値があります。
そのようなリスクは事前に対処され、proposalが決定される前に適切に軽減される必要があります。
リスクに対する主張が必ず全て受け入れられるというわけではありませんが、あなたの主張が適切であれば、proposalの提案者がそれに応じることを期待できます。
Considered alternatives
もうひとつ注目すべきこととしては、ユースケースに対処する代替案についてです。
多くの場合、想定される代替案とそのトレードオフについては最初からproposalに記載されています。
しかし、合理的な代替案が記載されていないこともあり、よりよいproposalの改善を思いつくこともあるでしょう。
そのような代替案を提案することで、proposalに取り組んでいるチームへの良いフィードバックとなり、チームに受け入れられる可能性が高まります。
Use professional language and be kind
専門用語で、丁寧な態度で。
専門用語ではない乱雑な言葉が使われていると、建設的なフィードバックとして受け取られる可能性は著しく低くなります。
さらにそれ以上に、ディスプレイの向こうにいるのは、自分の仕事をより良くしようと考えている人間であるということを忘れてはなりません。
彼らはおそらく、自分たちのproposalがどう受け取られるかについてストレスを覚えている可能性が高いでしょう。
たとえあなたが彼らのproposalに賛同できなかったり、それどころか彼らの仕事それ自体に賛同できなかったとしても、それに対する意見に共感や思いやりを込めることは可能であり、あなたに何のデメリットもありません。
皮肉を一切入れずに反対の意思を伝えることができます。
So, get (constructively) involved!
建設的に参加しましょう。
どれだけ適切な指摘や代替案であったとしても、そのフィードバックは必ずproposalに受け入れられ、統合されるというわけではありません。
しかし、ガイドラインを守ることで、あなたの意見を聞いてもらえる可能性が高まり、結果としてproposalに影響を与える可能性が高まります。
それこそが、本来の目的でしたよね？
感想
などと言われましてもね。
Web Environment Integrity APIみたいな根元から腐り果てているproposalに対しては袋叩きにする以外の何をしろという話ですよ。
といいますか順序が逆であり、実はこの記事自体がそもそもWeb Environment Integrity APIの炎上を受けて書かれたものです。
記事自体にはそのことは一切記載されていませんけどね。
Web Environment Integrity APIには以前からぽつぽつ批判があったのですが、一気に炎上したのが2023年7月19日です。
そしてこの記事が書かれたのが2023年7月20日です。
そしてこの記事の著者YoavはGoogleの中の人であり、コメントを粛正して回っている側です。
つまりはそういうことです。
ちなみにWeb Environment Integrity APIは、Googleの中の人(Yoavとは別人)が他のとこ(GitHub等)は民度低い犯罪者の巣窟だから無視するわなどと言い放ったせいでさらなる批判を招き、最終的に撤退に追い込まれました。
結果的にめでたしめでたし？
もっともWebViewでは広告ブロッカーブロックを続けるよとか諦めずにしつこくやっているので予断は許しませんが。
あと全然関係ないけどDeepLさん、さすがにこの訳はひどすぎないですかね。
本記事はCreative Commons Attribution 3.0 Unported Licenseライセンスで公開されています。