00:17
Takaya Deguchi
こんにちは、Deguchiです。
kudakurage
こんにちは、Motoyamaです。resizefmは、MotoyamaとDeguchiが最近気になっているサービスやデザインティフィックスを取り上げて、のんびり話すポッドキャストです。よろしくお願いします。
Takaya Deguchi
お願いします。
kudakurage
3月、ちょっと前の話だけですけど、まあでも大した話じゃなくて別にないんだけど。
3月に、3月結構なんかいろいろやることが多くて、まあね、年度末。年度末だからっていうわけでもない。
まあ個人だったらね、確定申告とかもいろいろあったし、みたいなとか。
まあいろいろ、まあ結構いろいろ忙しかった。忙しいなあみたいな感じだったんですよね、3月。
だからちょっと、1年前とかだったら、ザラシの動画を見たりとかしてたんですけど、そのザラシの赤ちゃんの動画を見て、こう癒されたりとかしてたんですけど。
金田智子さんって知ってる?
Takaya Deguchi
いや、わかんないです。
あ、金田智子さん知らないか。
kudakurage
何の人?
Takaya Deguchi
いやまあ、めちゃくちゃ有名ってわけでもないから、声優さんなんですけど、金田智子さんって。
で、まあ一時期、まあ今もかもしれないですけど、テレビとかにもよく出てた人で、なんかこうすごい声の高い声の人みたいな。
kudakurage
だからなんかすごい、まあアニメ語言っちゃアニメ語に、アニメ声みたいな感じですよね、なんか。
Takaya Deguchi
もうアニメ声って言っても、もうなんか、そのなんていうの、人の声じゃないみたいな、もう大体やってるのがあって、みたいな。
kudakurage
なんかのキャラクターとか多いんじゃないかな、多分。僕もあんまりよく知らないですけど。
Takaya Deguchi
まあその金田智子さんっていう人が、まあその声優でいるんですけど。
まあそのね、金田智子さんの、なんか動画、まあ昔出てた動画とかが、まあYouTubeに上がってたりして、それを見るのがめちゃくちゃ癒されたっていう話をしたかったんですよ。
kudakurage
いや、まあすごい、まあすごい声高いっていう人、まあすごいそういう特徴の人、じゃあその特徴の人なんですけど。
なんかね、めちゃくちゃ明るいんですよ、そんな。めちゃくちゃ、もう底抜けて明るいみたいな、なんか。
で、まあなんかね、動画は、なんか昔ファミ通TVっていう、なんかそのファミ通ってあるじゃないですか、雑誌が。
Takaya Deguchi
あの、まあ今もあるのかなファミ通って。さすがにないのかな、さすがに。ゲーム雑誌。
ないですか。
kudakurage
ちょっと今売ってるファミ通がまだ存在してるのかどうかって、僕知らないんだけど。
03:00
kudakurage
ファミ通、まあファミ通がやって、その多分ウェブサイトとかで配信してた、まあその頃YouTubeとか多分ないから。
やってた、そのファミ通TVっていうやつがあって、まあそれの、まあなんかMCとして、まあ神谷さんってもう一人別のね、あの男性の、まあその神谷さんも有名な声優の方ですけど。
と一緒にこう、そのファミ通TVってMCをやってたっていう動画が、なんか結構残ってるんですよ。まあYouTubeで検索したら多分出てくるやつとして。
いやもうなんかね、それ見るのがもう、毎日すごい楽しみでしょうがなくて。
Takaya Deguchi
そう。
kudakurage
いやなんかもうすっ、意味を、意味わかんないぐらい明るいわけですよもう、そんなのか。
ちょっとしたことで、もう。
Takaya Deguchi
それは何の動画なんですか?
kudakurage
まあ、そんなファミ通TVのMCだから、もうでも大した、正直ファミ通TV自体は、なんていうの、そのゲームを紹介するとか、まあそういう番組なわけですよ。まあゲーム雑誌のやってるところだからね。
でもその動画、YouTubeで見た動画自体は、そのゲームを紹介してる部分は一切ないんですよ。まあ一切ないっていうのは、まあその部分を省いてるんですよ全部。
でその、ファミ通TV始まりましたーみたいな、ちょっと最初の前説みたいな、なんかその前説というか、なんかちょっと、ちょっとしたオープニングトークみたいな。
のところだけをこう切り取って、まあ繋げてあるやつだった気がしたけど。
まあだから普通だったら、まあ進行通り行ったら、まあちょっとなんとなくその、春ですねーみたいなこと言って、じゃあこのコーナー、次のコーナー行きましょうみたいな感じで、もうゲームを紹介するコーナーに行くみたいな感じなんだけど。
その部分だけしかないんだけど、その部分がもうなんか、全くこう、進行通りいかないっていうか、その。
その、金田さんがぶっ飛びすぎてで。 今度はね、すっごい面白くてそれが。
Takaya Deguchi
そういうキャラの人なのね。 うーん、まあそういう、まあちょっと天然っぽいっちゃ天然っぽいんですけど、だから。
kudakurage
でもなんか本当に大したことないことで、自分で言って笑ってるとか。 へぇー。
Takaya Deguchi
なんかめちゃくちゃほんともう太陽みたいに明るい人で、もうなんか3月それにすごい救われたっていう。
全然わかんないな、その人。 見たことあるな。
kudakurage
金田さん、たぶん見れば、「あ、この人ね。」って思うと思うけどね。 なんとなく、「あ、この声の人ね。」とか。
またその別に僕も金田さんが出てるアニメを見たことあるかって言われたら、たぶんない気がする。
まあもしかしたらあるのかもしれないけど、なんかで実は見てたとかあるのかもしれないけど。
たぶんないと思うけど、まあなんかテレビによく一時期ね、バラエティーとかはよく出たりとかしてたことあって。
06:06
kudakurage
まあ最近はそこまでなんか出てることないと思いますけど。 へぇー。
Takaya Deguchi
まあ最近ちょっと僕もテレビ見てないからわかんないけど。 うん。
kudakurage
まあ最近たぶんアベマTVとか、アベマTVなんかね、声優の番組やったりとかしてるからね。
うーん。 なんかそういうのに出てるとか。
まあ最近ちょっと出てるかわかんないけど、ちょっと前も出てた気がすると思いますけどね。
うーん。 なのでね、ちょっとね元気がなくなったときにね、見てほしいっすね。
かねだともこ。かねだともこってYouTubeで検索したら絶対出てくるから。
Takaya Deguchi
へぇー。 うん。ファミ通TVのやつ。
それはみんな癒し目的で見てるもんなんですか?他の人も。
kudakurage
いや、意外と癒し目的で見てんじゃないかなと僕思ってますけどね。
へぇー。 なんかそれぐらいなんかもう、
うーん、なんだろうね、めちゃくちゃこう明るい気持ちにさす、なんか無理やり明るい気持ちにさせられるんですよ。
Takaya Deguchi
ああ、そっち系ね。
kudakurage
一応URLだけ貼ったわ。まあたぶんこれ、これだけじゃなくてね、いくつかあるんですけど。
そのファミ通TVってやつのオープニングトーク集みたいな。
Takaya Deguchi
ああ、思った以上に声高かった。
kudakurage
そう、だからすごい特徴ある声でしょ、だから。
たぶんね、この頃はまだそこまでバラエティー、地上波とかあんま出てない頃だと思うんですけど、そのファミ通TV出た頃って、結構まだ若い頃。
Takaya Deguchi
で、たぶんもうちょっとしたぐらいに、たぶん結構バラエティーに、こいつなんか面白いなみたいな感じで、たぶんみんな使い始めたみたいな感じで。
ちょっと今、5秒ぐらい見た中ですけど、なんとなくわかってきた。
いやもうマジで癒されましたね、これは。
僕は逆に、最近インパルスイタクラの一人キャンプ、キャンプ?一人ハイエース旅みたいな動画をそういう時に見てますね。
基本なんかハイエースに乗って、なんかいろんなキャンプ場行って、まあ車中泊か、車中泊動画かをしてるだけなんですけど、
それがね、なんか癒されるんですよ。なんか別に面白いことも何もないんですけど、
基本一人でプツプツ喋りながら、なんかまあキャンプしたり料理したりしてるだけなんですけど、
なんかコメント欄とか見ると、たぶんだけど女性なのかな?っぽい人たちがめっちゃなんか癒されましたって書いてて、
なぜかなんかそういう人たちに人気なのか。それが結構、淡々としてて癒されるっていう、その明るさっていうよりは。
kudakurage
はいはいはいはい。まあまあね、そういうのもね、あるけどね。
Takaya Deguchi
Vlogっぽいやつ。最近はそれ見てんな。その忙しい時期は終わったんですか?
kudakurage
忙しい時期、まあまあまあそうね、3月がやっぱりちょっといろいろとやることがバタバタ多かったんで、
09:03
kudakurage
まあある程度落ち着いたっちゃ落ち着いたかな。いっぱいパンパンなのにやることがまだあるみたいな感じが3月だったから、今はパンパンって感じ。
Takaya Deguchi
まあ今もパンパンなんだ。ちょっとまあフィグマの話しようかなと思うんですけど。
kudakurage
はい。
Takaya Deguchi
なんか最近フレームワークってイベントがあったんですよ、フィグマの。
kudakurage
うん。
Takaya Deguchi
で、超久々にリアルで参加したんですけど、そういうイベント。まあちょっとなんかその話しようかなと思って。
で、フレームワークっていうのが、なんかまあ去年はスキーマってイベントあったのを覚えてます?
kudakurage
うん。
Takaya Deguchi
なんか多分Podcastでも話したと思うんだけど、デザインシステムをテーマにしたカンファレンス。
来月やるConfigってやつはもうちょっとなんか、フィグマに直接そんなに関係ないデザインの話とかも出てきたりとか、割とかなり広めの話だけど。
このスキーマとかフレームワーク、今年のフレームワークってやつはデザインシステムに特化した、なんか話題のイベント。
で、去年よりはちょっと小規模だったのかな?多分。
で、東京とロンドンだけなんか世界の中でリアルで開催してるっていう感じで、基本はなんかビデオ撮ってそれを流す非同期開催というか、バーチャル開催みたいな感じらしいんですけど。
kudakurage
うん。
Takaya Deguchi
っていうイベントで、東京はなんかそれなりの会場、大きめの会場で結構人いましたね。
なんか変プラ、多分だけど、フォーム書いて申込みするんですよ。
で、それで多分抽選で一体選ばれてると思うんですけど、なんかちょっと普段より年齢層が高めな雰囲気がしたというか、
なんかエンタープライズ系の営業の場なのか、なんかそういう変プラ系の会社の人が多いのかな?みたいな、なんかそういうような雰囲気だったんですけど。
そこで発表されたというか、そのフレームワークのアメリカの方でのイベントの時に出たのがいくつか機能があって、
それについての話が最初にVP of Productの桑本さんからあったんですけど、
なんかタイポグラフィバリアブルスとか、あとはグラディエントバリアブルスとか、コードコネクトとか、なんかあの辺の話ですね。
あとあれか、Library Analytics APIっていう、大きくその4つの発表があって、
それについてのどうやって使っていったらいいのか?みたいな、なんかそういうセッションが中心だったんですけど。
なんか桑本さんが言ってたのは、やっぱりデザインシステムをただ作るっていうところから、結構運用をどうするか?みたいなところにフォーカスが移ってきているみたいな話があって、
12:04
Takaya Deguchi
結構去年のスキーマとか見てても、大きめのテク系の会社がそういう運用の話みたいのをしてたと思うんだけど、
それを運用した上での機能予防みたいなのをFigmaが取り入れて出していった機能ですみたいな、そういうニュアンスのことを言ってましたね。
で、タイポグラフィバリアブルスっていうのが一番の目玉の機能というかアップデートだったんですけど、
あとはコードコネクト、その2つかな。コードコネクトは完全新規の話で、タイポグラフィバリアブルスはバリアブルスっていう前からある機能の目玉のアップデートみたいなやつですね。
デザインシステムは最近ちょっと僕も仕事でちょっと作ってる。それは詳しくはそのうち外部に公開するときに話せるようになるかなと思うんですけど、
デザインシステムを作る仕事をちょっとやってて、でもやっぱりやってるとタイポグラフィのバリアブルス対応っていうのは本当に待望というか、待望というかこれなかったらできなくないみたいな気持ちになるんですよ。
で、やっぱバリアブルスは便利な機能ではある。何が便利かって簡単に言うとコンテキストによって参照先を勝手に変えられるっていうところが便利。
だからわかりやすく言えばカラーで言えばダークモードとライトモードでコンテキストが変わったときにカラーを参照しているカラーの値を変更できるっていうところがやっぱ大きい用途だと思うんですけど、
それと並んでやっぱタイポグラフィってそのコンテキストによる変化が大きいと思うんですよ。例えばレスポンシブデザインで
スマートフォンの画面幅になったときの基準となるフォントサイズが14ピクセルだとして、それをデスクトップに持って行ったときのコンテキストがデスクトップに変わったときに基準のフォントサイズが16ピクセルになるみたいな。
なんかその基準は変わるから、その基準に応じてタイトルのフォントサイズもボディーのサイズもラベルのフォントサイズも変わっていくみたいなことになると思うんですけど、
これまでの場合、デザインシステム側の視点に立ってそれを捉えると、テキストスタイル、例えばPCとタブレットとモバイルで3パターンテキストスタイルがあって、それを使ったコンポーネントをボタンコンポーネントみたいなものだったら3パターン用意して、
でもボタンの中でもUIのステートというか、ディセーブルとかフォーカスとかイネーブルとか色々あると思うんですけど、だからN×Mのパターンを作らなきゃいけないわけですよね。
15:12
Takaya Deguchi
だからこれまでの場合テキストスタイルを3つ、画面幅に応じて3つ作るみたいな、2つとか3つ作るみたいな感じになっていたので、どうしてもそれを包含するコンポーネントをその分作らなきゃいけないみたいな感じになって、
バリアンスっていう機能がFigmaあると思うので、基本的にはそれを使ってバリエーションを表現するんですけど、
ボタンとか特にアトミックデザインでいうアトム相当のコンポーネントの場合、そのバリエーションがめっちゃ増えるみたいな問題があると思うんですよね。
これまでの場合それがバリアブルズになってなかったので、そういう感じだったんですけど、それがバリアブルズ今回対応したことによって、
理想的にはコンポーネントを1つにギュッとまとめられるっていうところ、ボタンのコンポーネントだったら画面幅のコンポーネントっていうのは別に分けなくて、
それはバリアブルズ上のモードとして表現して、バリアブルズはあくまでUIのステートのバリアブルズだけを用意すれば良いっていうことになるので、
ギュッとバリアブルズのバリエーションの幅を狭めることができるっていうのがやっぱり一番大きいと思うんですよね。
やっぱりデザインシステム作ってるとバリアブル、コンポーネントのバリエーションがめっちゃ増える、めっちゃ増えるとやっぱりその分だけメンテナンスのコストが上がる。
例えば1個プロパティが増えたとしたら、それを全部そのバリエーション分反映しなきゃいけないとかしなきゃいけないのがやっぱりめちゃくちゃ大変なので、
そのバリエーションをいかに減らせるかっていうのはすごく大事だと思うので、だからこのタイプグラフィー対応っていうのがデザインシステムの作り手としてはすごい待ち望んでたっていうような感じがします。
なかなかやっぱりここがデザインシステムを作ってる側の目線なのか、プロダクトのデザインしてる側の目線なのかによってだいぶ嬉しさが変わるかなとは思うんですけど、
デザインシステムを作る仕事をしているとかなり待望の機能だったみたいな感じですね。
kudakurage
なんかでも最近あれですよね、もちろんそれができた方が良いっていうのはその通りだと僕も思うんですけど、
複数選択して一緒に同じところを編集していくみたいな機能も確か最近入ってるよね。だからある程度バリエーション作って、
いっぱいあったのを一個ずつ変えなきゃいけないみたいなのもちょっと軽減されるような変更部とかも入ってたような気がするよね。
Takaya Deguchi
そうですね。あれもすごい良いアップデートでしたね。似たパターンのものをコンポーネント化してなくてもマルチカーソルで選択できるようにするみたいなやつですけど。
18:06
kudakurage
逆に同じ構造っていうか、同じ命名規則でやってないとダメとかそういうのがあった気がしたけど、
うまく、ちゃんと思った通りに同じところが編集されていくって感じにならないとかっていうのが、ちゃんとそれをもう作っておかないと結局ダメだった気がしたけど、僕も何回かいろいろ試したりとかして。
Takaya Deguchi
ちょっと話逸れるけど、なんかあれはすごいデザインシステムっていう観点でも良いアップデートだなと思っていて、
なんかやっぱデザイン、時間軸の違いっていうか、デザインシステムを作る上でのコンポーネントって時間軸が長いと思うんですよ。耐久度が高いというか。
だからそれなりにいろいろ考えて、デザイントークンとかね、設計とかいろいろしなきゃいけないんだけど、一方でなんか、プロダクトのデザイナーの立場に立ってみると、
なんかこう、そんなに時間軸長くないコンポーネントを作る場合もあるじゃないですか。なんかちょっとした自分の作業の効率化のための短期的なコンポーネントみたいな。
kudakurage
はい、ありますね。
Takaya Deguchi
で、それが同じコンポーネントで軸で2つあると、なんかこう、なんていうのかな、その短期的なコンポーネントのほうは別にコンポーネントしなくても本当は良かったものだったりするので、
まあそういう時にそのマルチカーソルの選択があると便利だったりするっていう、なんかまあコンポーネントの使い方がよりこう、明確になったというか。
っていうのはなんかいいアップデートだなと思うところではありますね。
いや、だから結構タイプグラフィーのバリアブルズっていうのは割と長期目線でのなんか話かなという感じですね。
まあそうですね。まあなんかあの選択してやるやつは別にコンポーネントっていうわけじゃなくてもね、なんかもうフレームぐらいのやつさ、単位で。
kudakurage
この画面とこの画面とこの画面の、なんか同じように配置してあるものをなんか一遍に同時でこう同じように編集するとか変更するみたいなのがやりやすいとかそういうのもあったから。
Takaya Deguchi
単純にねコンポーネントの話っていうだけじゃない部分もあったからね、あれは。
まあというので、今回のアップデートというか、最近のFIG全体的にそうなんだけど、どっちかというと目線はデザインシステムを作り手というか、
長期目線での長い時間軸の中でのコンポーネントをいかに堅牢に作るかみたいな視点でのアップデートが多いかなっていう気はしていて。
今回のバリアブルズ周りのアップデートはまあその一つかなという感じですね。
kudakurage
まあもともとバリアブルズ出てきた時になんかまだ一部しかなかったから、これどうすんのみたいな感じの話もあって、
まあ徐々にやっていくよみたいな話があったから、まあその徐々にがようやく徐々になってきたみたいな感じですけど、まだだから完璧じゃないんだよね。
Takaya Deguchi
そう。で、まあやっぱ初感としてもまだまだやっぱ、完全に期待してたものではまだないかな。まだファーストリリースって感じだなっていう印象で。
で、もちろんなんか短期的な使い方をする上では全然今でも十分なんだけど、ちょっとなんかそのデザインシステムの作り手として長期目線でコンポーネントを堅牢に作ろうって思うと、やっぱまだまだちょっと足りない部分がいくつかあるなっていう印象で。
21:14
Takaya Deguchi
で、まあその一つがコンポジットトークンっていうのに対応してほしいっていうところ、見たい、現状は未対応だっていうところで。
そのコンポジットトークンっていうのが何かっていうと簡単に言うと構造体なんですけど、その連なって一つものを構成するようなもの、例えばタイポグラフィってそのフォントファミリーがあって、フォントサイズがあってラインハイトがあって、まあいろんな設定があって一つのタイトルのテキストスタイルみたいな、だから一つのものをまあいろんな値で構成しているものだと思うんですよね。
グラデーションもそうで、まあその複数の色があってその色のポジションというかがあって角度があってみたいので構成されているものだし、あとシャドウもそうで、あのブラーとか色の影の色とかブラーとか、あのXとかYとかまあいろんな要素があってまあ一つの影が構成されるっていう、まあそういうものをまあデザイントークン的な用語というか、
まあW3Cのトークンフォーマットモジュールっていうそのデザイントークンのフォーマットを作っているコミュニティグループみたいなのがあるんですけど、まあそこにFigmaも参加していて、でまあそこで結構なんかそのデザイントークンの統一的なあの仕様を作ろうっていう風な話を進められているんですよね。
で、まあデザインシステムの設計者的には結構それを参照していろいろデザイントークンについて考えることが多いんだけど、まあその中でコンポジットトークンっていう定義があって、それがまあ構造体、今言った構造体、そのタイプグラフィーとか複数の値を連なったあのトークンをどう表現するかみたいなまあ仕様がまあ今草案として上がっているんですよね。
で、現状はこの構造体、コンポジットトークンへの対応が今のFigmaのタイプグラフィーバリアブルズはされてなくて、現状はこうバラバラでフォントファミリーのデザイントークン、Lineheightはナンバー型のこれまでの既存のデザイントークンを使うみたいな、なんかそういうようなデザイントークンというかバリアブルを使うっていうようなことになってるんですよね。
だからテキストスタイルの完全なる代替には現状のバリアブルズのタイプグラフィーではならないっていうような感じで、現状はテキストスタイル、これまであったテキストスタイルもまあ複数のLineheightとかフォントファミリーとかを連ねた一つの束、グループとして扱うものだったと思うんですけど、
現状その後にグループとして扱えるテキストスタイルとバラバラで変数として扱えるタイプグラフィーバリアブルズっていうのを、まあ現状は併用するような想定なのかなっていうような感じで、普通に使う分にはテキストスタイルを擬似コンポジットトークンというか、擬似構造体みたいな感じで使えば十分実用に耐え得ると思うんですけど、
24:14
Takaya Deguchi
ただなんかこうデザインシステム的にはテキストスタイルを、例えばAPIで作成するとかがやりたくなるわけなんですよ、そのなんかデザインシステムの思想的にはこうシングルソースオブトゥルースって言って、
なんかまあ1個なんかデザイントークンの定義みたいのをどっかしらに作って、まあどっかしらっていうのはJSONファイルとして外部のファイルに作るなり、フィグマ上に作るなり、まあどっかで作って、その定義をデザイン側でも参照するし、実装側でも参照するみたいなことをやりたい、というかデザインシステムの思想的にはそれを目指すケースが多くて、
でまあフィグマも後で話すんですけど、コードコネクトっていう今回新しく出した機能で、まあまさにそれをサポートしようとしてるんですけど、ただなんかそういうフィグマもそういうところをやりたいんだろうなっていうところを感じつつも、現状テキストスタイルってAPIで作成することができなくて、
なのでまだまだそのタイプグラフィーの定義みたいなのを例えばどこかしらコードでも参照しやすい形でJSON形式みたいな感じで定義したとして、それをデザイン側でも実装側でも作成できるようになるんじゃないかと思うんですけど、
まあ現状は難しいっていうのがちょっとなんか物足りない部分で、まあそういう事でコンポジットトークに普通に対応してもらえればいいんですけど、まあ多分それが難しいんだろうな、結構難しいんだろうな、フィグマ的にUI的には結構大きくなってきてるんですけど、
kudakurage
難しそうだなっていう気配をこう感じるのが現状でしたね。 だから まあなんかできなかなさそうですけど、もともとのなんかバリアブルズの設計思想みたいなところを考えるとどうそれに対してデザイン側でも作成できるようになるのかっていうのが一番難しいところだと思うんですけど、
できなかなさそうですけど、もともとのなんかバリアブルズの設計思想みたいなところを考えるとどうそれに対してそういうコンポジットトークンみたいなものを組み込んでいくのかっていうのが、まあいろいろ議論ありそうだなっていう、その社内とかでもあるって思うよね。
なんかもともとなんかあれ単純に変…もうちょっと変数データベースというかさ、なんかそういう感じで結構いろんなことを解決しようみたいな感じで作ってたところがあったじゃないですか、バリアブルズっていう機能自体が。
だから割とその入ってくる値みたいなものがすごく原始的というかさ、数字だとかもうテキストみたいな感じで、だっていう風になってるから、なんかその辺をね、もうちょっとなんかなんだろう、まあ変数っちゃ変数って言えるから、だからそのコンポジットトークン自体も。
27:08
kudakurage
まあだからそういうものをどう扱っていくのかっていう風なのっていうのをうまく入れなきゃいけないんだけど、なんかでも多分その辺の考え方とかっていうのにちょっといろいろと反発もありそうだなみたいな、見てて思ったけどね。
Takaya Deguchi
今の中の人目線で考えてみると、簡単に言えば右のペンのUIとかを結構いじんなきゃいけないだろうから、なんかその辺の開発コストみたいなのは結構高そうだなっていう印象があって、で、現状やっぱタイプグラフィーにしてもグラデーションにしても、今回のアップデートでバリアブルズ対応されたんですけど、それぞれはバラで設定しなきゃいけないんですよね。
グラデーションもグラデーションの構成する色をバリアブルズとして指定するってことができるんですけど、例えば黒と白のグラデーションだったら黒と白っていう変数2つを選択する、設定することができるんですけど、じゃあそのポジションとか角度とかっていうのは現状はバリアブルズの対象外なんですよね。
だからやっぱそこもコンポジットトークン避けてる感じなんだろうなと思うし、あとシャドウスタイルも現状バリアブルズには一切対応されてないんですよ。おそらくシャドウってもうタイプグラフィーとかグラデーション以上にバラバラでは成立しないものというか、バラにしちゃったらただのx座標の値とかy座標の値とかになってしまうから、
だからバラで対応する意味がないから現状後回しにされてるのかなみたいな、これ想像ですけど。
あと、決定的に現状のタイプグラフィーバリアブルズで足りてないというか、早く対応してほしいなと思ってるところが、テキストスタイルの行間にパーセンテージの指定が使えないっていうところで、
要はラインハイトの指定って普通160%とか180%とかパーセンテージで指定することが多いと思うんですよね。
なんですけど、現状は固定値でしか指定ができなくて、だから16ピクセルの場合は16×180%した値を直で入力しないといけないみたいな感じになるんですよ、バリアブルズを使おうとするとね。
おそらくそれも現状のバリアブルズって、さっきもてもさんが言ってた型が少ないから、その型を足さなきゃいけなかったりすると思うんですよ。
現状数値扱うためにはナンバー型しかなくて、パーセンテージ使えないから現状そうなってると思うんですけど、そこにパーセンテージを追加するのか、
あるいはストリング型でパーセンテージを扱うようにする、割とその場しのぎな対応をするのかみたいな、その辺の議論で結構いろいろ膨らみそうな部分ではあって、
そういうところを避けてとりあえず出しやすい形で出したっていうのが、現状のタイプグラフィバリアブルズなのかなっていうような印象でしたね。
30:03
kudakurage
なんかすごい別目線で、フィグマ自体のインターフェースの目線からいくと、
たぶん現状のバリアブルズにあたるようなものを、ある程度何かを定義してそれを使っていくっていう考え方って、
だからまず定義して使うっていうような感じの流れになってると思うんですよ、基本的には。
だけど今までのテキストスタイルとか、グラデーションの動画かわかんないけどとかって、
すでに定義されている、なんとなく数値が入れてあるものを、これをテキストスタイルにするっていう感じで作っていくんですよね。
そういう違いもあるんじゃないかなと思ってて、だから今までのバリアブルズみたいなやつに考え方に当てはめていくってなると、
バリアブルズのデータベースみたいなセルみたいなやつを開いて、そこにこのテキストスタイルをまず定義しようっていうところから始まって、
定義してそれを参照する形で使うみたいな感じのインターフェースの流れになるのかなと思ってやるとしたら。
その辺も考えると、もしかしたらもうちょっと簡略化したテキストスタイルのやり方の方がいいから、
ある程度すでにあるものをテキストスタイルトークンみたいな感じで、テキストスタイルバリアブルズみたいな感じで変換するみたいな風に結局しちゃうかもしれないですけど、
その辺現状のインターフェースの使い方の流れっていうのを見ると結構明らかに違うかなと思って、そこがバリアブルズをまず定義してからそれを使うっていう流れなのか、
すでに定義していろいろと値をセットしたものをバリアブルズにするっていうかね、そういうふうなものとして変換するっていう感じの流れになってるのかっていう部分を見ても、
なんかちょっと違うような気がしてて、でもそこもなんかちょっと考え方があるのかなと思ってて、やっぱりいろいろたくさんね、
どんどん既存のものをポンポンポンポン、デザイントークンとしてやっていってほしくないから、まず定義してから使うっていう風に流れにしたいっていう考え方で作られてるのかなとか、
そういうのも考えるとなんかちょっとインターフェース的にはいろいろと変えなきゃいけない、なんかいっぱい作んなきゃいけない部分もあるのかなとかっていうのを思ったりもしたけどね。
Takaya Deguchi
そうして開発コストは高そうっていうのはすごい理解できるところではありますね。
kudakurage
なんか思想をどう埋め込むかっていうのの議論が結構実はその社内であるんじゃないかと僕は考えてるけどね。
プロジェクトマネージャーのカロリーは高そうだなとは思う。なんか自分がプロジェクト作るとしたらそういう議論を求めていくっていう。
33:07
kudakurage
かなりメタな話だからね、結構俺。
Takaya Deguchi
だいぶメタ読みしてますけどね、この話。
kudakurage
フィグマ自体が結局メタなわけじゃないですか、作る人のためのツールだからさ。
作る人自体がまずメタなことを考えてるのに、それをさらにメタ化したものを作んなきゃいけないみたいなことをやってるわけだから。
なかなか大変、多分思想がいろいろどうまとめるのかっていうのは大変そうだなっていうふうにちょっと考えてたけどね。
Takaya Deguchi
ただ、1ユーザーとしては普通に業間ぐらいだったら少数点でもいいからナンバー型で対応できるんじゃないかなとか思ったんですけどね。
そこだけはちょっと手早く対応してもらいたいなと思いつつ。
でもそのコンポジットトークンっていうのもW3Cのデザイントークンフォーマットモジュールってところで議論されてて、そこにフィグマも入ってて。
フィグマも一部の出してるサンプル、例えばバリアブルズをREST APIっていうエンタープライズプランでしか使えないAPIなんですけど、
それを使ってコード側と連携させるサンプルコードみたいなのを出してたりするんですよね、フィグマが。
そこでもW3Cのフォーマットモジュールの中での仕様を前提としてサンプルコードを提供してくれてたりするんですよ。
だから意識してないわけがないというか、もちろん知った上での現状だと思うので。
あと、こもちとトークンにはいずれは対応してもらえるのかなと思うんですけど、いずれがなるべく早く来てほしいなというところではありますね。
後から帰るのすごい大変なんですよね、この辺。
kudakurage
今のスピードを見てると結構時間かかんじゃないかなと思う。
Takaya Deguchi
来年かもしんない。
kudakurage
そうそうそうそう。そんなペースだよね。去年だったじゃないですか、バリアブルズ時代が確か。去年だっけ?
Takaya Deguchi
去年の夏ぐらいじゃなかったっけ?違うっけ?
kudakurage
それぐらいだったっけ?
まあでもそんなまだ1年ぐらいだもんね、だって。
Takaya Deguchi
だからそう考えると結構時間かかんのかなと思う。
待ち望んでます。
ここを後から変えるのめっちゃ大変なんですよね、タイプグラフィーのテキスト周りを移行してくるとなるとコンポーネント1個1個変えていかなきゃいけないんで。
っていうのがタイプグラフィーバリアブルズとグラディエントバリアブルズっていう2つのアップデートの話ですね。
でもう1個大きい話がコードコネクトっていうやつで、これどういう機能かっていうと、
簡単に言うとコードスニペットっていう、主にエンジニア向けというか実装者向けの右のペンにサンプルコードみたいなのが、
36:07
Takaya Deguchi
今はデブモードか、デブモードにすると出てると思うんですよ。昔は無料でも見れましたけど。
それが現状は単なるサンプルコードなんですけど、それがライブコードというかそのプロダクトベースのコードになるみたいな、そういうやつなんですよね。
実際の実装したコードでこういう風に使ってくださいみたいなことができる。
エンジニア的にはストーリーブックっていうやつがあって、リアクトのコンポーネントとかリアクトを実装した時に、
プレイグラウンドというかUIを実際表示しながらそのプロパティをいじって、
リアクト的なプロプスをいじって、ボタンがディセーブル状態になったらどういう表示になるかとか、
どういうプロパティが用意されているのかみたいなのを操作しながら動作確認するライブラリみたいなのがあるんですけど、ストーリーブックっていう。
デフォルトになっているやつがあって、分かりやすくそれをまるまるFigmaに持ってきたというか、
ストーリーブックの競合になるような機能をFigmaが出してきたっていうような話ですね、コードコネクト。
ただ、これエンジニア視点で見ると最初嬉しさがよく分からなかったんですよ。
なんていうか、もうストーリーブックってあるし、めっちゃ広まってるし、
大体のデザインシステム、ストーリーブック備えてて、ストーリーブックでコンポーネントの機能とかを確認するっていうのがかなりデファクトになってるから、
なんで今更Figmaがこれ出すんだろうなっていうのがいまいち分からなかったし、
エンジニア的に懸念するのは、ストーリーブックがある中で完全にFigmaのコードコネクトに移行してしまうと、
当然Figmaのアカウント持ってないと見れないっていうところもあるし、
ベンダーロックインみたいなのがされちゃうから、あんまりやりたくないなっていうのがまず考えること一つ目で。
じゃあストーリーブックとコードコネクト両方メンテナンスするかって言ったら結構大変だなみたいなところ。
そのダブルメンテみたいなところが、エンジニア的にはパッと思い浮かぶ分かりやすい懸念みたいなところなんですよね。
何が嬉しいんだろうなと思ってたんですけど、
Figmaのこのフレームワークのイベントの中で、Figmaの人がデモみたいなのをされていて、
その中で言ってたのが、なるほどと思ったのが、
このコードコネクトを使うとデザインシステムにコンポーネントが存在するというのが分かる。
それが価値であるみたいなことを言ってて、
これ何かっていうと、
39:01
Takaya Deguchi
コンテキストとしてすごい大企業を思い浮かべてもらえるといいかなと思うんですけど、
数千人とか社員がいるような会社の中で、
デザインシステムを浸透させるみたいなことを考えていくと、
これまでだったらデザインシステムを作りました。
Figmaのコンポーネントがあります。
Reactのコンポーネントがあります。
それらを束ねたガイドラインを書いたようなウェブサイトがあります。
そのウェブサイトをデザインシステムに名前をつけて、
SaraとかApronとかそういう名前をつけて、
それをシャナで浸透させていきます。
その浸透活動をすごい頑張りますみたいな感じになると思うんですよ。
そのデザインシステムの作り手としては。
そうするとプロダクト側のエンジニアは、
そのサイトを見て、デザインシステムこういうコンポーネント備えてるんだ。
じゃあなんかプロダクトのデザイナーから上がってきた
Figmaのデザインファイルを実装するときに、
このサイトにあるコンポーネントを使って実装していこうみたいな、
そういう思考の流れになると思うんですよね。
だからつまりそのサイトがあって、
コンポーネントがどんなものが備えてますかっていう
全貌を浸透活動するのをシャナで頑張らなきゃいけない。
それをデザインシステムのチームがすごい頑張るっていうのが
これまでだったと思うんですよ。
今回のコードコネクトっていう機能を使うことによって、
今の一連の話の中でやっぱり一番の接点、
エンジニアがデザインファイルとの最初の接点になるので、
プロダクトのデザイナーがFigmaでデザイン作りました、
じゃあこれディスお願いしますってデザインファイルを渡したときが
たぶん一番最初の接点になると思うんですけど、
その接点の段階でそのデザインファイルの中を見て、
デブモードでそれを見て、
この画面のこのボタンはコンポーネントがすでに用意されてるんだっていうのが
そこで気づくことができるっていうのがおそらくFigmaの人が言ってる話で、
だから浸透活動が例えば全然できてませんでした。
Figmaのデザインシステムの認知度がすごい低いですっていう状態であったとしても、
デザイナーがFigma使ってデザインファイルを作ってしまえば、
そのデザインファイルを見るだけで、
このコンポーネントすでにもう実装されたものがあるのね、
じゃあ使おうってなるっていう風な、
だからその起点をFigma側に持ってくることができる、
それによって浸透活動がしなくてもいいとはならないと思うんですけど、
より浸透しやすくなるっていうような、
そういう結構なんていうか、
想像力が必要な機能だなというのは思いましたね。
だから逆に、
数人規模とかスタートアップとか、
42:00
Takaya Deguchi
本当に少人数の規模感であれば、
そんななんか別に頑張って使わなくてもいいのかなとは思うというか、
あんまり上見が得づらい現状は、
ちょっと官報っぽいなというか、
そんな速攻性があるような機能ではないのかなというのは、
現状の僕の所感ではあるんですけど。
kudakurage
細かくいいって思える点を、
1個として多分それを挙げたんだろうね、きっと。
本当は多分もっと大きいことがやりたいんだろうなっていう、
そういう思惑みたいなのは見える気がするけどね。
Takaya Deguchi
超思想というか、
ベクトルとしてはさっき言ったシングルソースオブトゥルースを実現したいみたいなところが、
やっぱり大きな方向性ではあると思うので、
現状はデザイントークンっていうレベルの中で、
バレーブルズをAPIで操作するとかそういうところで、
実際にやろうとしているのがレベル1だと思うんですよね。
レベル2としてはコンポーネントのライヤーで、
究極的に言えばコンポーネント作ったら勝手にコードが生成されるとか、
そういうところまでいけたらいいのかもしれないけど、
要はデザインと実装を完全に1対1で対応させるっていうところが、
フィグマ的にはやりたいところではあると思うんですよね。
ただそこに至るまでには結構レベル感がいろいろあるし、
現状そのレベル1のデザイントークンに関しても、
さっき言ったコンポジトークン周りの対応がまだちょっと100%じゃなかったりとかして、
レベル1すらもまだ達成できてないと思うので、
段階的に進めていく上で、現状のコードコネクトっていう感じだと思うんですけどね。
kudakurage
やっぱりデザインの部分と、実際に開発としてコードに落としていくっていう部分のワークフローっていうのを、
もっともっと変えていきたい。
もしかしたらコード書かなくていいっていうところまで、
いずれ消化したいんだろうなっていうところの感じの思惑というか、
Takaya Deguchi
その辺のステップを徐々に徐々に刻んでいってるっていう感じはするよね、見ていて。
だから現状はコードコネクト単体取ってみたら、
この機能ってそもそも上位プランでしか使えないものなんですよ。
デブモードがそもそも課金しなきゃいけないし、
さらにコードコネクトはFigma全体の上から2つ目ぐらいのプランかな。
kudakurage
ビジネスプランとエンタープライズプランだけだった気がします。
Takaya Deguchi
かなり高級な機能ですよ、お値段的にも。
kudakurage
まあまあそうね。
Takaya Deguchi
なので、じゃあ果たしてそれを目的にそのプランに課金するかって言ったら、
現状は多分しないと思うんですけど、
ただそれでも機能として設立させないと世に出せないと思うんで、
っていう中で現状、さっき言ったような話をしてると思うんですけどね。
45:05
Takaya Deguchi
Figmaがデザインの使用書代わりになる、
実装の使用書代わりになるみたいなところをまずは目指したいのかなというような感じですかね。
最近入ったアノテーションっていう機能だったりとか、
あとはアノテーションっていうのはなんか、
kudakurage
コメント書けるやつね、コメントっていう。
Takaya Deguchi
簡単に言えばコメント書ける。
kudakurage
使用書作れるみたいなやつよね、本当に。
見た目、パッと見の使用書作れるみたいな。
昔から結構ね、それこそスケッチとかの時代、スケッチの時代って言うとあれですけど、
Figmaの前によく流行ってたツールとしてのスケッチの頃から、
プラグインとかでよくみんな使ってたりとかしてたようなものみたいなものを、
Figmaのツール上に落とし込んでいったみたいな感じっぽかったけどね、ああいうの見てて。
Takaya Deguchi
あれも最初、コメントで良くない?とか思うわけですよ。
何が嬉しいんだろうなみたいな。
デブモードでしか出てこないコメントみたいな感じだから、アノテーションって。
何が嬉しいんだろうなと思ってたんですけど、
ただ最近なるほどと思ったのは、アノテーションってコンポーネントに対して、
例えばここのマージンは16ピクセルお願いしますとか、
ここのカラーにはデザイントークのこれを使ってくださいみたいなコメントを書くアノテーションを付けるわけなんですけど、
あれって最近気づいたのがインスタンス側にも伝播するんですよ、アノテーションがね。
普通のコメントってファイルに対してコメントを付けるっていう感じで、
別にコンポーネントのマスターインスタンスっていうのは全然関係ない話なんだけど、
アノテーションに関しては、アノテーションのマスターにアノテーションを付けたとしたら、
それがインスタンス側にも伝播するので、
インスタンス10個作ってたとしたら、その10個分に対してアノテーションが付いて回ってくるみたいな感じの機能なんですよ。
だから、アノテーションをデザインステップの作り手が適切にアノテーションを付けて、
そしたらそれを使うユーザー側のデザイナーがボタンのインスタンスみたいなのを作って、
それでプロダクトのデザインファイルを作って、
それをプロダクト側のエンジニアがデブモードで見たら、
そのインスタンスに対して付いているアノテーションを確認できるみたいな、
そういうような思想だと思うんですよね。
それによって実装の品質を担保できるみたいな話だと思っていて、
それもさっき言ったコードコネクトと結構近くて、
かなりシーンとしては大企業とかかなり規模感が大きいような会社の中での話にならないと、
48:06
Takaya Deguchi
なかなか良さが伝わりづらいところというか。
kudakurage
でもデブモード上で参照できるものにしてるっていうのは、
僕はすごいいいなと思ったけどね。
結局だってこのフォントは16ピクセルにしてくださいとかって、
別に実装者以外にとってはどうでもいいコメントなわけじゃないですか、
そういうのって言ってみれば。
それでさ、そういうコメントとかでデザインファイルが埋め尽くされてしまうっていうのはやっぱり嫌なわけですよ。
ただでも実装するときにはそれを伝えなきゃいけないみたいな、何とかして。
っていう部分でデブモード上でそういう変更があったときとか、
そういうので見れるものとして使えるっていうのは良いなと思いましたけどね、やっぱり。
Takaya Deguchi
単純にコメントのタイムラインを2つ分けられるっていう話と、
さっき言ったインスタンス側に電波するっていう話の2つの価値というかのがあって、
後者が本丸なんだけど前者だけでも便利に使えるよっていうような話ですね。
結構Figmaのコメントってどんどんどんどん増えていって、
もう何が何なのか分かんなくなるみたいなのがなりがちかなと思うので。
kudakurage
僕はどっちかっていうとレビューされてコメントされる側だから、
割と僕はだからもうイシュークローズと同じ感じで、
これ終わったらクローズ、これ終わったらクローズみたいな感じしてること多いけどね。
Takaya Deguchi
僕もどんどんガンガンクローズしてきますね。
kudakurage
終わった話が残ってると気持ち悪い。
Takaya Deguchi
し、逆にずっと残り続ける話っていうのは大体実装の話なんですよ。
ここは何らかで実装してくださいとか、
今後もいうトークン使ってくださいとか。
だからそれはアノテーションに残しましょうって話だと思うんですよね。
kudakurage
議論する場とそれを実際にどう開発でコードに落としていくかっていう部分を
分離したっていう感じがするよね。
Takaya Deguchi
っていう話に戻すと、アノテーションもコードコネクトも
使用書代わりに使えるみたいなところを目指している。
結構この間まさになるほどと思ったのが、
大きめの会社の案件やってて、
この使用書くださいって言われたんですよ、簡単に言えばね。
だけどそれって別に僕的にはデザインファイル見れば明るくないって思うわけですよ。
フィグマ開いてそれと単なる1画面の実装をしたいみたいな話だったから、
別にそんな難しい画面ではなくて、
普通にデザインファイル開いてここのマージンはいくらかなって
見るだけで別に実装できるようなレベルの話だから、
51:02
Takaya Deguchi
いるみたいな気持ちになるわけですけど、
でもやっぱりベンダーとか実装専門にありますみたいな会社とかだと、
デザイナーと一緒に協業するみたいなところすらそもそもやってないみたいな会社もあると思うから、
そういうところに対して、
例えば内製でデザインシステム作って、
実際プロジェクトの開発はベンダーにお願いするみたいな体制のときに、
使用書を頑張ってデザイナーが作らなくてもフィグマが見てもらえれば、
そういうベンダーから見てもベンダーフレンドリーな状態になっているっていうのを目指すっていうところが、
コードコネクトとかアノテーションとかそういったところの価値なのかなというのは思いましたね。
kudakurage
もともと結構フィグマ、デブモード出る前からそういう思想でやってたけど、
その辺をどんどん強くしていって、
ただ、とはいえやっぱりまだちょっとエンジニアに対してインストールが必要な部分っていうのは結構多そうな気がするけどね。
まだ常識にはなってないのかなみたいな。
Takaya Deguchi
そうですね。
だからエンジニア的にも嬉しい機能を入れて何とか常識にしようっていうことをしてるっていう感じの一つがコードコネクトなのかなと思うんですけど。
実際コードコネクトもここ数日実際ちょっと触ってみてはいて、
さっき冒頭に言った懸念みたいなので、
例えばダブルメンテナンスになってしまうんじゃないか、ストーリーブック等みたいな話をちょっとしたんだけど、
その辺ももちろんフィグマの人は考えてるっぽくて、
だいたい的には売れてないんだけど、
このコードコネクトオープンソースに一部なっていて、
HPMのパッケージとしてギタブに上がってるんですけど、
それのリードミーとか見るとストーリーブックとのインテグレーションみたいなところも考えられて作っているので、
ダブルメンテみたいなところにはならないようにしようとしてるっていうような気持ちはすごい感じましたね。
kudakurage
結構現状のフィグマのビジネスといわゆるエンジニア界隈の
文化というか、そういう部分ってちょっと衝突する部分あるなって僕も思ってるというか、
結局フィグマってやっぱりツールで囲っていくようなビジネスじゃないですか、
言ってしまえば。だけどエンジニアの文化ってどっちかっていうとオープンにしていくっていうような文化だから、
どっかで多分その辺をうまく解消するようなインテグレーションがメインだと思うんですけど、
みたいなことをどんどんやっていかないと、それこそもしかしたらまた新しい競合ツールが出てきて、
フィグマがガラバゴス化していくみたいなさ、そういう未来もあり得るかもしれないから、
そういう未来にならないようにある程度開いていくっていうのがどっかのレベル間では必要になるんだろうなっていうのは思ってたけどね。
そこはね、なんかフィグマのプロダクトマネージャーだったらと妄想してみるとすごい大変なポイントなんだろうなと思っていて、
54:05
Takaya Deguchi
なんか最近のフィグマのアップデートを見てみると、やっぱ明確にエンタープライズかけるデブモードっていうところがやっぱこうマネタイズなポイントでもあるんだろうなと思ってて、
まあフィグマって結局エンタープライズの中で、
エンタープライズの中でのデブモードっていうのがやっぱり大変なポイントなんだろうなと思っていて、
まあフィグマって結局現状はエディター、有料課金のアカウント数をいかに増やすかっていうのがやっぱマネタイズのそこで売り上げ上げてると思うんですけど、
じゃあなんかエディターをどんどん増やそうってなかなか難しいと思うんですよ。
実際デザインやる人っていうのは組織の中で少数派だと思うから。
でももちろん思想的にはみんながデザイナーになれるようにっていうような思想ではあると思うんですけど、
まあ言うても割とそこそこな値段がする製品だから、
結局やっぱエディターって必要最低限の人にしか付与しないっていうのがまあ普通の会社だと思うんですよね。
っていう中で一個フィグジャムっていうのを出してきて、
まあ見ろみたいな感じでそのノンデザイナーであっても使えるよっていうので、
まあ1個アカウント増やそうとしてるっていうのが1個の筋だし、
もう1個の筋として今回DevMode、今回というか最近DevModeに注力してて、
リードとエディターの中間でDevMode用のアカウントっていうのを作って、
まあそこで対立しようっていうのが最近だと思うんですよ。
で一方でそのDevModeがまあこれまでの話で進化を発揮するのはやっぱ結構大規模な会社だと思うから、
だからそこでエンタープライズ機能っていうのがあってっていうような、
まあエンタープライズ機能の場合そもそもエディターの数もスタートアップに比べれば全然桁が違うと思いますし、
というところでエンパルトのエンプラかけるDevModeみたいなところがやっぱマネータイズの1個ポイントなんだろうなみたいな。
でやっぱそうなってくるとエンタープライズの場合はセキュリティとかそういう観点もすごい大事だし、
まあだからさっき言ったオープンソースの精神みたいなところよりも、
まあどっちかって言ったらそのプロプライエタリーな製品に対してもそんなに拒否感がないというか、
どっちかって言ったらセキュリティとかそういったところを重視で選ぶ会社が多いと思うから。
でもとはいえFigmaのコアのファン層みたいなのはスタートアップ的な文脈の人たちが現状は多いと思うから、
そこの折り合いをいかにつけるかみたいなところはやっぱFigmaのプロダクトマネージャーだったらすごい悩むんだろうなっていうのはなんか想像しやすいですよね。
難しいとこだよね。
でやっぱ特にDevModeって最初の、DevModeの中でもそのコードのスニッペット出すやつって最初無料で普通に見れたじゃないですか。
kudakurage
期間限定でね、最初の方だけお試しで使えますよみたいなとか。
57:00
kudakurage
でもその前も。
現状も簡易的なやつは一応見れるはずですけどね。
Takaya Deguchi
どこまでのレベル感だったか、昔のやつと同じかどうかちょっと僕も覚えてないですけど。
僕も最近気づいたというか、最近僕普通に基本的にはエディターとして使うコードばっかりだから、
普通の無料プランでどこまで見れるのかってあんま分かってなかったんだけど、
てかそれこそこの間、もてもさんがデザインしてくれたクランの新しいホームページの実装してて思ったんですけど、
クラン無料でFigma使ってるじゃないですか。
僕、要はDevModeが使えない環境なんですけど、そこで例えばグラデーションの値とかって、
Figmaのグラデーションの値を見るだけだと、実装的にシェンセスに落とし込んだ時にどういう値になるのかってちょっと分かりづらいから、
そこだけはサンプルコード見たいわけなんですよ。エンジニア地点で見てもね。
でも現状それ見えなくて、え、これどうすんの?みたいな思ったんですよ。
kudakurage
じゃあ参照できなくなってってるのかな?
Takaya Deguchi
完全参照できなくなってるんですよ。
それは、え、マジかと思った。やりすぎじゃないっていう。
例えばデザイン的に、塗りのバックグラウンドを塗りに対してノイジーな画像をレイヤー当てるみたいな感じ?
で、そのノイジーな画像に対してα50%とかにしてるみたいな。
ちょっと複雑な構成にしてると、それを実装的にシェンセスのバックグラウンドにどう落とし込んだらいいかって、
ちょっと頭の中で変換させなきゃいけないから、そこぐらいはやっぱコードのスニップアップ見れると嬉しいなと思うんですけど、
昔はそれ無料でも見れたはずなのに、現状それ完全にできなくなってて、
えーみたいな。とかっていうのは、なんかちょっとやりすぎなんじゃないと思ってしまう。
もうちょっとなんか、ペイオールを下げてほしいなというか。
kudakurage
何とも言えないって感じですね。
Takaya Deguchi
で、逆にこれのためにデブモード課金しますってないと思うんで。
難しい。難しいね。
kudakurage
いやでも、難しい。難しいよね。なんかやっぱりこうなんていうんだろう。
やっぱりサースというか2B向けの、やっぱりこうなんていうの、プロダクト開発で、
どういうふうに課金ポイントを作っていくのかっていうのの設計ってやっぱりいつも難しいなって思う。
Takaya Deguchi
難しい。
なんか特に。
分からないんですよ。
kudakurage
なんか無料と有料っていうのだったらまだ分かりやすい、なんか課金ポイント作りやすいんだけど、
その有料の中でもグレードを作っていくっていうのは結構難しいんだよね。
でも本当はやっぱりね、そういう作り作ってね、ある程度売り上げのベース増やしていけるようにしたいとか、
1:00:02
kudakurage
っていうのがやっぱあるから、たぶんね、もちろんFigmaもそういう思惑とかあるだろうから。
でもそこをうまく作って、うまい、いい感じのグラデーションでこうなんか作っていくのってすごく難しいんだよね。
Takaya Deguchi
そこのここまでは無料です、ここからは有料ですみたいなそのペイウォールの高さみたいなのを
いい感じに設計するのはすごい難しいっていうのはまあSARS作ってたからすぐ分かるんですけど、
とはいえグラデーションぐらいは無料で見せてくれないと困るなと思うっていうか。
そこをきっかけに有料に移行させるのはなんかちょっと違くないって思ってしまう。
そこ本質じゃないよなっていう。なんかちょっとヘイト貯めるだけっていうか。
っていうのに終末気づいた。
kudakurage
いやでも本当こういうの難しいんだよな。
機能別にするのかとかメンバー数に応じてにするのかとかいろいろ考えるんだけど、
メンバー数に応じてにするとなんか共通アカウント作られたりして、
Takaya Deguchi
なんかうまくハックされて使われちゃうとかさ、なんかそういうものもあったりとかさ。
kudakurage
あるからなんか結構難しいんですね。
Takaya Deguchi
これを考えるのってやっぱりいつも悩むことが多い気がする、なんかこの辺って。
難しいのはすごく分かる。
kudakurage
デザイナーに対しては現状ね、ある程度優しいというかさ。
Takaya Deguchi
いやそうなんですよね。
kudakurage
っていうところがあるから。
やっぱりその、分かるんですよねすごい。
だからそういう意味ではそのコラボレーションっていう部分で、
お金を取っていこうっていうような考え方だと思うんで基本的に。
でもそれはそうなんか割と正しいような気もするし。
ただその時のどうグラデーションつけるのかっていう部分だよね多分だから。
Takaya Deguchi
なんか今議論になってる部分っていうのは。
現状なんかデブモードがまだまだちょっと何ていうかな。
速攻性のある嬉しさみたいな感じづらい機能ではあると思うから。
さっき僕が言ったようなちょっと限定的なコンテキストの中ですごい官方的に機能を発揮する機能かなと。
そうね。
kudakurage
そういう意味でもやっぱもうちょっとそのエンジニアというか開発の人たちをどう巻き込んでいくかっていう部分で、
そのエンジニア的な文化っていうのをどう取り入れていくのかとかっていう話も入ってくるのかもしれないよね。
そうなんですよね。
Takaya Deguchi
もしかしたら。
kudakurage
なんかエンジニアがもうフィグマ使いましょうよっていう風にならないと多分世界的にうまくいかないんじゃないかなっていう。
Takaya Deguchi
そうなんですよ。
kudakurage
そのためにはある程度開いてエンジニアの文化をうまく馴染ませるようなものことを知っていかないといけない。
だけど一方でこうなんか囲い込みたいみたいな。
そうなんですよ。
結構そこが難しいところだよねやっぱりだから。
Takaya Deguchi
僕がエンジニア視点で見たときのフィグマに期待することはめちゃくちゃいろいろあって。
1:03:00
Takaya Deguchi
なんか一つは大きい話で言うとワークフロー的な部分ともうちょっとインテグレーションしてほしいっていうか、
なんかその現状で言えばデザインを作るツールからデザインシステムを作るツールにちょっと進化してると思うんですけど、
さらにその先には運用っていうのはワークフローみたいな、
デザイナーがデザインします、その後エンジニアが実装します、
てかその前なんだろうな、
要はGitHubとか分かりやすいと思うんですけど、
GitHubプロジェクトって機能があって看板の機能があるんですよね。
最初にプロジェクトマネージャーみたいなのを一周立てて、
トゥードゥみたいな、トゥードゥリストみたいなのを作って、
エンジニアがその一周をベースに実装して、
プロジェクトを作って、
プロジェクトがマージされたらその一周も勝手にクローズされて、
看板のトゥードゥからドゥイングに自動で移って、
ドゥイングがマージされる段に移るみたいな、
それによってプロジェクトマネージャー全体を俯瞰して、
全体の30%ぐらい終わったかみたいなのが把握できるみたいな話が、
プロジェクトマネージャー視点で見るとやりたいことなんですけど、
ただ現状デザインとエンジニアリングが完全にツールが分かれているから、
そこがすごいやりづらいんですよね。
ある一周があったとして、
これはデザインがダンになっているのか、
エンジニアリングがダンになっているのか、
そのステータスがどうなっているのかというのがわからないみたいな。
だから究極一周が一個立てたとして、
それに対してデザインファイルも実装ファイルも紐づいていて、
デザインがダンになりました、
じゃあ次はエンジニアリングですみたいなのが、
その看板で自動で開発レディな状態になっていますみたいな感じで、
ステータスが切り替わるとか、
そういったところがやりたいなと思うんですけど、
現状フィグマってレディフォーデブみたいなステータスが
セクションにつけられるじゃないですか、
デブモードの。
ただあれって単にフィグマ上でレディフォーデブになりました
っていうのが分かるだけっていう、
ただそれだけなんですよね。
だから理想的にはそれ後に、
例えばGitHubのissueが紐づけられて、
レディフォーデブにしたらステータスが変わるとか、
レディフォーデブ以外にも、
デザインする中でいろいろステータスってあると思うんですよ。
そのデザインできました、
デザインのレビューが必要です、
デザインのレビューも通りましたみたいなフェーズがあると思ってて、
だからそういうデザインの中でのステータスも連携できて、
そこがエンジニア側とも一緒に管理できるとか、
ジラとかそういう製品とかとの連携とか、
そういうのをもうちょい強めてもらえると、
エンジニアとかプロダクトマネージャー的にも、
Figmaが浸透した状態になるというか、
開かれた状態になるなっていうのとかね。
kudakurage
僕あんまり使ってないから分かんないけど、
一応確かデブモード上に、
GitHubとかジラとの連携するプラグインみたいなのが、
確かあった気がするけど。
Takaya Deguchi
あるんですけど、
1:06:01
Takaya Deguchi
GitHubプラグインに関してはちょっとまだ、
甘使いものにならないなと正直思ったところであって、
それは別にFigmaが出してるわけじゃなくて、
GitHubが出してるやつで、
単に現状はデブモードの中に、
Figmaの意思をリンクが貼れるっていうだけの話なんですよね。
だから意思を立てて、
Figmaの方にリンクを貼りに行かなきゃいけないみたいな、
そこは手動でやるみたいな、
それ誰がやるんだみたいな話なんですよ。
で、ジラはもうちょいインテグレーション強めというか、
Figmaからジラに起票することができたりとか、
そういうことができるので、
そこは結構いいかなと思ってるんですけど、
っていうのが現状サードパーティーが対応するって感じで
やってると思うんですけど、
もうちょっとFigmaとしてもその辺、
サポートがあってもいいなと思うんですよね。
kudakurage
そうね。
多分そこはやっぱりFigma側がもうちょっとそういう、
他のGitHubなりジラとか他のところに、
ガンガンサポートというかサポートもして、
お願いして進めていかないと、
多分他のところはあんまりモチベーションがない可能性あるよね。
だからGitHubとか別に作んなくてもいいかみたいな。
そうなんですよ。
Takaya Deguchi
なんかそういう感じ。
kudakurage
多分そこはお願いして一緒にちょっと作りましょうよ、
みたいなふうにやって、
Figma側がどんどんやっていかないと進まない気がするね。
Takaya Deguchi
あとやっぱデザインの中でのワークフローのステータスみたいなのは、
もうちょいFigmaとして定義してほしいというか、
現状Ready for Devしかないわけなんですよ。
1か0かみたいな。
デザイン中か開発中かみたいなしかないんだけど、
実際のプロダクトのデザインの中では、
もうちょいフェーズがあるわけじゃないですか。
まず叩き台を作りました。
それをレビューしますみたいな、
いくつかフェーズがあるし、
Figmaもブランチングっていう機能があって、
プロリクエストとデザインレビュー的なことができるんですよね、
上位プランでは。
それがもうちょいステータスと紐づいてるとか、
もうちょっとなんだよなっていう感じなんですよ。
完全にやってないわけではないんだけど。
マイクロソフトに買収されてほしい。
買収なのかわかんないけど、
一緒になってほしいなという気持ちがありますね。
マイクロソフトってギターブの親会社。
単なるコードとの連携。
逆に僕そんなにコードを書かなくてもいい世界って、
そんなに僕信じてないから、
デザインからボタンポチッと押すだけで
リアクトのコードを出力されますみたいな、
別にできればいいけど、
だいぶ先だよなみたいな気持ちになるんですよ。
どっちかというとそっちよりも
ASAIで生成するみたいなのが早そうだなみたいな。
そっちよりはどっちかというとチームワーク、
ワークフローみたいなところをサポートする方が
フィグマっぽさもあるし、
1:09:01
Takaya Deguchi
コラボレーションを支援するみたいなところの
思想とも合ってるだろうし、
そこを頑張ってほしいなっていう気持ち。
最近のフィグマのアップデートの動向を見てると、
そういうエンプラかけるデブモードみたいなところは
かなり重力事項なのかなというようなのは、
より今回のフレームワークのイベントに行ってみて
思ったところではありますね。
あとちょっと話は変わって、
来月コンフィグあるんですよね。
6月の26、27であって、
結構そこはもう何かアジェンダというか、
トピックこういうことを話すよみたいな、
一覧は公開されていて、
それをちょっと見てたんですけど、
何かいくつか面白そうなのがあって、
一つは何かキーノートで、
ファウンダーのディランフィールドの
発表するんですけど、
当然中身はまだ分からなくて、
ただ何か、
今年最大の製品発表会です、
みたいなことを言ってるので、
おそらくデカめのアップデートがあるんだろうな、
というか、
このフレームワークの段階でこのバリアブルズっていう、
地味であるけどデカい発表をしてたんで、
それを超える発表がおそらくある。
かなり分かりやすい機能なんじゃないのかなという、
気がするんですけどね。
何が来るのかなというところで、
やっぱ登壇者の一覧を見てると、
AI系の会社は多いんですよ。
AI系のアジェンダは多くて、
パープレキシティっていう、
最近話題のセセイアイの、
パープレキシティの、
パープレキシティの、
スタートアップとかが登壇してたりとか、
割とAI系の話が多そうなんで、
で、Pigmaの人もAI系の話をするっていうような、
のがちょっと書いてある。
コンテンツデザイン&AIっていう、
アジェンダが一個上がってたりするんで、
詳細は分かんないんですけど、
何かしらコンテンツデザインって言ってるから、
何なんでしょうね、
これは。
kudakurage
去年だっけ、買収したのは。
Takaya Deguchi
あれか、なんだっけ、忘れちゃった。
kudakurage
名前で忘れちゃった。
名前、デザイン、
もともとデザイン系のAIを作ろうとしてたところを、
Pigmaが、
作ってたところをPigmaが買収したじゃないですか。
なんていうとこだったか忘れちゃったけど。
Takaya Deguchi
AIは確実に出るとして、
それをどこに使うかっていうところですよね。
そうだね。
アドビスっぽく考えると、画像の生成とかテキストの生成みたいなのをするけど、
何かあんまPigmaっぽくないなとも思うというか、
1:12:01
Takaya Deguchi
まっすりだねみたいな。
kudakurage
前作ってたのは、だからそれこそ、
画面をデザインしていくときに、
提案してくれるみたいなやつだった気がするけどね。
UIの自動生成まで、
Takaya Deguchi
このタイミングで出るのかな。
出る。出てもいい。
出る要素は揃ってるけど。
kudakurage
自動生成までいくのか、
その提案止まりにするのか、
その辺はどうなのかってわかんないよね。どうするんだろうね。
FigJamとかだったら全然、
バンバン自動生成で保管していくっていうので、
良さそうな気がするけどね。
Takaya Deguchi
FigJamはあれですね。
FigJam AIってやつが去年末ぐらいに出てましたよね。
ブレインストーミングを促すようなボット。
生成AIボットみたいなので、
なんか結構いい使い方だなと思ったんですけど、こういうのは。
だからこういうなんか、
創造性を広げてくれるみたいな文脈で、
AI機能が入ると面白いなと思うんですよね。
まあUIの生成もね、もちろんあると嬉しいかなと思うし、
なんか最近バーセルが
V0っていう紹介したやつとか、
生成AIベースでUI生成するみたいなやつとかやってるから、
それをFigmaがやるっていうのも全然ありえそうとは思う。
ただここで、
このトピックとしてはコントローラーとしては
コントローラーとしては
コントローラーとしては
コンテンツデザインって書いてるから、
コンテンツデザインか、みたいな。
UIではないのかな、みたいなのも
思うところではあるんですけど。
とか、まあAI系は何かしら入るってのはほぼ確実かなというのは
トピック見てて思いましたね。
あとはなんか、デザインシステム系で言うと、
これはFigmaのヘルプに書いてあるんですけど、
拡張コレクションをエンタープラスに
出しますっていうふうに書いていて、
これがバリアブルズの機能なんですけど、
サブブランドの対応みたいなのを考えると、
要はメインブランドがあって、
メインブランドのブランドカラーみたいなのがあり、
サブブランドはそれがちょっとカラーが変わりますみたいなのって
よくあるじゃないですか。
そういうのを想定した機能らしくて、
だからそういうマルチブランドの機能っていうのは
デザイントークンの全体の設計は各ブランドで統一で
一緒なんだけど、
参照先の値がブランドによって変わるみたいな、
要はその継承みたいなことをしなきゃいけないんですよね。
マスターブランドからサブブランドに継承するみたいなことを
普通に考えるとやりたくなる。
ただ現状のデザインシステム、
バリアブルズのコレクションっていう
アプリを使って、
グルーピングする概念みたいなのがあるんですけど、
それだと継承みたいなのができないので、
1:15:01
Takaya Deguchi
おそらくその継承関係、
一部を継承させて一部をオーバライドしてみたいなことを
するための機能が入るっていう匂わせが
ヘルプに書いてあったんで、
もしかしたらそれが今回のConfigでも
発表されるかもなっていうのは
固いところでは思いましたね。
それは必要そうですね。
今の話はさっきのフレームワークの話と一緒で、
エンタープライズ向けの話なんで、
恩恵を受けるのは本当に全体の数パーセントの
ユーザーだとは思うんですけどね。
でもあれかもね、
kudakurage
AIの使いどころっていう意味では、
コンポーネントとかもしくはデザインシステムとか
っていう部分にも
AIっていうのは入ってくる可能性あるよね。
それはあるかもしれないですね。
すごい簡単に言ったら、
ボタンっぽいコンポーネントを作ったら、
ボタンのバリエーションって必要になることが多いわけじゃないですか。
普通のデフォルトの状態とホバーの状態と
ディセーブルの状態とアクティブの状態みたいな。
それを保管してこれ必要だよねみたいなのを
Takaya Deguchi
ポンって作ってしまうとか。
そういうのとかも含めて。
デザインシステム界隈だとV0っていうバーセルが
実験的にやってるサービスが出てきたことによって、
その文脈の話は結構あって、
究極的には
超抽象的な
VIの
データみたいな、カラーがどうで、タイプグラフィーがどうで
っていうのを加わせて、具体のUIっていうのは
全部生成AIが、具体のコンポーネントというのは
全部生成AIが作ってくれたらいいよねっていうような話。
kudakurage
もしかしたら既存のやつ、
既存画面作っちゃったっていうやつがあって、
ここからデザインシステム適当に作ったよみたいな、
ここにやったら作ってくれるっていうのも
Takaya Deguchi
あり得るかもしれないね。
全然あり得るし、バーセルの場合はV0っていうやつが
ShadowCNっていう、読み方っているか分からないけど、
デザインシステムのライブラリみたいのがあって、リアクトのね。
で、そいつが
簡単に言うと、生成AIフレンドリーなデザインシステムの
ライブラリになってて、
だから基本それをベースにして、
ブランドカラーとかそういうプロダクトによって変わる部分だけ変えて、
あとは
ベースはそれをコピペすれば使えるよみたいな
デザインシステムのライブラリがあるんですけど、
そういうもののフィグマ版みたいなものを作るみたいなのは
全然ありえそうだなという。
てかその流れはもう確実に来ると思ってて、
今デザインシステムね、僕も作ってて、
チクチクコンポーネントを作っているわけなんですけど、
そういうのをする時代っていうのはもうあと1年、2年で終わるんだろうなという気はしてて。
だから各プロダクトのライブラリを
作っていくときに、
1:18:01
Takaya Deguchi
そういうのを作っていくときに、
それをベースにしてUIを作ってくれるみたいな。
それでプロトタイピングをして、
いざそれで検証できていいねってなったら、
そこでプロダクトデザイナーが入ってちゃんと画面を作り込んでいくみたいな。
そういうワークフローに変わっていくのは全然ありそうだなとは思います。
あと数年で大きく変わりますよ多分。
別にデザインシステムを作りたいわけじゃないからね。
そう思いますね。
そう思いますね。
kudakurage
別にデザインシステムを作りたいわけじゃないからね。
Takaya Deguchi
そうなんですよ。僕もいろいろやってるけど、
別にデザインシステムめっちゃ作りたいわけではないっていうか、
作った後に興味があるのであって。
作る過程は別にAIに全然代替してもらって
構わないですよね。
kudakurage
でも一方で僕は作るのも、
設計するのも好きなんだけどね。
でも結局多分その辺は機械に置き換えられていくんだろうなと思うけど。
Takaya Deguchi
そうね。とはいえ全体の
完全に全てが置き換えられるのはもうちょっと先かなとは。
そういうデザインシステム×AIみたいな機能が入ると
個人的には熱いな。
画像とかテキスト生成みたいなのって
どこまで行っても
ちょっと一発ネタっぽいっていうか、
具体のプロダクトをデザイナーで使えるの?
みたいな思ってしまうんだよな。
kudakurage
使うようによっては使えなくはないけど
Takaya Deguchi
そこがフィグマの本丸ではないよなと思ってしまうっていうか。
kudakurage
なんかその
いわゆるシード値みたいなものによって
結構ランダムで当たり外れがあるみたいなさ。
ちょっと前もなんだっけな。
ソラか。ソラを使って
プロモーション。まだソラ自体は公開されてないから
一般には。プロモーションのために
クリエイターにソラを使って作品作ってくれっていうので
あるクリエイターが作って
プロモーションビデオを1分か2分もしないぐらいの
プロモーションビデオを作ったみたいな話が
書いてあったんだけど。
それも結局
なかなか思った通りのもの出てこないから
めちゃくちゃ回しまくってルーレットを
ちょっとでも
使えるものが出てきたらそれをうまく使って
いろいろ編集して手を加えて
頑張ってつなぎ合わせて
1分か2分ぐらいの動画にしたみたいなのを
書いてあったけど。そういうものになっちゃうわけですよね。
Takaya Deguchi
だから。
kudakurage
そういうものっていうよりは
一方でいいなって思う使い方っていうのも
いくつかあるような気がしてて
そういう生成っていうよりは
1:21:02
kudakurage
生成って生成なんだけど
もうちょっとクリエイターをサポートするようなもの
っていうか
完全に新しい新規のものを作るっていうよりは
やってることをサポートしてあげるぐらいのもの
っていう使い方のものっていうのもいくつかあるわけじゃないですか
この前話したアドビの動画のやつ
クレミアプロに使うやつとかも
割とそれに近いものですよね
必要じゃないものが画面に映ってたら
それを消せるようにするとか
ちょっとだけ尺が足りないから伸ばしてあげるとか
新しく全くゼロから1を作っていくっていうものっていうよりは
ちょっとここ
痒いとこが手に滞らないんだけど
みたいなところをAIでサポートしてあげるみたいな
そういうのがフィグマにも入っていくといいんだろうな
っていう気はしてるけどね
Takaya Deguchi
まさにそうですね
画像とかテキストとかコンテンツそのものの生成は
ビッドジャーニーとか得意な人に任せてほしいなっていう気持ちで
UIを作る上での
歯が良いところをカバーしてくれる
AI
っていうかあれだな
テキストスタイルのバリアブルズの移行をAIにやってほしいなとか
そういう
細かい部分のサポートをお願いしたいな
テキストスタイルの
全てのテキストスタイルのフォントサイズ2ポイント上げといて
みたいなのを依頼すると全部やってくれるとか
kudakurage
それはなんか
ちょっとプラグインかけばサッとできそうですけどね
Takaya Deguchi
でもプラグインかかなきゃいけないんだけど
kudakurage
それをやってくれるっていう
Takaya Deguchi
確かにね
そういう路線か
直球でUI生成かみたいな
UI生成は多分ないと思う
kudakurage
だからやっぱり
言ってもサポート
提案とか
この画面だったらここにいつもボタン置いてるから
ここに置くよねみたいなのを提案するとか
元々買収する前にやってたやつ
とかっていうのはあり得るかなっていう気がするけどね
でもそれも
ちょっと使ってないから分かんないけどね
鬱陶しいなって思うかもしれないけどね
うるせえよみたいな
ワードのイルカみたいなね
Takaya Deguchi
イルカ出てきたら面白いな
個人的には
バーセルのV0的展開に期待だな
あとなんか
セッションの一覧の中に出たら
ビジョンプロ的な何かのサポート
1:24:00
Takaya Deguchi
みたいな話
一応アジェンダとしては
From Flash to Apple Vision Proっていう
アジェンダが1個あって
Appleの人が登壇するんですよね
One Infinity Canvasっていう
セッションのタイトルが1個あって
イマシブモードか
の時のFigma
イマシブモード用のデザインをサポートする
何があるのかちょっと僕もよく分かんないけど
みたいなのが
方向性としては1個あるかなと思いましたね
kudakurage
見た感じ発表っていう
発表っていうものなのかな
Takaya Deguchi
発表ではないから
Appleの人がこう使ってますよ
kudakurage
みたいな話すのか
Appleの人のやつはそうなのかもな
2つに分かれてて
The Impact of Flashっていうのと
その後のInfinity Canvas
後半の方は多分Appleの人が
どういう風な感じで使ってるのか
ってもしかしたらされるのかもしれないけど
多分前半の方はFlash時代から
色々培ってきたものを
人とくわもとさんが
Takaya Deguchi
ディスカッションするっていう
kudakurage
これは単純に
Takaya Deguchi
これはこれで結構興味あるけどね
なんかの時にもくわもとさん話してましたよね
kudakurage
もともとドリームウィーバーの人だから
結構ね
Flashとかドリームウィーバーとか
その辺に関しては結構思うことが
Takaya Deguchi
色々あったろうから
これは昔話コンテンツな気がするな
前半は
今後Vision Proでこう使いますよみたいな
ショーケース的な話なのかな
直接的な機能の話
kudakurage
とは思うけどね
Takaya Deguchi
でもこのタイミングではないにしろ
でもなんか真面目に考えると
ああいう没入感的なUIのデザインを
Figma上でするってどうやるんだろうって思うから
何かしらの
そういうサポートが入っても
おかしくないのかなとは思うんですけどね
どうなんだろうな
kudakurage
結構難しい
難しそうだよね
Takaya Deguchi
別プロダクトみたいになるのかな
kudakurage
別プロダクトにしないとさすがに
今のFigmaに統合していくのはさすがに難しいと思うな
Takaya Deguchi
Z軸モードみたいなのが
kudakurage
ある程度Windowsっていう単位で
作っていく分には現状の
僕も作ってるからFigmaでも別に作れるけど
1:27:00
kudakurage
イマーシブモードとか
そういうことになっていくと本当にさ
3次元で考えなきゃいけない
Takaya Deguchi
ブレンダー的な操作感になるのかな
kudakurage
3次元だけじゃなくてもしかしたら
4次元時間軸も入った
体験としてどう作っていくのかっていうデザインを
しなきゃいけなくなるから
現状のFigmaの拡張として作っていくのはさすがに
Takaya Deguchi
難しそうな気がするけどね
ハンリアルとかゲームエンジン的な感じの
製品になっていく
そういうのを買収してやるとかはありそうだな
kudakurage
それこそね僕もちょいちょいたまに
面白そうなやつ使ったりしてるけど
いわゆる3Dグラフィックを作るためのツール
っていうので結構Figmaっぽいツールって最近よく出てきてるんですよね
ウェブでそういうの扱えるものとかも含めて
コラボレーションとかできたりとか
その辺がやっぱり
Vision Proが出てきて発表されて以降
うちはこのVision Proで
上手く使うこともできるみたいなのを
上手くアプローチしながらアップデート重ねていったりするから
その辺をもしかしたら
買収して別プロジェクト作っていくとか
っていうのはあるかもしれないけど
Takaya Deguchi
まあでもないか
最近のFigmaを見てるとそういう飛び道的なのかな
kudakurage
ちょっと手広げすぎになっちゃうかもしれないね
Takaya Deguchi
そこまで行くと
最近は後半だからな
kudakurage
ブランブランとかウェブモードとか広げるっていう上で
なんかいろいろあったけど結局
今はFigmaになってるけど
どこまで行くのかなFigmaも
最近そういう話でいくと
Takaya Deguchi
AffinityもCanvaだったっけ
kudakurage
どっかに買収されて
Affinityは僕もすごい好きで
一時期フリーランスになった時とかに使ってたけど
思想というかね
そういう部分で共感して使ってたけど
ちょっとやっぱり限界あるよね
Takaya Deguchi
限界?
買い切りモデル
Affinityは買い切りっていうのが一個の
kudakurage
なんかアイデンティティなやつ
アドビに対するアンチテーゼなんだよね
ビジネス的なところもあるけど
やっぱりアドビが強すぎちゃうところで
結局僕はAffinityを使わなくなったんですけど
っていうのは
一時期Affinityで使って別にそれは
アドビのイラストレーターとかでも開けるから
それでいいと思ってたんですけど
成果物として共有するものとしては
やっぱりふさわしくないなっていうことになっちゃうんだよね
要はクライアントワークをやるにあたって
1:30:00
kudakurage
納品とかするわけじゃないですか
Takaya Deguchi
最終的に
AffinityでAIファイルを出力するとかできないんですか
kudakurage
書き出しはできるのかな
ちょっと僕も覚えてないけど
本当の大元のリソースはAffinityになるわけじゃないですか
多分完璧に
AIファイルとして書き出すっていうのもなかなか難しいだろうし
考えた時に
最終的には結構
1年ぐらいはAffinityで頑張ってやってたことがあったけど
やっぱり他の人と協業するとか
クライアントワークで納品するってなったら
やっぱりAdobe使わなきゃいけないかなってなって戻ってきたんだけど
ビジネス的な部分で
買い切りですごい嬉しいんだけど
そういうビジネス的な部分も難しいし
現状のシェアとかワークフローとか考えると
っていうのも難しいしみたいなので
思想とかそういうものとしてはすごく好きなんだけど
なかなか難しいなって思って
いたらやっぱりビジネス的に難しそうな感じがあって
最近買収されてみたいなのがあってみたいな
感じだったんで
Takaya Deguchi
デザインツール業界の中での
攻め方として
キャンバみたいなデザイナーをターゲットにしていくっていうのは
フィグマを超えるやり方として
1個あるかもしれないですよね
kudakurage
最近キャンバ系のAIみたいなのも
最近よくちょっと出てきたりしてるから
そっちの方がAIとは一緒に良さそうだよな
Takaya Deguchi
プロイエスじゃないケースの方が
kudakurage
アドビブもそれに対して対抗ツール出してきたりしてるんで
最近キャンバ向けっぽい感じの
対抗のAI絡めたやつとか
だからまだその辺はね
キャンバもアフィニティを買収したのは
さらに頑張っていじりたい人向けのツールを
Takaya Deguchi
提供するっていうところでアフィニティ買収してるんで
kudakurage
すごい良い買収ですよね
さらにそこからまたAIも含めてってなっていくと
っていう意味では
その辺も結構期待は今後
できるのかもしれない
僕らが使うものになるかっていうのは別かもしれないけど
Takaya Deguchi
前ちょっと手伝ってたスタートアップで
インターン生がインスタグラム用の
クリエイティブをめっちゃ作ってる会社があったんだけど
そこは完全にノンデザイナーがそうやって作ってるから
キャンバがデフォルトになってて
キャンバの方がやっぱそういうインスタ向けの
テンプレートとか充実してて作りやすいとか言ってて
そうやって浸透していくんだなっていうのは
すごい思いましたね
kudakurage
何が言いたかったかっていうと
そういうカウンターがいっぱい生まれていって欲しいなっていう
そうなると
1:33:01
kudakurage
スケッチフィグマで止まるんじゃなくて
またさらなるものとかも含めて
Takaya Deguchi
そうなるとアドビニになりそうでならなかったフィグマは
どうなるんですかね
kudakurage
どうなるんですかね
結構難しいなと思うよね
今後買収できるのかとか
マイクロソフトだったらできるのかな
Takaya Deguchi
承認されるのかな
どうなんですかね
買収される側なのか
あるいはフィグマがいろんな会社買収していってどんどん大きくなっていくのか
どっちを描いてるのか分かんないけど
買収されるならマイクロソフトと一緒になってほしいな
っていう気持ちはあるな
kudakurage
さっきの話で
Takaya Deguchi
GitHubとかのインテグレーション考えるとそうだよね
kudakurage
もっとしてほしい
Takaya Deguchi
AIっていう意味でも相性はいいかもしれないしね
MS以外なさそう
買収できそうな会社で
Amazonとかはないだろうな
Googleもないだろうし
kudakurage
マイクロソフトぐらいしかない
Takaya Deguchi
ないな
kudakurage
ディランさんがどう考えてるかだよね
Takaya Deguchi
何がしたいんだろうな
悪い意味でフィグマには
悪い意味でアドビにはなってほしくないなと思ってて
課金の仕方みたいなところ
すごいベンダーロックにするところみたいな
さっきのデブモードとか
そうなりかけてるなって思ってしまったから
うまくオープンさと
グラデーション作るみたいな
さっきの話のやつを
実現されるといいなと思うし
kudakurage
まあでも
すごい楽観的に考えてるけど
そういう風になったらそういう風になったで
また別の何かがカウンターとして出てくるんだろうな
Takaya Deguchi
ペンポット
kudakurage
フィグマとかも割とそういう感じだと思ってたから
元々一番大きいのはスケッチだと思うけど
クサビを入れたのは
アドビではないものとして
クサビを入れたものとしてスケッチがあって
そこからの流れとしてインビジョンだったり
フィグマだったりフレーマーだったりいろいろあったけど
だからそういう風な流れになったら
また新たな何かが出てくるんだろうなっていう気はするけどね
Takaya Deguchi
そうですね
っていう割と大きめの機体もあれば
細かいところの改善も
いろいろ言いたいところはあるなとは思ってて
なんかこう
例えば
マリアブルズで言えばさっきの話もそうだし
シャドウのトークンにも早く対応してほしいなっていうところもそうだし
あとコンポーネントも何か
1:36:01
Takaya Deguchi
スロットとか呼ばれてるやつ
今ってタブナビゲーションとか
アイテムを複数連ねるようなコンポーネント
リストアイテム リストコンポーネントとか
そういうやつってちょっと作りづらいじゃないですか
現状ってタブナビゲーションとかだったら
5タブとか上限を設けて
5タブ用のコンポーネント作って
使う側で数のコンポーネントを作って
それによって
使う側で数減らすみたいな
非標準するみたいなアイテムを非標準してタブの数減らすみたいな
感じになってるけど
なんか
エンジニア的な視点で見ると
大体リアクトのコンポーネントとかだと
チルドレンっていうプロプスが生えてて
リストっていうコンポーネント作ったら
チルドレンっていうプロパティに
子供の中に入れるコンポーネントを
食わせるみたいな感じの設計になるんですよ
そういう感じにできるといいなっていう
上限があるタブとか
ヘッダーにアイコンが並ぶような
ナビゲーションとかだと現状でもいいんだけど
リスト系の上限が無制限の
子供が無制限に増えていくようなコンポーネントって
現状ちょっと作りづらいところあるじゃないですか
フィグマ上で
その辺もうちょっとなんとかならないのかなっていうのは
思ったり
あとデザインステム作っていく中で
フィグマがまだ未開拓な領域としては
命名規則的な話
なんかこう
コンポーネントの名前の付け方とか
バリアンツのプロパティの名前の付け方とか
そういうのを結構エンジニアリングと
密接にかかってくるところではあるから
例えばコードコネクトとか
あと最近の
フィグマのVSコード向けのプラグインみたいのが出たじゃないですか
VSコードから
エディターからフィグマが開けるみたいなやつ
そのプラグイン使うと
フィグマのレイヤーの名前
フレームの名前が
コードを書くときの
変数の候補として出てくるみたいなやつが
あるんですよね
そういうのが出てくるとより命名っていうのがすごい大事になってくると思うんですよ
ただなんかデザインするときに
命名を頑張って考えようっていうマインドになかなかならないっていうか
デザインが
デザインフェーズまったたなかみたいなときに
ちゃんと命名考えてみたいなところはあんまりやらないと思うんですよね
だから大体こう
デザインがフィックスしてきたら
ちゃんと考えるかみたいなことになると思うし
1:39:00
Takaya Deguchi
そこにデザイナーが何人か複数でデザインしてたら
余計命名規則ちゃんと作るのは難しいと思うんで
なんかそういうところのサポートみたいなのが
あるといいなと思ってて
エンジニアリングの世界ではテキストリントとか言います
リンティングツールみたいなのがよくありますけど
そういう規約に違反してたらエラーが出るとか
自動で修正してくれるとか
そういうのとかありそうでまだFigmaやってないなみたいな
やってほしいなと思うところではありますね
これもデザインシステム作る上での視点だけど
っていう
そういう
コンフィグは
そういう期待がありますね
来月1ヶ月後くらいには分かるとは思うんですが
AI
さっきのAIかけるデザインシステムみたいなところは
確かにあんま考えてなかったけど
やってくれたらすごい熱いなと思いますね
でもなんかもう一方で
kudakurage
最近のスマートフォンみたいにあんまり期待してない
っていうかもうある程度成熟しちゃってるから
あんまりそんなに期待することもないっていうところも
僕はあるんで
Takaya Deguchi
それはありますよね
僕はデザインシステムの仕事今やってるからホッとだからこう話してるだけで
なんかやってなかったら別にえーっつって
なんか出てんなぐらいな感じだったと思う
もしかしたらやっぱりあれなのかもしれないね
kudakurage
次の次元に行く新しいデザインツールとかっていうのを
考えるっていうフェーズになるっていうのは
それこそやっぱりビジョンプロとかそういう世界観に入ってきた時に
また新しいものが必要になっていくとか
そうかもしれないね
冒頭言ってた最近のアップデートも
Takaya Deguchi
大多数の普通にフィギュア使って
プログラムデザインしてる人たちにとっては
そこまで関係ない話だと思うから
てかそんなに振り回される必要もないかなと思うし
そうね
だいぶニッチだなとは思いますね
そんな感じかなっていうので
個人的にはそういう仕事を今してるので
すごいホットトピックではあるので
コンフィグも昨日とかも結構ガッツリ見そうだなと
思ってるんで
また来月あたり話そうかなと思います
はい
kudakurage
では終わりますか
リサイズFMへのご質問やご感想
リクエストなどはXにポストしていただくか
ショートノートにあるお便りのリンクから送っていただければ
配信内で取り上げたりしますので
どしどしいただければと思います
リサイズFMは毎週金曜日に配信しています
Spotify、Apple Podcast、YouTubeなどで配信していますので
よかったらチェックしてみてください
1:42:00
kudakurage
ということで今回はここまでまた次回お会いしましょう
Takaya Deguchi
さよなら
