00:00
[音楽]
こんにちは出口です
こんにちは本山です
リサイズ編は、本山と出口が最近気になっているサービスやデザイントピックスを取り上げて
のんびり話すポッドキャストです
よろしくお願いします
お願いします
ちょっと前に
僕が言えなくなりそうって話したと思うんですけど
いやもう、ギリギリのところで回避しまして。
うんうん。
もう、回避するの大変だったんですけど、すごい。
うん。
で、まあ、元々海の方に住みたいなっていうのもあったんで、
平塚市とか大磯とか、辻堂とか、まあその辺、千賀崎とか、
まあその辺の物件をずっと探してたんですけど、
まあ結果的にちょっとその辺りの場所に住めることになって、
今、ようやくちょっとずつ落ち着いてきたっていう感じなんですけど
良かったですね
いや、本当に一時はどうなるかなっていう感じだったんですけど
なんか本当に、なんだろう、家がなくなることを覚悟していろいろ準備もしてたんですけど
まあ、なくなるって言っても、一時的にちょっと他で借りてるオフィスのところに、一時的に対比するというか。
ちょっとそこで忍ごうかなって思ってたんだけど。
いやでも、さすがになんか、2階引っ越すの面倒くさいなぁと思って。
うん、面倒くさいですね。
手続とかもさ、色々あるじゃん。なんか、単純に人と荷物の移動だけならまだいいんだけど。
いやもう、それさすがやっぱきついなと思って、そのギリギリのラインのところでもう、わーってこう決めるっていう
めちゃくちゃ滑り込みで
住み心地はどうですか?
いやまあ、いいですよ
一軒家っぽいとこなんすよね
ああ、そうですね、ちょっと一軒家っぽいとこなんですけど、ただまあ駅から遠いんですよね
その で まぁ 別に 僕 車 持っ てる わけ で も ない ん で まぁ 車 買っ て も いい か な と か ちょっと 思っ た けど
その 駅 から 遠い から ろう か な と 思っ た ん だ けど
まあ で も 言っ て も そんな に 電車 に 乗る こと も なく まぁ 都内 に たまに 行く こと は ある ん だ けど
まあ で も 自転 車 で 行け ば
そ そんな に その 不便 じゃ ない と いう か
感じ だ し
で まぁ 結構 だ から その 住宅 街 と いう か 外れ の 方 な ん です よ ね
その駅から離れて。
で、まあスーパーとかなんかお店とかも遠くなるかなってちょっと心配してたんだけど、
まあなんかよくよく探してみると近くにあって、
で、なんかちょっとした居酒屋とか、レストランというかランチが食べれる場所とか、パン屋とか、
03:01
まあそういうのも割ともうすぐ近くにあって探したら、
まあ全然悪くないなみたいな。
お前よりも栄えてる感じですか?
いや、お前より栄えてるかって言われるとちょっと、まあわかんない。
どっちもどっちって感じなのかもしれないけど。
まあでも、僕は海寄りの街なんで、駅からも遠いっていうのもあって、
駅周辺だったらすごいお店とかもいっぱいあったりする場所なんだけど、
結構、海寄りでなんか、住宅街って感じなんで、
めちゃくちゃお店がいっぱいあるとかって、そういう感じじゃなくて、ほとんど家なんだけど。
でも、やっぱり海が近いから、最近、本当めちゃくちゃ海に行ってるんですよ。
海に行ってるって、別に海に入ってるとかなんかしてるわけじゃないんだけど、散歩してるだけなんだけど。
どれぐらいなんですか?家から。
いやでも歩いて5分か8分とか、10分かかんないぐらいではもう普通に着いてますね。
うーん。
良さそう。
そうそう。
いやまあなんかさ、結構その、完全にリモートワークというか、ほとんど家から仕事するっていう環境になったから、これこれで。
今までオフィスがあってオフィスに行ったりとかっていうのがあったりしたんだけど
だから結構意識して外に出るようにしてるっていうところもあるんですよ
逆に完全一人の期間ってこれまでなかったんですか?
完全一人
完全に一人ワークというかオフィスにも行かずみたいな
まあフリーランスやってた時もあったんで、別にその時は一人というか
まあでもその時代はミーティングとかもあったのか
ああそうそうそう、だからね結構出向いてそこのなんか事務所でオフィスで仕事したりとかっていうの結構あったりしたんだけど
確かにね、キベラ作ってる時うちのオフィスで寝たりしてましたもんね
寝たりしてたっけ?
寝袋をキベラの会社のオフィスに持ち込んで寝てましたよね、モトヤマスさん。
ああ、ちょっと切羽詰まってる時、やったかもしれないですね。
ちょっとやんなきゃいけない仕事がいっぱいあって、徹夜でやるから、ちょっと仮眠取るために。
寝袋持ち込んでいいっすか?とか言って、持ち込んでましたよね。
だから結構、だからそう、そうなんだろう、家でほとんどやってるから、もう下手するとさ、やっぱ出ないじゃないですか、ずっと。
うん。
なんか、ちょっとご飯買いに行くときぐらいしか出なくなっちゃうじゃないですか。
うん。
なので、意識して、できるだけ一日一回は外に出るようにしてて、今。
うん。
で、まあ、朝か夕方か、よくだからそれで、その海の方に散歩に行ってるんですよね。
06:05
うん。
ああ、と。
いや、偉いですね。
僕は気づいたらもう2週間外出ないのか。
そうだからね。
いやでもなんか、それのおかげか、
今までよりも多分、ちゃんとこう、なんていうの、ちょっとした運動というか、外に出てるっていうのがあって、
ちょっとね、ちょっとだけ痩せてきてるんですよ、なんか。
へー、その散歩で?
たぶん、まあ散歩とかじゃないかな、きっと。
へー。
いやだから、出たほうがいいよ、外に。
うん、そうですよね。出た方がいいと間違いなくそうだと思う。
いや、本当に出て良いなと思う、なんかやっぱり。
まあ今の季節ね、まだちょっと海なんだろう、季節じゃないっていうかあれだけど、
まあでも普通にまだ寒くないからそこまで、気持ちがいいしね。
逆に夏の方が日差しを遮るものが全くないから、浜辺って。
ああ、そういう感じなんですか?
そうそうそう。
だから、夏の方が多分暑いと思うんだけど、
今、昼間とか逆にもう暖かくてちょうどいいぐらいだもんね。
うーん。
まあ、風が強かったりするけど。
うん。
いや、浜辺で仕事もできそうです。
そうですね。一応ヘリノックスチェアのビーチモデルも持ってるんで、それ持ってけば仕事できなくもないですね。
それいいな。
こなれてきたらね、もうちょっとランニングとかそういう運動もしていこうかなと思ってるけど、まだ体が重たいんでずっと運動してなかったのもあって。
当面は、なんか散歩をずっとやっていこうっていう風に思ってますけどね。
散歩ね。
いや、コンソールでやらなきゃいけないなとは思うんですけどね。
なんかその、なんかこう、目的のない、なんかこう、散歩が苦手なんですよね。
あ、そう?
苦手っていうか、なんか、やろうと思わないとできない。
まあまあやろうと思わないとできないけどね正直散歩なんて
でもなんかできるだけ本当は朝に散歩したいなと思ってて
朝できるだけ早く起きて散歩して
そっから仕事するみたいなの
たまにしかできてないんだけど朝は
そうするとなんか結構いい感じに1日が回せるなーっていう気はしてるんで
いや、釣りしたらいいんじゃないですか。
うん、ちょっとね、ある程度余裕が出てきたら、釣りもしたいなぁと思ってますね。
09:02
なんか結構、浜から投げ釣りしてる人が多くて。
浜から釣れるんですね。
うん、みたいですね。
なんか、土曜とか日曜とか祝日とかは、本当朝行くと釣り人だらけですよ。
へぇ~。
まあ、サーファーとかもね、あの、よくなんか、なんか状況が良かったら結構いたりすることもあるけど。
あとなんか、夕方ぐらいになると、今夕方ぐらいも散歩よく行ってるから、なんか見てると、
まあ、たくさんはいないけど、なんか小学生とかね、そういう人たちも夕方ぐらい、平日の夕方とか、なんかツリしてますね。
なんか僕、江東区の、まあ深川エリアというか、なんかまあウンガとかがいっぱいいくつか通ってるエリアなんですけど、
なんかそのウンガでも釣りしてる人いますね。釣れるんだって思うけど。
いますよね。その辺も結構、僕の友達も、なんかよく子供と、その辺に釣りに行ったりとかしてた気がするな。
うん。
たまに乗り合い漁船みたいなのもなんか出てますね。
東京湾に向けて。
じゃあ今日はFigma Schema の話をしようかなと思うんですけど、
まあ去年もやってた Schema Conference っていうFigma のカンファレンスで、
本当は全部通して全部の話したいなと思ったんだけど、
まだちょっと録画とか公開されてないっぽいんで、とりあえず僕リアルで東京のイベントに行ったんで、それの話をしようかなっていう感じですね。
Figma ってなんか大きいカンファレンス2つあって、1つがスキーマでもう1個がConfig ってやつで、Config は、いつだっけあれ、春頃だっけ、やってて前も話したと思うんですけど。
Configureはどちらかというと、Figma Community 全般みたいな感じで、
Figma に関係ないデザインに関する話とかも、
デザインに関する話が全般あったりとかするという感じだと思うんですけど、
Schema はデザインシステムに特化した話が多いというようなカンファレンスですね。
Figma が声をかけて登壇者を集めているみたいで、
スキーマのイベント通して、Figma の営業というか、
みたいないいともあるのかなっていう感じで、
割とConfigとかに比べると大きい会社、
常常企業とか、メガベンチャーとかが登壇に多いような感じのカンファレンスですね。
僕は品川でやってて、品川の会場に行ったんですけど、
なんかめっちゃ豪華で、基本無料なんですよ、参加者はね。なんですけど、なんか軽食もついてるし、飲み物も飲み放題だし、
12:05
なんかこう、グッズとかもなんか結構、いい感じの糖とかもらえたりとか、
あと、一部、アトラシアンの人とか、フィグマンの人とか、英語で発表の人もいるんですけど、
ちゃんと同時通訳ついてたりとか、めっちゃ豪華な感じでしたね。
UBIの谷さんっていうデザインエンジニアの谷さんが、フィグマの人じゃないけど、MCとして登壇してて、
各登壇者が登壇する前に毎回紹介をしてみたいな感じで、大変そうでしたね。
最初は気になったやつだけ話そうかなと思うんですけど
最初はフィグマの桑本さんっていう
型書きなんだっけ? VP of Product かな?
桑本さんは元々マクロメディアに10年ぐらいいて
その後フィグマに行って、今回アドビに買収されて、またアドビに戻ってきたみたいな感じだと思うんですけど。
もともと日本で生まれ育って、幼い頃にアメリカに家族で移住したみたいな感じみたいですね。
話の内容的には、去年もあったんですけど、ストラクチアートデザインとフリーフォームデザインっていう、デザインってその2つがあるよねみたいな話があって。
フリーフォームデザインっていうのはなんかこうキャンバスに矢を描くみたいな感じで、
その構造みたいなものがなくて、自由にできるデザイン。
基本的に作って壊しの繰り返しに強いようなタイプのデザインっていうのがあるよねっていうのと。
あとストラクチャルデザインっていうのはその逆で完全に構造化されたデザインだから、
コンポーネントとかそういうものを使って
そういうのを組み合わせながらデザインするから
なるべくコンポーネント作ってインスタント作って
デタッチをしないみたいな
逸脱をしないような構造化されたデザインという
大きく二つがあって
Figmaっていうのはフリーフォームとストラクチャーとの
両方をサポートしたいっていう思想があるっていうのは
改めて言ってて
新しい話としては、デザインシステムが日々複雑化しているように、という話がされていて、
そもそもフリーフォームって、なんでストラクチャーデザインがあるかというと、
フリーフォームデザインだけだと、デザインを管理する立場に立ってみると、
やっぱり統一性を保つとか、そういう観点で、
なかなか完全に自由だと難しいよね、という中で、
本来フリーフォームであるデザインという料金の中で、いかにストラクチャーを実現するかというのが大事みたいな話の中でデザインシステムというものを、またフィグマはサポートしていると思うんですけど、
15:09
ただデザインシステムをサポートするっていうだけっていう中でも
やっぱ最近Figmaの新しい機能とか見ていくと
どんどん高度なデザインシステムに対応するような
アップデートがされてると思うんですよね
例えばオートレイアウトの中に
最近ついたじゃないですか
アブソリュートで配置するみたいな
だからいかにストラクチャードの中に
フリーフォームとのバランスを取るかみたいなところを
結構試行錯誤してるのかなって思うんですけど
それによってストラクチャルデザインでも
表現できることが増えてきた
それを複雑化と言ってると思うんですけど
例えばレイアウトって意味では
レイアウトとかテーミングとかプロセスとか
いくつかの軸に分けて話があったんですけど
一つレイアウトっていう軸では
グリッドとかフィードとか
グリッドの中でもツーカラムとか
そういうレイアウトってあると思うんですよね。
特に言ったら、例えばカードコンポーネントみたいなのってよく作ると思うんですけど、
カードコンポーネントって、カードの中身には何が入るかっていうので、
結構ストラクチャードにするのって結構難しかったり、
アーシュが出やすかったりするっていう。
最近だと、ネステッドコンポーネントって呼んでましたけど、
コンパネートをネストすることによって
県パターンが多くて足が多そうに見えるものを
いかにストローキュアにするかっていうところの
取り組みというか
苦労がありますよねみたいな話
でもう一個がテーミングっていう軸だと
今って単一ブランド単一プロダクトであっても
ライトモードダークモードに対応する
みたいな感じで
一つのカラースキムではなくて
複数のスキムに対応しなきゃいけないとか
それが事業が高く化していって
メルカリーだけだったものがメルペイとか
そういうのがマルチプロダクトになっていくと
そのプロダクトも増えていって
それに関連してテーマが増えていくこともあるし
GMOとかそういう全然違うブランドを
複数管理してるような会社だと
そういうマルチブランドになると思うんですけど
そういうものをいかに実現するか、みたいな苦労ってありますよね、みたいな話。
で、その中でキーワードとして挙げてたのが、ヘッドレスデザインシステムっていう考え方が最近出てきた、みたいな話をしていて、
これちょっと後でまた取り上げようかなと思うんですけど、
ざっくり概要言うと、完全に構造と表現の部分を分離して、
それでメタデザインシステムじゃないけど、複数のカラースキームがある場合でも適用できるように、テーマを切り替えれば適用できるようにする作り方とか、
18:05
最近Figmaユーザーの中から出てきてますみたいな話。
あと3つ目がプロセスっていう軸の話で、
岡本さん自身がデザインシステムって作ってもそんな更新しないじゃないかって、昔は思ってたっていう話をしてて、
ただそれがデザイナーが20人とかになってくると
やっぱり毎日1回2回デザインシステムに
アップデートが入るみたいなことになってきていて
そうなってくるとやっぱり何らかのプロセスをちゃんと
定めるっていく必要があるっていうことが
改めて分かってきたみたいな話をしていて
そのプロセスのその一つがマージとかブランチングですね
そのブランチ切って新しいデザインシステムに対する
機能を追加して、マージしてみたいな。
それによってFigmaも最近同じような機能をサポートしてると思うんですけど、
それが多分実現されたのかなって思うし。
あとは最近はテスティングも大事だよねみたいな話をしていて、
まさにエンジニア世界にあるユニットテストとかあると思うんですけど、
デザインシステムにおいても、ビジュアルレグレッションテストっていう、
ビジュアル回帰テストってやつなのか、
デザインシステムとかコンポーネントの見た目の差分があるかどうかを取るようなテスト
っていうのも大事だよねっていう話をしてましたね
で実際僕も今年のなんか1回話したと思うんですけど
クックパッドの春先にクックパッドの仕事中に座ってて
そこでも実際デザインシステム
エプロンっていうデザインシステムを作ってる中で
このビジュアルレグレッションテストを導入するみたいなことを
実際やったりとかしてましたね
だから結構そういう大きめなデザインシステムになってくると
本当にこのコンポーネントごとに差分があるかどうかっていうのを目視で確認するとか難しいから
だからそのビジュアルレグレッションテスト、VRTっていうんですけど、VRTの仕組みを入れるっていう
チームは結構増えてきてるのかなっていう感じがしましたね
それはなんか差分を出してどうテストするんですか?
それは厳密なテストというか差分があるからこれは意図通りなのかどうかというところを
レビューするっていうね
そうレビューするという感じですね
もしくは完全に正としたものに対して意図しない変更が入ってたら
試合をこけさせるとかそういうのもあると思うんですけど
もちろん意図通りの変更を加えることもあるから
主には意図してないところに差分が発生してないかっていうのを確認するためのツールっていうような感じですね
はいはいはい
そういうのを効率化するためのものってことですね きっと
変えたけどどこが変わってるっていうのが一々全部見てるのが難しいんで
その差分だけを見てるようにっていうようなことですね
21:02
そうですね 意図せずなんかパディングが膨らんでるとかそういうのを検知するような感じですね
そういうレイアウトとか低微量化プロセスとか
そういうデザインシステムに必要とされているものは複雑とされている中で
Figmaが一部サポートしているものもあれば
テスティングとかまだサポートできてない部分とかもあると思うんですけど
やっぱりこういうのって複雑なのに対してどう対処するかって言ったら
結構エンジニアリングの世界、コードの世界っていうふうに呼んでたけど
コードの世界からの考え方の流用って役立つことが多いですよねっていう話をしていて
そのコンポネートをネストするっていうのも まあそもそもコードの世界というか
HTMLとかReactとか そのコンポネートをコンポジションするみたいなのって
まあ昔からよくある話だし
そのテーミングのさっきのヘッドレスデザインシステムってやつも
まあ結構今っていうか ここ4,5年ぐらいかな
ヘッドレスCMSとか、構造と表現の部分を分離するみたいな考えで、
特にフロントエンドの世界って流行ってるというか、
主流になってきてると思うんですよね。
例えば、JAMスタックみたいなのがあったりとか、
あとはなんだろうな、
前、Shopifyの話をチラッとしたかもしれないですけど、
Shopifyもヘッドレスコマースみたいなのをやろうとしてたりとか、
いかにシステムと表現の部分を分離するかっていうのを
考え方が結構フロントエンド中心に流行ってきてるから
そういうのをデザイン取り入れるっていうのもありだよねとか
あとさっきのブランチングとか
テスティングっていうのは まさにコードの世界の考え方の話だよね
っていう感じで
やっぱりそういうコードの世界から学ぶことは多いよねみたいな話をしてましたね
今だからデザインっていうのはまあ過去すごくシンプルなもの
そのなんでしょうね
昔のデザインツールみたいな単なるキャンバスがあって
そこにドロイングするみたいな感じのシンプルなものだったんだけど
まあどんどんどんどん複雑化しているっていうような話があり
まあその複雑化した世界の先には
まあやっぱコードの世界が今実現しているものに近づいてるよね
みたいな話をしていて
ただやっぱりデザインってのは本質的にフリーフォームなものだから、そのフリーフォームなデザインってのも大切にしたいみたいな話は、フィグマの重要な思想として、それは大事にしたいみたいな話をしてましたね。
そうだよね。
なんか、こう、まあ、ストラクチャーのデザインって、まあ、すごく重要なものではあるけど、
なんかこう、それに縛られて作るようなものでもないような気はしてるんですよね、やっぱり。
そうですね。
24:01
だから、その新しく何か、まあその、既存のものに付随するものとして新しい何かを作るっていうふうに考えた時に、
じゃあ果たしてそれはストラクチャーのパズルを組み合わせて作らなきゃいけないものなのかって言ったら やっぱりそうじゃないじゃないですか
それに適したものをまず考えるべきだと思うんですね
っていう意味で、デザインシステムって言っても ただコンポーネントの予選集めじゃないことの方が多いと思うので
特に今は、ある程度思想だとか、もうちょっと原始的な、アトム的な考え方とか要素とかってあるじゃないですか。
やっぱり色だとか、雰囲気というかスタイルというかテーマというか。
その辺はもちろん、ソウとかっていうのはあると思うんだけど、同じサービスの話をしてるんだとしたらそれはね。
だけど やっぱり それ もうちょっと細かい単位というか どう見せるかっていう部分は
やっぱり それ 新しく考えるものがあったとしたら それに合った形だとか形態があるとは思うんだよね やっぱり
そうなった時に 最近だとデザインシステムが「もう作りました」とか 「やってます」みたいな話ってあるけど
それをどう活用してるのかっていう話が まだあんまり見えてこないなっていう気がしてて
実際にどう運用されてるのかとか それを使ってどんな人がどんな風に活用してるのかっていう部分
結構そのっちの方が重要じゃないですか 作ることよりも
その辺は結構気になるところですよね。
ただ単にストラクチャーにして縛りをつけていくだけじゃないと思うし、
それを使ってどういう風にうまく役立ったのかとか。
僕は新しいコンポーネントを作りがちなところもあって、
だからそういう意味でデザインシステムを作ったんだけど、
そこから逸脱したものを作ることもよくあるみたいな
結局そこから修正して戻ってくることもあるんだけど
もともと考えてたものっていうか ストラクチャードのものに
なんかその辺 他の人たちはどういう思考でやってるのかなとかっていうのは気になったりするんですよね
そうですね
僕 どっちかというと エンジニア比率が高いから
基本的にストラクチャードな世界で 仕事をしてると思うんですよ。
というか、どっちかというと、立場的にデザインされたものを ストラクチャーな世界に持っていくっていう仕事が多いですけど、
デザインの世界でストラクチャードをやってるのって なんでなんだろうなって思うことがたまにあるんですよね。
27:08
はいはいはいはいはい
まさにこう、岡本さんが言ってた通りで、デザインって本質的にフリーフォームなものだから、そこをなんでこんなにストラクチャードにすることにみんなが構ってんだろうな、みたいなところは思うことはあり
コードの世界って完全にストラクチャードな世界だと思うんですよね。
でもコードの世界でもフリーフォームなことをやりたい人たちっていると思って、
それってプロセッシングとか、いわゆるクリエイティブコーディングと言われているような世界のものって、結構ストラクチャードなコードなんだけど、フリーフォームな表現を実現するためのツールを作ったりとかしてると思うんですけど、
でもやっぱ本質的には、基本的にはストラクチャードなものだと思うんですよね。
だからデザインを作ってそれをデジタルプロダクトにするってことはフリーフォームなものをストラクチャーと変えてるエンジニアが変えてる感じだと思うんだけど
デザインの世界もストラクチャーでコードもストラクチャーで、何ていうの、二重管理してる感じにすごい見えることがあって
だから何だろう 完全にもうちょい この界隈が進化すれば フレーマーとかフィグマもやろうとしてる
デザインから行動を起こすみたいなことを 完全に自動でやるみたいな世界であれば
デザインをストラクチャーにする意味って あると思うんですけど
今ってエンジニア改善するわけだから 人がストラクチャーに起こしてるわけじゃないですか
であれば、角にデザインの世界を ストラクチュアにする必要ってあるのかなって思ったりもしますね。
まあなんだろうな、何か考えるときに、 そういう構造化されたものをベースに考えると、
まあ 比重はあるんだけど 思考が固まりがちというか そうなってしまいがちなんじゃないかなって気はしてるんで
結構 僕はだから そういう意味では 忘れるんですよね 一体それを
一回 あえて忘れて考えて その上で ここはこれで置き換えられるよねっていう部分を直していくというか
徐々に ストラクチャーの方に寄せていくというか
っていう思考をしてることが やっぱり多い気がしていてそこは
なんかそうしないと 思考がやっぱり狭められてしまうというかさ
逆に制限されすぎてしまう
もちろんなんだろう 人によると思うんだけどそこって
例えばデザイナーはそういうのが そういうふうにやってもできるけど
逆にデザイナーじゃない もしかしたらビジネス職とか
30:00
そういう人たちにとって 同じように考えようと思ったときに
手がかりが何もなさすぎて考えられないってこともありえるんで
もしかしたらそういう人たちにとっては
そういうある程度構造化されたものがあった方が
助けになりやすいとかっていうのはあるかもしれないと思うんですよね
だからそういうなんだろう
いろんな人がデザインに関わっていくっていう文脈では
やっぱりそういう構造化されたものって必要だろうなっていう気持ちもしてるんだけど
やっぱり一方でデザイナーがやっていくっていうふうになった時に
その構造化されたものを並べて 画面を作っていくっていうのは
ちょっと違うなっていう気もするっていう 両側面があるというか そこって
まあ なんか そこ 答えはなかなか出ないんだろうとは思うけど
デザインシステムがどういう役割
どういう人たちにどういう役割になっているのか どう使われてるかって
一番最初の方に話した話 戻っていくんだけど
っていうのが結構気になるなっていうのは そこもあるんですよね やっぱり今から
まさに今の話に対して カーンウォルツさんも言ってたのは
デザインシステムを考えるときの フレーミング
デザインシステムを使うときのフレーミングとして
Reduce the change of making a mistake って言ってたけど
間違いを減らすっていうフレーミングは 止めたほうがいいみたいな話をしてて
デザインシステムによって人を制約して、とにかく間違いを減らすんだ、エラーを減らすんだみたいな
考え方でデザインシステムに向き合ってしまうと、それは自由なデザインを阻害してしまうから
それは違うんじゃないかみたいな話をしてて
そうじゃなくて
Reduce friction so we can increase creativity って言ってたけど
クリエイティビティを生むために摩擦を減らすっていうようなフレーミングの方がいいんじゃないかみたいな話をしてて
摩擦っていうのは例えばなんかこう色はこれって決める
こここのプロダクトはこの色しか使えませんって決めるんじゃなくて
ある程度複数のバリエーションがある中でデザイナーはそこを選べるみたいな
まあでも完全にオリジナルを作るとそれはそれでそれが摩擦を生んでしまうから
ある程度の緩い制約を設けることによって その中からデザイナーがクレイティビティを発揮できるようにするみたいな捉え方の方がいいんじゃないかみたいな話をしてましたね
だからそうなんだよ それは結構Appleとか Googleが出してるマティアルデザインみたいなガイドラインにも似てるようなところが僕はあるかなと思ってて
ある程度、そのなんていうの、構造化されたものに沿った方が、基本的には良かったりするわけです。
まあ、それなりに考えられてるものだし、それってものだったりするから。
33:01
だけど、それよりもこっちにした方が、オリジナルで作った方がいいよねっていう部分っていうのは、
やっぱりそれなりの覚悟を持って、やっぱりそこって決断するべきところでもあるわけですよね、やっぱり。
だからそこって。
それは やっぱり Apple の iOS の Human Interface Guideline とか その辺のやつとかを乗っ取った方がいいんだけど
そこから外れるときは 結構 これは やっぱり これじゃないとダメなんだっていう強い意志があるように
デザインシステムの場合も同じな気がするんですよね
これはすごくいい話だなと思って
あとなんかあれだわ、そういえば、今日ちょっとなんかチラチラ、デザインシップのキーノートとか発表を見てたりしてたんですけど、
一番最初のキーノートかな、Nozainaっていう会社の立川さんっていう方のお話があったんですけど、
立川さんが書いた『進化志向』っていう本の話がベースでほとんど話をしてたんですけど、
これ何かといったら、デザインの手法というか考え方というかやり方っていうのを、
他のものから学べないかって考えたときに、自然界から学ぶことができるんじゃないかっていうふうに考えたものが、この進化思考っていう考え方なんですけど、
例えばデザインの場合だったら観察するっていうことと
何だったっけな 観察することとそれを形態として形作ることが必要だと思うんですけど
形作るアイデア出すとかっていうことだったりすると思うんですけど
何が必要かって言ったら、進化でも同じなんですけど、進化って結構なイレギュラーが生まれて、それが環境によってさたされ、減っていったっていうか、適応していくものとそうじゃないものが分かれていったっていうような考え方じゃないですか、基本的には今ので。
それに近いんじゃないかなっていう話をしてて、その時に。
なるほどね。
そうなった時に、デザインを考える、例えばアイデアを何か出すっていうふうになった時に、ちょっとイレギュラーなものをどう考えていくのかっていうのの参考に、結構進化思考っていうところで、
生物界のさっきの進化の話だとか、どういろんなものが生まれていったかって話をしてたんですけど、
だからさっきのイレギュラーを生まないっていうのは、そこも制限してるみたいなところがあるような気がするんですよね。
逆にイレギュラーを生むようにしていくっていうのも必要。
もちろんそこから選別していくとか、適切なものを選んでいくっていうのもまた別で必要なんだけど、そのプロセスの中では。
ただなんかそれがないと、より良いものが生まれていくっていう考え方にはならないんじゃないかって話をしてたような気がしていて。
36:03
へー。 結構ね、結構このそのキーノートというか、まあ本の話っていうのは面白かったんですよね。 うーん。
で、なんかやっぱりさっきのその、ね、そのデザインシステムに縛られすぎると、そういうイレギュラーなものというか、なんか新しい発想っていうのが生まれなくなってしまうっていう話も、すごく近いなと思って今。
うん、確かに。 なんかそういう、まあそのなんか進化というか、
パターンから逸脱したものが実は種類になるみたいなことがあるからって話ですよね。
そうね。
それがまさに、
神河さんの話の中ではクリエイティビティっていうのを表現だったのかなって思うんですけど、
まあっていう話からスタートして、
これは大事な話だなって思いましたね。
あと面白かったのはスマートHRの人の発表かな。
スマートHRって結構デザインシステムを公開してて、
GitHubでリポジトリもあって、そこでやりとりしてみたいな、結構オープンにやってる会社だと思うんですけど。
スマートHRはプロデューサーも、ブランドデザインも参照しています。
今回はプロデューサーの方で、いかにデザインシステムを使っているか、みたいな話をしていました。
で、色々あったんですけど、いいなと思ったのは、
そもそもデザインシステムがうまく機能するための開発のアプローチをとっているみたいな話をしていて、
スマートHR の場合は、サービス開発していく中で大型機能をドンと出すっていうよりは、
次に出す大きい機能をなるべく最小単位で分割して
最小単位というのはユーザーにとって価値がある
最小単位で大きいフィーチャーを分割して
それで出すということをしているみたいな話をしていて
そうすると色んな機能が並列して開発が走っている中で
最初のフォーの開発フェーズだと
最小単位っていう感じで分割していくと
必要なコンポーネントが
開発のスコープが小さいから
似通ってくるみたいな話があって
そうするとデザインシステムがうまく機能するみたいな話をしてて
これはすごくいいなと思って
さっきのモチャノさんに言ったデザインシステムをどう使うかっていう話だと
プラグとデザインの分脈だと
39:00
サービス開発をどう進めてるかっていうのと表裏一体の話だと思うんですよね
だからそれこそ新規機能をどんどん作ろうみたいな開発のフェーズだったら
デザインシステムってあんま使えないと思うんですよね
まあ抽象度が高いATOMとかのものだったら使えるかもしれないけど
より具体のコンポーネントって機能が増えるとか
特に新機能とか新しいユーザーを取りに行くってなると
やっぱりインスタッドすることが増えてくると思うから
もしかしたら PDCA でやっぱりこれはいらないなっていう
なくなってしまうっていうこともあるからね
それが結構早いサイクルで回っていくからね
そうですね サービス開発でも結構難易度が高いもので
プロトタイピングより求められるものだと
作ったはいい 作ってデザインシステムで反映したはいいが
結局使われなかったとかなんかよくあると思うんだけど
そういうサービス開発がどのフェーズに入るかとか どういう進め方をしてるのかっていうのと
結構密接に関わってくるかなと思うんだけど
Smart HR の場合はそういうアプローチを取ってるから デザインシステムと相性がいいみたいな話をしてて
それは確かになるほどだなって思いましたね
そうだね
なんか コードから来てる部分ってあるよね
元々さあんまりデザインシステムっていう考え方って
なかったに近いじゃないですか
まあ当たり前だけど
だけど
まあなんかよく昔あったものとしては
やっぱりCSSフレームワークみたいなのがあって
まあクックパッドとかでも作ったりしてたけど
やっぱコードから来てる文脈っていうのがあるような気がするよね
そういう意味でやっぱり
そうですね
まああんまデザインで関係するデザインシステムって
多分、まあそのブランドデザインとかそっちの方面の話ではあるとは思うんだけど、
あんまりデザイナー関係ってものってないと思うから。
うん、そうだね。
なんかこう、もうちょっと抽象的なものってあるじゃないですか、やっぱりその、なんていうの。
極大的なコンポーネントとかってそういう話じゃなくて、
もっと抽象的なレイヤーのストラクチャというか、そういうものもあると思うんで。
そういうものはあるデザインで完結すると言えるのかもしれないけど
実際に目に見えるものとかそういうものになっていけば
やっぱりある程度テクノロジーと密接に関係してくる部分があるから
そこはやっぱり構造化されたデザインシステムが
コードから起点でどう管理されるかとか作られていくかっていうのは
あるような気はするよね
特にプロダクトデザインでデザインシステムを使おうとなったら
必然的に開発とどう連携を取るかみたいなところは
大事になってくるし
プロダクトマネージャーとかプロダクトオーナー的な人が
42:00
どういう開発スタイルを取っているのかというところも
デザインシステムを作る意義があるのかというところに
絡んでくるんだなというのは思いますね
スマートHR も結構規模としては大きいんだけど、
やっぱりさっきの冒頭の話と同じように、
デザインシステムはあくまでガイドラインとして、
補助線的に使っているだけで、
それを逸脱するみたいなことも許容しつつやってるみたいな話をしてましたね。
で、なんかまあ、やっぱり規模が大きいなと思ったのは、
結構なんかこう、Figma のブランチングとか使いつつ、
カンチングとか使いつつ レビューして マージするフローを整えたりとか
あとは 社外にも公開してるから マージ後はデザインシステムに
どういうアップデートが入ったかっていう のを社内にも記事書いて告知するし
社外にもそれを告知してるみたいな 感じで
めっちゃちゃんとしてますね めっちゃちゃんとやってんだな
って かつアクセスビリティ的な チェックをQA担当者として
めちゃめちゃちゃんとしてるね。
ガイドラインも整備室2みたいな、めちゃめちゃちゃんとやってるなと思いました。
そうだね。
ここまでなんか、かっちりちゃんとやれるのは、組織的に理解があるっていうか、組織にやりたいこととマッチしてるから、だからこそだと思ったんですけど。
そうですね。
だから、そうだな。
ちゃんと開発とも絡んでるし、働き方っていうとあれだけど、開発の仕方にマッチしたものを作っていってるっていうのがいいんだろうね。
単純にまとめたものとして作ったっていうだけではなくて。
あとはB2Bサース僕もやってて思うけど、やっぱB2Bサースは比較的デザインシステム取り入れやすいんじゃないかなっていう気をなんとなくしてて、
B2C ほど、作ったものが全く使われませんでした、みたいな、度合いって少ないというか、ある程度課題がB2Cよりは見えやすいことが多いから、B2Bの場合はね。
2C とか言ってると、そもそもこれは必要なのかみたいなのって、わかんなかったりするじゃないですか。
だから最初からストラクチャードにするのって、なかなか難しかったりもすると思うんですけど。
課題が本当に課題なのか、みたいなとこから始まるもんね。
そうそうそう。
で、作って壊しても頻度も高かったりとかするから、そうするとなかなかストラクチャードにやりづらかったりするけど、
B2B は比較的そっちはやりやすいのかなっていうのは、実際やってて肌感で思いますね。
っていうのがスマートHR の話で、あとアトラシアンの人の話も、やっぱ規模がでかいだけあって面白かったですね。
45:04
アトラシアンのデザインシステムの場合は、アトラシアンのプラットフォーム上で外部のサードパーティーの人がアプリを作るみたいなことをやれるようにしている。スラックアプリを作るみたいな感じ。
そのためのデザインシステムを作っている。
その人たちが使えるようなデザインシステムを作っている。
社内も含めてその人たちも使えるようなデザインシステムを作っている。
と言っていましたね。
デザインシステムを変えたとしても、
アップデートしたとしても外部の人がそれに追従してくれないことがあるから、
いかに外部の人があえて追従しなくても済むように、
デザインするようなアップデートを進めるかみたいな話をしていて、
例えば、エンジニアリング的には、
例えば、UIコンポーネントのインターフェースというか、
Figma用語で何て言うんだっけ?
プロパティー的なもの?
変数みたいな、プロパティー、プロパティー、
リアクトとかでいうとプロプスって言うんだけど、
コンポーネントに対する変数みたいなやつ。
要はコンポネートのインターフェースみたいなものが変わったときとかって
デザインシステムを使ってる人たちにそれを追従してもらう必要があると思うんですけど
それを自動で書き換えるようなCodeModって言ってたけど
そういうようなツールを使ってるとか言ってたりとか
あとはそもそもカラーパレットで
例えばダークモード太陽のカラーとか定義して使えるようにしてるけど
それを使ってもらえなかったりとかするから、そのサードパーティーの開発者に。
だから、Figmaでプラグイン作って、そのアトラシアのデザイントークンをピックアップできるようなプラグインを作って、
それでカラーパレットを気軽に使えるようにするようなことをしてるとか。
なんかさっきのくわもとさんでさ、テーミングの話もちょっとあったけどさ、
そこをやっぱり早くFigmaの公式で取り入れてほしいなって思ってるよね。
やっぱりずっと。
Dark Modeが出てきたあたりから。
やっぱりそこは大変なんだよな。
たぶんDark Modeって話だけじゃなくてさ、
あとRussianとかだったら色んな製品があって、
その製品群のそれぞれサービスのカラーみたいなのが多分あってとかっていうのがあったりすると思うんだけど。
そういうのを気軽に切り替えられるのか、すぐ作れるのかとか、
その辺の対応できるものっていうのが、
いい感じにFigmaに取り入れられないかなっていうのをずっと思ってるんだけど、
まあないから、みんな頑張ってプラグイン作るみたいな感じになってますよね、今のところ。
48:04
なんかカラーで言うと、デザイントークンの名前の付け方とか、設計の仕方みたいな感じですよね。
その、カラードットブラックっていうのが、0.0.0.0.0.0.0.なわけじゃなくて、
それをこう、ある程度改装も出せて、カラーボーダードットサーフェイスとかやったら、
なんかその色が呼び出せるとか、なんかこう、なんて言ったらいいのかな、
その色の定義と色の使用箇所を分離して、こう、うまく文字列で表現するというか。
そうですね。
まあそれでうまくテーマで切り替えていくみたいな感じのものが、
ああ、そうだよね。
なんかね、Figmaでできるといいなっていつも思ってんだけどね。
わかんないけど、Color.body.light みたいな感じだと、
ライトテーマのデフォルトのボディの背景色が引っ張ってこれて、
そこをライトっていうのは、高度的にダークに変えるだけで、
ダークモードのやつが引っ張ってこれるとか、
なんかそういうやつですよね。
その辺は、頑張ってほしいなと思っていますね、やっぱり。
あと、すげえよく言うと、そのテーマだけじゃなくて、もしかしたらちょっと違うかもしれないけど、
多言語化的なものも一つのテーマとして考えられるのかもしれない。テーミングとして。
まあ、わかんないけど、昔ちょっと多分そういう話したような気がするけどさ、
子供向けなのか、もしかしたら同じもので、子供向けと保護者向けっていうものがあったりしたりして、
それによって言葉遣いもコピーライトもテーミングで切り替えていくっていうのが必要になるかもしれないっていう話。
それが多言語化にも、それがうまく多言語化とかそういうことにも繋がるんじゃないかっていう。
結局なんかキーバリューがあって、
なんかそのキーっていうのが、例えばカラーボーダー、サーフェースみたいな、
なんかこうの、なんていうの、その色の使用箇所を示してて、
その色の使用箇所のバリューがコンテキストによって変わる?
ライトモードなのかダークモードなのか、
あるいは子供向けなのか、老人向けなのか。
そういうものですよね。
バリューが別にカラーだけじゃなくて、
ひょっとしたらフォントサイズなのかもしれないし、
ボーダーなサイズなのかもしれないし、
あるいはさっき言ってたテキストなのかもしれないしみたいな。
その辺がもうちょっとFigma本体というか 公式でうまくサポートされて強化されていくと
嬉しいなっていうのは いつも思ってるところですよね
51:00
なかなか難しいのかもしれないけど そういうのを
なんか それ 実装してんでもすごい迷うんですよね
僕はだいたい新しいサービスを立ち上げるとか、
何かLP、ちょっとしたLPでも何でもそうなんだけど、
だいたいデザイントークンっていうファイルを作って、
そこにFigma上で定義されているカラーとかフォントサイズとかを
全部一回そこでキーバリューで定義するんですよね。
でもその時に、例えばカラーをどういう…
ただブラック#0000って書くのがよりは
使用箇所を名前キーにして書いた方がいいのかとか
その辺って結構みんな試行錯誤してやってる印象だし
デザインの段階でデザイナーがすごくストラクチャーに考えてたら
それをコードに起こすだけでいいんだけど
そうじゃない場合が結構多いから
そうすればエンジニアがフリーフォームを ストラクチャーで変換するという作業が必要になって
デザイントークンの設計みたいなのを エンジニアがする実装の段階ですることになるんですよね
だからそもそもFigmaがそういうのをサポートしてくれてたら それって結構開発者も助かるだろうなって思いますね
そういうものを便利に使おうとすると、うまくそういうストラクチャードの部分に当てはめていかなきゃいけなくなるから
でもそうなると、開発するときに楽になっていくっていうところは確かにあるかもしれない
だからそういう意味でも、テンプレートじゃないけど、そういうものが作りやすい構造になってそもそもひぐまがなっているっていうのは、いいことかもしれないね
別にそれを一番最初から乗っ取ってやらなきゃいけないってことはないんで
ある程度作った上でカラーをそこからまたそういうストラクチャーの上に当てはめていくっていう作業をしていければ
いいような気がするんですよね
なんかコンポーネントをストラクチャーにするっていうしすぎるとさっきのフリーフォームが障害されるみたいな話が出てくるけど
色のバリエーションとか、フォントサイズのバリエーションとかって、そんなに、すごくそこにクレイティビティが発生するということはないと思うんですよね。
フォントのサイズとかって、ある程度決まってるじゃないですか。
だからそこは完全にストラクチャードにできるようなテンプレートを用意しちゃって、もういいんじゃないかなっていう気はしますけどね。
まあっていうのはまあいろいろみんな試行錯誤してると思うんですけど
アトラシアンとかは結構その辺はまあガッツリプラグインなりコード書いたりやってますっていう話でしたね
まあでもなんか外部の人もそれを使う機会があるっていうのは
かなりこうそのいわゆるデザインシステム担当者みたいな人がいるんでしたっけ?確か
54:07
全然いると思います。
が、なんかめちゃくちゃ仕事ありそうだなって感じするよね。
会部の人もガンガン使って、なんか行ってくるかもしれないし、みたいなところがあると。
まあ、だからここまでいくと、もう本当にマテリアルデザインとか、
HIMAITAI SKYTLINE作ってるのと変わんないのかと思いますね。
そういう感じですよね。
あとは、ノートの人の話とかだと、
結構ノートってこうサービスの人格、ボイス&トーンみたいな話。
ノートってサービスがどういう言葉遣いをするかとか、どういうトーンで話すのかみたいなのを、やっぱサービスの特性上大事にしてるから、
そういうノートらしさみたいなところをデザインシステムにも反映して、ビジネスのメンバーにも使ってもらえるように整備してるみたいな話とか。
でもそういうのやっぱり大事ですよね
デザインシステムが開発者だけのものにならないというか
本当にそういうタイプになってるね
開発者のためだけに作らないデザインシステム
全然知らなかったけど
同じこと言ってたんだ
結構、僕も昔クックパッドにいた頃に色々
デザインを横口で見るっていう組織にいたから、
会社全体をデザインで底上げできるものをっていろいろ考えてるとか、
仕事してる時期がいろいろあったりしたけど、
その頃にアイコンを本当にして発表資料とか営業資料とかに使えるようにするみたいなのを作ってみたりとか、
結構そういうところはあると思うんだよね、デザインシステム。
僕も2018年頃にクックパーと行った最後の年に、
クラミスさんと一緒に、そのCITRUSっていう、
当時のエプロン、今はエプロンというデザインシステムがあるやつの前身みたいなものを作ってたんですけど、
それもコンセプトとしては、どっちかというとビジネス、開発者じゃない人たちをターゲットにしたデザインシステムを作ろう、
当時サラっていう開発者寄りのものがあったから そうじゃないものを作ろうみたいな中で
グクパトらしいボイサノトーンみたいな パーソナリティみたいなのも定義したりとかもしてたんだけど
カラーの定義みたいなのもしたんですよね ストラスカラーみたいなのを定義して
それを結構 一応 そこまで考えてなかったんだけど
ちょっとしたコピペをしやすいように ちょっとしたページを作ったんですよ
そのストラスカラーの それが意外にプレゼンを作るときとか
57:01
そういうところでも使われたりとかして
そういうのを結構開発者じゃない人たちに向けてやる上でも大事なんだなって思いました
最後はチームラボの話があって、チームラボの中でもクライアントワークをしてる部門の人の話、メディアートとか、クライアントワークの方の話があって、
まあなんか 話の内容としては 結構バックエンドは
クライアントワークやる中でもバックエンドは基盤の共通化みたいなのをやってきた
例えばECの基盤とか そういうものは独自で作ってきたから
クライアントワークのデザインにおいても 共通化みたいなことができないかみたいなことをやってみたんだけど
結論としてはできなかったっていうような そこは諦めたっていうような話
なんだろうね、まあこれできない、僕もできないだろうなぁと思うんだけど、ただ、もしかしたら、
そんなんだろう、さらにそのデザインシステムのシステムみたいな、その大枠は作れるんじゃないかなっていう気がするよね。
それは僕も思ったんですよね。なんか、確かになんか、発表の中でも、アトムに相当するものは今日とかできるんだけど、そうじゃないものはできないし、
やっぱりビジネスのやり方として 他方との違いみたいなことを結構大事にするから
住宅の場合 だからやっぱ共通化しづらいよみたいな話をしてたんだけど
でも結果なんかこう 結構なんか各案件ごとにオーダーメイドデザインシステムを
毎回作ってるみたいな話をしてたんですよ
だからってことはさらに抽象化したメタデザインシステムみたいなものって
なんかないのかなっていうのは聞いてて思ったのがありますね
まあ なんていうかこうね フレーム デザインシステムを考えるためのフレームワークみたいなものは多分作れるような気はするよね
そのメタデザインシステムみたいなものの やっぱり抽象度のコントロールって難しいんだろうなと思って
なんかそれが汎用的であればあるほど 要は抽象度が高ければ高いほど
それって HAC とか Material Design とか あるいは Hand Design とか そういうものになっていくんじゃないかなって思うんですよね
なんかそのいい感じの具体度で設定するのが 使い勝手がいいところなんじゃないかなって気がしてて
なんか その僕が持っているのは そのコンポーネント 具体的なコンポーネントを定義するようなものではなくて 全く
デザインシステムをどう作ったら一番最適に 簡単にというか 最速で作れるかというようなフレームワークを考えればいいんじゃないかなと思っていて
こういう手順で こういうものを こういうふうに当てはめて作っていけば デザインシステムがもうすぐバンって作れますよっていうような元
1:00:00
ああ そうそう だから その中傷度のコントロールが
どの会社でも適用できるデザインシステムが 作れますようだと中傷高すぎると思うんだけど
例えばチームラボだったら チームラボのデザインシステムを作る上では
ここをやればいいですよみたいな 具体的な設定の仕方が大事なんだろうなと
あともう一個考え方としては
冒頭に小川本さんの話の中で出てきた ヘッドレスデザインシステムというような考え方
これが何なんだろうなと思って、もうちょっと調べてみたんですけど、
Figure 1 の何かのイベントで、
頻度の会社の人が登壇して発表してたものから出てきてるっぽいんですけど、
要約すると、ボタンコンポーネント作るんだったら、
ボタンの構造だけを定義して、
そこに色をどう当てはめるかっていうのは、
デザイントークンでテーミングを切り替えるみたいな感じでやりましょうっていうような感じ。
だから完全にFigma上で構造とスタイルを分離しましょうみたいな感じで。
これは確かに。
これ考え方として面白いなと思ったんだけど、でもすごい既視感があるっていうか、
HTMLとCSSみたいだなって思ったんですけどね。
うん、そうね。
うん。
まあ、なんか、これもだからどこまで、なんだろう、こう、まあ難しいな。
なんか、全部いじれるようにしちゃったらさ、結局一緒じゃないですか、多分。
そうなんですよ。
その、各プロパティ、その、文字列もそうだし、色もそうだし、そのボーダーありかなしかっていうのもそうだし、角丸ありかなしかもそうだし、パディングどうなのかとか、その余白とかね。
大きさとか 全部いじれるようになっちゃったら 結局 それなんか
それって
ボタンっていう概念的なものと プロパティは分けられるんだけど
それって そこまで分解しちゃったら
なんか どういう なんかあんまり意味がないんじゃないのかっていうか
そう なんていうの そのボタンタグを書いて
で その状態でも ボタンのUIはなしてるわけじゃないですか ブラウザ上で
で そこにCSSでボーダーなんちゃら感じだって書いて スタイル上げててくのと
あれ一緒じゃないかみたいな
たぶん 全部を操作操作というか プロパティを書かなきゃいけないっていうふうにするわけじゃないんだよね きっとたぶん
そうそうそう だから多分その中小度のコントロールがあるんだろうなって思うんですよ
そこがやっぱり一番難しいだろうなって思って
だから結構さっきのTeamLabの話も一緒だなと思って
中小度上げすぎると何にも使えるってなるんだけど
1:03:00
それってHRGなりMadeleine Designなり もしくはHTML、JSSなりの再発明になっちゃうなっていう
で 具体によればよるほど 使いましができなくなってくるっていうところ
だから結構 考え方としては面白い 面白いというか 重要だと思うんだけど
デザイン等で管理していくっていう 考え方の部分とかね
だけど それをどこまでコントロールして どこまで制限するのか
どこまで供用するのかみたいなところが 重要なところだよね 多分これの
構造化したっていうこと自体というよりも そこの先にあるような気がするよね 重要なことが
そうそうそう なかなかデザインシステムの話を
いろいろよく聞くように ここ数年になってきて思うのは
デザインシステムをどう使うかっていうのも大事だし
あと、そのコンポネントの捉え方みたいなものの、もうちょっとなんか、なんていうのかな、
ノウハウがないかなっていうのはよく思うことがあって。
なんかこう、なんて言ったらいいのかな、
まあアトミックデザインとかに近い、一番近いかな、世の中に出てるノウハウとしては。
なんかあれって、こう、コンポネントをレイヤードにして、
アトムっていう名前をつけて管理しましょうみたいな 大雑把な考え方だと思うんですよね
だけど結局そのアトムが何なのか
名前がちょっと難しくてあれだったけど
そのアトムの次のレベル2の概念が何なのかみたいな 具体例って各プロジェクト次第だよねみたいなところがあって
結局その捉え方が色々あって
これは頭なんじゃないか それはレベル2なんじゃないか これはレベル3なんじゃないか みたいな議論になっちゃうみたいな感じで
うまく定着しなかったって印象なんですよね
そうね
だけど コンポネントをレイヤーで捉えるみたいな考え方自体は大事だと結構思ってて
だから そのコンポネントをどう捉えるかっていうところの
ノウハウってもうちょっと出てこないかなっていうのは
実際ストラクチャーに変換する立場の人間として すごい思うことがよくある。
何だっけなー。 安倍真だったっけな。
なんかデザインシステムの考え方が、そのアトミックデザインに近いんだけど、
ちゃんとうまく分離できてるようなやつが確かあったような気がしたんだよな。 思い出せなくなっちゃったけど。
まあでもなんか結構アトミックデザインに初期に安倍真之ご当さんとか結構よく発表してたから、結構そういう知見はいっぱいあるそうですね。
そうそう。なんかアトミックデザインって、さっきのレベル1、レベル2で言うと、レベル1が原子、アトムで、レベル2が分子、モレキュールで、レベル3が、もうちょっと合体したものっていう。
1:06:11
オーガニズムか。
そうです。だいたいレベル1とレベル2をどう分類するかが結構揉めるんだよね。
そうです。
レベル1とレベル2は相対的な話じゃないですか。
レベル1はどこまで中小を高く設計するかというところも難しいところだなと思っていて、
ボタンコンポーネントというのがレベル1によくされると思うんだけど、
それがどのプロダクトでも使えるようなレベルの抽象度を求めているのか
単一プロダクトの中で使い回すできるレベルのものをレベル1と呼ぶのかっていうのはチーム次第だと思うんですよね
そうね
それを基準としてレベル2、レベル3、レベル4が決まってくると思うから
やっぱりその抽象度のコントロールって難しいなっていうのを
でも、アトミックデザインが生まれた時では、多分一つの単一サービスのとかっていう考え方の部分が大きいと思うから、
さすがにそれをさらに抽象度高く、いろんなサービスも含めたデザインシステムっていう考え方で当てはめていくのは、
多分このレベル1、レベル2、レベル3、レベル5までのところに当てはめるの難しいんじゃないですかね、さすがに。
アトミックデザイン自体に当てはめていくのは もうちょっと変形させないと
なんか開発の現場でよく見るのは 最初から抽象度を高めすぎっていうパターンをよく見るなと思って
なんかこうプロダクト1個新規出してあげるっていう中なのに
何にでも使えるような 例えばなんていうの 名前で言ったらカードコンポーネントみたいなのがいきなり登場して
でもカードコンポーネントって何?ってなるじゃないですか。
だからなんかその、大体抽象度高すぎだから、
僕はなるべく主語を小さくするように、最初は設計をするようにしてるんだけど、
なんかこう、どこどこの画面のカードコンポーネントみたいな。
なんか抽象度高すぎて設計しすぎると何にでも使えるように見えちゃって、
何でも使えるように見えちゃうから みんなが参照し出すんだけど 実はそこまで考えられてないから
やたらアッシュみたいなのが増えていったりとか やたらプロパティみたいなのが増えていったりとか
この画面のときはこのプロパティをオフにする みたいなのが増えていって
結局 コンポーネートで共通化してるみんな 来ないみたいになるみたいなパターンってあると思うんですよね
まあそこは難しい。どうやるのがベストかっていうのは難しいけど。
1:09:00
まあエンジニアリングでもね、普通にいきなりこう中小度の高いものをバーンってクラスを作るみたいなことをしないこともあるじゃないですか。
ある程度ね、それを多分何回も使い回すんだろうって思ってたら、なんか作っても、いきなり最初から作ってもいいと思うんだけど。
まずとりあえず一番わかりやすい 実質的なものを作って
それに似たようなものをまた作ることになったら
じゃあもうちょっと抽象化したものを一個作って
なんか使い回せるようにしようみたいなふうにするのが
まあいいんじゃないのかなっていうふうには
まあエンジニアリングの部分でも思うところがあるから
それと一緒ですよね
やっぱそのエンジニアリング世界から 取り入れられるところなんじゃないかなっていう気がしてて
エンジニアリー世界でいうデザインパターンみたいなものとか、よくあるけど、
クラスの設計をどうするとか、アーキテクチャの設計をどうするとか、
いっぱいノウハウがあると思うんですよね。
同じように、UIコンポーネントの設計も、僕よくやるのは、
実際、マテレイデザインとか、アントデザインとか、
そういうよく作られているそうなやつのコンポーネントの流動を見てそれをまずマネするみたいな感じ
当てはめてみるみたいな自分のプロダクトに
てすると中長の設計がいい感じに揃うかなみたいな感じでやってたりするんだけど
なんかそういうノウハウがなんかたまるといいなみたいな
冒頭のエンジニアル世界からデザインの世界に当てはめるみたいな話で言うと
っていうのを妄想したりしてましたね
いやーなんか最近やってるちょっと開発の案件があるんですけど
ちょうどなんか僕が後から入った案件だったんですけど
まあこう、まあコンテキストとして デザインは、
上ではあんまりストラクチュアにされてない感じのデザインがあり、
まあそれを、わりとこう、
ジュニア寄りのフロントエンドのエンジニアが、
あの、高度に起こしてたっていうような現場なんですけど、
その中であったのが、グリッドか、
グリッドのレイアウトがあって、
その中にカードURみたいなものが並んでいる、よくあるURじゃないですか。
ある画面ではグリッドで並んでいる、違う画面ではリストで並んでいるみたいな感じのものがあったんですよね。
カードの中身の情報は一緒。
それを実装がどうなっているか見てみたら、
それをカードの大小として捉えていたんですよね。
グリッドで格子上に並んでいる方をカードUIの大として捉える、
1:12:00
リスト上に並んでいる方をカードUIの小として捉える、
名前がカードラージ、カードスモールとなっていて、
それだとカードミドルが出てくるとか、色々思っちゃうわけなんですよね。
それがどちらかというと、縦組と横組の違いだと思いました。
カードのバーティカルとホリゾンタルで捉え直して、UIを分け直したりしました。
そういう捉え方の違いは、UIをどう捉えるのかという事を知見がたまりづらいと思いました。
特にデザインの段階ですごく考えられる
デザインの段階ですごくストラクチョンになっていればいいんだけど
なってない場合、それを開発にするという時に
見たままの状態で捉えて実装すると
ラージ、ミドル、スモールみたいになっちゃうんだけど
それをUIのパターンとして捉えると
これは縦組と横組の違いになっちゃうのか
みたいな 捉え方になるよなと思って
なんかそれでもうちょいコンポーネント の設計みたいなところって
僕も結構悩むしどうしたらいい のかなっていうのを最近よく思ってますね
デウチ君が悩んでたらちょっと 大変だけどね
他の人はもっと
いや 結構 だってさ この領域って ある程度デザイン的な理解もあるし
エンジニアリング的な理解もあるっていう人間が できないと結構厳しいじゃないですか やっぱり
他の人ってなかなか難しいと思うんですね そこの理解していくというか 整理していくっていうのが
そういう意味では出口君が頑張らないと 難しいんじゃないですかね
もちろん頑張るんですけど、頑張るけど、やっぱ悩むなって思うことが多い。
でも、なんか悩むというか、面白いなと思ってるんですよ、そこが。デザインをどう捉えるかっていう観点で。
ある種、デザインコンポーネント辞典みたいなのを作ったらいいかな。
そうそう いや まさにそうなんですよ それが欲しいなと思ってるんですよ 常々
こういう なんとなくパターンがバーってあるじゃないですか いっぱい
で このパターンだったら こういう感じの名前で呼ぶよねみたいなのを
いや そうそう そう
で こういう時にだいたいなんか使ったりするよねみたいな
そうそうそう そういうのね 作ろうかなってちょっと思いました 最近
なんかでも難しいよね 特にその何て呼ぶかとかっていう部分って やっぱり揺れがちじゃないですか なんか人とか会社とかによって
1:15:03
そこを…一つはそのアップルが出してるHuman Interface Guide Lineとかが 参考になったりするわけですけど
どう呼ぶかとかっていう部分は まあでもやっぱりそれに乗ってないというかね ないものもあったりするわけだし 世の中には
名前自体の統一というか、
たぶんこういう捉え方もあるんだよっていうことが示すことが大事かなっていう気が何となくしてて、
サイズで捉えるんじゃなくて、レイアウトで捉える、さっきの横組立て組みたいな話。
組み方の違いとして捉えた方がいいんじゃないかみたいなこととか。
ボタンのUIがあって、もう一個が3つのボタンが並んでるグループになってるボタンみたいなのがあったとして
そうやって完全にボタンの違いとして捉えるんじゃなくて、あるボタンとグルーピングされたボタンっていう風に捉えるとか
そういうの作れたら作ろうかなって最近思いました
ていうか自分が欲しいなって思う
自分以外に欲しいって言う人が多いと思う
自分以外で欲しい人がどこまでいるのかわからないけど
いやなんかでもあってもおかしくないから
そういう本を作って技術書店とかで売ったらいいんじゃないですかね
なんかよくあるじゃないですか
なんかそういう全然関係ないけど
アイデア百科事典みたいなとか
そういうのあるじゃないですか
ビジネス百科事典みたいな
そういう感じでデザインコンポーネント百科事典みたいな
作ろうか
最後の方だいぶ揃えちゃったけど
でも総じてデザインシステムを各社どう使っていくかみたいな
やっぱり各社がどういうビジネスをしているかというところとも表裏一体だなと思ったけど
そうだよね
そういう話が多かったですね
ちなみにアドビーのあの字も聞こえませんでしたね
解消から
それ面白かった
そこは突っ込んで欲しかったけどな
なんかQ&Aセッションとかで
アドビの件はなかったかのような感じでした
アドビって言おうとしたらなんか止められるのかな
あ、ちょちょちょ
マクロメディアとか言ってたけどね
今後どうなるかわかんないけど
まあなんか、録画も出るっぽいんで、いつ出るかわかんないけど。
あとなんかあれでしょ、なんか、なんかわかんないけどさ、
まあ色々各地で、ニューヨーク、東京、ロンドンでやってるけどさ、
なんかバーチャルっていうのがあるんでしょ。
ああ、そうそうそう。あれ、何なのかよくわかってない。
何なんですかね、このバーチャル。
登壇者とか出てないからね、これは何なのかよくわかってない。
謎ですよね。
それもまた16日だから、まあこの配信されてる頃にはもう、いや終わってると思うんだけど
1:18:06
そうですね、まあだから来週ぐらいには録画出たりするのかな、月末ぐらいには
じゃないですかね、もしかしたらでも逆にこのバーチャルが録画なのかもしれないですけどね
ああ、そういうこと?
かもしれないね
まあ、そんなんていうの?
かもしれない
リニア配信的にさ、一緒に見ようみたいな、ライブ配信的な感じでやるのかもしれない
そうそうそう わかんないけど
まあなんか ちょっとじゃあ
それも見てみようかな ちょっと
そうですね 特に川本さんのキーノートは面白かったんで
見てみるといいかなと思います
はい じゃあまあそんなところで終わりましょうか
はい
リサイズエヘムへのご質問やご感想 リクエストなどは
#リサイズエヘムでTwitterにつぶやくか 賞の取り合えるお便りのリンクから
送っていただければ配信内で取り上げたりしますので
どうしどうしいただければと思います
リサイズ編は毎週金曜日に配信しています
Spotify、Apple Podcast、Google Podcast、YouTubeなどで配信していますので
よかったらチェックしてみてください
ということで今回はここまで
また次回お会いしましょう
さようなら
さようなら
♪~
