2023/04/07 に公開1448 views
@odan3240 が @AlanGDavalos, @ibulog_, @vwxyutarooo とともに、 UIT Meetup について振り返りつつ語りました。
音声書き起こし
1. オープニング
@odan3240
こんにちは、 uitのオダンです。今回も、uitインサイドを始めたいと思います。uitインサイドは、ユーザーインターフェースと、テクノロジーを愛する開発者のためのポットキャストです。 さて、今回は3月15日に開催されたuitミートタップ、ボリューム19デザインシステムのリアルのアフターショーをお送りします。uitmータップのアーカイブは、ショーノートにurlを貼てお
@odan3240
きますので、このカクターショーと合わせて、お楽しみいただければなと思います。 というわけで、えー、本日のuitインサイドのゲストは、デザインシステムのリアルの 各セッションで登壇していただいた。アランさん、ゆプロクさん、ゆ、トラさんの3名をお呼びしております。皆様、本日はよろしくお願いしますよろし、
@ibulog_
よろしくお願いしま
@vwxyutarooo
ますよろしくお願いします。
2. セッション1振り返り
@odan3240
はい、では、まず最初にえっとい、uitmタップをまだご覧に なられてないし、視聴者の方も多分いると思うので、それぞれ自己紹介を お願いします。所属と名前と、あと、登談の内容について軽く喋ってもらえると、大変助かります。じゃあ、えー、登談の順番で、アランさんからよろしくお願いします。
@AlanGDavalos
はい、えーっと、マーラインのフロン、天ド開発センターのダブロサランです。 普段はあのま来inのデザインシステムの適度やってることもあってま。今回ま、実際にまだえーっと、デザインシステム をま導入してない、もしくはま作れてないプロジェクトと言いますか。ま、会社向けにどういった選択肢があってま、どれが自分のチームの規模に合うのか、というセッションを
@AlanGDavalos
あのやってみました。あの、内容は結構ま充実してるので、まあぜひ聞いてください、よろしくお願いします、
@odan3240
ありがとうございますじゃあ、次えーグブログ3をお願いします。
@ibulog_
はい、えーっと、マルヤマイブキで、イブロブと申します。えー、smarthrで、uxライターをしております。 え、登談内容はですね、開発者が使いやすいデザインシステムっていうところで、 えっとーまあ、あのー、開発者がえー。実際のプロダクト開発の現場で、
@ibulog_
どういう風に使っていただけるような、デザインシステムを作っていくか、っていうところのメインでお話をしております。あの、私自身、uxライターということで、フロントエドの技術にはそんなに詳しい方ではありませんので。この ホットキャストでも、なんか黙ってたらあ、わかってないんだなって。あのスルーしておいていただけると助かりますよろしくお願いします
@odan3240
よろしくお願いします。最後にゆうたろうさんお願いします。
@vwxyutarooo
はい、 えーとー。メルカリという会社で、エンジニアリングマネージャーをしているユウタロウと言います。で、普段はえーっと、ウェブアーキティクトと、デザインシステムという2つのチームの マネージャーとして見ているんですが、今回自分の方では、えーとー。特にデザインシステムのウェブ
@vwxyutarooo
メルカリデザインシステムのウェブで、えっと、採用した。えっと、ウェブコンポーネンスという技術で、利用者に技術的な選択肢をおー持たせようということで、そういう技じゅ決定をえー2年ほど前にした。 ですが、実際のえー、使ってみてとか運用してみて、自分たちが困ったり したことだったりとか、プロダクトのイクラメントに合わなかったりとかっていうような背景から技術スタックに移行することに決めたんですけど、自分の話の中では、
@vwxyutarooo
えっと、じゃあ実際に何が起こったのかっていうこと、何が問題だったのかで、実際に移行を始めてみて、どうだったのかっていう話をさせていただきました。はい、よろしくお願いします
@odan3240
よろしくお願いします。では、 まず、最初に最初のセッションのデザインシステムを作る意味あるのに、ついて振り返っていきたいと思います。登談のアンケートでは、発表のフリートークの時に、社内政治の話になったと思うんですけど、 それに共感するコメントがついてましたね。
@AlanGDavalos
まあ、なりますね、やはり、まああの動画でも話していたと思うんですけど、やはりこういった範囲が大きいプロジェクトほどま、色々なステイクホルダーがあるので、 満足してもらわない人が増える分、どれもに対して、なんか全てのあの要求を満たすことは、 そもそも不可能っていうところもあるので、まあ、それをどうバランス取るのかですよね。結局は、
@odan3240
まやはり大きい会社のデザインシステムだと、やっぱそういうところをつけられないという話ですね。
@AlanGDavalos
そうですね、まあ、大きい会社じゃなくても、多分あの発生する時はもう発生してしまうんですよね。
@vwxyutarooo
あそこはやっぱりブロギさんがうちは社内せいじゃありませんよってたのがそう
@odan3240
発言でしたよ。
@ibulog_
いやいやいや、言っちゃって、ちょっとあのあと後悔したんですけど、
@odan3240
ありました。smarthr社内で、そのuitミートアップの登談後、なんか 反響とかってあったりはしましたか。
@ibulog_
あー、そうですね、まあ、それで言うと、まずあのー、社内政治のことについては言っちゃったっていうのがまず反響として。
@ibulog_
そうですね。他だと、組織の大きさの違いみたいなのは、やっぱりあるよねっていうのは、社内でもありましたね。そのsmarthrよりかは、やはりこうlineさんであったり、メルカリさんの方が 組織っていうのはずっと大きいので、こうデザインシステムに求められる役割みたいなものも結構違うんだねっていうのは、反響としてありましたね。
@AlanGDavalos
そうですね、ま、自分の登壇でもまだからこそ、結構なんか組織の規模によってどういうものがま合うのかが結構変わってくるので、うん、 こういう理由がま、その理由の1つなんですよね。結局
@vwxyutarooo
なんか社内政治で、なんか1番大事だなって思ってるのがま。もちろん、みんな社内政治は嫌いだとは思うんですけど、 ま、その中でデザインシステムみたいなベネフィットをがあるものをこうみんなに納得してもらうのを、スムーズにするための社内政治とかっていうのは、えっと、大事だと思うんで すけど、ま、そもそも、えっと、目的とかベネフィットがないのに、権力を得るためだけの社内政ージは悪ですよね。って話をいわゆみわれてみたプのみんなでしてて、
@vwxyutarooo
嫌なものではあるんですけど、向き合うべきものと、本来必要でないものっていうのをしっかり分けて、社内政ージを考えていけるといいなと思いました。
@odan3240
まさにその通りです。デザインシステムに関わらず、なんか任意の技術選定とか、意思決定はやっぱ その導入する組織とか、チームのゲボ缶であったりとか、文化であったり、みたいなところに、やっぱ大きく依存するんだなと 思ってて、やっぱチタで流行ってるから。とりあえずデザインシステムを導入しました。ではなくて、やっぱそのアランさんの発表にあったように、チームの規模とかま達成ししたい目的に応じて、
@odan3240
方法を柔軟に選択するのが大事なんだなと発表聞いてて思いましたね。
@AlanGDavalos
そうですね、まう、もちろんなんかチームでやることま仕事なので、ま、そもそもなんか自分で全てを決められるわけではないし、みんなの なんだろう。都合ある程度考えないといけないんですよね。で、それはデザインシステムとなると、ま、結構もう会社希望って言いますか。なんか、 もうほとんど全てを巻き込むようなものだになると、ま、余計なんか身長
@AlanGDavalos
に行けないといけない。あの時はあるので、ま、それもあって、結構時間かかったりしますけど、ま、最終的になんかちゃんと時間をかけてやると、ま、あとあとま楽できますって言いますか。なんか、ちゃんとそのベネフィットをあのもらえるので。 そうですね、さっきも言いましたけど、要はバランスですね。最終的には、便利な単語、
@vwxyutarooo
アランさんの発表の中でいいなと思ったのが、ま、そもそも、インハウスのデザインシステムと、オープンソースのuiライブラリーみたいなものに比較した時に、じゃあ、インハウスのデザインシステムを多大なコストをかけてやる意味があるのかどうか 話に含まれていたと思ってて、うん、うん、ちょうど自分の組織でも、やっぱりうん。社内ツール向けにもデザインシステム使いたいんだけど。 とかっていう話がよく上がってくるんですけど、じゃあ、社内向けにインハウスのデザインシステムを開発する意味が本当にあるのかどうかだったりとかっていうのは、えっと、アランさんの発表みたく、基本的な何のためにやるのかっていうところ、
@vwxyutarooo
立ち返っていくと、そこは実はオープンソースにuiライバいいんじゃない。っていうものもあったり、逆にtocでちゃんとえっと、ブランディングだったりとか、デザイン一貫性みたいものをグループ会社で統一しています。 行きますっていう時に、えーっと、インハウスのデザインシステムが、えっと、すごいこ効力を発揮したりとかっていうのを、ただ、デザインシステムがいいから 使うっていうんじゃなくて、そこのなんで使うのかっていうのも、そこの選択がちゃんとできるっていうのが発表の中でいいなと思いました。
@AlanGDavalos
そうですね、なんか、もうユウタロさんがすごくいいままとめをしてくれたと思うんですよね、 要はそこなんですよね、結構ま、例えば、インハウスのツールとかの開発では、ま、そもそも、なんかデザインのなんか、リソースとかをかけられないというケースが結構多いじゃないかなと思うので、なんかもう それこそなんか時々なんかバッケンドエンジニアがなんかフロンテンドもやってるとかっていうケースも多分
@AlanGDavalos
多々あると思うので、そういったものに関しては、なんかそんなかデザインにこだわった。デザインシステムよりも普通になんかuiライルなんか使いやすいuiライラリーをま選択した方が 何か届くですしかつ、まあ、本当になんか会社と言いますか。プロダクトの明治がま、大事な時にこそ、そういうことをま強く 認識させる。かつ守ることを簡単にするために、デサインシステムをやることに。まあ、意味があるのかなって、あの思いますね。
@vwxyutarooo
もう1個置くアランさんの話の中で、 すごい感激した話があって、デザイナーがものすごい強い。ちゃんと発言権を持ってる組織っていうのがすごいなと思っててま。エピソードの中で、例えば、デザインのプランニングだけで、1年かかりましたよ。みたいなエピソードがあった けど、別に1年かけたらいいものができるとか、そういう話ではないんですけど、
@vwxyutarooo
ただ、組織として、そこにちゃんと1年準備のコミットができるだったりとか、それはデザイナーが必要です。って言ったら、それがちゃんと社内でこう時間が与えられるみたいな。そういう文化とか、環境とか、 そのパワーバランスみたいのはなかなかないんじゃないかな。すごいなって思いました。
@AlanGDavalos
そうですね、なかなか待っていられないっていう。 まあ、ケースがあると思うので、それを当時、それをやるまリソースも。まあ、その時間も まあったっていうところもあって、最終的には結構マイノドサンシステムででよく言うファンデーション。あの、結構なんかタイプーラィやらー。カラーやら、スペイシングやら。なんか、そういった部分で
@AlanGDavalos
ましっかりとしたルールができていることで、あととのコンポーネントのデザインの時に、 結構なんか意思決定が結構早かったんですよね。なんか、デザイン側でのなので、まあ、そういう基礎をしっかり固めることに時間をかけた分、 ま、あとまデザイン側も結構楽でしたので、そういうところは結構強調していた年単位の話はつ
@AlanGDavalos
こに繋がってて、なんかちゃんとするには、本当にそれぐらいの時間をかけないと、まあ、あとあとこれをちょっとこうすればよかったなってなってしまうことも多発してしまいますね。
@ibulog_
ちょっと話戻って、アランさんにお聞きしたいことあるんですけど、はいか、組織のサイズによってこう取るべきデザインシステムのあり方も異なるっていうお話が あったと思うんですけど、ま、組織の大きさもこうどんどん変わっていって、基本的には大きくなっていく方向になっていくと思うんですけど、そうなると、当初選択したデザインシステムのあり方って、ものすごい窮屈になったりとか、そういうことって起こりうるのかなと思って、 そういう場合ってま。これもようもバランスの話になってしまうかもしれないんですけど、なんかもうちょっと先を見越して、ちょっと今の自分たちにはこう。
@ibulog_
あのー、リッチすぎるデザインシステムかな。って思うところにチャレンジしていくべきなのか、それともこう 組織の大きさが変わっていくのに合わせてこう。その都度、デザインシステムのあり方を変えていくのがいいのか、みたいなのってどう思われてますか。っていうのをお聞きしたいです。
@AlanGDavalos
そうですね、なんか、結構デザインシステムの移行とかって、多分リソースが半端なくかかると思うんですよね。で、 だまだからこそ、あの先ほどイブログさんが言ってた通り、なんかま未来を見越して、ある程度次のステップに行くようなものを想定した上で、 あのやることが正しいのかもしれないけど、ただ、なんかすごく未来まで行ってしまうと、ま、逆に今苦しむだけで、なんか
@AlanGDavalos
その得をするのも、もう何年ぐらい前、あの後の話になってしまうので、あのだから、その結構そのテーブルに結構丸とか。あのま、ちょっと ワーニングサインのものを入れたと思うんですけど、まあ、要は大体丸につけてるところはま、ある程度組織が大きくなっててもま一旦大丈夫なんだけど、ただ、なんか ちょっと注意のマークつけてるところは、組織が少しだけ大きくなったとしたら、もう完全にアウトになってしまいそうなやつなので、ある程度なんかそれを踏まえた上でのちょ
@AlanGDavalos
表示になっているので、基本的にはおそらくあの結構カスタマイズ性のある あのライブリーの方がどの規模にもあの結構一致してるので、その中でまちょっと自分の力量より、ちょっとだけ上を選択するぐらいがちょうどいいのかもしれないな。 思いますね。
@vwxyutarooo
なんか、さっきの話で、自分の経験から思ってることは、デザインシステムで組織が大きくなるま、利用者が大きくなるほど、デザインシステムをリッチではなくて、よりジェネリックにジェネラルに 作っていくことが求められていて、例えば、こうちょっとデザインシステムにするべきか、プロダクトのチーム側で管理する。根本にかって迷う時があって、小さい スケールの時って、ザシステム入れちゃっても、そんなに後で大変になることってないんですけど、
@vwxyutarooo
それがデザインシステムの利用者とか、プロダクトが増えていくほど、あーまいっかデザインシステム入れちゃえっていったものが、後々こう汎用性もなければ、微妙に違った使われ方をしちゃったりして、 辛くなるみたいなことがよくあると思っていて、なんで大きなそうですよね。組織で使われるデザインシステムを目指すっていう時には、より ストリクトに。えっと、汎用性のあるコンポーネントかどうかっていうことを突き詰められるのが求められるんじゃないかなって思っていて、結論は変わんないんですけど、考え方は、自分がの経験からはそっち方向に行くんじゃないかなと思ってます。
@AlanGDavalos
そうですね、 ま、これはちょっと。また、なんか多分どの当壇にも載ってない話にもなってしまうかもしれないけど、結局さっきユウタロさんが言ってた通り、こう全てのものをまデサインしたし、システムにとに取り入れてしまったら、 なんかもうプロダクト作る意味があるのかっていうぐらいになってしまうので、なんかもう本当になんか組み立てるぐらいな
@AlanGDavalos
あのものになってしまうので、なんか、それだと、ちょっとプロダクトの独自的なものがちょっと失われかねないっていうところもあるので、ま、デザインシステムの理念自体は ま、結構多分、そのデザインのそのファンデーション的にはちゃんとああるべき ですし。なんかそこで、なんかそれに基づいたものが、ま。どこのプロジェクトにも使われてもいいんですけど、ただ逆になんかライバリーと言いますか。なんか、その行動自体に
@AlanGDavalos
作るコンポーネントにしては、なんか、そのデザインシステムの全てをコンポーネント化して、なんかライブラリーに入れるか、入れるべきかどうかっていう話はちょっと違うんですよね。多分、なんかさっきユウタロさんが言ってた通りな がすごい汎用的ね。どこにも必要で、どこにも使われがちなところだけをまあ入れるべきなんじゃないかなと思いますね。ここら
@vwxyutarooo
だけでずっと話しちゃいそう
@odan3240
し、次のセッションの理解にいきますか。 では、えー、次はえ、2つ目のセッションのスマートhrデザインシステムのシステムにについて、振り返りをしようかなと思います。 uitmタップのアンケートでは、えっと、btob系のシステムを作るときに、ま参考にしたいとのえっと、コメントがついていました。
3. セッション2振り返り
@odan3240
やっぱり、lineとメデカリさんの発表は、ま、toc向けのサービスのデザインシステムの紹介であって、のに対して、tob向けのデザインシステムの発表タんで、やっぱそこが結構 あ、どういうものを開発するかとかま、どういう目的で作るのかっていうところは、ちょっと異なってて、面白いのかなと思いました。
@ibulog_
そうですね、やっぱりこうtoシー向けだと、ターゲットによって当然こう必要なものも異なるしか全てが異なる上で、それを束ねるデザインシステムっていうのを ま、考えなきゃいけなくなってくるのかなと思うんですけど。ま、tobー向けで、特にこう一体感を持って、プロダクトを提供してるみたい な場合だと、そこはそこまで考える必要がない、どっちかというと、もうあの統一感を持たせるっていうところが統一感があってまユーザーがそのプロダクトを連携して、
@ibulog_
複数のプロダクトを同時にこう使っていくような場面で迷わないみたいなところが1番重要なところに なってくるので、結構確かに考え方、違う部分あるのかもしれないなと思いますね。
@AlanGDavalos
そうですね、なんか、tobー独自の悩みではないものの、多分なんか ツーbの方は結構1ユーザーがなんか自分のプロじゃ、なんか、プロダクトを複数使うケースがトゥーシーよりは若干なんか確率が高いと思いますので、その一貫性がより大事になりますよね。
@ibulog_
そうですね、やっぱり一貫性が大事なのと、そうですね、あとは、 感染も大事にしてるんですけど、割とこれはtobに限らずなんですけど、開発チームが 下した決定みたいなのも、結構尊重している部分があ
@ibulog_
で、結構デザインシステムから外れた決定みたいなのがあってもこう。それが開発チームが、例えばユーザーリサーチなんかをして、こういう使い方がいいっていう風な あ。コンテキストがあるんであれば、あのー、それはあの、あくまでデザインシステムっていうのは、ガイドラインとしての位置付け、 そして、割とそれがこうユーザーに価値をもたらすのであれば、ゴーゴーみたいな雰囲気文化があるので、そこも
@ibulog_
もしかしたら、toシーとはちょっと違う部分なのかもしれないなとは思いましたね。
@vwxyutarooo
あとは、自分が感じたのはま、tゥービー向けだと、よりツールっぽいサービスが多くなるのかなと思ってて、 管理画面だったりとか、そういうものがってなった時に、やっぱりデザインシステムとして、威力を発揮しやすいコンポーネントが多いですよ ね。テーブルとか、フォームとか、あそこもなんかsmarthrさんがこう、デザインシステム。すごいうまくいってる感じが話に出てくるのも、
@vwxyutarooo
そこも1つ大きそうだなっていうのと、あとは、デスクトップがメインですもんね、それもやっぱり1つこう デザインシステムをシンプルに保てる1つビジネス的な要因があるのかなと。 で、もし仮にこれあん。iosandroidウェbで、ウェbのモバイルとディスクトップみたいに、4つの展開になってくると、めちゃくちゃめんどくさくて、
@vwxyutarooo
もうやってらんねえよみたいになるんですけど、iosってandroidで、例えばこうosレベルでこうuiの違いっていうのがある程度あって、 それを壊さない程度のプロダクトの独自のuiみたいのが、 こう求められたりすると思うんですよ。出会った時にこう、デザインシステムを使いながらも、全てのプロダクトで、なるべく共通の体験は与えるんだけれども、osの体験を壊さないレベルで、そこに違いを生むっていうことが
@vwxyutarooo
あったりして、これは多分トーcーで、特にモバイル向けにやってるところは、悩みどころだと大変なところだと思うんですけど、 そこはやっぱりディスクトップにフォーカスして、体験を設計できるっていうのは、1つtobのビジネスの うー利点って言うんですかね、強いところだなと思いました。
@ibulog_
確かにそうですね、なんか、コンポネントと組み合わせっていう意味でも、デザインシステムの中によくあるテーブルっていうコンポネントの問い合わせがあって、 そういうのはあるテーブルでよすくあるテーブルっていうま、smarthrプのプロダクト内で使われてるから、よく使われてるから、よくあるテーブルなんですけど、 テーブルっぽいこう、uiだったらよくあるテーブルのコンポレート組み合わせを使っちゃえば、それで、あの画面がある程度できるっていう。
@ibulog_
あ、そういう使い方ができるのは確かにあのユタロさんおっしゃる通りかなと思いますね
@odan3240
あと、なんか、リンゴの違いとかもありますよね。カラーとか、タイプグラヒーとかのデザイントーク をま管理する時に、やっぱandroidiosだとま言語が違うので、なんか、jイソンとか、amルとかで定義した上で、各言語にまインポートするみたいな。そういう運用になるかと 思うんですけど、ま、ツービっていうか、ま、デスクトボンディとかだと、まあ、gsで、とりあえず
@odan3240
オブジェクトとして管理すればいいので、その辺の手軽さもありそうだなと思いました。確かにありそうですね、
@AlanGDavalos
そうですね、そういうじ事実面でのちょっとよりシンプルに取れる選択肢っていうのは、まさっきユウタロさんが言ってた通りの話で、あとは本当にそうですね。なんか、さっきブロクさんが言ってた通り、なんか テンプレートがより活かせるんですよね。
@ibulog_
そうですね、ありそうなんか そうですね、私自身はこうま、smathrのデザインシステムが結構当たり前と思って暮らしてたんですけど、やっぱこう社外に 目を向けると、あ、結構やっぱりこううまくいきやすい要素っていうのを、そのートhrの中で揃っている上での今なんだなっていうのを、こう
@ibulog_
再認識できてよかったですね。
@vwxyutarooo
そうですね、それで言うと、うちはめちゃくちゃ苦労してます。
@odan3240
あの、
@vwxyutarooo
smarthrさんの話を聞いて、めちゃくちゃいいなと思ったのが、あのー、やっぱ、プロダクト開発する人も、デザインシステムにすごい前向きな感じが発表から伝わってきてて、 これはデザインシステムに管理しましょうとか、これ、デザインシステムに入れましょうこれはこっちでやりましょうに管理 そういうのが、えー、プロダクト開発をする側からも、積極的に行われてるんだなっていうのがあって、これがうーまさっき言った通り、こう。tocでザシステムそのものが複雑で、
@vwxyutarooo
かつ組織も大きくて、開発チームとデザインシステムの距離がちょっとあったりすると、デザインシステムに入れようとすると、機能開発。ちょっと時間かかっちゃうから、開発側で勝手にやっちゃえ。みたいな ことって起こったりするんですよ。そういうのが、えーっと、イブラグさんの発表から、真逆のなんか、こう開発現場が見えてきて、 すごいいいなと思いましたね。
@ibulog_
そうですね、確かに、基本的にデザインシステムが先行して、何かを作るっていうことがほぼないんですよね。現場が開発する上で、こうどういうuiがいいかとかを調査して、 その上で見つけた。なんか、法則性みたいなものが、もしあれば、それをデザインシステムに掲載する。まあ、あのuiコンポネントであれば、 あのまあそれをコンポネント化するっていうような。あのー、進み方なので、そこはもしかしたら結構違う部分かなと僕も感じましたね。
@AlanGDavalos
そうですね、やはりそのまユウタロさんがあの前言った通り、なんかこうトーシーだと結構なんか各プロダクトになんか独自性を 持たせるみたいなことが結構大事だったりして、それに関しては、ま、テレビだと、もうなんかソリューション なんか全体になんか一貫性を持たせて、かつなんかま使う部分がまいよく似てるので、少し管理しやすいんですよね。
@AlanGDavalos
あのす、多分なんかそういう要求に簡単に答えてしまうかもしれないんですよね。開発側の
@vwxyutarooo
アランさんの今のは、いい意味で言いましたそれとも、ちょっと心配ですよね、っていう意味でした
@AlanGDavalos
いや、いい意味ですよまあ、なんか独自なんだろう。結構なんか、そのプロダクトの種類の違いが、まあ、はっきり出てるなってちょっと思ってて、 まあ、なんかどちらがいいかっていう というよりは、プロダクトのタイプの違いでま。そういうことがもう必然的にま、そういうハードルが違いますよね。そもそも、
@vwxyutarooo
うん、その通りだと思います。
@AlanGDavalos
ただ、逆に思ったのは、tocとtob向けに、なんか同じデザインシステムを使おうとすると、ま結構混乱してしまいがちなので、 なんかそれが1番難しいです。
@vwxyutarooo
そう、メルカリはtovもtocもどっちも開発してるので、そこをもし共通で使おうと思うと、結局デザイントークンぐらいしか残んないんですよね。
@AlanGDavalos
そうなんですよ、そ、なんか例えばなんですけど、なんか、トゥーシー向けのプロダクトにテーブルって使いますか。
@vwxyutarooo
使わないんですよね、うちは持ってないんです、ケーブルをデザインシステム。
@AlanGDavalos
へー、そうなんですよ、 だから、なんかまあそういった違いが結構はっきり出てしまうんですよね。なんか、そもそもなんか何に対して 作るのかによって、確かに
@ibulog_
なんか全然すと鏡の質問になっちゃうかもしれないんですけど、そのtobーとtocで完全にデザインシステムを分けちゃうと、どうなるんですかね、
@AlanGDavalos
どうでしょう、それは逆になんか うちでなんだろう。なんか、そういう分け方じゃなくて、まあ、例えばメッセンジャー向けとか。なんか、他のプロダクト向けに なんか色々やって、なんか区別して色々やってたんですけど、結局なんかどっちにも似たようなことをしてしまいがちなので、なんか、それはそれでかけるリソースとかが増えていくので、
@AlanGDavalos
分けてもいいっていう話ではなくて、なんかこう。また、なんかバランスの話に戻ってしまうけど、な か、どっちもどっちでいいところもあれば、悪いとこもも悪うので、なんかどっちがなんかすごい優れてるのかっていうのはちょっと難しいですよ。
@ibulog_
いや、そうですよね、なんか優れてるかは優れてる、優れてないは多分そうですね、バランスの問題ですよね、確かにあ、難しいですね
@AlanGDavalos
まあえて言うとすれば、 おそらくどっちもあるにしたら、どっちにも使えるようなものにしてしまった方が、区別して作るよりは、なんかかけるリソースは少なくなるけど、作る難しさが増えるっていうような、多分なる 分け方だと思いますね。
@vwxyutarooo
うちの場合は、もうtーbというか、ツール向けには、オープンソースのこのライブラリーを使いましょう。っていう風に、今、そういうディスカッションというか、 方針をあのー、持っていこうとしてますね。自分たちの場合は、ま、例えばメルカリ、別にメルカリのブランディングなんて大したことないですけど、 例えば、こうどっかの企業にメルカリの通話を使ってもらうっていう時に、メルカリのボタンは赤くていいよね。とか、絶対なんないと思うんですよね。って考えた時にそうですね、使う利用者の
@vwxyutarooo
ベネフィットを考えた時に、うちでは、そんなに内政のデザインシステムで、えっと、tobのツールとかをカバーする必要はないんじゃないか、というほ議論に、多分僕は向かっていくと思います。
@AlanGDavalos
確かに、それは選択肢の1つかもしれないですね、
@odan3240
ぼちぼち、次のセッションに映りますか。 じゃあ、最後にえっと、真のスケーラブルを目指したwebコンポーネンツ、デザインシステムの失敗と、今後について振り返りを行いたいと思います。えっと、ミートアップのアンケートでは、 今回、そのすごい大きな変更がひ必要となる。まあ、技術選定になったと思うんですけど、ま、
4. セッション3振り返り
@odan3240
それに対してますごい前向きに前を向いてま、今後どうするかっていうのを検討しているのが良いという風なコメントがありました。 自分からし質問なんですけど、そのリプレース先の技術スタッフがまあ、リアクトっていう話だったんですけど、なんか 具体的になんかどういう。例えばcss書く場合に、そのcsインjsでやるのか、cssモジュールでするのか、みたいな
@odan3240
選択が存在すると思うんですけど、今後の方の具体的な芸術選定がどんな感じかっていうのを聞いてみたいです。
@vwxyutarooo
うーん、そうですね、大枠の大前提になる考え方は、そこまで大きくは変わってなくて、なるべく利用者の技術をデザインシステムが決めないとか、 あ、利用者がえっと、技術を決定すべきっていう基本的な考え方はのこ てるんですね。なので、えっと、例えばcssで言うと、cssインジjsを使って、えっと、バンドルサイズを
@vwxyutarooo
デザインシステムで大きくするだったりとか、もしくは、えっと、利用者がこのcssnjsのライブラリーを使ってください。みたいな風にはしないようにしてるっていうのが、このリアクトを選定した後でも共通してる考え方です。なので、 特典ライブラリーに極力依存しない形で、リレクトのデザインシステムを今書き直してます。cssイん css、モジュールスとか、その辺を組み合わせてやってますね。プロダクトで使うってなると、まいくつか、ちょっと
@vwxyutarooo
cssモジルつ懸念が出てくると思うんですが。ま、そんなにクラスの詳細度とか、オーバrラidとか失いが発生しないっていう前提で、デザインシステムで、そういう意思決定をしてたりとか。あとは まリアクトで言うと、やっぱcssが1番でかいですかね。何技術買うってなった時。
@odan3240
そうですね、まだに全然定まってない印象がありますね。なんか、デファクトというか、
@vwxyutarooo
そうですね、テールwindowとかでもよかったんですけど、ああ、 どこまでしー。シームスイッチャーに対して、どこまで柔軟に作れるかな。っていうのが、ちょっと自信を持ちきれなかったので、割ともうレガシーで誰でも扱えるようなcssモジュールスに行きましたね。
@odan3240
そうですね、まあ、なんか生のシーセスがかけるっていう安心感は大きいですもんね、うん。
@vwxyutarooo
あとは、今回のウェブコンポーネンツの話が技術選定をしたのが、2年前ぐらいだったんですよ。で、 2年経ってもやっぱり厳しいものもあれば、 少し良くなってるんだなっていうものも、アランさんとかがtwitterにこう。はいはい、書いてくれたりしてて、そうですね、歩みはまあゆっくりなんですけど、少しずつ前進もしているぞっていうのが、ウェブコンポーネンツの
@vwxyutarooo
なんでしょう。今回の発表を中心に結構印象的だったところなんじゃないかな、と。
@AlanGDavalos
そうですね、ちょうど今日あの出てきたあの、サファリーのリリースになんかめちゃめちゃあのブコンポ、熱 の機能こい。あの、たくさん入ってたんですよ。 あの、デクララティブシャドードームとか確かなんだっけ。えーっと、エレメントインターノースとかも入ってたはずなので、結構サァリさんの
@AlanGDavalos
おふか、ポンツのエンジニアが喜んでました。
@vwxyutarooo
まね、効率だけをつけ詰めていくと、やっぱり今からでもリアクトにするなみたいな。理由は、自分たちのプロダクトを見た時にはあるんですけど、ただ、 ウェブコンポーニンズが少しずつ前進してることで、うー採用できるプロダクトもちょっとずつ、また今後も増えてくんじゃないかな、というのは、ウェブコンポーニンズやめます。って言ってる意味ですけど、 けど、使えるプロダクターはまだまだあるんじゃない。って思いましたね。
@odan3240
まあ、また来年また同じような状況だったら、また全然wェブコンポーネントは可能性としてはあるかも。っていう 感じなんですね、まあ、あるかもって
@AlanGDavalos
そうですね、 個人的にが、まあ、ウェコンポーネツのあのコミュニティグループに、それは所属するぐらいのものなので、ま。ちょっとあの、みんなあの意見が偏ってしまうかもしれないけど、やはりなんかま標準である分、あのま進み。 なんか実際になんか全てのブラウザーが実装して、初めてなんかお広範囲で使えるようになるっていう
@AlanGDavalos
欠点はあるんですけど、ま、それが逆に見ると、ま、それさえクリアすれば、なんか後ほどに消されることはないんですよ。 なので、なんかそれをベースにちゃんと固めてしまえば。例えばなんですけど、なんか最近結構リアクトがなんか批判の対象になってくることは ま、増えてきてるっていうところなので、消えるのか消えないのかっていう以前に、なんか別のものに移行するタイミングはまいずれくるかもしれないので、そのタイミングで別のものに行するコストは結構増えているので、
@AlanGDavalos
まあ、逆になんか標準のもので作ってしまうとなくならないので、とりあえず、なんかそれを代弁しながら、なんか少しずつなんか あの新しいものを作るよみたいな取り方もできるので、まあな長い目で見てしまうけど、なんか長い目で見てまより安心できるのかなってちょっと思ってます。
@vwxyutarooo
うん、これすごい難しいんですよね。自分もウェブコンポーネンツは、 もっと普及ほしてほしいなと思っている側なので、積極的にウェブコンポネンスやめましょう。とは言いたくない派で、
@AlanGDavalos
なるほど、まあ、
@vwxyutarooo
ただ現状として、ウェブコンポーネンツは別にリアクトを置き換えるものでもないですし、まあ、うん、両方が必要な場面が少しずつ違っていて、
@AlanGDavalos
えー、
@vwxyutarooo
僕らの場合は残念ながら、ちょっとこれを活用することができませんでした。っていう話だったんですけど、ま、例えばそうだな。 linとか、スマarトhrもそ話の中でそうだったと思うんですけど、例えば、ssrのコストがそんなにカツカツにならない。メルカリって、アイテム数がめちゃくちゃ多いんで、ssrコストがめちゃくちゃ すごいことになるんで、例えば、じゃあ、ウェブコンポーニンズとヤクと
@vwxyutarooo
組み合わせたssrしましょう。っていうと、絶対にオーバーヘッドは、リアクトだけのssrより大きくなるって考えると、 そのちょっとのオーバーヘッドがめちゃくちゃ大きな金額になって返ってくるみたいな。ビジネス背景があるんですけど、逆にえーと、そこまでssrに対してシビアじゃない。サービスと か、プロダクトっていうのは、ウェブコンポーニンズとリアクトを組み合わせるっていう選択肢もあるし、ステートだったりとか、そういうのが複雑じゃないのであれば、最初から全部ウェブコンポーネンズ
@vwxyutarooo
作るっていうこと、どんどんブラウド対応が進んでるとか。えっと、今までちょっときつかった仕様がこうどんどん 実装されてくみたいなのに伴って、 今後もまあまだwebコンポーニンsが、うーん、使える場面が今後ちょっと増えていくんじゃないかなっていうのが、さっきのサファリのニュースも含めて、web開発者にたちにとってはいいニュース
@vwxyutarooo
ですね。
@AlanGDavalos
そうですね、 要はなんかま全てのツールはなんか全てのプロジェクトに合うことは、ま、そもそも不可能っていうところもあるので、自分のプロジェクトに見合った もの。まあ、先ほども。多分なんかそのような話をちょこっとしてたんですけど、ま、これもまあ、そのうちの1つなんじゃないかなと思ってて
@AlanGDavalos
ま。本当になんか自分が置かれてる状況。プロジェクトのまリソースや、なんか、スペックなどを踏まえた上で、まあ、自分にできる最選の あの選択肢をするのがま1番ですよ。っていうのは、まあ結論になってしまいますけど、
@vwxyutarooo
あとはそうですね、アフタートークとしては、やっぱり書き換えは大変ですね。
@AlanGDavalos
大変なんですよ、あの
@vwxyutarooo
とに大変なので、皆さん技術選定は気を付けてやりましょう。って
@AlanGDavalos
そうなんですよね、 ライフサイクルが似たものではあっても、結構そもそも根本的な違いがあるので、
@vwxyutarooo
あとは特に自分たちが苦労してるのはそうですね。社内で、ウェブコンポーネンツをの知識を貯めて作った人が、今はもう転職しちゃってたりとか、別のチームに やってたりして、残ってないっていう時に、えっと、今までウェブコンポニツを触ってき 来なかった人も、今の実装からなんでそうなってるのかを紐解いて、次のリアクトン実装に生かす。
@vwxyutarooo
みたいなことが結構求められる場面があって、で、スペックが残っていたとしても、じゃあ、えっと、実際のプロダクトに組み合わせたと こうなるから、こういう実装になってるよっていうのが、コメントとして残ってる場面もあれば、残ってないことも、 実際の現場では多々あると思うんですよ。で、そういうのがえっとー、そうだな、
@vwxyutarooo
ウェブコンポーネンツにあー、詳しいデペロッパーとそうじゃないデベロッパはどっちも世の中において、プロだク会社の中でも、やっぱり強みがバラバラの時に 特定の人に頼って、そのwebコンポーネスンデザインシステムを開発してしまったっていうのが、僕たちの開発背景にあったので、その人たちが今デザインシステムに関われないっていう 状況で、そもそもじゃあなんでこういう実装になってるのかっていうのは、紐解くところから。今、えーと、エンジニアたちが大変頑張っております。というのか、リアルな現状です。
@AlanGDavalos
まあ、そうですね、なんかある意味あのビューのコードベースをうん、あの、アンギュラーの開発者に紐解いてほしいみたいな。うん、言い方。 まあ、要はなんかそれぐらい異なってしまうと、まあ、少しずつなんか学びながら元々の技術を学びながらなんか なな。なんでそうできてるのかをちょっと色々汲み取らないといけないんですよね。
@vwxyutarooo
そうですね、大体もうできったような気がしています。
@odan3240
うん、結構喋りましたね
@AlanGDavalos
とはもうしめますか。
@odan3240
はい、じゃあ、えっと、クロジングします。はい、 というわけで、今回は3月15日に開催されたuitミートアップボリューム19、デザインシステムのアフターショーをお送りしました。ゲストのアーランさん、eブログさん、ゆうたろうさん、ありがとうございました。
5. クロージング
@AlanGDavalos
ありがとうございました
@ibulog_
ありがとうございました