音声書き起こし
1. オープニング
@potato4d
こんにちは、UITのpotato4dです。ユーザーインターフェースとテクノロジーを愛する開発者のためのポッドキャスト「UIT INSIDE」、今回もやっていきたいと思います。今回ですけど、早速なんですけど、ちょっとお知らせがありまして、玉田さんの方からお願いしてもよろしいでしょうか?
2. 玉田さん卒業のお知らせ
@spring_raining
はい。私はですね、今回の収録を最後にですね、UIT INSIDEを卒業することといたしました。本当にエピソード何回だろう、100いってるかもしれない。8回くらいからよく出させてもらってるんで。
@potato4d
8回くらいからというと、すごいですね。
@spring_raining
長い間収録してきたのですごい感慨深いです。期間も7年ですよね。めちゃくちゃ長い間、本当にいろいろといろんな話ができて本当に楽しかったです。
@potato4d
ということで玉田さんの卒業ということで、今回はですね、長らくお聞きくださっている方も多いかなとは思いますので、せっかくなので卒業前にいろんな話を振り返っていければなと思っております。特にですね、玉田さんはTech-Verseなど他のチャンネルでの発表でもたびたび取り上げられている通り、かなり
@potato4d
デザイン領域に関わることが多い開発者としての側面が多かったかなと思いますので、ちょっとそのあたりについて話を深掘りしたいなと思っております。よろしくお願いします。
@spring_raining
よろしくお願いします。
@potato4d
早速ですけど、なんかあれですかね、エンジニアとして関わっているデザイン系の案件とか、なんかどういうのがあったかみたいな話からしていきますか。
3. 社内アイコン管理システム「Laicon」
@spring_raining
そうですね。デザインが関連する業務、結構なんかいろいろな意味合いでデザインってありそうですけど、その中で言うと3つあるかなと思っていて。一つ目が、話した気はするんですけど、Laiconというプロジェクトを
@spring_raining
以前開発しておりまして。これはですね、社内で使用しているアイコンをフロントエンドやその他の場所で使いやすくするために、様々な形式で提供するためのシステムというのを開発していました。これをデザインと言えるのか
@spring_raining
ちょっと微妙なんですけど、アイコンセットなんでデザインに関連することなのかなと思います。これ開発を始めたのがもう本当に入社してすぐで、当時はですね、Font Awesomeというものがすごいデファクトまではいかないんですけど、すごい
@spring_raining
使われていたので、そのLaicon自体もFont AwesomeのAPIとか使い心地をベースに開発をしていきましたという経緯で作ってきました。いろいろやったんですけれども、
@spring_raining
アイコンのデザイン自体は私は着手してなくて、それを管理するためのツールみたいな意味合いで関わっていて。例えばアイコンをnpmパッケージとして利用できるようにするみたいなパイプラインの構築であったり、あと面白いのはアイコンは
@spring_raining
デザイナーの方が作るんですけれども、それに対して開発者の観点でアイコンのレビューをしたり、あとデザイン面でこういったところをこうした方が良いというのをレビューするためのシステムみたいなものを作ったりしていました。これはすごい使っていたので、
@spring_raining
やがてFigmaが普及してきて、レビューみたいなものをFigma上でできるようになりましたので、そういったものを考えて、後々Figma APIと連携するシステムに作り変えたりみたいな方向を転換したりしていました。
@spring_raining
Laicon自体は2年前ぐらいに手を離れたんですけども、はい、すごく最初の業務としては思い入れが深いものでしたね。
@potato4d
今はもうSVGベースに、ほとんどSVGとか画像ベースとかになってるかなと思いますけど、当時はいわゆるアイコンフォントみたいなのがかなり人気な時期でしたよね。
@spring_raining
そうですね、アイコンフォントありましたね。そうなんですよ。今ももちろん使われているんですけれども、SVGからフォントデータに変換するみたいなものも。Font Awesomeを使う側としてはすごく使われていたと思うんですけれども、いざアイコンフォントを作るってなった時に
@spring_raining
どういう問題に当たるかみたいなのは、実際に作らないとわからなかったことなので、すごい面白かったです。
@potato4d
この頃から結構フォントに関わっていたんですね。
@spring_raining
そうですね。
4. LINE Seed JP と Google Fonts
@potato4d
フォントで言うとあれですかね、LINE Seedの話もやっぱりデザイン関連で言うと大きいですかね。
@spring_raining
そうですね、それも前回ではないですか、前回、前々回、187ですかね、収録した通り、LINE Seed JPというコーポレートフォントをGoogle Fontsに登録するという作業の、私は基本的にその開発面というのを
@spring_raining
やってまして。見えるところではGitHub.comにフォントをOSSとして公開したり、あとはGoogle Fontsに登録するためにフォントデータが守るべきルールみたいなものがあるので、そういったものを適用させるために
@spring_raining
コード、実装面もありますし、
あとは結構そのアプリケーションの開発とはちょっと違うところとかやっていたりしていました。
@potato4d
確かにあれですね、結構意外と話聞いてると地続きなところも多いというか、確かに本業してる感じがしますね。はい、ぜひLINE Seedの話はですね、かなりプロジェクトオーナー含めてエピソード187でたっぷりと話されているんで、そちらも合わせて聞いてもらえればと思います。
@spring_raining
確かに。
5. デザインシステム「toly」の開発
@spring_raining
そうですね、もう一つ最近すごく大きい仕事としては、デザインシステムの開発をやっています。はい、tolyなんですけれども、以前というか、デザインシステムが新しく必要になったんですけれども、
@spring_raining
そこで、もともと私たちのプロダクトでアプリケーションを開発していたときに作っていたコンポーネント集みたいなものがあるんですけれども、それをデザインシステムという建て付けとして実装したという感じで。これもデザインシステムなので、デザインに
@spring_raining
関連する業務なのかなと思います。今これもすごいUIT INSIDEでは話してなかったかもしれないんですけど、すごく技術的に面白いところがあって。これもそうですね3年ぐらいは、はい、すごく取り組んでいて楽しかった仕事になります。
@potato4d
ぜひその技術的な部分もこのタイミングで聞かせていただきたいなと思ってます。
@spring_raining
わかりました。
6. 開発者だからこそできるデザインへの関わり
@potato4d
ちょっと技術的なところに深掘りする前に、今回のエピソードとして聞いてみたいなと思ったのが、エンジニアとしてデザインに関する業務に深く関わる機会ってそんなに多くの会社だと多くないのかなとは思っていて。やっぱり交わるところはあれど、かなり仕事として違う部分も多いのかなとは思うんで、
@potato4d
ここまで密接に連携して仕事することが多いっていうのも珍しいのかなと思ってるんで、そこの中で自分の中で得られたものであったりだとか、意識したこととかがあったら先にそこから聞きたいなとか思ってるんですけど、なんかあったりしますかね。
@spring_raining
そうですね。私自身はデザインに興味はあるけれどもデザイナーではないので、基本的には例えばLaiconの時も話したんですけど、実際にこの手を動かしてデザインを作るということに関わるということは基本的に
@spring_raining
なくて。そうですね、まあ強いて言えばUIT INSIDEのWebサイトとかですかね、それぐらいだったんで。あくまでエンジニア、開発者としてデザインに関わるっていうことが多かったです。一方で結構開発者だからこそできるデザインに関われるところがあって、
@spring_raining
例えばLaiconであれば、開発者が使用するためにnpmパッケージとして提供するみたいなところは分かってないとなかなか難しいところではありますし、あとはデザインシステムの場合だと
@spring_raining
Figmaのデザインをコンポーネントとして解釈する際にいろいろと考えることがあるかなと思っていて。一番大きいのは拡張性ですね。例えばデザイン上ではこうなっているけれども、これをコンポーネントとして使う
@spring_raining
ことになった際に、ここの部分がすごく変えられるだろうなみたいなものを予想してコンポーネントを作っていくっていうところがすごく開発者らしいところかなとは思っていたので、そういったところは特にデザインシステムの開発をする上で
@spring_raining
身についたというか、はい、気づかされたところかなと思います。
@potato4d
直接的にデザインを作るわけじゃなくても、やっぱり実開発で特にデザインシステムとかってなると、使われ方によって見た目上の幅は出てくるはずなんで、そこをうまく吸収するっていうふうなところで、デザイン観点を意識するエンジニアとしての能力が問われるというか、やりがいが生まれるところだったって感じですかね。
@spring_raining
そうですね。本当にFigma上のコンポーネントをとっても、デザイナーの意図みたいなものをやっぱり汲み取りたいなとは思って、それをAPIとして解釈、再解釈するみたいなのはやっててすごく面白かったところですね。
@potato4d
確かに。Figmaに関しては最近はどのデザインツールでも画面遷移みたいなのをちょっと表現したりみたいな機能がありますけど、やっぱりどこまで行っても静止画の延長ではあるんで、そこに幅を持たせるみたいなのは補完する能力というか頭の中でみたいなところが問われるので
@potato4d
なかなかやりがいはありそうですし。
@spring_raining
そうですね。本当にさっきの静止画の例も特に分かりやすい例ですごい、トランジションとかは本当にそこに関してだけはデザイナーだったかもしれないですね。動きをWebで表現するみたいなところはやっぱりクリエイティビティが
@potato4d
面白いですね。
@spring_raining
発揮される。
@potato4d
ですし、予想外のデータが入ってくる場合にでも綺麗に表示するみたいなところって、ある程度開発者っぽい嗅覚も必要なところですよね。
@spring_raining
そうですよね。
@potato4d
そういうFigmaファイルの外から出て実プロダクトに導入されるまでの間をうまくデザイナーとコミュニケーションを取りながら補完していくみたいなのは面白いところではありますよね。
@spring_raining
やっぱり面白かったです。
7. デザインをやりたい？感覚の言語化の難しさ
@potato4d
とはいえ、なんか自分としてもデザインもやりたいんだよなみたいなのあったりしたんですか? やってる中で。
@spring_raining
確かにそうですね。正直なところこのUIT INSIDEのWebサイトのFigmaを作っているときめちゃくちゃ楽しかったんで、純粋にやりたいですよね。結構そう、やりたいとなったときにどうするかっていうのは結構、そうですよね。
@spring_raining
デザイナーの仕事を見てすごく全然簡単ではないなっていうところは思ったので、気軽にやりますって言えるようなものでもないなっていうのはありますよね。でもやりたいですね。
@potato4d
そうですよね。
@potato4d
やりたいが、プロダクションクオリティを満たしながら継続的にやるには、やっぱり専門家じゃないと難しい部分があるよな、より協力すればするほど感じるっていうところですね。
@spring_raining
そうですね。
@spring_raining
難しさの一つとして、感覚的なところが求められるっていうのはすごく感じていて。例えばデザイナーがこのコンポーネントを作っていいなと自分が思ったとしても、それがなぜいいのかみたいなのが言葉で言い
@spring_raining
表せないなっていう気は持っていて。このUIT INSIDEのサイトも自分がいいなとは思って作ってるんですけど、それをちゃんと説得力、なぜここをこうしてこうなったのが結果いいですみたいなのを伝えられ
@spring_raining
ないといけないなとは思っていて。そこが経験なんですかね、必要なところなのかなとは思った。
@potato4d
確かに、こう、それっぽいからの先に、そのそれっぽいの先の理由をつけるには、経験がちゃんと必要で、っていう。また、そこも壁があるって感じ。
@spring_raining
これを身につけるためには根拠みたいなものが必要なのかなというところは難しいですし、経験だとするとそれこそ作り始めないと経験は積めないので、本当に鶏卵問題というか。難しい。
8. アクセシビリティという根拠
@spring_raining
結構デザインとは変わるんですけれども、最近デザインシステムを作る上でも一つのテーマとしてはアクセシビリティを改善しましょうみたいなところをすごく強く意識しているところなので、その観点で見ると結構
@spring_raining
アクセシビリティはWCAGであったりドキュメントがすごく整備されているじゃないですか。なので、すごくやりやすいなと感じるところはあって。例えばここのコントラスト比はこうしてます、なぜならコントラスト比をこの数値以上にする必要があります
@spring_raining
っていう根拠があるからそういう設定してますっていうのはめちゃくちゃ言いやすいところがあるので。ただそれをそうですよね、デザインとして消化するのは難しい、限界があるところだと思いますよね。
@potato4d
そうですね。
@potato4d
あれですよね。なんていうか、マイナスがないことをしっかりと説明することはできるけど、プラスであることを説明するのが難しいみたいな話ですよね。
@spring_raining
そうです。やっぱり一人で作るものではなくて、たくさんの人が関わるものを作るのであれば、ある程度はそういう説得力を持たせるところは大事かなと思うので、そのプロセスでアクセシビリティのやり方って
@spring_raining
いうのはもしかしたら参考になるかもしれないかとはちょっと思いました。
@potato4d
なかなか面白いですね。でもこうやって見てみるとなんかあれですね、こう関わる中でいろいろ自分にできることとか自分なりのこう関わり方みたいなところはあるにせよ、まだまだやっぱりこう完全にデザインに入っていくには難しい部分もある感じがしますね。
@spring_raining
そうですね、将来的にはという感じですけど。
9. Web Components・Lit・Zag.js
@potato4d
ではちょっと逆にですね、今話に上がっていた開発者としてできるところみたいなところについて深掘りしていきたいなと思うんですけど。やっぱり技術的なところとかで言うと、幅を持たせる部分というか、実際にFigma上にあるデータとは違うようなデータ形式、例えば
@potato4d
とんでもない物量のデータが入ってきたりだとか、予測しないようなものが入ってくるみたいなところを含めて調整するのも一定エンジニアとしての手腕が問われるところになってくるかなとは思うんですけど。技術的な挑戦として今回デザインシステムの話を聞かせてもらってるんで、デザインシステムでの実例で
@potato4d
いいかなと思うんですけど、こういうことやって特に面白かったとか、特にやりがいがあったみたいなのあったら聞きたいと思うんですけど、何かあったりしますか。
@spring_raining
そうですね。デザインシステムの内容でいきますと、技術的に今すごく一番変わっているところで言うと、Web Componentsを採用しているところですね。あまりそうですね、今回デザインのお話なのであまり深掘りはしないんですけども。
@spring_raining
これを開発する上での知見みたいなのは、個人的にはこの3年間ぐらいで身についたところで、本当にこれは他のデザインシステムにはないだろうなというのは面白いところかなと思います。具体的にはLitという
@spring_raining
ライブラリを使ってコンポーネントを開発してるんですけども、Litを使った上でWeb Componentsを作り、ラッパーとしてReactコンポーネントやVueコンポーネントを提供するという構成になっているんですけども。やっぱりWeb Components
@spring_raining
の独特の考え方みたいな、考え方とまでは言わないですけど、Custom Elementsの知識っていうところはなかなかReactやVueとは全然違うものだったんですけど、そこはすごく身についていて、
@spring_raining
フルスクラッチではないですけれども、かなりの部分を自前で実装するみたいなことをやっていて。Litは使っているんですけれども、例えばSSRとかのコンポーネントがあるんですけど、そういったものは使っていなくて、基本的なテンプレートやLitElementのクラスとか、
@spring_raining
そういったところは使っているんですけれども、それ以外の部分、ラッパーコンポーネントを作る分とかはかなり自前でやっているところがあったので、そういったところをかなり時間をかけて作ったところっていうところは振り返りとしてあります。
@potato4d
あれですよね、デザインシステムになるとWeb Componentsを使う理由が出てくるというか。普段の開発だとやっぱりReactであったりVueであったりみたいなその技術をそのまま使うのが多いですけど、こういう時には中間層としてWeb Componentsがかなり光りそうな感じがありますよね。
@spring_raining
そうですね。Web Componentsのコンポーネントライブラリを作って思ったのは、これだけで複雑なアプリケーション作れるけれども結構大変だろうなって正直思っているところであるんですけれども。ただある程度完結して機能がそれほど多く
@spring_raining
ないものを作るには、すごくこの数年間で全然作れるなっていうのは思ったところはあるので。多分今後もReactやVueでアプリケーション開発していくと思うんですけども、それはそれとしてWeb Componentsについて知れたのはすごくいい経験でした。
@potato4d
あれですね。
複数フレームワークとかに対応したい、複数ライブラリに対応したいみたいなモチベーションがあると、そのままDirtyに作るのはやっぱり大変だと思うんですけど、そういうところでWeb Componentsが光るというのも得られたインサイトではあったみたいな感じですよね。
@spring_raining
そうですね。あと複数ライブラリの対応という面でいくと、コンポーネントライブラリの振る舞いを実装していく必要があって、結構素の状態で実装するのは大変な部分にはなってくるんですけども、
@spring_raining
そこではZag.jsというライブラリがあるんですけども、それを使って開発をしていったりっていうところは結構特徴的ですね。Zag.js自体もReactやVue、Svelte向けのラッパーではないですけど、インテグレーションがあるんですけれども、もともと
@spring_raining
そういうインテグレーションが提供されているぐらいUIライブラリに依存しない実装になっているので、そこが今回のWeb Componentsの採用にハマったっていうところはすごくライブラリを作る上で幸運だったところで。
@spring_raining
Zag.jsが管理するステートの結果をDOMに反映させていくっていうところだけを実装すれば良くなったっていうところがあって、これによってかなり助けられているところはありますね。で、同じような考え方で言うと、ヘッドレスコンポーネント、
@spring_raining
例えばReact Ariaとかはそうだと思うんですけど、そういったものは考え方としては一緒なんですけど、Reactに依存しないという意味で言うと結構選択肢が少なくなってしまい、もっと増えてほしいんですけど、今のところはZag.jsは第一選択肢かなと思っています。
@potato4d
2年半くらい前のUIT × Bonfire Front-end Meetupでもちょっと紹介いただいてましたけど。
@spring_raining
そうですね。
@potato4d
そのまま今も実用続けられてるって感じなんですね。
@spring_raining
そうですね。それの話で言うと、確かHauntedを使ってるっていう話はあったと思うんですけど、これはやめました。で、LitとZag.jsで構築をするっていう感じですね。
あれですかね、Hauntedの話はなかったのか。
@spring_raining
でも基本的には実装はそのまま維持してます。結構話をした時点では作ってますっていう状態だったんですけども、今はかなり使われていて、React向けのフレームワークもVue向けのフレームワークも両方とも使われています。結構、ホッとしたというか
@spring_raining
ちゃんとWeb Components使えるのかっていうのは不安だったんですけれども、そこはアクセシビリティ面も含めて結構大丈夫だったという結論になっています。
10. ライブラリ開発とアプリ開発の違い
@potato4d
なんか面白いですね。デザインシステムを運用していく中で、普段触れないようなライブラリを使うことがどんどん増えていって、そのプロダクション経験みたいなのも積み上がっていくのが面白いですね。
@spring_raining
そうですね。その意味で言うと、やっぱりアプリケーションを作るのと、ライブラリとかフレームワークまでは言い過ぎかもしれないですけど、ライブラリを作るのはだいぶ違いますよね。すごく求められるところが違うっていうところが気づかされてます。
@spring_raining
結構そうですよね。両方やっている上ですごく良かったのは、アプリケーションを作っている側の気持ちに立てるみたいなのは、はい、すごく感じてますね。で、結構Webフロントエンドだと両方やってるっていうケースが多いので、あんまり
@spring_raining
利点として感じられないのかなとは思うんですけど、結構ライブラリを作る側と使う側の断絶みたいなのがあると、なかなか失敗しやすいかなとは個人的には感じているので、
@spring_raining
デザインシステムの開発をする上でも
@spring_raining
開発者の目線とか問題みたいなものをいかに汲み上げていくかっていうのは気をつけていたところです。
@potato4d
面白いですね。なかなかこうどっちもやるからこそ見えてくる景色みたいなのが。
@spring_raining
そうですね。
@potato4d
いいですね。
@spring_raining
ちょっと話が脱線してしまいましたが、でもある意味デザインかもしれないですね。開発者のライブラリを使う、使われ方のデザインみたいなのは、UIというよりはUXというか、そういったところの一部と言えなくもない。
@potato4d
そうですね。使う側で言うとDXだとかみたいなことよく言いますけど、ライブラリ開発者の観点に立つと、DXこそがUXみたいな感じになりますもんね。エンドユーザーが、ライブラリ開発者にとってのエンドユーザーは開発者なので、っていう感じがしますね。
@spring_raining
そうですそうです。なのであまりエンドユーザーとライブラリのユーザーみたいなのは差は感じてないですよね。
@potato4d
そう考えるとあれ、デザインシステムに関わることによってデザイン領域との距離も縮まるし、いわゆるプロダクト開発のサイクルみたいなのを別軸で持つこともできるみたいなのもかなり面白いポイントではありそうですね。
@spring_raining
話としては結構繰り返しになっちゃうかもしれないですけど、やっぱり開発者の目線でこういったところは拡張性を持たせてほしいみたいなものは、感覚としてすごく気づかされるところなので。
11. CSS Variable と Grid で作る拡張性
@spring_raining
それで言うとそうですね、結構このコンポーネントの技術的な観点のところでもう一つ特徴を言うと、拡張性は欲しいっていうのは利用者の目線で求められるところかなと思うので、そこは結構
@spring_raining
そのCSSのレイヤーで頑張ったところかなとは思います。
@potato4d
これはサービス側のトンマナに合わせたいとかそういう感じですか。
@spring_raining
そうですね、それもあります。結構やっぱりコンポーネントっていろんな要件で粒度が決まっていて、例えばテキスト入力のコンポーネントであれば、理想的には入力する領域だけを一つの
@spring_raining
コンポーネントとして作りたいけれども、ただアクセシビリティ的には入力フォームに対してラベルをつけないといけないみたいな制約が出てくるので、そうなってくるとテキスト入力とラベル、それに紐づくラベルを一つのコンポーネントとして
@potato4d
ああ。
@spring_raining
扱うかみたいな、そういう結構アクセシビリティ的な要件でコンポーネントの粒度を決められるみたいなケースが多かったんですね。そうなってくるとコンポーネントを使う側は、ただラベルを自由に置きたいじゃないですか。
@potato4d
そうですね。
@spring_raining
といった要件が出てくるので、やっぱり必ずしもコンポーネントの粒度をその開発者の自由度に合わせた形にできないっていうケースが出てきた時に、拡張性みたいなものを求められる。コンポーネントとしては一つなんだけれども、
@spring_raining
ラベルをどこにでも置けるようにするみたいなところから拡張性みたいなニーズが出てくるのかなと
@spring_raining
感じていて、そこが、そうですね、CSSの設計のところに考えるところとして増えてくるっていう。
@potato4d
アプリケーションのデザインという風なところと、アクセシブルである部分という風なところであったりだとか、もろもろのちゃんと使えるコンポーネントとしての要件を両立させるのがなかなか難しい部分ではあるという感じなんですね。
@spring_raining
そうですね。
@spring_raining
今回の場合だとWeb Componentsを使ってるっていう制約って言っちゃ悪いんですけど、そういうところもあるので、ある程度コンポーネントとしてはReactみたいに本当に自由度の高いコンポーネントっていうのは若干難しいところがあったっていうところで。
@spring_raining
具体的にCSSの設計どうしてたかというと、基本的には外部からCSS Variableを渡してレイアウトやデザインを規定するみたいな設計になっています。
@spring_raining
結構そこがReactのコンポーネントとかと違うところかなとは思うんですけども。とはいえ結構本当に一番大きいのは、CSS Grid Layoutの導入によってそれぞれの領域というか要素に対してこの要素の名前をつけるとか、そういった
@spring_raining
ところがそのGrid Layoutですごいやりやすくなったので、それをCSS Variableで外部から規定するっていうのがすごくやりやすくなりましたし、あとはSubgridの機能が出てきたことによってそれがさらにやりやすくなり、
@spring_raining
見た目上が一つのコンポーネントなんですけども、そういったことを意識させないようなレイアウトっていうのもすごくやりやすくなったので、これは本当にCSSの発展のおかげかなと思ってます。
@potato4d
なるほど。規定の配置みたいなのはデフォルトではあるが、そこをアプリケーション側の都合に応じてGridのテンプレートを変えるだけで自由な配置ができる感じに作ってあるんですね。
@spring_raining
そうですそうです。なのでカスタマイズの要件はどちらかというと色を変えたりとかそういったことよりは、ラベルをここに配置したりとかそういったレイアウト面でのカスタマイズみたいなものが今のところはメインにはなっているかもしれないです。
@spring_raining
もちろん例えばダークモードに対応させたいみたいな場合も使えますし、そういったところでもやっぱり開発者の目線ではここはこうなっていてほしいみたいなものはできるだけ拾い上げたいなと意識していました。
@potato4d
今話を聞いてて、最近のフレームワークとかって色々CSSカスタマイズできるものが多いかなとは思うんですけど、そうなってる背景の一端を今知れた気がします。作ってる側はそれを両立するためにやってたんですね。
@spring_raining
最近だと本当に特にTailwindはそうなんですけれども、Tailwind自体はすごくいいんですけれども、それをやっていると最近のCSSの発展みたいなものにはちょっと気づかされないみたいなところは感じているところかもしれません。
@spring_raining
特にGridは苦手なんで、Tailwindは。
やっぱりなかなかSubgridってどこで使うんだみたいなのは、このコンポーネントを使ってる側はわからないですけれども、作ってる側からするとこういうところでSubgridを
@spring_raining
使うんだみたいなのはすごく理解できたっていうところですね。
12. デザインシステムと生成 AI
@potato4d
最近はTailwindとかもすごい圧倒的な人気になってきましたし、なんならAgentic Codingとかで流行ってるので、全然マークアップ見てないよみたいなことも増えてきたかなと思いますけど、やっぱ触ることによって見えるものもいっぱいありますね。
@spring_raining
そうですよね。それで言うと全部生成されてしまうことによってデザインシステムって今後どうすればいいんだろうみたいなのは結構難しいところなんですけど、
@spring_raining
とはいえ、私もTailwindをすごく使っているし結構好きなんですけど、苦手なところもあるかなとは思っている。なんかあまり結論が出てこなさそう。
@potato4d
なんか結論みたいな話になっちゃいますけど、なんかある意味今回のデザインシステムの開発みたいなところを通じて、Agentic Codingみたいなのが流行ってますけど、これこそがガードレールみたいな感じになるじゃないですか。作ったデザインシステム自体が。なんでなんか需要は消えることがないというか、
@potato4d
むしろ効率的にハイクオリティなものを生成するためには、オーダーメイドで作られているデザインシステムがあって、そこでカスタマイズの余地があるみたいなのはめっちゃポジティブに働きそうな感じもしますよね。
@spring_raining
ガードレールの面で言うと、CSS Variableを通してレイアウトを規定するっていうのが、全然結果としてそうなったっていうだけなんですけども、生成AIとの相性も結構良いなという風に思っている
@spring_raining
ところではあって。結構CSS Variableを設定することによって開発者の意思みたいなものを伝えられる所はすごく大きいです。例えばGridの領域の名前を付けられますけれども、その名前から
@spring_raining
そういった意図を読み取ったりとか。
@potato4d
そうですね。
@spring_raining
そうですね。そういったところはもちろんAIの発展というか機能の向上によって進化するところはあるかもしれないですけども、とはいえその意思を伝えられることによってデメリットみたいなのが全然ないと思うので。
@potato4d
そうですね。自動で読み取ってくれるとしてもHuman-Readableな名前で書いてる方がコンテキストの消費も少ないしみたいな話もあるでしょうし。
@spring_raining
そうですそうです。なのでそういったオプションであったりpropsとか、あとCSS Variableの名前、命名とかそういったところを通じて、開発者にもそうですし、AIに対してもその意思を伝えるみたいなところは、話を戻すとそれこそUX
@spring_raining
みたいな。
@potato4d
使いやすさにつながっていく。
@spring_raining
つながっていくみたいなのが
@potato4d
ありますね。
@spring_raining
ありますね。うまくまとまった気がします。
13. クロージング
@potato4d
ラストエピソードでいろいろ面白い話聞けてよかったです。それこそ本当にせっかくなんで、UIT INSIDEをお聴きいただいている皆様に最後一言あったら
@potato4d
お願いしたいんですけど、なんかありますか。
@spring_raining
本当に長い間聞いていただきありがとうございます。全然UIT INSIDE自体はまだまだ続きますが、そうですね、私はこれからは一視聴者として聞いていきたいなと思います。でもゲストとして呼んでいただく分にはまたよろしくお願いします。
@spring_raining
ということと、また皆さんUIT INSIDEについて意見があったりとか、あと話したいみたいなのを私たちはすごく楽しみにしていますので。そうですね、もしリアルとかまた別の場で会うことがありましたら、
@spring_raining
UIT INSIDEについて話や意見、感想などを聞かせてもらったり、もし出たいのであれば私にでも良いのでまた話をいただければなと思います。本当にありがとうございました。
@potato4d
本日で玉田さんの出演は最後になりますが、カンファレンス会場とかで多分会うこともあるかなと思いますので、聞いてくださっている方はお気軽にお声掛けとかしていただければと思います。
@potato4d
というわけで、今回は玉田さんの卒業エピソードとして、デザイン×エンジニア領域のこれまでの仕事みたいなところについて話していきました。LINEヤフーのフロントエンド組織ではこのようなフロントエンドに関する議論などを日々行っております。過去には社内勉強会などのコンテンツを外部に発信していた例もたくさんありますので
@potato4d
これからも様々な情報を発信していければと思っております。また、このポッドキャストに関するご意見ご感想につきましては、ハッシュタグ「#UIT_INSIDE」にてつぶやいていただけますとスタッフのほうで拾わせていただきますので、ぜひぜひお気軽に投稿いただければと思います。
@potato4d
では、玉田さんと一緒に話していきました。ありがとうございました。
@spring_raining
ありがとうございました。
