00:00
[音楽]
こんにちは出口です
こんにちは本山です
リサイズ編は
「もとやまと出口が最近気になっているサービスやデザイントピックス」を取り上げて
のんびり話すポッドキャストです
よろしくお願いします
お願いします
なんか出口くんはさ
情報系…一応情報系の勉強も多分学生の頃してたんですよ?確か
そうですね
僕はそんなしてないわけだけど
なんか最近チューリングコンプリートっていうゲームがあってですね
それをちょっと時間があるときにやったりしてるんですけど
論理回路を作るパズルゲームみたいなやつで
そんなのあるんだ
なんかこの系のなんかやつって結構あるらしいんですけど
なんかこのTuring Completeってやつは
なんかSteamで最近なんかリリースされたやつで
へー
でなんか
最初の方は本当に部品があんまりなくて
その部品があんまりない中でこうXORとか作ったりするんですけど
ほほほ
で、その XO を使って、またもっとリッチなものを作っていって、
ちょっとずつ部品が増えていくみたいなやつを出てて。
ああ、なんか回路を結ぶみたいなゲーム?
そうですね。回路を、必要なパーツを置いていって、
で、こう結んで、期待してる答えを出せっていう答えというか。
あー、なんかやったな、授業でこういうの。
そうそうそう。
多分、情報系の学生とかだったら、
多分、授業で普通に書いて、論理解読。
手書きでやってましたけど、すげー嫌いだったけど。
いや、それをね、最近やってるんですよ。
マジ。
いや、難しいね。
あー、なんかいろいろ思い出してきました。
課題ですげーやらされた思い出を
いや難しい
最近ずっとバーって進めてんだけど
なんか1ビットメモリーっていう課題があって
その1ビットメモリーなんかラッチ
SRラッチっていうなんかこうパーツを使って
なんか1ビットだけそのメモリーとして保存できるものの回路っていうのを作れっていう課題をやってんだけど
なんか僕はもうめちゃくちゃ難しくて、これどうやってやったらいいんだろうってずっと悩んでるんですよ、最近。
楽しいんですか?これは。
でもね、できると楽しいけど、ほぼほぼ苦痛ですね、なんか。
まあ、パズル的な感じ?
03:02
うん、そうそうそう。あとなんかさ、やっぱり、愚直にやればできるなっていう回路もあるわけですよ。
それが正解なのかよくわかんないんだけど、だけどなんかあまりにも愚直すぎて
これはダメだろうみたいな気持ちになりながらクリアするみたいなこともあって
全部if文で繋ぐみたいな
そうそうそういう
いやー
なんかでもこれ書いてるとさ、一応クリアするんだけど、さっき言ったように無理やりクリアしてたりとか
あとなんか結構なんか雑になんかなんかいろいろ試行錯誤した結果やっとできたみたいな感じでなんかもうなんか図としては汚い感じのものさ出来上がったりしてさ
いやもうこれはジョブスに見せたら怒られるんだろうなっていう気持ちになって
なんかマインクラフトもチューリング完全だからなんかできる、なんか同じようなことができるみたいな話ありますよね
ああ、ね、うん、結構いろいろそれ系のパーツがありますよね、マインクラフトも。
いやー、これ、ほんと、WOZはすごかったんだろうな、と思いましたね、これやってて。
いや、なんか、最近まあ、マイクラやってるじゃないですか、その何かで。
で、なんか、人が作ったあの、機械、機械っていうか、あの回路を見ても、何やってるのか全然わかんなくて。
やっぱそれになんかちょっと近しいというか
いやなんかでもこれね
最後どこまで行くのか全然わかんないんだけど
なんかCPUとか
なんか結構ね
コンピュータっぽいところまで作れる
最後は作るらしいんですよ
へぇ~
これは一人で淡々とやるゲームなんですか?
一人で淡々とやるゲームですね
あ そうそういう感じなんだ
制限時間とかがあったりも
今のところやってるやつはないですね。
難しい。
ちょっと勉強したいなと思って、これやってて勉強したいなと思って。
なんで?
論理回路の勉強したいなと思い始めちゃった。
なに?どういうモチベーションなんすか?
わかんないけど。
わかんないけど、クリアできないから悔しいから、
だから、ちゃんと論理解るのを勉強したいなって気持ちになってきちゃって、逆に。
なるほどな。
いや、僕は正直学生の時やらされた思い出が蘇って、全然やりたいとは思わないです。
難しそう。
こういうゲームがあるんですね、スチームに。
結構 この論理解除系のゲームは 多分いくつかあるんじゃないですか
別にSteamに限らずですけど
今までのなんかゲームっぽくすることで 学びやすくするみたいですよね
06:02
そうそう ゲームっぽいのはわかるんですけど これもうモロにこう…
なんていうか… すげえなんか 原始的な感じですよね
うん まあまあ そうですかね
うん
でも 結構ね わかりやすいよ
まあちょっと今英語でしか出てないんで
まあ英語が読めると結構きついかもしれないですけど
まあでもわかりやすく
なんか最初のステップが本当に処方的なところから
ステップ追ってやってくれるから
その辺はなんか結構
なんか勉強になったなっていう感じがありますけど
ちゃんとなんかこう
回路が繋がっているように
アニメーションが入っているとか
そういうのもあるんですね
そうそうそうそう
とか一応なんかこう
なんかなんていうの
課題があって、それの通りちゃんと動くかどうかっていうテストをしなきゃいけないんだけど
なるほどね
そうそうそう
で、テストしてそれがちゃんと通ればOKみたいな感じで
じゃあ、なんか実際こうプレイグラウンドみたいな感じで動かせたりするんだ
そうそうそう
本当に全然作ってる途中でも動かしていけるから
だから結構試行錯誤しながらやれるんですよ
それは面白いですね
なるほどね
まあでも、僕はもうかなり中盤ぐらいでつまずいてるから、もう先が思い合われますね。
なるほど。
知り合いのエンジニアもなんかやってたっぽいけど、なんかかなりよくわかんないもの作ってた気がする。
なるほどね。難しそう。
じゃあちょっと今日はスキーマー コンファレンスの話をしようかな
と思うんですけど
Figmaの何でしたっけ夜12時ぐらい から朝6時ぐらいまでやってたやつ
ですよね
そうそう
だいぶ前にイベントの告知があって 応募してっていう話をちょっと前に
してたような気がしますけど
そうですね。ちょっと前のサブトピックスで取り上げたと思うんですけど、
戦線週の10月8日に12時スタートで6時終わりっていう、
日本に住んでる人的には結構きつい時間帯のイベントだったんですけど、
改めて何かというと、Figma が開催するデザインシステムだけを取り扱ったオンラインイベントみたいなものを、
事前に登録して招待されるような形だったんですよね。
招待性と言ってたら、多分ほとんどの人が招待されてるんじゃないかなと思うんですけど、
うん。でなんか結構こう、事前登録の項目が結構いろんなこと書かされて、なんかこう、リンクというのは誰か教えてくださいとかね。
09:00
うんうん。
なんか、そうさ、肩書きを教えてくださいとか、なんかいろいろ結構書く感じだったんで、
まあ多分なんか今後こうFigmaとしてデザインシステムみたいなの強化していくから、
まあそれの営業リストというか、エンタープランスプランを売るためのまあリスト作りみたいな目的もあるんじゃないかなという風に見てたんですけど。
うん。
で、やっぱり中身的にもデザインマネージャーというか、デザインシステムマネージャーみたいなタイトルの人、
型書きの人が話してることが多くて、聞き手としてもそういう人を想定してそうな内容でしたね。
大体全部で8個かな、話があったんですけど、
ちょっと面白かったものを一つ一つ取り上げていこうかなと思っていて、
まず一番最初にキーノートっていうような形で
Figmaのディレクター・オブ・プロダクト
結構役員の人かな?
桑本さんっていう方の話があったんですけど
これFigmaがどういう思想で作ってきたかっていう話
で、個人的にはこのカンファレスの中で僕が一番面白かったんですけど
面白かったんですけど、なんかこう、もともとフィグン、あの、この桑本さんが、このマクロメディアにいたらしいんですよね、97年頃に。
マクロメディアでオーサリングツールを作るチームにいたらしくて、で、まあ、そこでできたのがドリームウィーバーらしいんですよ。
この時のドリームユーボーを作った時の最初の着想としては
HTMLっていうものがまだ結構世に広まりだした頃なんですよね、97年って
その頃のHTMLに対する理解としては
これはポストスクリプトと同じようなものなんじゃないかって考えてたらしくて
ポストスクリプトってプリンター用のプロトコルみたいなもので
昔ってプリンターにこういうものを印刷しろっていう指令を
プログラムみたいなものを書いて印刷してたらしいんですよ
だからこう何だろうな
例えば絵を書いてそれを印刷するとしても
その絵を一旦プログラムに変換して
ポストスクリプトっていうスクリプトに変換して
それでプリンターに指令を出すみたいな感じだったんですよね
で、そこに対してイラストレーターとか、
そういうドローイングツールが生まれたことによって、
人間がそういうスクリプトを手書きしなくても、
ドローイングツールが絵とスクリプトを変換してくれるっていうことが当たり前になっていったと。
だから、HTMLも同じように、
ポストスクリプトのときのドローイングツールのように、
デザインとコードをつなぐ役割のツールが必要だっていうふうに考えて、
それでDreamweaverを作ったっていうような話だったんですよ。
そう、だから結構Dreamweaverを設計してる時には
12:00
いかにデザインとコードを紐づけるかっていうところを重視していたっていう話があって
結構これを聞いてた僕はこないだ
Designing with Codeっていう会で話したフレーマーの話を結構思い出しながら聞いてたんですけど
ドリームウィーバーも97年から似たような思想で作ってたっていう話ですね。
結構ドリームウィーバーを作る中でもう一個大事にしてたのが、
ドリームウィーバーを使う人がいかに再利用性を高められるとか、一貫性を保てるとか、デザインの。
当時でいうとカラーだとか業館だとか、今でいうデザイントークンってやつをいかに再利用させられるかっていうのは、
この当時から結構大事に考えていて、
その結果アセットパネルっていうような
ドリームウィーバーの機能があるらしくて、
そこで例えばスニペットを一覧できるとか、
画像とかそういうアセットをDragonDropでいつでもどこでも配置できるとか、
そういう機能を作ってたっていう話があって、
ある意味これがすげえ原始的なデザインシステムであって、
このDreamweaverのアセットパネルみたいなものは
今の現代のFigmaを使ったデザインシステムにも通じるみたいな
そういったような話をしてましたね
そうそう
で、そういうようにデザインとコードをすげえ行き来するってことを重要視してて
Dreamweaverを作ったんだけど
ただ実際問題リリースして
人々がどうやって使ってるかっていうのを ユーザーがどうやって使ってるかと見てみると
実際にはまず Photoshop でデザインをして
それを Dreamweaver 上でもう一回デザインし直して
最後に Dreamweaver って基本的には
Widgetwig で見たままのデザインができて
それをコードベースに切り替えられるっていうものじゃないですか
まあなんかフォトショーで一回自由にデザインして
画像としてデザインした上で
それをドリームウィーバーでもう一回デザインし直して
さらにもう一回ドリームウィーバー上のコードビューに変えて
コードに手直しするっていうようなことをやっているっていう実態があって
だからなんかこうドリームウィーバーを作った設計者としては
なんかそれがこう二度手間に見えて
こうフォトショーでデザインしたものをもう一回ドリームウィーバーでデザインし直してるから
それはすげえ奇妙だなと思ってたんだけど、
ただやっぱなんでそういうことをみんなするかって言ったら、
Dreamweaverってコードとデザインを行き来しやすくするとはいえ、
やっぱデザインするときにはストラクチャーとデザインって言ってたんだけど、
構造を意識しなきゃいけないっていうのがどうしてもあって、
逆にフォトショーデートのデザインをフリーフォームデザインって言ってたんだけど、
15:00
フリーフォームデザインの場合は構造を意識しなくて済むから、
単にキャンバスにボタンをどう配置するかっていうだけの話なんだけど
ドリムイーバーでのデザイン そのストラクチャルデザインの場合は
どうしてもこのボタンをここに置いたらディブの構造がこう変わるとか
なんかそういうことを意識しながらデザインしなきゃいけないから
なんか最初からこうストラクチャルデザインをやるには
なかなかこうデザイナーのマインドセット的にハードルが高いことに気づいた
みたいな話をしてて
まあなんか僕も本当に初期の頃初期の頃はドリームウィーバー使ってたこともありましたけど
なんだろう正直言うとそういうふうに考えてたっていうよりはどっちかというとやっぱりドリームウィーバーの限界によって
制約が生まれていた部分があったと思うんですよね
例えば幅60ピクセル開いたボックスの中にテキストを入れるって言う風になったら
もうその制約になんかこう従わなきゃいけなくなっていくわけですよ ずっと
そういう制約をどんどん作っていくみたいなところがドリームウィーバー使ってるとあって
なんか簡単に言うとなんかつまんないものができてくんですよね
ドリームウィーバーで作っていくと
だからそれを他の人たちもそういうふうに思った部分はあって
なんかもっとこういうふうに表現したいのっていうのが
やっぱりドリームイーバーでは全然できなかったっていう事の方が
やっぱり強いんじゃないかなと思いますけどね
たぶん当時の限界、ツールとしての限界があって
そのストラクチャーデザインだからってよりはっていうのもあるし
そのツールとしての限界で表現したいものが表現できないっていう
まあ2つがあったんでしょうね
まあが結構こう、この岡本さんの話の中ではそのフリーフォームデザインっていう
まあある意味、 多能的?無能?どっちだ?ちょっとわからないけど
フリーフォームは無能的か?
無能か、無能的か。無能的なデザインとストラクチャーデザインっていう多能的なデザインっていう2つがあるから
その2つの違いをデザインシステムを設計するときにも考えなきゃいけないみたいな話を結構強調してましたね
この話を聞いてて フレーマーの話を すげえ思い出したんですよね
フレーマーって最初は本当 ストラクトデザインをすげえ押し出してるツールで
デザインとコードが切り替えながら コードコンポーネントっていう形で
コードを書きながらデザインできるから すごいだろうっていうようなツールだったんだけど
コードをどうしても書かなきゃいけないっていうのは
いい意味でも悪い意味でも制約になっていて
だから自由にやりたいことを、まだコード書くフェーズじゃないって、デザインし始めの初期の段階だから、そんなガレガレコード書くというよりは、自由にキャンバーツに絵を描くような感じでデザインしたいんだけどできないみたいなところがあったんだ。
あったところに、ようやく最近フレーマーウェブとかFigmaに寄せてた部分があって、フリーフォーム的なデザインをアップデートで強化しているっていうようなフェーズだと思っていて、
18:11
だから、そういうバランスをいかに取るかっていうのは、どのツールも苦労してるんだなっていうようなのが見えてきました。
で、まあそう、で、まあ、小川元さんの話に戻ると、フリーフォームデザインとストラクチャルデザインの違いが、そのドリームウィーバーを作ってて、よくよく分かったから、
だから、結構Figmaを2015年に上映して作り始めた時も、その思想っていうのは結構大事にしてたっていうような話をしてましたね。
2015年ってちょうど、なんかマテリアルデザインGoogleが出したりとか、あとアトミックデザインとか、あとセールスフォースがLightningっていうデザインシステムをリリースしたりだとか、
ちょうどこういうウェブ界隈というか、こういう業界にも構造化、デザインの構造化っていうのがかなり話題になっていた時期だったらしくて
だからFigmaはもう2015年のこの時期からデザインシステムに関する機能を強化するってことを方針として決めてたらしいですね
まあちょっとその頃使ってたかあんま覚えてないけど
まだFigmaって初期の頃ってなんかほとんどあまり機能がないみたいな感じのとこあったもんね確か
コンポーネントもあったっけなっていうくらいの時あった気がするし
そうっすよね2015年まだなかったんじゃないかな
もちろんねオートレイアウトとかも絶対ないし
ないないっすね
最近ようやくオートレアートもそうだし、バリアントとか、あとちょっと前にあるFigmaのデザインシステム機能と呼ばれているチームライブラリみたいな機能だとか、そういうのがどんどん追加されてきたけど、
そういうのは2015年の段階からそこにかけようみたいなことは結構考えてたらしいです。
あとはFigmaが大事にしてるのって それだけじゃなくて
Figmaの一番特徴的な部分ではある ウェブブラウザベースで使えるだとか
またはコラボレーションするだとか そういうのも大事にしてるんだけど
その3つ目の原則としてデザインシステムに かけようみたいなことを意識してたっていう話でしたね
結構面白いなと思ったのはFigmaはデザイナーのツールであることを目指してるんじゃなくて
デザイナー以外の人たち、エンジニアとか
UX Writerみたいな人たちとか、そういった人たちも含めたチーム全体の
シェルみたいなものになることを目指すみたいな話をしてて
ある意味OSみたいな感じでチーム全体がデザインに関われる
21:04
効率的にできるようにすることを結構意識しているみたいな話をしてましたね。
やっぱりそういうふうにFigmaもデザインシステムに結構注力しようというふうに決めてるんですけど、
ただそこでもやっぱりドリミヴァー時代の教訓を活かしてフリーフォーム、デザインとのバランスっていうのは結構気を使っているっていうふうな話をしていて、
具体的には、例えばFigmaにカラースタイルを定義する機能があるじゃないですか。
カラーパレットがあって、この赤色、緑色、黄色みたいな、色を定義、色を何を使うかを決めて、
これをその上で、この赤色をプライマリーカラーにするとか、
この青色をハイライトカラーにするとか、アクセントカラー、これでみたいな定義をして、
それを他のプロジェクトにも使えるようにパブリッシュしたりとかできると思うんですけど。
あれもあくまであれはそういうふうにも使えるよっていうふうに作る。
初めからこれがプライマリーカラーですみたいな定義してからデザインをし始めるんじゃなくて、
あくまでデザインをして色がこのところとこれみたいな感じでフリーで決めて使ってからデザイントークンとしてじゃあこれプライマリーカラーにしますみたいな感じで定義するっていう、
この順番は結構意識してるみたいな話をしてましたね
なんかあれですよね、似たようなところで言うと
今となったら多分みんな当たり前に思うかもしれないですけど
そのコンポーネントをまず定義してから
そのコンポーネント内に使われてる要素の色っていうのを変えれるじゃないですか、今って
これってスケッチは、今ちょっとスケッチ最近使ってないんでよくわかんないですけど
スケッチも同じようにコンポーネント的なものがあって、それを定義するんだけど、その中の色とかって変えれなかったんですよね。
なるほどね。
だけどFigmaはそれをできるようにしてて、そこもある種フリーフォームの思想が入ってる部分なんじゃないかなというふうに思うところがあるんですよね。
そうかもしれないですね。
スケッチの場合だと、コンポーネントを色別に定義するとか、その色の部分を変えれるように設計しておくとかっていう、最初に定義をしなきゃいけないっていう部分が入るんですよね、スケッチの場合は。
だけど、Figmaの場合はその辺を後から自由に変えれるようにっていうのを許してるっていう部分があるっていう。
うんうんうん
まさにこの話の最後にも言ってたんだけど
デザインシステムを作る側の人間
この話のターゲットとしてはデザインシステムマネージャーなんだけど
その人たちの視点から見ると
デザインシステムから逸脱すること
デタッチしたりとかオーバーライトしたりとか
ってことはすげえイライラしてしまうことなんだけど
24:00
やっぱ、UNOを使った創造的なフリー フォームのデザインも大事だから、
そういう逸脱は許容すべきだっていう ふうな話をしてて、
それがまさにFigmaのさっきの表もと の話なんでしょうね、
反映されているところとして。
この話をデザインシステムカンファレンス の冒頭にするっていうのが
すごいいいなと思ったんですよね。
なるほどね。
あとは今後の話として、Figmaはフリー フォームデザインと
ストラクチャーデザインのバランスを 気にかけてたんだけど
ドリームウィバー時代には ストラクチャーデザインとコードっていう
ストラクチャーデザインとコードの 切り替えっていうところも大事にしてたから
フィグマでも同様に ストラクチャーデザインとコードベースの
端渡しも重視していきたいっていうふうな話はしてて
ただコードに関しては ちょっと設計を考えなきゃいけないねみたいな感じで
話してたんで 前回のDesigning with Codeの話をしたときに フレーマー
はやっぱりその子が強いよね みたいな話で Figmaはどうするんだ
ろうね みたいな話をしてたと思うんですけど Figma的にもなんとかそこは
しなきゃいけないと思ってるけど やっぱり根本の設計がフレーマー
とは違う部分も フレーマーは根本的にコードベース
で作るってことを考えてるから やりやすいけど Figmaはそうじゃない
そこはどうしようか ちょっと悩んでる風な雰囲気でしたね 話しぶり的には
ここは難しいところだよね さっきのドリームイーバーの話と同じで
やっぱりフリーフォームのデザインっていうのを許せば許すほど
多分それをコードに落とし込んでいくっていうのが どんどん無理が生じていく部分があるから
その両方をなんとか無理やり両立させようとすると 多分うまくいかないというか
破綻する部分が出てきちゃって中途半端なものできちゃうから
だからある試合僕は諦めていいんじゃないかなと思いますけどね
あとは今FigmaがなんだっけAnimaだっけ
外部のツールと連携して
コードとのブリッジの部分は外部のツールに任せるみたいなことやってるけど
まあなんかそういう戦略でもいいのかなと思いますけどね。Figmaが頑張るっていうよりは。
もしくはあれだよね、FigJamみたいにさ、別ツール作ってやった方がいいかもしれないね。
ああ、フレーマーをカクチャーするじゃなくて。
フレーマーみたいなものをFigmaが作る。
そうそうそう。で、Figmaで作ったものをそっちにうまくインポートするっていうかさ、そういう感じで持ってった方が。
まだわかんないけど 戦略としては やりやすいのかなって思いますけど
あとの話にも出てくるんだけど やっぱ各社どこもコードといかに
分離するかってところはやっぱ 考え始めて 考え始めててか もう
27:02
実践し始めていて だからFigmaとしても そこを何とかプロダクト
そしてカバーしていくっていう のは必須になってくるんだろうな
っていうような話は受けました 最近 特にノーコードとかローコード
みたいなキーワードがすごく流行ってるしね
それ以上多分ちょっとなんかノーコードローコードの文脈ともちょっと違う部分もあるのかなっていう気はしてて
ノーコードローコードってどっちかというと
なんていうのノンデザイナー、ノンエンジニアー、まあノンエンジニアーかな人が
こうコード書かなくても
ものが作れますみたいなツールじゃないですか どっちかというと
このデザインシステムカーフェレンスでいうコードっていうのは どっちかというと
Single of Truthとか言われてますけど エンジニアとデザイナー
まあ要はFigmaで作ったものとReactedで作ったものが 同じものを共有しているっていうような状態
をいかに作るかってところが結構なんかこう 話題の中心になってて
例えばわかりやすい話 デザイントークンの中でカラーコードとかを Figma と React 両方で定義するんじゃなくて
Figma 上でも React 上でも Swift 上でも Android 上でも 全てにおいて同じカラーコード 同じソースを共有してるみたいな状態をいかに作るかみたいなところを
結構みんな この後の話でも気にしていて
だからノーコードローコードの一歩手前として、
たぶんまずはそのシングルオブ・トゥルースの状態を作るみたいなところをまずやっていくんじゃないかなっていう気はしてますね。
まあっていうようなのが、くわもとさんの話で、
結構ドリームイブア時代の思想の話から、フィグマの2015年から続く一貫した思想の話まで、
全体的に一貫性があって、フィーグマンシスフォーの強さっていうのは、こういうところが来てるんだなっていうのが分かって面白かったですね。
あと次にあったのが、Netflixのデザイナーの話なんですけど、NetflixがHawkinsっていうようなデザインシステムを作ってるらしくて、その話ですね。
この話は結構実際FigmaのNetflix上のFigmaのファイルを画面共有しながら話してて
ここ結構なんていうのFigmaの中身公開しますみたいなそういった話なんで
結構これは動画を見た方がいいかもしれないですね
ああそうそうこのFigma Schema Conference全部YouTubeに動画が公開されてるんで
たぶん今でも全然見れるんで。
このNetflixの話は動画を見た方がいいかなっていうような話でしたね。
で、まあ面白かったのは、最初この話をスタートする時に「ムービーを再生します」とか言って、
30:06
このNetflixのこのHawkinsというデザインシステムがどう使われてるかっていう、
なんかすごい映画みたいなムービーを流してくれたんですよ。
だからすごい派手なことやってんのかなと思ったんだけど、
結構話を聞いてみると超地道なことをやっていて
例えばUIコンポーネント、デザインシステムの中のコンポーネントの各ページ
ドロップダウンのUIを紹介するページみたいなのをFigma上では作ってるんですけど
そこにも細かい聞き配りをしましょうみたいな話があって
例えばコンポーネントごとにこれはもうパブリッシュなものであるとか
これはまだインプログレスなものだから作業中のものですよみたいなことを表記するみたいな話とか。
あとなんかこう、アイコンだとかをこう、チームライバルにパブリッシュしたときに、
ハートマークのアイコンを単にハートってするだけじゃなくて、
なんかこう、LikeだとかLoveだとかSaveだとかFabだとか、
なんかそういったような関連するような名前にも引っかかるように、メタデータには気を配りましょうねだとか。
結構こう 地道な話が多かった ですね
なるほど なんか 大きい会社で 使うデザインシステムって感じ
がしますね
そうそう そう でもみんなやってる ことはやっぱり地道にちゃんと
やってるんだなっていうような 感じでしたね
あとはNetflixならではだなと思 ったのはMoriyaっていうFigmaプラグイン
を作ってるらしくて これはさっき 言ったドルミーバーのアセットパネル
みたいなものの 現代版 Netflix版みたいなものなんだけど
例えば Netflixの場合 映画のコンテンツを扱うから
多言語対応っていうのが一番キモいになってくるところらしくて
だから同じなんていうの 例えばスターウォーズとか
そういう映画 一つにとっても
これを韓国版にしたらどう見えるかとか
日本語版にしたらどう見えるかとか
また 映画のタイトルって結構 日本版と海外版だと タイトルが違ったりとかするじゃないですか
だから 日本で見たときにはどう見えるかとか それによって文字の幅が変わったりとか 業界が変わったりとかするから
そういう日本語版のタイトルをすぐに引っ張ってこれるように プラグイン上でやったりとか
なんかこう各言語各映画タイトルごとにこうアセットをすぐに引っ張ってこれるように
っていうようなプラグインを作ってるみたいですね
うーん便利そう
結構そのどうやって使ってるかも動画で見えるんで
なんか結構すごい便利そうな雰囲気がしましたね
33:00
まああとはなんかFigMagicっていうなんかまあ
社内サイトみたいなのを作ってるらしくて
なんかまぁそこでもなんかこう、フォーキンスをどうやって使ってもらうかみたいな、こう手順書とかなんかこう動画とか、なんかそういうのすごい準備してるらしいですね。
なんかこういう社内サイトは結構どの会社もやってるっぽくて、まあやっぱこうシステムを作りましただけじゃなくて、まあいかにそれをどう使ってもらうかってところのオンボーディングってのはかなりこう各社気を使ってるような感じでしたね。
まあそうだよね。使ってもらわないと意味がないもんね。
特になんかこのNetflixのHawkinsの場合は、NetflixってC向け、まあ要は映画を見る一般ユーザーがいるのと、
あとスタジオ向けっていうそのB向け、映画を配給する側の人たち向けにもツールを作ってるらしくて、
おだしょー:なるほど
おだしょー:だからC向けのHawkinsとB向けのHawkins2つがあるらしいんですよね
っていうのもあるってそういうコンテンツサイトというか
啓蒙サイトというかそういう社内サイトは結構こう丁寧に作ってるみたいですね
コンポーネントに何が必要かとかをこうアンケートを社内のデザイン取ったりとか
どれが使用率高いかとか、投票制で決めたりだとか、ガバナンスというか、そういうのもちゃんと地道にやってるっぽいですね。
こういうところもやっぱ大きい会社ならではというか。
でもあれか、普通にデザイナーが勝手に何か作るっていうのもやってるのかな?
まあ 勝手に作ったりもするけど コンポーネントとしてこういう
のも入れてくれっていうのは そういうのを統括する人たちがやって
んのかな
おだしょー:やっぱりどの会社も 最初はやっぱりボランティア
ベースで プロダクト側のデザイナー プロダクトデザイナーのボランティア
ベースで作り始めていて そのうち 大きくなってくるとデザインシステム
1000人のデザイナーが入ってきて 1000人のデザイナーとかエジェニア
入ってきてその人たちがメンテナンス するみたいな感じらしいですね
だけどやっぱ各社そのプロダクト 付けのデザイナーとデザインシステム
付けのデザイナー比率はやっぱ 圧倒的にプロダクトデザイナー
が多いからいかに彼らにセルフ サービスで使ってもらえるかって
ところは重視してるみたいですね
まあっていう話の流れでいくと まさにそういう話がアトラシアン
の人からあったんですけど、リイメージニングアトラシアンデザインシステム
っていうような話があって、これアトラシアンってデザインシステム
10年ぐらい歴史があるらしいんですよ。もう作り始めてから。この人は途中から
入った人らしいんだけど、この人から見ると巨大で手に負えないほど巨大
36:02
みたいな話をしてて。アトラシアン結構いろいろサービスあるしね。
そうそうそう。まさにアトラシアンって18個製品があるらしくて、だからその18個で一つのアトラシアンブランドの一貫さを保たなきゃいけないから、
なかなかこう、そこが大変の源泉というか、
だっていうふうな話をしてましたね。 まああとさっきの比率の話で、アトラシアンの場合プロダクトデザイナーとデザインシステムデザイナーの比率が
1対42だっていう話をしてて
だからもう380人ぐらいデザイナーがいるらしいんですよね
そこに対して9人のデザインシステムのデザイナーで対応してるみたいな
デザインシステムを使うのってエンジニアもいるから
対エンジニアだと200対1まで比率が発火するみたいな話をしてて
なんかめっちゃ大変ですみたいな話をしてましたね
それでもデザインシステム、1000人のデザイナーで9人いるってのは、日本だとなかなかないことだと思うんで。
まあちょっと規模が違いすぎる感じがしますけど。
そうそうそう。だからなんかそういう比率の差があったりとか、またそういうデザインシステムの歴史も大きいんで、長いんで、
どういう苦労があったかみたいな話をこの中ではしていて
何回か失敗してきましたみたいな話をしてたんだけど
まず最初にあった失敗は2016年頃に
新しいデザインガイドラインという形で
デザイナー向けのデザインガイドラインと
エンジニア向けのコンポーネントライブラリーというのを出したらしいんですよね
で その2つって当然 1つの考えに基づいて 2つのものができてるわけなんだけど
そのうちその2つが同期しなくなって どっちが正しいんだみたいな感じで
みんな混乱し始めるみたいなことが起こったみたいな話をしてて
だからこう エンジニアのコンポネントライブラリにはこのコンポネントがあるんだけど
それがデザイナー向けのガイドラインにはないとか その逆があったりとか そういうことが
なんでだろうね
起き始めたと
で それが何でかっていうと まあ やっぱ デザインチームとエンジニアチームで
もう全然別チームとしてリリースしたっていうのが失敗だったっていう話をしてて
それはそうだよね
で やっぱそれは何でやったかっていうと やっぱりリリース直後は
最初にファーストリリースするっていう上では 独立性を進めてた方が個々のワークフローを変えずにやれるから
早かったっていう話をしてたんだけど、
でも結果リーズしてからコラボレーションはあんまりそのチーム間でしなくなってきて、
だからだんだんデザインとコードがどんどん分離していったみたいな話をしてましたね。
39:00
だからここでもさっきのシングルソースオブトゥルースの状態を作るために、
ちゃんとそこを仕組みで担保することが大事だみたいな話をしてましたね。
っていうようなシングルソースオブ ツルースの状態を作るのが大事
だってことをそこから学んだから 今度 AtlasKitっていうUIライブラリー
みたいなものを提供したっていう 話をしていて AtlasKitってやつが
いろんなコンポーネントをまとめ たコンポーネントライブラリーみたいな
ものらしくて 120個ぐらいコンポーネント があるらしいんですよ すげえ巨大
イメージできないんだけど
で ただここでの失敗は
なんかその120個以上あるそのコンポネントの責任範囲を
そのメンテするの
メンテの責任を全てデザインシステムチームが持ってるように
こう社内で認識されてしまったっていうのが
結構失敗だったっていう風に言ってて
まあさっきみたいにその圧倒的にプロダクト付けのデザイナーとよりも
よりもデザインシステムのチームの方が小さいから、
その人たちが全てにおいて責任を、そのコンポーネントライブラリに責任を持っているっていうふうにすると、
全然対応できないし、結果として事業側のスピードを落としてしまったみたいな話をしてましたね。
だから、ここからここまではプロダクトチームが責任を持って、
ここからここまでは、プロダクトよりなんだけど横断的な、
例えばモバイルとかウェブとかに責任持てる パラトフォームチームっていうのがいるらしくて
その人たちが責任を持つとか あるいは ここからここまでデザインしているチームで責任を持ちますよみたいな
その責任分担を明確にするっていうことが大事ですみたいな話をしてましたね
あとは面白いなと思ったのは コンポーネントによってもやっぱりプロダクトに依存しすぎるもの
例えばアトラシアンで言えばトライロ でしか使わないプロダクトだとか
コンポーネントだとかっていうの がどうしても出てくるからそういう
のをなるべく早く切り離したほう がデザインシステムから切り離
して事業側で面倒見てもらった ほうが良いですみたいな
まさ:それはそうだよね
りなたむ:それじゃないと絶対 スピード落としちゃうからデザイン
システムとにかく抽象的なもの として各事業体に影響されるべき
ではないみたいな話をしてましたね。
アカウンタビリティと同じくって言ってたんだけど、
責任範囲をどこで引くか、どこで境界線を引くかっていうところは、
組織のあり方とも紐づいてくる話だから、そこは結構吟味すべきだみたいな。
結構この話聞いてて、マイクロサービス、エンジニアー的な文脈で言うと、
マイクロサービス化みたいなことを やってる会社は多いけど
なんかそういう話ともやっぱり似てるな っていうふうなのを聞いてて思いましたね
マイクロサービス化が流行ってるから むやみやたらにいろんなサービスを
42:01
マイクロサービスに過ぎると 事業側がメンテするのか
横断チームがメンテするのか 不明確になったりとか
結果として事業側のスピードが落ちてしまうとか
そういう話をマイクロサービスの文脈でも 聞いたりするけど
デザインシステムでも一緒なんだなっていうのは この話を聞いてて思いましたね
特にアトラッシャンの場合みたいな いろんなサービスがあってデザインシステムを作るってなると
共通化される部分っていうのもなかなか難しいかもしれないですけど
どこまでデザインシステムに乗っ取るのか、みたいなさ、そういう、なんていうの、疑問というかさ、そういうのが生まれてきたりするのかなと思いますけど、
デザインシステムって、そういう意味では、どういう立ち位置で考えたんですかね、そのアトラシアの人たちは。
ああ、どういう立ち位置。
まあでも多分あれなのかなさっき言ってたような感じだとしたら
もうちょっとしたなんか便利ライブラリーぐらいの感じで
パーツいっぱいあるからこんなか選んで適当に使ってねぐらいの感じでしかないのかな
あーなるほどね
なんかそこはそうですねなんかこう抽象的に言ってたんであれなんです
僕の理解の話になるんだけど
最初はやっぱ単なるUIライブラリ集みたいなものをデザインシステムとして打ち出してたらしいんですよ
だからいろんなプロダクトから汎用的なパーツ集をデザインシステムでやってて
デザインシステムチームが存在してそのパーツ集をメンテしていきますみたいな位置づけでいたらしいんですよ社内に
なんだけどそれがさっきの話でそれがいつしかそのパーツ集というのはすげー被害化してきたから
全てにおいて責任を持つことがデザインシステムチームでできなくなって
だからそれをプロデュースチームだとかと分担してきましたみたいな話があると
だからある意味パーツ種っていうのはデザインシステムと呼ぶことをやめたっていうふうに言ってて
もうこのパーツ種はあくまでもパーツ種であるみたいな
じゃあデザインシステムって何なんだろうっていうと
もうちょっと包括的な、例えばデザインにどう取り組むべきかみたいな話だとか、具体例は示されてなかったんだけど、
アトラスシアンが大事にしてる価値観とかデザイン原則みたいなものを
みんなの視点をそらえるとか共通言語にするとか
新しくデザイナーが入ったときのオンボーディングに役立つようにするとか
っていうところのコンテンツをデザインシステムと呼ぶようにして
あくまでその上にアトラスキットっていうライブラリ集がありますみたいな
45:01
そういうような位置づけに整理したっていう話はしてましたね
いやなんか 割とそれ 僕は重要だなと思っていて
割と最近デザインシステムっていうと
いろんなものを指してデザインシステムって 言われているような気がしていて
いっぱいコンポーネントを集めたボタンとかが 入ってるやつをデザインシステムって言ってる人もいるし
一方でもうちょっと抽象化された
こういう価値観で作っていきましょうっていう
ガイドラインを作ったものをデザインシステムだって言ってる人もいて
まあそれどちらも間違ってはないのかもしれないですけど
やっぱりなんだろう
コンポーネント集だけだと絶対こう
なんていうの
柔軟性がないから
絶対難しいわけですよ
でそのデザインシステムの中に
やっぱりその一番根本になるその価値観だとか
哲学みたいな部分っていうのがないと 変化もしづらいというか
アップデートもしていけないっていう部分があるんで
割とその辺をまず揃えるっていうのが 重要であって
コンポーネントとかっていうのは どっちかっていうと
僕はあんまりデザインシステムっていうよりは
ライブラリとかなんちゃらキットみたいなもの っていうぐらいの感じにしておいたほうが
いいんじゃないかなっていう 新しい案がやってるようなやり方が
割としっくりくるなっていう感じはしますね
まさに、デザインシステムとは何なのかっていう、線引きをどこに置くかっていうのは、
やっぱアトラシアンジュニアの歴史があるだけあって、かなりそこに苦労してやってたっていうような話でしたね。
なんかそういう意味でも最近さ、やりといろいろ各社、日本でもデザインシステム的なものを作ってる会社さんっていっぱいありますけど、
ちゃんとそういう、どういう価値観で作っているのかっていうか
そういうのを大事にしているところっていうのは結構好感を持てるなっていう
皆さん、僕がクックパッドにいた頃最後の方にやってたのが
シトラスってデザインシステムを作ったんだけど、くらみつさんっていうデザイナーと一緒に
でその時ってやっぱCookpadって昔からあの池田さんとか本山さんも作ってたサラっていう
どっちかというとパーツ種に近いものがすでにあったから
だからそのStrustってものを立ち上げた時はどっちかというとデザインシステムなんだけど
といってそのパーツ種を作るってよりは
そのすでにあるそれがあるからその使い方だとかもっと抽象的なデザイン原則みたいなところとか
あとはCI/VIみたいなところ パーソナリティとかみたいなところを中心としたものをStrustと呼んで作ってた感じでしたね
最近だとFreeとかも確かデザインシステムを作ったりとか あとAveMaもSpindleというやつ作ったりしてますけど
48:12
なんかアブユマとかも結構そういうどういうところが重要なのかっていう価値観というか
哲学みたいなものっていうのを割と明確にして
で、さらにその上にそれをどういうふうに表現したら
それが統一的に同じようなものが作れるのかっていう部分を結構細かく設計してるんですよね
ボタンとかの前の話っていうか
ボタンになる前のその哲学をどういうふうに表現したら
落とし込めるのかっていう部分も割と言語化されてて
そういう意味で結構このアメバナとかが作ってるというか考えてるものっていうのは割と先を言ってるというか
なんかすごいなっていうふうに思う部分があったんですよね
やっぱココナのレイダーとアベマノスピンドルとフリーのデザインシステムはやっぱこう
よくできてるなっていうふうに思いましたね最近見てて
だから結構このデザインシステムが指すものが何なのかっていう話で言うと
結構やっぱ話の中心このスキーマのカンファレンスの話の中心は
やっぱこうUIライブラリをどう作るかっていう話よりは
そのデザインシステムという
ああそうだな
そのUIライブラリというよりは
UIライブラリを中心としたシステム全体をどう使ってもらうかとか
あとはこうデザイン新しく入ってきたデザイナーをどうオンボーディングするかとか
あとはどうデザインシステムにコントリビュートしてもらうかとかサポートしていくかとかっていう組織的な話が結構中心で
それらを具体として、例えば社内サイトを作りましたとかツールを作りましたとかそういうのがあるんだけど
そういうものを総合してデザインシステムと呼んでるっていうような感じの話が多かったですね
いやなんかやっと、やっとそういう話になってきたなっていう感じがしますね。
だいぶ前にもなんかそういう話してた気がしますけど、デザインシステムを作ったっていう話じゃなくて、
なんだろう、それをどう社内に浸透させて使ってもらえるようにしてたとか、
そのアップデートをどういう風にしていくのかとかっていうのを考えるみたいな、
そういう話に今後なってくるんじゃないかって話してましたけど、
話してましたけどまあなんか海外 ではそういう感じっていう印象
はしますね
うんなんか正直このスキーマの 話を聞いててもなんか日本の最近
のDNSを作りましたみたいな話と はだいぶこう1週も2週も先を行
ってるなっていうような感じの ものは受けましたねまあもちろん
にそのね出てくる会社がアトラシアン とかヘンソルキスとかだから
こう規模の差はもちろんあるんだ けど
はいはい
ちょっと時間もあれなんでサクサク行くと
あとはLiftがユーザーセンターデザインシステムリソースっていうような話をしていて
51:02
これもLiftもLPLっていうLiftプロダクトランゲージっていうデザインシステムがあるらしいんですけど
それをいかにこう
これも本当オンボーディングとかドキュメンテーションとかの話が中心なんですけど
いかにシャナーで広めていくかみたいな話をしてましたね
なんか面白かったのは
そのホームボーディングサイトみたいなのをやっぱ作ってて社内で
でその中にデザインラボっていうような
エンジニアリングラボっていうようなコンテンツがあるらしくて
デザインラボの方はお題があって
まずペーパープロタイプのUI
手書きしたUIがあってそれをFigmaのデザインに落とし込んでいく上で
いかにデザインシステムをどう使うかみたいな手順書みたいなのが書いてあったりするらしいんですよ
だからそれを読めばデザインシステムを使いながら
手書きのデザインをFigmaのデザインに落として込んでくる上で
このデザインシステムをどう使えばいいかっていうのがすぐわかるようにデザイナー向けにしてたりだとか
あと逆にEngineering Labって方ではデザインシステムLPLを実際実装するときにどう使うかみたいのを
実際のケースを見せながら話してたっていう
そういう事例集みたいなのを作ってたっていう
エンジニア向けにもそういうのをちゃんと作ってるのは
なんかあれですね いいですね
もう各社当たり前のように
やっぱりエンジニア向けっていうのはやってますね
うんうんうんうん
まあなんかすごい
思い出しますね
なんかSALAとかを作ってた
SALAはCSSフレームワークくらいのものですけど
CSS フレームワークのあの皿も一応ね、なんかそういう、こういう感じで使うんだよみたいなのを、なんかサンプルページみたいな、なんかデモ画面みたいなの作ったりとかしてましたけど。
うん。だからやっぱ話してる人も、こうデザイナーだけというより、やっぱソフトエンジニアも結構登壇してたりするし、
あとはUXエンジニア的な人も結構登壇してて、
だからやっぱこうデザインシステムを作る上では、
デザイン的な思考も大事だし、エンジニアリング的な考え方も大事だし、
だからそういうハイブリッドの人には向いてますみたいな話を、
あとはラシアンの人もしてましたね。
そういう人がなかなか市場にいないから採用も大変だっていう話もあると思うんですけど。
あとはリフト、リフトはやっぱりエンジニアとの協業をいかにするかってところは重視してて、
リフトはね、結構なんか、話、僕が聞いてて受けた感想としては結構こう、なんだろうな、原理主義じゃないけど、なんか結構ルールに厳格だなっていうような印象が受けて、
例えば言ってたのがデザイナーがFigma上でデザインシステムから逸脱して一貫性を崩すと
54:05
その付け合いをエンジニアが追うことになって
結果としてデザイナーとエンジニアの信頼関係が崩れるみたいな話をしてて
結構それは極論だなとは思うんだけど
でもそういう面ってあると思うんですよ
あれこれなんか逸脱してんじゃんみたいなのをエンジニアが刺して
空気を読んで実装していくみたいなことってよくあるじゃないですか
だからそれはさっきの冒頭の桑本さんの話じゃないけど
逸脱も大事だと僕は思ってるんだけど
だからLiftがやってるのはLintツールっていうのを作ってるって話をしてて
デザイン用のLintツールかな
そうそうFigma用のLintツール
リフトプラグインを作ってるっていう 話を聞きましたね
おだしょー:ありますね そういうの
ここの例えば色がデザイン システムに定義されてないですよ
っていう警告をデザイナーに出す とか そういうのを作ってるみたい
ですね
おだしょー:そういうのあると 便利ですよね 確かFigmaのプラグイン
でもそういうのあった気がします けど リフトツール的なの確か
あとリフトだけじゃないん だけど わかりやすい話として上がる
この中ダークモードに対応するって話は
結構デザインシステムの用途として分かりやすいから
各社いろいろ話をしてて
Liftもやっぱプロジェクトの性質上ドライバーが使うものだから
結構夜間のドライバーが使う上で
ダークモードが結構大事だって話をしてて
それでなんかライトモードとダークモードの切り替えを
ワンタッチでできるようなプラグインを作って
QAをなるべく早くできるようにするみたいな話をしたり
それをやることによってデザイナーがみんなデザインシステムに定義されているカラーを使うように誘導できるからそういう効果もあるんだみたいな話をしてましたね
あと面白かったのがサポートの話をしててデザインシステムチームがデザインシステムを使う上でのサポート社内のデザイナー向けにするって話を各社してるんだけど
リフトの場合は24時間で東海岸でも西海岸でも数時間以内対応できるような体制を組んでるみたいな話をしてましたね。
んー
んー
とか、あの、あと、オフィスアワーを設けてデザインシステムチームに好きな、あの、いろいろ対面で相談できる時間を作るとか、
なんか、日常的に3分の1の時間はサポート対応に時間を当ててるとか話してましたね。
すごい、大変そう。
ここまでいくと本当 ジョーシスチームじゃないけど なんかそういうような感じですよね
そうですね
まあでもなんかこういう世界線の話なんだなっていうふうな
57:04
まあそうだよね インフラ的なものですよね 開発の
開発基盤って昔クックパッドでも今もあるのか分からない そういう部署ありましたけど
やっぱりそういう立ち位置だなって思いますね
僕らがCookpadにいた時も
一応授業部付けのデザイナーっていうのは基本的にはあまりいなくて
デザイナー部みたいな
そういう部署でやってたんだけど
それの位置付けとしてやっぱり
社内全体のデザインに対する底上げをするっていう
指名があってやってた部分が一つあったので
そういうのでデザインシステムを作ったりとか そういうのもやったり
結構いろいろ啓蒙活動的なことを いろいろやってたところもあったんですけど
そういうところですよね デザインシステムが担う部分っていう
やっぱ基盤チームだからこそ さっきの新しい話で
どこまでがプロダクトチームが責任を持て どこまでが基盤チームが責任を持ったのかみたいな
責任分担の話も大事になってくる し
まあ基盤チームがどうしてもプロダクト チーム事業チームに比べるとニーズ
が少ないからいかにこう事業側 に
セルフサービスでデザインシステム を使ってもらえるようにする仕組み
を用意するかだとかまたサポート をいかにするか
事業側にもデザインシステムにコミット してもらえるように
そのコントリビューションガイドみたいのを用意して
気軽に参加してもらえるようにするかみたいなところは
結構各社気を使ってる感じでしたね
なんかちょっとあんま関係ないかもしれないですけど
クックパッドとかはさ、結構別にタブ書のやつでも
コミットしてOKみたいな感じの雰囲気だったじゃないですか
文化としてなんか変だなと思ったら
それを承認するっていうか、レビューしてマージするかどうかっていうのは、その部署の人がちゃんと決めるわけだけど
でもそれをしてOKだし、みんな割とそういうのを気づいたらやったりするっていうような雰囲気というか文化があったから
あれは非常に良かったなと思いますよね
そうですね
やっぱりデザインシステムとかも作って あの人が作ってるから自分は関係ないみたいな感じになっちゃってると
なかなかメンテも大変になってきたりとか チグハグになってるっていうか
使う側と運用する側とチグハグになっちゃう部分っていうのは たぶんいっぱい出てくると思うんですよ
これ欲しいんだけど対応してもらえないからみたいな感じで 結局独自のもの作ってたりとか
なんかやっぱその辺のこう多分これぐらいの規模になるけど
その辺をどう馴染ませていくかみたいな
そういう感じの話になっていくんでしょうね
1:00:00
そうですね
まあ多分どの会社も最初はそういう文化的なものに
こうサポートされながら
みんなが善意でこう作り上げるみたいな感じだったんだろうけど
それをいかにこうプロダクトがスケールしていく中で
ニーズが増えていく中で
ちゃんとこう根付かせるかみたいなところで
みんなドキュメントサイトを作ったりとかしてる
っていう印象でしたね
ちょっとあと最後にしとくんですけど、
あとはAsanaっていう、
あの、to-do listのサービスの話が、
デザイントークンをどう扱うかっていうテーマで話してて、
これも面白かったんだけど、
そうですね、デザイントークン、
ここでデザイントークンってのは、
まあ、主に色の名前とかが、いや、色とかがそうなんだけど、
それだけじゃなくて、コンボテの名前とか、
名名規則的なものをどう作るかみたいな話をしてましたね。
どういう名名規則でやるべきなのかっていうのを、結構具体的に話してたんで、
詳しくは見てもらえるとかなり参考になるかなと思うんですけど、
基本的には、例えば色名だったら赤色、レッドってするよりは、Danger Hover Redみたいな感じで、
なんかこう、これはホバーの色で、かつ危険なものだからまつ変わらないってことを、
っていうような意図を、ちゃんと名前から伝わるようにした方がいいっていうような話をしていて、
じゃあそれを具体的にどうやるの?っていうと、
なんかね、4つぐらいの構成があって
センチメント、ユーセッジ、プロミネス、インタラクション
まあなんか、1つ目の要素が
なんかこれは、成功を表すものですよとか
ワーニングを表すものですよとか
危険なものですよとか
まあそういうなんだろう
ユーザーの感情的なものを
まあ表す名前をまずボードにつけろと
で2番目に用途これはバックグラウンドだとかテキストだとかアイコーナーとかボーダーだとか
まあUIとしては用途の名前をつける
で3つ目にストロングとかメディアムとか
まあなんかこう視覚的にこう強調するものかそうじゃないものかみたいな
そう視覚的な情報をつける
で最後にインタラクションホバーとかアクションとかディスエーベルとか
で、例えばSelect Text Hoverみたいな感じの名前にするのが大事だみたいな話をしてましたね。
こうすることでデザインを離れてコードベースになったとしても、例えばCS上でカラーの変数名になったときに、
このカラーがどこでどう使われてるかっていうのがすぐわかるから、この命名っていうのはすごい大事だみたいな、
さっきのシングルオブトゥルスの状態を作るためにデザインとエンジニアリングで一緒なものを見るために大事だから、そういう命名規則を考えた、考えた、みたいな話をしてましたね。
1:03:09
こういうのね、色もそうだし、アイコンの名前とかもね、さっきちょっと話がありましたけど、なかなかどうするのかって難しいですよね。
っていうのもなんだろう同じ赤だけどまあ赤危険な部分に使っている赤もあるかもしれないしすごく 強調したい部分として使っている赤かもあるかもしれないっていうでも同じ色の赤
ということがあったりして まあそれを重複して定義するのか
まあ本当にFigmaで変数的に色をオーバーライドして定義することができたら 僕が一番いいなってふうに思ってるんですけど
言ってることわかります?
赤っていうのを定義して、その赤っていうのをベースに
デンジャーな、デストロイドなボタンを使ってる
色ですよっていうのと定義して
もう一個別に、ちょっと強調するバッジの赤っていうのを
同じ赤色を参照するみたいな
そういうことができると本当は僕は一番いいなと思ってるんですけど
なかなかそれは実装してもらえなくて
じゃあちょっとそれに関連してもう一個話そうかな
じゃあなんかねまさにね
あの最後にGoogleがMaterial You & Figmaっていうような話をしてたんですよ
でMaterial YouってGoogle I/Oで
前回のGoogle I/Oで発表されたやつ
壁紙の色とかから動的に1個テーマカラーを決めて
そのカラーを、一つのカラーをベースにアルゴリズムでカラーパレット、複数色のカラーパレットを作るみたいなものなんですけど
つまり、それをデザインの観点で見ると、エンジニアの観点で見ると、色をハードコードできない世界になっていくわけですよね
もうなんか OS 側で色ってのが決まってくるから
こうプロダクト内コード内でこの色はここではこの色を使うってハードコードができない世界になってくると
そうだね
でFigma上でもそれは同様でやっぱこう元となる色が変わるから
こうFigma上でデザインしてる時にも色を変えられるようにしなきゃいけない
色のハードコードがFigma上でもできなくなるから、それをサポートするためのプラグイン、
Material Thema Builderっていうプラグインを作ったっていう話をしていて、
それはどういうものかっていうと、Figmaプラグインなんですけど、任意の画像を選択すると、
この画像の中からこの色を使うっていうふうに選択すると
もうそのプラグイン上でMaterialUと同じようにパレットを作ってくれて
1:06:04
それをFigmaに適用してくれるみたいな感じのものですね
だから自分でデザインを作ってそのプラグインを使うと
その、Material View の元となる画像を、
まあ、に、いろいろ複数選択すると、ポチポチ自分のデザインの色を切り替えられる。
自動で切り替えられるみたいな、まあ、ツールで。
で、それをやるためには、Figma 上でもカラーコード、ハードコードできないっていうことになってくるから、
なんかね、さっきももちゃまさんがちょうど言ってたものなんだけど、
色の扱いを3つのレイヤーに分けるって話をしてて
Values, Palette, System っていう3つ
で、Values ってのはまあレッドみたいなとか
まあ#0000みたいなそのいわゆる普通のカラーコードがValuesで
で、Palette っていうのは、命名的にはなんだろうな
なんかこう、えー
あれかな?色の名前、本当に色の名前的なものなのかな?
あのまあ、えっとアンドロイドのマテリアルデザインの場合は、色と番号みたいなそういうのがありますけど
そう、色の番号ですね。なんかそう、こう
えっとね、MaterialUの場合はパレットに14色だったかな?を定義するらしいんですよ
だから基本的には、その壁紙の色からその14色の色をアルゴリズムで勝手に決めてくれるっていうような実装らしいですよね
だからその14色をパレットっていうふうに定義して
で今度3層目のシステムっていうレイヤーではそのパレットの例えば1番の色をプライマリーカラーに使いますとか
2番の色をコンテナの色に使いますみたいなその用途をそこで定義するみたいな
だから色の定義と用途の定義を分けるみたいな感じですね
だからさっきももさんが言ってたレッドって定義してこれをデンジャーにしますみたいな
のやつをFigma上でできるようにプラグインを作りましたみたいな
ことを言ってました
きっと多分あれなんでしょうね
Figma上では色の定義はプライマリーカラーだとかセカンダリーカラーみたいなものっていうのを一応定義しておいて
それをプラグインで切り替えていくみたいな感じにしてるんだろうね
そうそうそう
でもあとはMaterialUってアクセシビリティそのコントラストの差とか
そういった色のアクセシビリティーも 担保した上でアルゴリズムで決定するから
そういうアクセシビリティーの状況も プラグインで見えるようにしてます
みたいな話をしてましたね
だから結構みんなやっぱりFigmaが どうしてもまだデザインシステムに
機能的に追いつけてない部分を運用でカバーしたり プラグインでカバーしたり
みたいなことをしてますみたいな 結構泥臭い話をみんなしてましたね
みんなしてましたね
まあそうだよね いや 中でも結構 みんなこう 異論について悩ましているんだ
1:09:03
っていうのが分かって 早くFigmaが対応してくれないかな
って思いましたね これで これを見てまた
全体的ね そうそう 異論の話も命名規則の話も
やっぱまだまだツール側のサポート が足りてない部分だと思うんですよね
そうだよね いや アイコンとかもな
なんかさ、アイコンも結構色々議論する部分があって、実は明々規則で。
そのさっき言ったように、検索性を求めて、同じハートマークなんだけど、
Likeでもいけるし、いいねでもいけるみたいなふうにするっていう考え方もあるんだけど、
また別で、これはハートなんだけど、Likeで使ってるものだから、
Likeとしてしか使っちゃいけないみたいなのもあるじゃないですか、ここに。
他のとこで同じように使う、なんかちょっと別のものとして使っちゃダメだよっていう意味を込めて、
ライクのアイコンですっていう ふうに定義してることもあって
結構その辺もいろいろ議論がある ところなんですよね
そういうのはやっぱりみんな知って ましたね
なんかそこはメタデータで ここで 扱わないくださいみたいなの
書くべきだみたいな話をしてる 人がいたりとか
みんなそういう運用でみんなカバー してるから
本当はねなんかこうレイルスじゃない けど
そういうのも全部フレームワーク側で担保できるような中、
デザインシステムフレームワークみたいのが今後作られるといいのかもしれないですけどね。
なるほど。
っていうのが、残りのセッションはアフタートークに回すとして、
面白かったのはそんな感じですね。
なので、総じてデザインシステム、コンポーネントをいかに作るかっていう話よりは、
それを作った上で社内にいかに浸透させるかとか、メンテナンスするかみたいな、
あとはエンジニアとかとコラボレーションをいかにするか、みたいな話が中心でしたね。
これからやっぱりデザインシステムそのものの話というよりは、コラボレーションの話っていうところに多分移っていくんでしょうね。
私はここまでやるとしたらやっぱりデザインシステムの 専属の人がいないとそれはできないよなというふうな。
そうですね。なかなか難しそうだな。
だからやっぱりエンジニアチームにおける基盤チームみたいなものが
やっぱりチームみたいなものが各社持つみたいな状況が、もしかしたら数年後日本でも当たり前になるのかもしれないですね。
なるほど。
っていうのがよくわかった、カンファレンスで。なかなか日本の情報だけ見てるだけだとなかなかなかった話が多かったんで、面白かったですね。
これセッション何個ぐらいあるんでしたっけ
1:12:01
8個かな
あ、そんなに1個どれぐらいの長さがあるんですか
1個30分40分ぐらいですね
まあまあまあじゃあそれなりのボリュームあるんだな
ある
まあでも4時間ぐらい半日ぐらいあれば全然見れる
そうですね
あとなんか僕youtubeの翻訳で見てたんですけど字幕の翻訳
これ結構普通に使える全然意味わかるなっていう感じだったんで
全然自動翻訳なんですけどそれでも意味が全然わかったんで見てみるのおすすめですね
じゃあちょっと空き時間だとか休みの日だとかに見てみるyoutubeで見てみるのもいいのかなって感じですかね
多分ちょっとURLとかは小ノートとかの方に書いておくかなと思うので
今回僕が話しながらメモったやつがあるんでそれをそのまま小ノートに貼っとこうかなと思ってます
概要に
皆さんも良かったら見てみてください
はい、じゃあそんな感じですかね
はい
リサイズHMへのご質問やご感想、リクエストなどは
#リサイズHMでTwitterにつぶやくか
ショーノートにあるお便りのリンクから送っていただければ
配信内で取り上げたりしますので
どしどしいただければと思います
リサイズHMは毎週金曜日に配信しています
Spotify、iTunesのPodcast、Google Podcast、YouTubeなどで配信していますので
良かったらチェックしてみてください
ということで今回はここまでまた次回お会いしましょうさよならさよなら
(エンディング)
