license)に基づいて翻訳・編集しています。マテリアルデザインをウェブ上で公開したての頃の課題のひとつは、かなりの数の異なる実装が求められたことだと思います。単一の情報源(SSOT)として、Angular、PolymerそしてMDL(マテリアルデザインライト)がありましたよね。最初は、AngularとPolymer、そして他の全てのウェブフレームワークそれぞれに個別のディベロッパーチームを組み、それぞれのマテリアルデザインへの実装について構築していました。その規模で継続していくことが難しいと考え、マテリアルデザインシステムでの反復を素早く進めることにして、他のコンポーネントライブラリでは単一の情報源を保つことができませんでした。JavaScriptを一度書くと、HTMLと相互作用する部分を抽出することで、DOMを直接参照することがなくなる技術の開発に取り掛かりました。そこから、そのJavaScriptをそれぞれの個別のコンポーネントライブラリに書き込みました。それは完璧な解決方法ではありませんし、今でもより早くより良くするために取り組んでいるのですが、この方法によってコンポーネントがそれぞれのフレームワークに属しているように見えるようになり、どのフレームワークに携わっているディベロッパーでも、その環境の一部としてシームレスになったと感じています。僕たちがマテリアルデザインライトに関して苦戦したことのひとつに、DOMに多くの黒魔術が行われていたということです。Tools(開発者ツール)をチェックしてみたら、そういったランダムな要素があるわけです。黒魔術はできる限り避けようとしています。自分のチームが書いたどのコードをチェックしている時はいつでも、ちょっとでもハックになるようなものや、性能を向上させるようなものは避けるようにしています。真実としてあるのは、もしマテリアルデザインシステムを進化させたいのであれば、コードの上に構築できる必要があります。コードの各層が重要なんです。いろいろな黒魔術と距離を置くようにしつつ、できる限り全てのコンポーネントライブラリで機能する単一の情報源をもつということですね。既存のフレームワークに関する作業という点では、そこにどのような関係性がありますか?というのは、例えば、Reactなどがそうですが、既に実際の世界観があるわけで、WordPressもそうですよね。そこでは、その世界で作業をしていかなければなりません。その結果として、特定のことができたりできなかったり...ということがあると思います。Androidではないフレームワークを維持するなどというのは、単一のというか、ウェブのように異なるコード間の関係性が重要になると思います。扱うのが大変であり、とても面白いことでもあります。基本的にディベロッパーが今まで使用していたものを優先するようにしています。Reactは最高の例ですね。Reactには元々、膨大な量のコードベースがあり、それらはとんでもなく人気があります。そこで、私たちはそれをまずは優先しました。ReactライブラリをReact用として作ったんです。そこからAngularやPolymerといった使用を開始したい他のライブラリもあります。その場合でも、まずはディベロッパーがそれまで使っているか、いないかに関わらず、そこで使われているベースを優先するようにしています。それら全てを機能させるという点で言うと「ひとつのフレームワークがあるやり方で進めたい」という一方で「別のフレームワークが別のやり方が良い」ということも時にはあります。常に妥協することが求められています。Polymerチームのディベロッパーと一緒に仕事をしたり、Reactのコミュニティと話をしたり。その中で、問題を解決するための正しい方法を探ろうとしているんです。そこで正しい妥協点に辿りついて、落ち着くというような感じです。ブラウザについても同じことです。初めにChromeでの開発から始めることが多いです。いうのも、それがベストで良く機能するとわかっているので。SafariやFirefox、Edgeもサポートしなければなりません。Explorerは一番最後にテストすることが多いんですが...。私たちとしては、IEでも機能するようにしたいと考えていますが、緩やかに手を引いているような状況であるのは確かです。それが注意深くかつ緩やかなやり方で行っている限りは、問題ないだろうと思います。それはプラットフォームにおいても同じことです。どのプラットフォームでも完璧に機能している状態ではありませんが、そういう状況下で緩やかにそのコンポーネントから距離を置いておけば、全体として機能するということです。mustard(求める基準を満たす)」という表現を使っていると思います。基本的に機能させなければならない基準ラインのようなものがあるということです。それが機能していなかったり、その技術に対応していない場合、僕たちがデザインしているエクスペリエンスに到達しないということになりますよね。私たちもその概念を使う必要がある場面がありました。マテリアルデザインのシェイプに新しいものを加えた時です。ウェブプラットフォームでは、どの技術を使っていて、どのウェブプラットフォーム、ブラウザにおいても、丸い角はとても簡単です。隅切りの角は不可、現状の技術では、とにかく不可ということです。そこで、マテリアルデザインチームに対して、「聞いて。2018年の今、CSSのスペックをアップデートすることはできるし、ここから3年先、私たちのプロダクトの次世代版ではこの機能を搭載することになるだろうけど、それを今実装することはできない」と話しました。そんな感じで、いくつかの機能については線引きする必要があると考えています。コンテンツを煩雑化せずに、かつ、誰も使うことができないようなハックのようなものにならないように、機能を実装することはできないのです。SVGやそこに加えるシャドウ、それらのSVGのスクロールパフォーマンスは、ブラウザやコンポーネントの状況といったもの全てを転送させることで、あっという間に非常に混乱したものになってしまいます。