デザイナーとコードの関係
本日も前回に続いて、Qiita のデザイナーの綿抜さんにお越しいただいております。
今回はウェブ UI デザイナーのコード人口がなかなか増えないというテーマについて話していこうと思います。
よろしくお願いいたします。
よろしくお願いします。
やっぱりコードって書いた方がいいんですかね、そのデザイナーの人たちも。
そうですね、僕の持論では絶対書いた方がいいとは思っています。
結構、書けた方がいいというよりかは、書かないといけないぐらい、個人的には思ってますね。
書かないといけないまでなんですね。それは、やっぱりどういう理由なんですかね。
完成品のグラフィックを作っている、ビジュアルを作っているという気持ちだと、
そのウェブとかUIとかを作るときって結局、インタラクション、ユーザーが触って何をするかとかっていうのが重要になってくるので、
実装の部分が分かっていないことには、例えばそうだな、材料のこと全然詳しくないプロダクトデザイナーとか、
布の特性全然知らない服飾デザイナー、服のデザイナーとかっていうのと同じことだなって僕は思っているっていう感じです。
分かりやすいですね、例えば。
分かりやすいですね、特にデザインツールの変遷とかも、今までのイラストレーターでウェブを作ってた時代からXDとかFigmaが出てきて、
Figmaは特にコードを書ける人がより使いやすい、感動的に使いやすく成長しているイメージがあるんですけど、自分の中では。
なんでこの機能がどういう背景でできたんだろうみたいなのを分からずに、コードを書いてない人は分からずに使うかなと思ってて、
そのデザインデータの質は違いそうだなって思ってますね。
ウェブデザインの特性
全然違うでしょうね、あれはもう間違いなく違うと思います。思いますよっていうか、違いますね。
断言しちゃって構わないんじゃないかなって。
なんかやってない、コードを書いてない人が上がってくるデザイン見て、じゃあこれあなたならどうコードで書けますかやってみてくださいって言いたくなる時がありますね。
そうするとやっぱデザインとしての設計ってちょっと崩れてないかとか、
やっぱなんかウェブのUIのデザインってなると結構考え方が他のグラフィックデザインとか、
何だろう、紙のデザインとかと違うけど、その考え方を継承しながら作ってる人も結構多いなって印象があって、ウェブって。
多いですね。
多いですよね。
チラシをパソコンの画面とかスマホの画面で表示しているみたいな気持ちの人は多分多くって、これチラシがどうこうっていう意味じゃないんですけど、
ポスターでもチラシでも何でもいいんですけど、紙っていうのはA4だったらA4とかA3だったらA3とか、まず幅や高さは変わらないじゃないですか。
かつ受け取った人によって、名古屋市に住んでる人はこのチラシで、豊田市に住んでる人はこのチラシで、みたいなのも基本的にはチラシだとあるから、ポスターとかだとないじゃないですか。
内容が違うみたいなとかじゃなくて、基本的にはもうみんな一緒、すごいスタティックなんですよね。
けど実際アプリケーションって大概ダイナミックというか、それはデバイスによって全然表示も違うし、あとはログインが必要なサイトとかだったらもうログインしてるしてないとか、あとはカートに物が入ってる入ってないとか、でも全然違うわけじゃないですか。
もう同じ画面があることの方が少ないじゃないかなぐらいなんですよね。
ってなってくると、スタティックなチラシを作ります、ポスターを作りますの気持ちで向かっちゃうとむしろ、うまくいくことの方が少ない。うまくいったらラッキーだと思った方がいいぐらい。
情報の見せ方、組み方が全然違いますもんね。その領域が違うからこそ。
そうですね。
ウェブの世界と紙の世界って。
そうなんですよね。紙だと作り手側がこう見せたいっていうのが結構細かいところまでチューニングができるんですけど、ウェブのスクリーンってほぼ無理というか。
極端な話、デバイス設定で文字のサイズを変えてることもあるわけじゃないですか。大きくしたり小さくしたりとか。
もうそれぐらいで揺らいじゃうんですよね。情報の順番だとか、見えてる全体の印象みたいなこととか。
1920×1080がベストっていう作り方をすると、スマホで見たらとか4Kディスプレイで見たらみたいな時に全然印象違って見え方、受け取り方違っちゃうみたいなのはもうしょっちゅう起きる。
デザイナーとエンジニアの協力
しょっちゅう起きます。
僕ちょっと素人なんで適当なこと言うんですけど、例えばデザイナーの人が1回そういうデザイン作りましたと、1980×1020で作りましたよみたいな時に、
後からレスポンスにした時にスマホとかでこんな崩れちゃったよみたいな話とかってもらうわけだと思うんですけど、
初学者のうちから全部考えるのは無理なので、学びの入り口としては全然いいと思いますよ。
ただ、そういう出来事があっても、とはいえデスクトップを作って、モバイルはいい感じにエンジニアの方にお願いしますみたいなデザイナーもまあまあ、
結構多いらしいと聞くので。
ああ、そうなんですね。
うーん、まあらしいですよ。
へー、そうなんだ。それはちょっと知らなかったですね。
変な話、モバイルってほとんどレイアウトって縦1列にしかできないじゃないですか。あんまり2列3列とかって、
デスクトップで複雑なやつ作って、これを並べられる感じでモバイル版に収めてくださいみたいなリクエストとかは結構まあまあ聞きますね。
ああ、私それ聞きたいですね。
なんか結構聞くために頼った会話だけでもないと思うけどなぁ。
そうなんですね。
そっか、X状ではもうなんか、
3、4ヶ月に1回ぐらいなんかそういう漢字があるような気がして、
聞いてみてほしいです。
はい。
早めに1回にやると、
それがもういくつかの回答になるかもして、
あ、それとも浅夜の時点で出てくるかもしれません。
浅夜の時点で出てくるかもしれません。
浅夜の時点で出てくると、
浅夜の時点で出てくるかもしれません。
わかるよ。
それは、
だって、
いやそう、
3、4ヶ月に1回ぐらい、なんか、そういう恒例状があるような気がして。
確かにそれはやらないとダメですね。苦労をちょっと知ってもらわなきゃいけないですね、それも。
そう、なるほど。
デザインデータの質は確かに、本当にコードを書いてる人と書いてない人で全然変わると思うし、
一度まず経験してみるっていうところは大事かなと思ってて、
それを自分で作ったデザインが、まずデザイン頑張ってみてくださいってやったときに、
こういうところも考慮しなきゃいけないんだっていう気づきを得て、学べるか否か。
そうですね。
あとは、特に紙出身のデザイナーって、これむしろいいこだわりなんですけど、
例えばそうだな、ある段落とある段落のテキストの分量がちょっと違うから変なとこで開業されちゃうなみたいなときに、
倍の程度にちょっとサイズ変えたりするんですよ。
上の段落は99.5%にして、下の段落は101%にするとか、そうすると気持ちいいとこで開業されるみたいな。
あるある。
コマ何パーが印刷されてももう分かんないじゃないですか。同じサイズだなってしか人間見えないので。
全然大丈夫なんですけど、そういうのは例えばウェブとかでやろうとすると、
いや、スマホのときは結局ここで開業されちゃいますけど、みたいなのが起きるとか。
あとは、なんだろう、例えばコード書いてる身からすると、
これ文字量が20文字変わるごとに不文をかけってことですか?みたいなデザインデータが出てきてしまうとか、イメージ的にはね。
コード的な不採ですね、それは完全に。
例えば、見出しが画面の幅いっぱいになってほしいみたいなやつが、
最近だとCSSの計算でちょろちょろともしかしてできるかもしれないけど、
JS使って計算しなきゃいけないみたいなこととかになって、かつ、
この文字数を超えたらとはいえ2行にしたいです、みたいなオーダーがあったりすると、すごいことになっちゃうわけじゃないですか。
これはもう、無理な時もあるよ、みたいな。
なんか、なんだかんだ強引で読み解けないCSSは不採になると思っていて、
たとえできるとしてても。
そうそう。
CSSも脆いんで、完全とは言い切れないから、そういう不採になるようなデザインが生み出されている時点で、
それをエンジニアも実装している時点で、
ちょっとなーっていうところはあったりはするんですよね、自分の中では。
2人3脚で不採に走っていってるチャートみたいな。
そのデザインを需要している側も、需要している側で不採を生んでるんですよ。
なるほど。
これは僕は今、デザイナーの立場だから、デザイナーコードを書いた方がいいよって言ってるけど、
これもし僕出自がエンジニアだったら、エンジニアももうちょっとデザインやった方がいいよって多分言ってるんだろうなって。
いやー、わかります。
なるほど、なるほど、なるほど。
そう、僕は主体がデザイナーだから、コードを書かないとそういう不採だとか、
なんかそういうのに気づけないですよ、実装上のあれこれ気づけないですよっていう話をしてる。
ポジショントークと言えばポジショントーク。
うんうん。
いや、その最近、CSSとか結構書くことが自分も増えたんですけど、
あー、そうなんだ。
だからちょっとだけわかるんですよ、ちょっとだけ。
で、最近あったのが、10行になったら開業、開業じゃないわ、もっとビルボタンを出してくれみたいな、
10行以上になったらもっとビルボタンを出してくれとか、20行以上になったらもっとビルボタンを出してくれみたいなのがあったりして、
でもそれもその何行になるかって横幅で変わるから、
そうそうそう。
あのタイミングで出すの?みたいなの結構あったりして。
そうなんだよね。
確かに確かにそういうの思いましたね。
その話で言えばさ、例えばJavaScriptだったらさ、文字数を行数が無理だからじゃあ100文字でって言われたとして、
いやリング数で数えていいのかこれみたいなのあるじゃないですか。
なりますなります。
なんて読むかわかんないけど、INTLテグメンターみたいなやつで分割すべきなのか、
サロゲートペアは?とかなんか出てくるじゃん、みたいなのの苦しみをデザイナーも知っておいたほうがいいなっていう気がして、
100文字って言うけどさ、みたいな。
どこだい?みたいな。
いやそうなんですよね本当。
だからなんかデザインやってて、そうですね、デザイナーやってる人たちにこういうこと考えながらやってたのかなとか演じながらやってたりとかして、
最近はAチームのデザイナーの人たちはそういうことも考えて結構やってくれてたんだなっていうのをちょっと感じることも多くて、
なんか、すごい良い会社だったんだなっていう、思ったりしますねやっぱり、そこはやっぱりそういうのを教えてくれる人がいるんだろうなっていう。
今のも例えばデザイナーもちょっとコードわかるし、エンジニアもちょっとデザインわかる状態だったら、例えばそうだな、
全文取ってくるとさすがにパフォーマンス的によろしくないけど、200文字ぐらい取ってくればさすがにその1文字2文字の差でおかしくなることはないから、
ざっくり200文字ぐらい取ってきて、先頭の1行分ぐらいの高さで切り取りましょうみたいなこととかが、
良いかは別にしてそういう着地を議論できるわけじゃない。
そうですね。
これがどっちかが一方の知識を全く知らないとか、デザインを作った通りに実装してくださいよみたいな強情なデザイナーだと、
これはヤバいってっていうのが平気に生まれちゃう。
デザイナーとエンジニアの関係
わかります。
その辺りを議論の土俵に立てるぐらいは、せめてこう知っておかないとねって思いますね。
実装できるべきとまでは行かないですけど、そうやって話ができるエンジニアに、これってヤバいっすよねみたいな、難しいっすよねこれみたいな。
怪しさに気づいて相談できるぐらいは欲しいかなみたいな。
すごく共感しますね。
たとえお互い知識ない者同士で仕事することって全然あると思うんですけど、
気をつけたいなって思ってることは、お互いがなんでダメなのかみたいな、ぶつかり合うときあるじゃないですか、
そのときにダメな理由とか、こうした方がいい理由っていうのが実装面でもデザイン面でもあると思うんですよ。
それをちゃんと正しい言葉で説明しあえて、そこからエンジニア、デザイナー2人がちゃんと責任を持って作れるのであればそれでいいかなとは思いつつ、
一番の理想は両方ともの知識があることだなって思いますね。
そこが結構抜け漏れて、デザイナーとしては強引にこのデザインが美しいからこうだって言われても、エンジニアとしてはいやでも組めないからって、
組めないってどういうこと?え、どういうこと?うんぬんかんぬんみたいだったら、もうめちゃくちゃ不毛なんで。
そうなんだよね。
あとデザインの観点だと、なんか結構A案、B案どっちでもいいけど、A案のがかっこいいかなぐらいで出すときって正直言ってあって、
そのときに行動してると、A案、B案どっちでもいいんだったら明らかに実装楽なのはB案だもんな、B案にするかみたいなのがパッと考えられると、
デリバリーも早くなるし。
いやめちゃくちゃありがたいですね。
なんかその時点で実装面での目線が、一旦入る、判断で一旦入るっていうのって全然エンジニアに届いたときの、
なんだろう、からデリバリーまでが全然速度変わるので、
マジでありがたいですね。
本当に楽というか、めっちゃ簡単でしたもん、デザイン、エンジニア実装するときに。
まずそれが例えできないとしても、なんかデザイナーだけでこっちだって決めるんじゃなくて、エンジニアに相談してくれるっていうだけでも全然違う。
それだけでも全然違う。
もうほとんど同点の2案あるんだけど、これ明らかにどっちが苦しいとか楽なのあります?って相談するっていうのは一ついい姿勢かなって思いますね。
仮に自分がデザイナーとしてあんま詳しくないっていう自覚があるんだとしたら。
デザインシステムの役割
私が今いる会社はもう完全にデザイナーコード書かないような状況になっていて、
エンジニアがUIの組み立ても全部やっていくっていう感じの組織になっているんですけど、
だからこそまだ完成しきっていない状態でもデザインをお披露目して、
ここが実装が難しいとかこういう観点が抜けてるとかをエンジニアがフィグマにコメントを残していくみたいな文化があって、
それで擦り合わされてるからアウトプットとして出てきたものを組みやすい状態になっていたりしますね。
そういう途中での擦り合わせは絶対必要かなって思うね。
もうウォーターフォール的に、はいデザイン工程おしまいです、ここからはエンジニア工程です、戻ることはないですってすると、
多分まあ苦しい。
苦しいですね。
あとはデザイナーがコーディングの知識がなかった場合、
コーディングの知識がある人が作ったデザインシステムとか規約に乗っかるとか、
そういうのである程度制限がある中のデザインになってはしまいますけど、
だからこそ正しいUI設計ができるっていうところはあると思うので。
デザインシステム周りもコードの知識が全然ないデザイナーって、
だいたい制限が多くて、嫌だ、稼が多いっていう反応になるんですよ。
なるほど。
変な話、ちょっとしたレイアウトとかサイズのパターンは、
大きいほどいろんなデザインのパターンが組めるわけじゃないですか。
で、さっき言ったみたいに1%とか1ピクセルとかで調整したくなっちゃうのがデザイナーの差がなので正直言って。
嫌だよ、そんなSMLしかないなんて、みたいななんか言っちゃうんですよね。
なるほど。
で、でなるとせっかく仮に神の視点から見たらめちゃくちゃいいデザインシステムだったとしても、
デザイナーがこんなバリエーションの少なさでも嫌ですよ、みたいになってサジ投げちゃうみたいな。
とかっていうのも結構聞く話ではあって、デザインシステムの導入に失敗しましたみたいな話の裏側みたいなね。
それはデザイナーのわがままというよりかは事前にこれぐらいのバリエーションでやってきますよみたいな合意形成が取れてなかったから、
ユーザー体験の向上
デザイナーがてっきり10種類ぐらい使えるもんだと思ったら、
エンジニアは2種類しかダメですって言って喧嘩になっちゃったみたいなイメージ。
なんか、私の感覚だったらなんかデザインシステムがあることによってある程度ルール決まった上での設計ができるから、
デザイン設計する上でも楽になったと感じるんですけど、
それこそ多分装飾系多めなというウェブサイトを作ってきた人たちとかだと、
通信とかだと表現によって売り上げを立てたいとかそういうニーズとかもあると思うんで、
それを制限がある中組み立てていくのって難しいよねみたいなところは論争になりそうですね。
そうなんですよね。
そのあたりもね、自分で書いたことあると、まあでも妥当なとこですよね。
この3種類がね、みたいなのはなんか諦めじゃないんだけどなんか、
なんだかんだこれぐらいだよねっていう感覚が身についてくるというか。
確かに。
なんか、やたら種類増えると命名も大変じゃないですか。
はい。おっしゃる通り。
XMLで済むんだったら楽だけど、4種類目が出てきたときに、
XLはあるけどXSはないのか、いいのかなこれみたいなことを考えちゃうとか。
たまにありますよね。XXXLみたいな。
もうこれ以上追加できないよーって。
こんなにいる?みたいなね。
何で使い分けているんですかって感覚みたいな。
その分チェック項目とかも増えますしね。
そうそう。
どういうデバイスでどう見えるかとか、そういうところもパターンがある分不明瞭になるので。
そうなんだよね。あと例えばこう、プライマリー、セカンダリーぐらいは名前が浮かぶ。
まあターシャリーも浮かぶかなってなるけど、4番目って何て言うんでしたっけみたいになるじゃん。
僕なんか調べるんだけど。
絵を作ってる人からだったら、いや4種類欲しいんですよってなったら、
まあなんかなりそうだなって気がするのよね。
でも多分コード書くときに命名が苦しいってことは多分、
うまく役割与えられてないじゃんみたいなことの証拠な気がするから。
そうですね。それはもうエンジニアでもよく言われるやつですね。
その辺りもね。
お前命名できないってことはどういうことか分かってんのかって。
扱えてないってことだぞみたいな。
これは責務がちゃんと分割できてないぞって。
そうそう。通称で40話みたいな。
あの赤くて丸いやつと青くて角ばったやつとみたいなのがあるけど。
デザインシステムってなったらそうはいかんわなみたいなあたりとかも、
多分ちょっとぐらい自分でこう作ってみてとか、
それを組み合わせてデザイン作ってみないと、
その感覚っていうのはなかなか得られないかなって。
いやー確かに。
いやでもなんかフィグマが成長したことによって、
なんかそれがコード書けずとも制約が必要であるパターンとか、
命名付けが必要なパターンっていうのが多く出てくるようにはなってきたなと思ってて。
はいはい。
それこそバリアンスの命名どうしようとか、
コンポーネントの命名どうしようとか、
使うケースあんまないかも。
デザインシステム作らない上ではあまりないかもしれないけど、
バリアブルとか使っていくと、
もう命名の嵐じゃないですか。
そうね。
でもなんかわからない命名とかわからないパターンとか作ってったりとか、
なんかパターンが多いほどコンポーネントやばいことになるじゃないですか。
そうね。組み合わせばかりだね。
組み合わせ爆発100種とかなんかよく見かける話なんですけど。
嫌だからね。
なんかデザインツールがコードにすごい近寄ってくれたおかげで、
寄り添い合える世界が近くなってきたような気がしてて、過去よりかは。
もともとフォトショーから頑張ってデザインを組んでたものからすると、
マジでフィグマの存在はコードを書いてる人からしたらありがたいですね。
でかいね。コードを書いてた身からすると、
最終的にこういうコードになるんだからこのデータだわなっていうのが、
かなりスムーズな作り方ができるので、
そういう意味で僕のサイドからしても嬉しいですね。
分かります。
And now, a short commercial break.
エンジニアの価値は世界が決める。
転職ドラフトは年収アップ率94%、
平均年収アップ額148万円と、
圧倒的な実績を誇るITエンジニア限定の転職サービスです。
今までのエンジニア経験を登録することで、
前線された企業から年収提示付きのスカウトが届き、
リアルな市場価値が測れます。
気になる方は、転職ドラフトで検索してお気軽にご参加ください。
ITトリオ。
後ろ向きなっていうか、コード書けないとこんなところがつらい話ばっかりしちゃったから、
コード書けるとこれもいいよって話はしたいんだけど。
そうですね。ぜひぜひ。
デザイナーとしていろんなアプリとか使ってると、
エラーが出るにしてもこういう出し方してくれると分かりやすいなとか、
電波悪いにしてもこういう風になってくれてると、
404出るにしてもこんな風になってると分かりやすいなみたいなのって結構大事なというか、
感じること多いわけですよね。
コードが分かるとそのあたりをちゃんと心地よい、
エラーならエラーなりに心地よいとか、
そういうのを提供しやすいなってすごい思ってて。
具体の話でいうと、リアクトの最近サスペンスが出てきてみたいな話とかをちゃんと使えると、
読み込み遅いデータにしても、
ちゃんとここでこういうコンポーネントを作っておけば、
そんな不快な待ち時間にもならないよねみたいなのは意図して作れるというか、
そういうのを想定しながら作れるとか。
でもそうやって技術的なことを知らないと、
なんかあれじゃないですか、
フェイスブックとかでシュンシュンってなるやつみたいな、
そういうのを言った時にしか話せないというか。
ってなっちゃうので、そこを知っとくと、
この場合だったらこうした方が心地よく使えるなみたいな、
更新するときとか、
今からもう一回リトライするときとか、
そういうのでね、
いい体験を提供できるよねっていうのが繋がりやすくなるかなって。
確かに。
ユーザーが使う、ある意味ブラウザの知識じゃないですか、
ブラウザとしてどう動いていくかっていう前提で、
デザイナーとしてどういう体験の引き出しを持っていればいいかみたいな、
すごい強みになるなって思いましたね、そこまで考えられると。
そうなんですよね。
でもなかなかいないですね。
いるいないで言えばだいぶ少ないよ。
少ないなって今、話してて、
デザイナーの役割と課題
ここまで考えられたらすごいなとか思ったけど、
なんで少ないんだろうなっていうのは、
そうなんですよね。
なんでかなかなか解明できないんですよね。
そもそもデザイナーって種類が多いじゃないですか、
一言デザイナーって言っても、
ウェブに携わってるデザイナーでも種類が多いイメージがあって、
何が強い、何が強いとか、
その中で特にUIウェブが強いみたいなデザイナーが、
そもそもそんなに多くないイメージがあって、
世の中に出ているウェブサイト、
半分くらい多分ウェブ製作、
事業会社の方がデザインシステムとか、
そういうデザイン設計とかがちゃんと、
ベースがあるというか、継続してデザインを運用していくみたいな、
文化がちゃんとあるけど、
製作ってクライアントさんに綺麗に見えるものを提供したりとか、
やっぱりプレゼンテーションして取りに行かなきゃいけないから、
考え方が違ったりとかなると、
めちゃくちゃ古いにかかった上での、
一種のデザイナーっていう感じがして、
対応も難しいんですよね、上で。
そうですね。
製作会社のデザインシステムで聞くのと、
ヘッドレスUI的なのを社内で作ってるのは時々聞くが多いんですけど、
毎回パララックスを実装するから、
画像を与えればパララックスできるものを作っておこうとか、
パターンとして準備しておくみたいな。
ただ、とはいえサイズ、色、形は毎回もう絶対違うから、
それはもう都度都度考える前提でやってみたいな。
そこからもう一回設計し直してっていうところだから。
あくまで機構をライブラリとして切り出すというか、
そんな感じっぽい。
なので、事業会社のデザインシステムとはまただいぶ違うだろうし、
あと結構、制作会社とあちいちの問題なんか、
デザイナーが一旦もう自由にやっていただいて、
あともう私たちがどんだけでも拾うんでみたいな、
割り切ってるとこも聞き忘れ。
割り切ってるところ?
もう自由にやっていただいて、はいって言って。
あるデザイナーの自由さをどんな奴が来ても拾いきれることが、
エンジニアのスキルの高さとか強靭みたいになってるとこも聞き忘れし、
それはそういうところだなっていう気もする。
確かに確かに。
私も昔はどんなデザインが来てもCSSで表現します、キラリ、
それがかっこいいキラリって思ってた時代があって、
でも今思うと、あのコード誰が見て理解できるんだろうって。
あのコード残したけど大丈夫かなって。
その後変更を加えた時に多分ぶっ壊れるけど大丈夫かなって。
読めるかなって。
あるよね。ミニファイしたわけでもないのに読めない。
疑似要素ゴリゴリで何かめちゃくちゃ作って、できたみたいな。
あるよね。
そういう経験してるんですね、デザイナーの人も。
なんかある、多分エンジニア、いかにもエンジニアっていうよりか
マークアップ出身だと一回CSSでどこまでできるのかっていう時期は多分来ると思う。
あるよね。
やる。
マークアップが多めの人はね、多分どこかではキャリアのうちやってると思う。
やってると思いますね。CSSでどこまでお絵かきができるかっていう。
そうなんだ。
どんなカンプでもやってこいみたいな時期があり、
で、どんどんエンジニアリングに寄っていくと、
あ、CSSってこんなに脆いんだ。どうやって運用していくんだろう。
大丈夫かな、あのコードってなっていく。
エンジニアとの協力
なるほど、なるほど。
ある時期はね、これ多分JQueryのなんとかゆらゆらでできるけど、
ここをあえてCSSでやってみようっていうのがあるから。
えー。
めっちゃくちゃある。
そういう形の中二病があると思う。
その中二病で一つ記事書いた。
黒歴史。
あるよね。
あるあるある。
大体ある。
いっそJavaScriptを書いた方が二三行でできるやつをね、
なんか様々なCSSを書いて、なんでわざわざこんな五十行も書いたんだろうかみたいな。
あるあるですね。
そうなんだよね。
全然知らない世界でした、本当に。
時間的に締めますかね、そろそろ。
はい。
ちょっとお願いしていい?どう締めたらいいかわからなくなっちゃった、デザイン。
はい、Tトリオ。
はい、ということで、とても特に私と渡抜さんでキャリアも近いということで、
共感の嵐で盛り上がってしまいましたが、
結論としては、エンジニアもある程度デザインの知識があって、
デザイナーもある程度コーディングの知識があるとより良いアウトプットができる。
あとは、なかったとしてもね、うまくコミュニケーションを取っていくことで解決できる課題とかもあると思うので、
ぜひ参考にしてみてください。
ということで、2回渡抜さんには登場していただきました。
ありがとうございました。
ありがとうございました。
最後にちょっと一言感想とかいただけると嬉しいです。
僕、登壇結構あるんですけど、ラジオの形式、音声だけって普段なかなかやんないので新鮮でしたね。
それこそね、コードが云々言ってましたけど、物を見せて喋ることが多かったんですけど、
音声だけで伝えやすくってどうやるといいんだろうなっていうのもちょっと考えたいなって思いました。
確かに、音だけですもんね。声、喋りのみ、言語のみ。
普段とは違う難しさがあるなみたいな。
そういう気づきにもなりました。ありがとうございます。
よかったです。
よかったです。ありがとうございます。
よろしければまたぜひ来てください。
よろしくお願いします。
ということで、この番組を気に入っていただけた方はSpotify、Apple Podcast、YouTubeなどで番組のフォローをお待ちしております。
レビューもぜひお願いいたします。
お便りも募集しています。
放送の概要欄にあるリンクからどしどし送ってください。
Xで感想を呟く場合は、ハッシュタグ、ITトリオでお願いします。
前回に引き続き、渡邉さんにぜひXでも感想を伝えてあげてください。よろしくお願いします。
よろしくお願いします。
それではまた来週お会いしましょう。
ありがとうございました。
ありがとうございました。
