00:00
[音楽]
こんにちは出口です
こんにちは本山です
リサイゼ編は、本山と出口が最近気になっているサービスやデザイントピックスを取り上げて
のんびり話すポッドキャストです
よろしくお願いします
お願いします
なんか出口君はさ、多分興味ないんだろうなーってちょっと思っていることを話すんだけど
ほい あの野球興味ないですよね
ないですね
まあでもねちょっとこれはねー 話したいなぁと思って
その あの佐々木老基選手の完全試合っていうなんかちょっとチロットでも見ながら
ニュースでニュースで見ました あーだよねさすがにニュースになるよね
いやーもうすごすぎて なんていうかまあなかなかちょっと野球見てないとこのすごさが伝わりづらいとは思うんだけど
うん ただの完全完全自衛ってそもそも何かわかります
完封した 試合
完封はそうまあ完封なんですよだから まあゼロ10でゼロ10で抑えてまぁ最後まで投げ切ったっていうのは完封なんだよね
うん 完全試合っていうのは
一人もその何ランナーその類進めるじゃん野球だと1類2類3類って打ったら
一人も類に出さなかった
そうそうそうしかもヒットだけじゃなくてファーボールもなくて一人も類に行けなかったっていう
全ストライクってこと?
そう、全アウト
全アウトっていうか、全打席ね。っていうのが完全試合で。
これ、完全試合だけでもめちゃくちゃすごいんだけど、
その、完全試合だけじゃなくて、13連続脱三振っていう、
なんか、連続で三振を取るっていうのを13回やるっていうのをやって、
これがめちゃくちゃ日本記録を大幅に更新してるんですよ。
これまでは何だったんですか?
今まで確か8回ぐらいだったんじゃなかったっけな 8か9ぐらい連続脱三心が最高だったんだけど過去ね
それを13連続脱三心とって で連続じゃなくても19脱三心1試合19脱三心っていうこれも日本記録なんであのまあ並んだ形
なんですけど超えてはいないんだけど うん
でしかも完全自愛するっていう とんでもないとんでもないことをしてで
でさらにすごいのが その佐々木東州も20歳だし
その一緒にバッテリー組んだキャッチャーの松川選手っていうのも高校生の1年目のルーキーなんですよ18歳なんですよ
03:09
へー それでパーフェクトゲームやるっていう
いやもう えーみたいな
チームどこでしたっけ? チバロってですね 強いんですか?チバロって今
まあそう 強いかどうかって言われるとそうまあめちゃくちゃ強いわけではないかな
いやこれは本当すごくて
今日もね、千葉ロって戦があったんですよ。
それが、ゾゾマリンスタジアムっていう千葉の方のね、
球場でやるから、本当は友達と見に行こうよって言ってたんだけど、ちょっと予定があって行けなかったんだけど、
今日も佐々木隆起選手が投げる、松川選手も受けるっていうので、
で8回まで完全試合やってるんですよ
で9回も投げんのかなと思ってたらなんか9回は交代しちゃったんだけど
多分ね特典が入ってなかったんですよね0対0で8回まで終わって
で9回どうするって感じだったんで多分もう 球数も100球超えてたんでまぁそれで多分
もう投げんのやめよって感じでなんか引っ込めたんだと思うんだけど
いやなんかでもそれもだから完全試合もあとちょっとやってたらもし本当に投げてて完全試合達成したら2試合連続完全試合っていう
なんかもう誰も絶対できないだろっていう記録を達成しそうだったんですよ
めちゃくちゃすごいなみたいな
なるほど
これね、ほんとすごくて、さっき言ったように、19打3進とって完全自衛してるから、最初の完全自衛105球しか投げてなくて、
105球で完全自衛やろうと思ったら、かなりストライク先行でストライクを投げまくってないと、なかなか達成できないと思うんだよね。
その三振取ってるわけだし。必ず三振取るってことは必ず3球以上投げなきゃいけないってことだから。
ああ、なるほど。
だからボールばっか投げてたらこの球数で絶対できなくて。
これは本当にすごいなぁと思って、でもなんか最近YouTubeで、だから
佐々木隆起選手と松川選手の動画ばっか見てますね。
そんな野球好きでしたっけ?
僕、野球は好きですよ。
そっか。
でも、若干心配になってきちゃったけど、僕はもう…
なんで?
佐々木隆樹選手の投げ方、大丈夫かなーみたいな、肘壊したりしないかなーとか、肩壊したりしないかなーみたいな、そういう目線で見る感じになっちゃって…
06:11
あんま投げすぎてもダメなんでしたっけ?
ん?何が?
あんまり一人で投げすぎるのも良くないみたいな感じなんですか?
それはなんか体的にってこと?
そうそう
まあまあそれはそうですね
なんか甲子園でも確か100球ぐらいで
なんか変えるみたいなルールがなんかあるかないかみたいな話があった気がするし
うーん
まあでもなんかまだちょっと体がさ
ちょっと細いっていうかさ見た感じ
身長でかいから、まあでかいんだけど、とはいえ、大谷みたいなすごいごっつい感じじゃないから、見た感じね、まだまだ。
だからちょっとまだ体ちゃんと作って、そういう意味でも今日引っ込めたのかなっていうふうにちょっと思ったんだけど、だから。
8回で、100球超えてたから確か。
なんかもう、いきなりメジャー行きますみたいに言って、なんか体壊して帰ってくるみたいなことにならないといいなーっていう風にちょっと思いながら、
なんか若干親目線みたいな感じで見てますけどね、だから。
元々活躍してた選手なんですか?去年とかも。
去年もね、そんな投げ切ってなかった気がするんだよね。
しかも、ホーム変えたらしいんですよ。他あんまり知らなかったんですけど。
高校生時代から160キロぐらいバンバン投げる頭首で確か。
ドラ1でロッテが取って、ちょっとずつ育成してたんだけど。
やっぱり肘に負担のかかる投げ方をずっとしてて。
でそれをなんかホーム改造してようやく去年ぐらいからこうだいぶ安定してきたみたいな 感じでもう今年はすごい仕上がってるみたいな
ん いやーなんかロッテーまあ僕最近は別にどこのファンっていうのはあんまりないんですけど
その野球のチームで昔はのロッテがすごい好きだったんですよ 昔ってもだいぶ前ですけどね
初柴選手とか小坂選手とかっていうねかなり渋い選手がいっぱいいるチームだったんで
なんかその頃がまあ僕ロッテ好きでロッテよく見てたんだけど
なんかねまたちょっとロッテファンになりそうだなって思ってなんか久しぶりにでも野球を球場に見に行きたいなって思った本当に
うーん
見たことないですよ いや楽しいよ楽しいと思うけどなぁやっぱり
昔なんか 地元でたまに中日がなんか試合
09:04
うんやっててそれなんか中身に行ったような気がするな 僕もね一回ね父親に
連れてかれてって言うとあれだけど、連れてってもらって、
あのまだ名古屋ドームがない頃の名古屋九条みたいなさ、ドームじゃない時あったじゃん、まだまだ。
はいはいはい。
その時に一回…
めっちゃ昔。
そうそうそう。ドラゴンズ戦を見に行ったんだよね、確か。
僕も一回なんか見たような気がするな。
ドームになってからも確か友達と一緒に行った気がするのは、その時は一塁側スタンドだったかな。
そこら辺の席を友達がもらったから一緒に見に行こうみたいな感じで行って、
始まる前にサインボール投げるんですよね。
選手が、ホームスタジアムだったと。
はいはいはい。
それでなんか、大西、その当時いた大西選手っていうやつのボールをキャッチした記憶がありますね、なんか。
なんか、わかんない。
愛知県だからかもしれないけど、小中学校の時、やたらなんか小体験もいてもらえるみたいなのなかったですか?
え?ないない。
中日新聞だったからかな?
ああ、そうじゃないんじゃない?それは
かも、なんかそういうのあった気がする
いやもう最近ほんと佐々木隆起選手やべえなみたいな感じでもう
いやほん、なんかでも最近さそれで youtube ばっか見てるんですよさ
そういう佐々木隆起選手とか松川選手みたいなやつも
で、色々見てると野球選手のOBがみんなYouTubeやってんの?
ああ、でもサッカーもそうですよ
あ、ほんと?サッカーもそうなんだ、そういうのって
ああ、やっぱそうなんだね
サッカーで言うと、あの鈴木恵太っていう昔笑われていた選手がいるんですけど
その人のYouTubeのチャンネルとか面白いですね
毎回誰か呼んでインタビューするんですけど、インタビューのスキルがすごい高くて面白いです。
そうそう、やたらめたらやってて、古田選手のやつとかは結構見てる人も多いだろうなと思ってて、元ヤクルトの古田、キャッチャーの古田選手ですけど。
なんかその辺のやつとかはもう僕もちょいちょい見たりとかしてたんだけど
なんか最近見たらもうなんか、まあマイナーとは言わないけど
この人も始めたんだみたいな人が、とりあえずなんかちょろちょろ喋るみたいな動画をいっぱい出してる
めっちゃやってます
12:00
めっちゃやってんだよねなんか
だいぶ飽和してきてるような気がすんだよねそれが
Jリーグ公式youtubeとかも、なんか割とちゃんと作ってて面白いです。
ああ、そうだよね。
戦術解説とか。
ああ、はいはいはい。
いや、パリーグもなんか、そのね、なんかリーグでなんか動画出してますね。
結構面白くて、たまに僕も見たりするんですよね、それ。
サッカーもそういうのあるんだなぁ。
めちゃくちゃやってますよ、なんか。元日本大教が。
でも相性はいいよね。
うん、そうっすね。
技術的な部分とかはね、なかなか知らない部分も、小さい子供だったらなかなかプロの技術を知るっていうチャンスもそんなに多いわけじゃないわけだし。
戦術解説とかね、面白いですよね、プロ目線の。
そうか、サッカーも確かにちょっと見てみようかな。あんまり僕のオススメに出てこなかったから見てなかったけど。
めっちゃやってますよ。
面白そうだな。
なるほどね。
しかもなんていうの?僕らが大学生とかの頃に日本代表選手で活躍してた人が今引退して、
ちょっと時間ができたからわかんないけどYouTube始めるとますみたいな感じの人が多くて。
その世代の選手がよく出てるから、現役っていうよりはね。
余計に面白いですね、自分にとっては。
僕もそう、野球もそうだよな。本当、なんか90年代とまでは言わないけど、2000年代ぐらいに活躍してたね。
そうっす。現役はやらないから。
ちょっと活躍して有名な人が。そうそうそう。
なんかね、みんなやってるっていう印象がありますね。
最近ね、それこそ元っていうか、ライブ前にもう辞めちゃったけど、ドラゴンズの監督やってた、オチアイ監督。
はいはいはい。
もちろん、もちろん。 申し訳ないですけど、もちろん、もちろん。 申し訳ないですけど、申し訳ないですけど、 もうなんかね、見たらね、すっごいおじいちゃんになっててね、 もうなんかね、見たらね、すっごいおじいちゃんになっててね、 なんかそれは残念で感じたんだよね。 もうなんかね、見たらね、すっごいおじいちゃんになっててね、 なんかそれは残念で感じたんだよね。
まだドラゴンズの監督やってる時は、まだ若い感じ、若々しい感じあったんだけど、もうなんかおじいちゃんみたいな感じになっちゃって。
ちょっとね、それは残念。なんか自分の中でちょっと残念だったんだよね、やっぱり。
おじいちゃんになっちゃったなぁ。
なんか野球わかんないけど、やっぱ実家にいた頃ってよくテレビで、中日の試合とか流れてたから、その時の選手の名前とか監督の名前はなんとなくわかりますね、やっぱ。
あー、「たつなみ」とかね。「赤見賢進」とかね。
いや、そんなに熱い話だとは思ってなかった。
ちょっと、やばい、話しすぎたな、なんか。
15:00
話しすぎちゃったけど、じゃあちょっとお便り届いてるので、またお便りを紹介しましょうか。
ラジオネーム 春香さんからですね
いつも楽しく拝聴しております ありがとうございます
現在 私は UI や UX 周りのデザイン業務に携わっているのですが
デザイナーの評価方法に悩んでいます
KGI KPI といった評価指標は デザインとの相性が悪い気がしていまして
プロダクトマネージャーも 私も頭を抱えております
デザイナー全員目標を満たすとかざらにあります
売上やCVRのようなビジネス的なインパクトを 図る指標ばかりでユーザー視点が抜け落ちてしまいます
お二人はどのようにしてデザイナーを評価していますか?
かなり専門的なご相談内容になってしまいましたが ご意見を伺いたいですっていうような
なかなかまたまたハードなご質問 ありがとうございますね
難しいですね。
これさ、僕はそんなに、何だろう、デザイナーを、なんていうの、人事評価するっていうのをそんなしたことないんです。採用の評価はしたことあるんだけど。
うん。
出口君はさ、CXOとかやってたわけじゃん。
うん。
だから、そういうデザイナーの評価みたいなさ、人事評価みたいなのをやったりしてたんじゃないの?
やってましたね。そんな人数は多くないですけどね、僕の場合は。
うん。
デザイナー多くても僕の下に2人とかみたいな感じだったから
この話別にデザイナー以外、プロダクト開発に係るエンジニアデザイナーの話なのかなっていう気がしてて
まあ言うは言うくついてるから
同じデザイナーでもわかりやすい業務とわかりづらい業務ってある気がして
エンジニアもそうだと思ってて
やっぱりプロダクト開発に関わるデザイン、エンジニアリングって
わかりづらくなっていくなという気がしてるんですよね
基本、マイナスを埋める業務じゃないじゃないですか
エンジニアリングでも何か、なんというの
例えばインフラとか 割と測りやすいような業務もあるけど
例えばパフォーマンスを改善するとか
マイナスを埋めるみたいな作業って 測りやすいと思うけど
やっぱりプロダクト開発になると エンジニアも測りづらくて
僕自身も昔はクックパトとかで サービス開発エンジニアみたいにやってた時は
割とUUとかMAUとかPVとかで評価されてる時もあったけど
やっぱり何だかなみたいなことを思ってたんですよね
18:01
特に僕のやってた新規のメディアとかだと
台風とか天気が悪くなると人は家にこもるから
PVとかUUが上がるとかあるんですよ
でもそれで評価上がるってなんかよくわかんないじゃないですか
まあそうだね
農業かなみたいな
天気悪くて雨が降ったら
なんか台風が来てね
借り取れなくなって
なんか評価下がるみたいな
でも僕はまあ一応プロジェクトオーナーみたいな立場で
言うようにも責任持ってたから
まあ別にまあそれで評価されるのは間違っちゃなかったんだけど
やっぱり今週は台風が来たから 油油が上がっていいですねみたいなのって
なんか変だなと思ってたんですよね
だから本質的にプロダクト開発に関わる デザイナーエンジニアを
ビジネス的というかサイトの指標というか そういうもので測るのってやっぱり難しいと思ってて
だから根本なんか評価は極めて難しいと思ってるんですよね。
定性、定量的な評価は。
だからあんまそこでひてくり回して考えてるっていうのは、
僕はあんまりやりたくなくて、僕はね。
だから基本は、OKあるじゃないけど、
定性的な目標とかを基本的なメンバーに自分で立ててもらって、
それを達成できたかどうかみたいなところ。
で、その期待とそのギャップでちゃんと測るってところしかやってなかったですね
なんかこう、だからなんて言ったらいいのかな
でもそれでもやっぱ定量的に評価してると求められることは
なんかこう、例えば僕だったら取締役だったけど
なんかもう一人、僕自身が評価される相手としては社長がいたんで
社長からはエンジニア、デザイナーも ちゃんとビジネス的な指標に紐づけて
評価してほしいみたいな 定量的な評価をしてほしいみたいに言われるけど
言われるけど無理じゃんって思ってたから
そこで、頑張ってKPIをひねくり出して評価するのって 本末転倒だなと思ってたんですよ
例えばエンジニアリリース回数とかデプロイ回数とか試作の立案回数とか
そういうのをやろうとも言えばできると思うんですよ 一応
でもそこ別に本質じゃないじゃないですか
別に10回機能をリリースしたからいいっていうわけじゃないし
1回でもインパクトがあればそれでいいと思うし
だからあんまそこ頑張るの嫌だなと思ってたから
基本は僕は数字とかそんなに位置を立ててもらうから、そこは別に重視せず、実際何やってたかみたいな行動ベースで評価するっていうのをやってましたけど、
21:01
それはあくまで人数が少なかったからできたっていう感じですかね。
そうねー
この話って究極やっぱその評価する側
その上長的な人の信頼感による部分だと思うんですよ
マネージャーが他の部門から信頼されている
もしくは社内で重要度が高い発言権があるみたいな人だったら
その下についてる人たちの評価って、ある程度数値にしなくても責任感で担保されてる面があるかなって思うんですよ。
逆に立場が弱くなってくると、やっぱ数字にしろって言われて、無理くり数字にして、実際マッチしてるかどうかわからないみたいなところでストレスがあったりとかすると思うんですよね。
そうですね。あまり答えになってないけど。なんかこう、本質的にはやっぱ難しい。
まあね、難しいよね。
無理に近いと思ってる。
まあ、ちょっとさ、会社とかその組織の規模にもよるとは思うんですけど、
なんか僕は、なんだろう、こう、あんまり偏らない評価をした方がいいというか、
複数軸で評価をいろんな意味で持ったほうがいい 評価軸を持ったほうがいいんじゃないかなっていうふうに思ってて
例えばサービスのKPIが1本でダメだったら ダメになっちゃうじゃん
お前ダメですみたいになっちゃうじゃん その数字が上がらなかったら
だからそれを複数軸評価の軸として このサービスについてとか
もうちょっと、例えばデザインの啓蒙活動みたいなさ、社内なのか社外なのかわかんないけど、そういうのに人力するみたいな、それもやろうと思えば通知目標つけれるじゃないですか。
ブログ何本書くとかさ、いろいろっていうふうにやるとか。
例えばデザイナーだったら僕は、デザイナーだけじゃなくてエンジニアとかもそうだと思うけど、
一つスキルを身につけるとかでも、僕は会社のためになると思うんですよ。
そのスキルが会社で活かせるようなものであれば。
だからそういうものも評価に入れてみたりとか、
もちろんね、それはだからどれが一番とかっていうのなくて、多分バランスよく見なきゃいけないんだけど、その辺も。
なんかどれだけやってましたみたいになっちゃうとよくないから、やっぱり。
とか、あとなんかそういう評価する、時空もそうなんだけど、評価する人も、なんかできるだけ僕は、なんかこう色々多様性を持たした方がいいとは思ってて、
なんかやっぱりそのクックパッドもそうだし ハテナもそうだったんだけど
なんか360度評価みたいなのがあったりとか
24:03
そのサービスの上長の評価と
それとは別にデザイナーの上司というか
デザイナーっていう枠組みの中の
先輩からの評価とかさっていうのもあるし
一緒に働いてる同僚からの評価っていうのもあって
なんかいろんな方面からの評価があることで
バランスよく本当はどうだったのかっていうのが、頑張ってたのかどうかっていうのが測れるっていうのがあるんじゃないかなって思うから
なんかやっぱりそういう意味でも、人っていう意味でも評価する軸っていう意味でも、複数持っておくっていう風にしておくのがやっぱり一番いいというか
結局、そうしないと、数字がダメだったらダメですみたいになっちゃうからやっぱり。
本当は頑張ってたのに評価されないとかさ。
それも誰かが、本当は見てたんだけど、その人の意見が反映されてなかったらってなっちゃうと。
だからそういう意味でも複数軸で見るような仕組みを作ってあげるとかっていうのがやっぱり必要なのはと思うんだけどね
そうですね、やっぱり定量的な数字で評価っていう部分だけじゃなくて、行動評価みたいな部分
でもちゃんとデザイナー、またはプロダクトにかかるエンジニアを評価しないと厳しいというか
その辺がビジネス側が逆に言えば 定量にしやすいっていうのがすごいあると思ってて
僕実際営業とか評価もしてたこともあったけど
そっちってKBが分割しやすい 受注額がこれがあって
それを分解すると受注数と商談数になってみたいな分解がすごいしやすくて
それを追っていくってのもすごいできてしやすいから、評価もしやすいんだけど、
なんかそれをやっぱそのまままるっとデザイナーエンジニアに求めると、やっぱこういう話になっていくと思うんで、
そこはそもそも考え方が違うんだよってところから、
なんかやっぱこう、まあ啓蒙というか、なんかこうしなきゃいけないんだろうなっていうのは思いますね。
うん、そうだね。
まあOKRだなぁ でも結局こういうのって
まあね、方法論としてはそうだと思いますね
まあそうね
まあでも結構難しいよね なんかCookpotの時もさ
一応会社のOKRがあって部門のチームのOKRがあって
で、それをもとにさ、どれをやろうみたいなのをさ、個人が立てていくんだけどさ、OKR立てるの難しかったね。
OKRって、なんかOKRって言うけど、なんか、指してるものが結構人それぞれ違うことがよくある気がしてて。
27:06
あ、そう?
いや、なんていうのかな。いや、大雑把な意味でOKRはいいと思うんですけど、あ、あってると思うんですけど、なんて言ったらいいの?
その結局オブジェクティブに何を置くかとか、
そのキーデザルトをどう測るかっていうところって、
個人のセンスに委ねられるところは結構あると思うんですよ。
結局そのキーデザルトの置き方がちゃんとオブジェクティブにマッチしてないと、
結局測れるようで測れなかったりとかすると思うんですよね。
要はこのUUとかPVとかってキーデザルトっぽいけど
デザイナーの評価としてもキーデザルトとして正しいのかっていうとそうじゃないって話だと思うんですよ
今の話、この話って
なんかそこもね、直接的なKPIってなんかやっぱり分かりやすいから
それってしがちだけどさ、なんかもうちょっと本質的なKPIという数値見る場所ってあるじゃない?
なんかそうなんですよ、なんかね、数字ってこう、なんていうのかな、すごいこう、なんかこう、安心感があるじゃないですか、特にわかんない人から見ると。
わかりやすいよね。
そう。だからそれがすごい危険だよなって思うんですよ。
なんかこう、うん。
よくKPI立てろとか言われるんだけど、
やっぱそこにすごい時間かけるのってどうなんだろうって、すごい僕は思っちゃうんですよね。
なんか。
あー、まあ。
うん。
まあね。
ちょっとわかんないです。
僕根本やっぱ目標とか評価とかあんま好きじゃないから
いやでも好きじゃないと言ってもさ、やんなきゃいけないじゃないですか
好きな人なんていないと思うけどね
まあそうそうそう、評価するのもね辛いからね
いや本当ですよ
難しいよね
難しい
いや関係ないけどなんかあのさ
僕もだから色々採用系の評価を色々するけどさ
新卒の評価がマジでムズイ。
分かんないじゃん。本当に分かんないからさ。
もうなんか潜在能力があるかどうかぐらいで見極めるしかない。
面接の話?
新卒の場合ってなんか面接というか、面接じゃ面接か。面接もあった気がするし。
なんか 面接ですね 採用の時のですね どっちかっていうと
はいはいはい
難しいよね
でもなんか僕 ビジネス側の面接もするようになって思ったんですけど
30:06
エンジニアデザイナーの方がまだ楽だなって思っちゃった なんていうか
ポートフォリオなりGitHubなりがあるから そこ見れば
ちょっと審査さんは別ですけど、中途は特に、なんていうか。
はいはいはい。
ああ、まあ、そうなのか。
いいか悪いかの2部で判断するとしたら、それはすぐに分かる。
まあ、でもさらにいいの中で合うか合わないかを判断するのは難しいんだけど、なんていうか、その最初の足切りはしやすいなと思うんですよ。
なんかビジネス側の面接って、特に自分がビジネスの職種じゃないから、
その上でやるって見ていいものが何もないし、分かりづらいなって思いましたね。
まあ、そうだよね。まあ、そうか。
確かにビジネスの方が難しいのかな。
なんかポートフォルを見たら、一瞬である程度は分かれちゃうんですか?
その「良さそう」、「ダメそう」。
まあまあまあ。そうね。
で、良さそうな中でもさらに見極めるのは難しいですけど
はいはいはいはい
うん
まあでも、結局なんかでも
デザイナーも僕いろいろ見てたけど
まあもちろんね、そのさあ
なんか良さそうなものを作ってるかっていうのもあるんだけど
なんか結局、それはもう最低ラインになっちゃってたんだよね
その時の採用だとやっぱり
あーうん、わかる
なんかね、やっぱり頭の回転というか
回転じゃないんだけど、なんかね
思考みたいなとこに行き着くよね、なんか
だんだんこうやってると
そうですね
まあマインドともちょっと違うんだよね
マインドとも違うんだけど、なんか
考え方みたいななんか
そういうとこに行き着くところがあるよな、やっぱり
ちょっと採用の話になっちゃったらあれだけど
まあでも評価はやっぱり
まあクックパッドの時もそうだったし、ハテナの時もそうだったし、やっぱりなんかいろんな、複数の軸で見る、複数の人が見るっていうのを
にするのがやっぱりいい気がするけどな そうですね、まあ話をまとめれば
数値で評価1本っていうのは多分デザイナーには あまり向いてないんじゃないかなっていう気がしてて
まあスケールはしないけどある程度行動評価みたいなのを 地道にやるしかないんじゃないかなと僕は思っているかな
まあだから一応持つけどっていう感じですよね そうそう 目安としてね
で チームとしても多分数値的な 数値目標みたいなのを持ってたりすると思うから
33:00
なんかね やっぱり
その責任はやっぱり 上長が多いことになるみたいな
基本的にはね
まあでも 上長もやっぱり 数値だけじゃなくて
なんかね いろんな面で
その評価指標っていうのを 持っておかないと
それこそね やっぱり
サービスがダメになったから ダメです みたいな
うん、うん。
うん、っていう話で、答えになってんのかな、これ。
あんま、僕らはこう、評価をめっちゃやってるタイプでもないから。
うん、その人事評価っていう評価はしてないんだよね、やっぱりあんまり。僕も。
あんまね、でかいチームでマネジメントしてたタイプじゃないからね、2人とも。
うん、そうですね。だからなかなか難しいけど、でまあ、Hatenaとかクックパッドのやり方はいいんだろうなって僕も思うから、今、やるとしてもね。
だからまあそういう意味ではやっぱり複数の軸で複数の人が評価するっていう仕組みにするっていうのがやっぱりいいような気がしますね。
うん。
っていう、もうオープニングトークだけで40分近く話してますけど。
どうしようかな
どうしようかな
今日はこれで終わりにしますか
それともまだまだ評価の話をし続けますか
どうしようかな
絶妙な時間になっちゃったな
いやもういいですよ
どうします
仕事をしようかな
最近僕クックパートの仕事やってたんですよそういえば
ノート書いたんですけど
はいはい
やってたこととしては
クックパッドのクラミさんが頼まれて
やってたんです
フリーランスとして
やってたんですけど
クックパッドのPC版のデザインを
デザインのアップデートをするっていう
ちょっと渋い仕事を
やってたんですよ
これあれですよね、だからデザインのアップデート
っていうよりも
デザインの
バックエンドっていう言い方ちょっとおかしいけど
なんか仕組みのアップデートみたいな感じですよね
多分
そうそうそう
リニューアルって言ってないのはあえて言ってなくて
デザイン的にはそんなめっちゃジャンプアップしてめっちゃ変わったって感じではなくて
あくまでスタイルがちょっと今っぽくなったかなみたいな感じの変更に留めてるんですけど
やっぱそれを変えるだけでもなかなかグッグパッドって
特にCSSシュッと変えられるだけって思える程度の
ビフォア・アフターの変化であるんだけど
そのシュッと変えるにはやっぱりとどまらない
色々絡み合って裏側の問題があって
それをデザイン夫妻と呼んでるんですけど
それを解消するっていうのが目的なのをプロジェクトに
4ヶ月ぐらいかな手伝ってたんですけど
36:01
これは中の人やりたくないよね
そうそうそう
いやーこれ
本当に大変だと思うな
ちょっとなかなかね、これでも
クックパッドの内部事情を知ってる人じゃないと
この大変さはわかんないんだよね、なかなか
そうね、知らない人向けにどう大変かっていう話を
ちょっとでもしようと思うと
そもそもクックパッドって
クックパッドってPC版はRubino Railsで作られてるんですけど
それもう15年ぐらい歴史があるコードベースなんですよね
そもそもクックパッドのGitのリポジトリって
世界で一番でかいRaillessアプリケーションと呼ばれてるぐらい
いわゆるマイクロサービスというアーキテクチャが流行る前からあるものなんで
いろんなGagpadっていうサービスもそうだし、管理画面もそうだし、
いろんなアプリケーションがその一つのリポジトリに集まってるっていうような状態のものです。
要は、コードベースがすごくでかいんですよ。
そこからバックエンドに関しては、いろいろマイクロサービス化するみたいな感じで切り出されて、ちょっとは軽量化しようみたいなことはされてきたんだけど、
CSS に関してはこれまでの歴史がすごくたまりに溜まっているというようなものだったんですよね。
だからなかなかモダンな CSS の書き方みたいなものも全然なされてないし、
基本的には10年前ぐらいのフロートレイアウトでクリアフィックス使ってみたいな、
そういう頃のCSSがめちゃ溜まってるっていうような、そういうようなものですね。
で、その中でデザインの不細って何なんだろうみたいな話をすると、
やっぱこう、CSSってものがすごく特徴的な技術というか、
あれって基本的にはスタイルを定義していくもの、
見た目のスタイルシートっていうぐらいだから、スタイリングをしていくようなものなんだけど、
特徴として上書きができるっていうところってすごくあると思うんですよ。
カスケーティングスタイルシートっていうぐらいだから。
なんだけど、それがやっぱすごく上書きとか拡張がすごくしやすいがゆえに、
ルールとか、秩序がない、もし年月末上でその秩序がなくなっていくと
どんどん絡み合って複雑化していくっていうような技術だと思うんですよね
その結果を凝ることって、ちょっとスタイルを変える、色をちょっと変えるとか
背景色をちょっと変えるとか、それをしようと思っても
39:02
思わぬところに影響してたりだとか
なんていうか
あとはこう CSS って
詳細度セレクターの詳細度とかありますけど
なんかこう
思ったように
スタイルが適用されてなくて
別のやつが優先度が上にあって
それが優先されてしまって
Important ってやつをつけないと
思うように
スタイルが書き換わらないとか
なんかそういうのあるじゃないですか
あるね
そういうのってやっぱり 開発の効率とか あとはこう なんだろうな
マークアップも本来 SEO とか アクセスビリティ的にはこうやるべきなのに
まあちょっとこう それがやりづらくなってるとか
そういうプロダクト品質とか そういうものにも影響するっていう部分があると思ってて
そういうやっぱ スタイルだけの話なんだけど
それが開発のしやすさとか プロダクトの構造にもすごく影響を及ぼすっていう
プロジェクトの構造にもすごく影響を及ぼすっていうのが、CSSなのかなと思うんですよね。
だから、歴史がすごく10年以上経ってるものって、それがもう複雑に絡み合っちゃって、
スタイルをシュッと色を変えたいって思うんだけど、それが全然できないみたいな。
それをやるためにはまずは、あれこれしなきゃいけないみたいな、そういうもの。
今回のプロジェクトの目的としては、単に表面のスタイルを変えるのもそうなんだけど、
もともとデザインシステムを刷新するっていうことをやろうとしてたんですよね。
はいはいはい。
それがエプロンってやつなんですけど、
もともとクックパッドってSaraっていうCSSフレームワークがあって、
で、その後に、SALAはC-SETフレームワークなんであくまでその実装上のデザインシステムみたいなものなんですけど、それが10年ぐらい前からあって
2018年ぐらいに僕も当時いたんで、それこそクラミッツさんと2人で、CIとかVIとかそのブランドのアイデンティティー的なところをスコープに置いたSTORASっていうデザインシステムをまたベタ立ち上げたんですよね
で、2021ぐらいに藤井さんというデザイナーとか、
くらみすさんとかを中心にして、そのエプロンというようなデザインシステムが立ち上がったんですけど、
それはそれまでのシリーズフレームワークとしての部分もあるし、
CIとかVIとかそのアイデンティティ的な部分の定義もあるし、
割と規模の大きいデザインシステムになるんですけど、
そのエプロンを導入していくっていうのが 今回のプロジェクトなんですよね。
今回はガッツリエンジニアとして関わっていて、
エンジニアリング以外のことは基本は他の人が やってくれていたプロジェクトなんですけど、
僕はひたすらシーセスを書いていたんですけど、
42:03
クックパトの話抜きにして、結構そういうデザインシステムの代替わりみたいなことを今回やったんですけど、
それをやってると結構、個人的にデザインシステムってこういうことかっていうような分かりがいくつかあって、
ちょっとその話をしようかなと思うんですけど、
そもそもSALAってCSSフレームワークのSALAってやつ
本山さんも開発やってたりとかしてたと思うんですけど
あれってなんか結構
僕そのSALA立ち上げの時には関わってないんだけど
なんか今思うと結構こう
エンジニアが素早くデザイナーなしで
サービスを立ち上げるっていうところに
特化してたフレームワークだったんじゃないかなって思ってて
そうね
それで何かっていうと
例えば utility class
例えば .titleっていうクラスをつけると
クックパッドのタイトルとか
見出しとかで使われてるスタイルがすぐ適用されるとか
あとはこう
タイトルでさらにそこに right ってつけるとそれが右寄せになるとか
left ってつけると左寄せになるとか
そういうクラス名をHTMLに付与していくことによって
ひとつの由来を作っていくというような
要はCSSをなるべく書かずにして
HTMLをいじるだけで完結するようなふうにするというような
それによってサービスカラースの速度を上げるというような思想だったりとか
あとはアトミックデザインでいうアトムみたいなコンポーネント
カードのザブトンになるような四角形のものだとか、
見出しとかに使われるような帯のデザインの部分だったりとか、
ブロックとかボックスとか呼ばれてましたけど、そういうものを提供して、
それをエンジニアが実装時に拡張しつつ新しいUIを作るみたいな、
新しいUIのベースとなるようなすごく抽象的なコンポーネントをたくさん提供するみたいな
そんなざっくるわけで2つの強みというか特徴があって
結果として当時ってやっぱ10年前ってデザイナーが少なかった
本当に少なかった それこそ持山さんとか池田さんとか何か数名しかいなかった
たぶん確か皿作ってる時って池田さんぐらいしかいないんですよね
もうちょっといるんですけど、僕もいなくて、それで確か池田さんがすごいこれを無理やり、最初はなかなか入れないと進んでいかないから、頑張ってこれ作って入れていくっていうのをやって導入したみたいな感じだったんですよね、確か。
45:02
僕も当時インターン生だったんだけど、確かデザイナーと名乗ってるのって、本当に池田さんぐらいしかいなくて、エンジニア兼デザイナーみたいな人は何人かいたんだけど
だから、エンジニアの比率に対してデザイナーが圧倒的に少ないみたいな組織の状態だったから、だからデザイナーがなるべくいないチームであっても
この皿を使うことによって 素早くクックパッドっぽいUIが作れるみたいなところが
すごく設計思想としてあって それがハマって すごく活発に使われてたっていうような感じだったんじゃないかなと思うんですよ
なんかちょうどその頃って Twitter Bootstrapとかそういう系のやつがね
そういうCSSフレームワーク的なものが いっぱい流行ったんだよね 確か
うん そうそう
それに近いような形で、エンジニアがさくっとインターフェースを作れるっていうもの、
あずらくの見た目を整えられるっていうものとして、
すごくたくさん使われるようになったっていう感じだった気がしますね。
で、それがやっぱり10年、現役が結局続いてるんですよね。
その2012年ぐらいからできて、今2022年まで至るみたいな。
僕はサラって当時としては 画期的なデザインシステムだと思ってるんですけど
やっぱりこの10年経つと いろいろ素敵な事情とか 時代に合わなくなってきた部分がいろいろ出てきていて
それが今回のデザインサイト 呼んでるものの正体にもなるんですけど
CSS自体も結構アップデートしてますしね そもそも
僕もノートにちょっと書いたんですけど、例えば、まあその、まあそもそも前提としてやっぱその印象として、当たる印象として10年前に作られたものなんで、今見るとやっぱちょっと古臭い印象になっているっていう、岩自体がね。
見た目がね、なんかちょっと時代に合わないかなみたいな、なんかそういうのもあるかもしれないね。
で それ自体は別に仕方ないことなんだけど ただ 皿の特徴として拡張性がとにかく高かったっていうところで
結構 時が経つと拡張性が高いがゆえに いろんな人が皿のUIをベースにして新しいUIを作るっていうことをやってたので
本当にいろんなクックパッドのサイトのいろんなところに皿が使われてるわけなんですよ
それも皿が表層的に使われてるわけじゃなくて内部に結構埋め込まれた状態で使われてるっていうようなことが起こっていて
それこそ皿だよね やっぱり皿になってるよね やっぱりちゃんと
そう皿なんですよ 料理じゃなくてね
ちゃんと皿になってんだよね だからさ ずーっと掘ってかないと皿までたどり着けないみたいなさ
そうそうそう。本当に長手を表してるっていうような感じで。
48:04
そういう意味では、サラとしてはちゃんとうまくいったんだよね。
めちゃくちゃ設計。僕もサラにかかってないから、当初。
あくまで使い方、現代の使い方を見た上で、さっき話したような、
こういう特徴だったんだろうな、こういう設計ストーだったんだろうなっていうのを見た、考えてたんですけど。
なんかちょっとノート書くにあたって 昔の資料ないかなと思ってググってたら
池田さんのその発表資料が出てきて
それを見たらまさに同じことが書いてあって
本当にもう設計思想通りに広まってて
すげーすごいな池田さんって思ったんだけど
だから本当に皿になってたから
なったがゆえに本当に埋め込まれて
サービスの中に本当にサービスの皿になって埋め込まれてるから
それをやっぱそこが皿の見た目がちょっと古臭いからと言って
それを変えるっていうところはなかなかできないわけなんですよ
上に料理が乗っかってるから
皿の色を塗り替えたとて料理が乗っかってるから変わんないみたいな
そうそうそうなんですよ
っていうような感じだし
あとねクックパッドだけじゃなくて
やっぱこの10年でああいうクックパッド規模の代行サービスって
どれもやっぱ主戦場がモバイルに映ってると思うんですよね
PC から
だからやっぱり 事業部でサービス開発してる人たちも
主戦場モバイルにあるから
PC の特にしかもパッと手が出せない
皿の変更っていうものは
なかなか優勢が上がりづらくて
結果として根本的な解消ができないみたいな
状態になってたんですよね
だから僕が呼ばれたっていうような感じなんですけど
でもその中でもPCで活発にまだ開発してるページって一部はあって、機能で一部はあって
そういうところって逆に現代のトマニアに合わせるように表面だけをなんとか上書きする
要は皿の表面だけをペンキで色を変えるみたいなことをされてて
まあでも結局その皿本体には 日々が入っているんだけど
でもそこをなんとかパテで埋めて
こう色を塗り替えてみたいなことを しているっていうような感じなんですよ
でもそうなっちゃうと
そもそもデザインシステムとして
コンポーネント UI のコンポーネントを 提供している意義が薄れてる
薄れちゃうんですよね
結局コンポーネント提供してるんだけど
それを上書きして別の UI に変えてるわけだから
そもそも中央瞬間的に
コンポニュートを管理している意味があまりなくなっていくので
っていう意味でデザインシステムとしてコンポニュート提供しているって意義が
やっぱり10年経つと薄れていくっていうようなことだとか
あとはUtility Classってさっき言った
CSSをなるべくかかわずにHMLにマークアップするだけで
51:01
スタイルが作れる、UAが作れるっていうようなものがあったんだけど
やっぱり10年前の技術全体にやってたから
フロートレイアウトは前世紀の時代ですよね。
今ってもうフレックスボックスとかそういうもので基本的にレイアウトを組んでいくような時代じゃないですか。
CSS グリッドとか。
だから逆にその過去のユーティリティがあることによって、
フロートレイアウトで組まれたページに例えばモダンCSSを取り込んでいくって、
小さい部分、部分的なものだったらできるけど、大部分なものになってくると難しいと思うんですよね。
だから、過去にユーティリティーって便利にするためにあったものがあることに、
今、現代で無駄な記述、フロテラやと打ち消すためのやつを書かなきゃいけないとか、そういうものが必要になってきて、
その無駄な記述を経過として 助長しているっていうような現象があったりとか
うん
フロートとフレックスボックスだと HTML の記述的にももしかしたら変わってくる可能性があるしね
なんか場合によっては 書き方によっては
そうそうそう
やっぱラッパーとかをどうするとか 記述の前後の関係とか
やっぱマーカップの仕方もちょっと変わらざるを得ない部分がどうしても出てくるし
あとはやっぱ10年前だとまだまだレガシーなブラウザ IE9とか
9はどうかな10とか11とかは全然前世紀だったと思うんで
なんかこうそういう古いブラウザ用のブラウザハックとか ベンダープレフィックスとかなんかそういうのが全然バレバレ書いてあるような感じなんで
そういうのもどんどんCSの見通しを悪くするような原因になっていくわけですよね。
あとは、これはクックパッド固有の実証かもしれないんだけど、
アプリケーションでデザインシステムが必ずきれいに分かれていない状態になってきて、
一体化しちゃってるっていうような現象があったりとか、
クックパッド.comのベースのスタイルだとか、サイトのレイアウト、全体の絡む幅だとか、
初代のフォントファミリーとかモディサイズとか
なんかそういうものを
本来はアプリケーションが責任を持つべきなんだけど
デザインシステムが担保、責任を持っちゃってて
なんかそこがこう、昔はこうね
単一事業だったからよかったんだけど
そこで複数事業とか複数ブランドがなっていく中で
デザインシステムっていうのが本当はこう
汎用的にいろんな社内の事業、ブランドから
ある固有のサービス、アプリケーションが 特有なものになっちゃってるって言うような事象とか
そういうような時を得ることによって
昔は開発速度を上げるための デザインシステムだったんだけど
54:03
やっぱりククワットのPC版って どっちかというとメインに活発に開発されるというよりは
どっちかというと今は遠熟期というか 運用がメインのサービスだと思うフェーズになってきてるので
そうなってくるとデザインシステムに求められる役割も変わっていくわけなんですよね。
今回のエプロンというデザインシステムって、設計思想自体は結構変わったところがあって、
もともとは抽象的な、要はSara時代は速度を上げるためにユーティリティークラスとか抽象的なコンポーネントを提供して、それをベースに拡張して新しいUIを作ってもらうとかそういうような思想だったんだけど、
今回の新しいデザインシステムの場合は
そもそもパーツとして成立している UI
具体的に高いコンポーネント
例えばドロップダウンとか
ダイアログとか
ページネーションとか
Banquesとか
そういうような
それ単体でUIとして成立しているような
コンポーネントを提供して
さらにそれを基本的に拡張せずに
そのままアプリケーション内で使ってもらうような想定で作られているデザインシステムで
結構そこが大きく思想が違ったりするんですよね
このコンポーネント拡張をしないアプローチって
デザイン強度というか一貫性みたいなのは結構担保できると思うんですよ
サービス会社が基本的には拡張、上書きをしないって前提なので
ボタンはこれって決めたら どのサービスでも同じようなボタンが使われて
NPMとかそういう仕組みで配信 各アプリケーション配信して
その大元を変えれば各サービスに反映されるっていうような
デザインの一貫性というのはすごく保たれるような 仕組みアプローチだと思うんですよね
ただ逆にトレードオフとして
コンポネートを基本的に拡張させないから
エプロンという新しいシステム自体にも提供するコンポネートの質と量が結構求められるっていうようなアプローチだと思ってて
要は基本的に拡張しないから
その量が少なかったり質が悪かったりすると
そもそもエプロン自体を活用しようと思う
することがサービス活用ができなくなるっていうような話なので
だからデザインシステムのメンテナーが必要になるアプローチだなっていう風にアプローチなんですよね
そこは今回、カックパトの場合はデザインの基盤のチームみたいなのが今、去年だっけな、一昨年だっけな、その辺りからあるらしくて
まあ 基本はそのチームがメンテナンスをするっていうような組織体制になってるから
57:06
まあ そういうアプローチができるっていうような感じみたいですね
で なんか これって結構 なんか Figma のスキーマ
なんか 前 ResizeFM でも話しましたけど
スキーマっていう Figma のデザインシステムのカンファレンスが去年の夏ぐらいにありましたけど
ありましたね
結構そこの発表を見てても、例えばNetflixとかもそうですけど、
基本的にはデザインシステムチームみたいなのがいて、
その人たちがコンポーネントだとかを準備、提供して、
それをサービス側というか事業側に使ってもらうっていうような構造の組織的な話が多かったなっていう気がしてて、
やっぱこういうメンテナー開催型のデザインシステムっていうのは
まあ結構まあ割と大きめの会社では
まあそういう流れなのかなっていう気がしてますね
そうだよね
まサラの時もね一応やってたんですよね
だからそのまあ完全に専属ではないんだけど
僕とも一応 結構ボランタリーみたいな感じですよね
いや一応僕は普通にメンバーとして入っていて
だからさっき言ってたその評価にも入ってるんですよね その皿をメンテナンスする評価軸みたいな
ああ そうだったんだ
そうそう そう だから一応だから僕とか他の何人か
まあちょっとクライアント側の フロント側のエンジニアとかも含めて
そういう皿とかそういうものをメンテナンスする メンテナンスとか メンテナンスっていうとあれだけど
アップデートするとか 必要なものを入れたりとか直したりとかっていうのは
サラの時もやってた時期はありましたね もちろん
うん
まあ確かにその辺あれですね やっぱ
思ったこととして デザインシステムと デザイン組織のあり方ってすごいリンクしてんだなって
うん
改めて分かったというか
多分 そのモテマサの時代って
僕もちょっと一時言いましたけど ユーザーファースト推進式的なチームがあって
デザイナー横断組織みたいなのが あった時代ですよね
そうそうそう
で、基本的には事業部に、横断チームからデザイナーが一滴が派遣されて、
で、こう一緒にサービス開発していくみたいな、そういうようなスタイルでしたよね。
あの時って。
で、確かその後にその横断組織が解体されて、事業部付けになったんですよね。デザイナーが。
はいはいはい
だから多分その時で 多分その明確に皿をメンテナーする誰かってのが いなくなったと思うんですよね
はいはい
で今回またそれがまた一周して 新しくデザイン推進部だっけな
ちょっと名前はあれですけど
1:00:01
あのっていうまた横断組織ができて
でそこでまたメンテナーが誕生したっていうような感じだから
結構こうゆり戻しがあったんだろうなっていうような
だからその辺が結構デザインシステムをどういうアプローチで作るかっていう
この速度を上げるって基本的にエンジニア側に
エンジニアとか事業部側、事業部でサービス開発をしてる人たちに
DIY的な感じで使ってもらうっていう皿みたいなアプローチもあれば
今回のエプロンみたいなパーツとかもう出来上がるものを提供して
なんかそれをそのまま使ってもらうみたいな
なんかそういうアプローチもどっちがいい悪い点 特にないと思うんですけど
なんかやっぱりそれって組織の広報フェーズとか あとは対象となるサービスのフェーズ
立ち上げ機なのか ある程度遠熟機なのかみたいな
なんかその辺とすごいリンクしてるだなっていうのは 改めてやってて思いましたね
まあそうだよね なかなかね メンバーが揃わなかったら
そういうのに手が回らなくなっていってしまったりとか
まあ状況によってね 組織のなんか
できたりできなかったりっていうことがあるから
まあそれが反映される部分であるよね 確かに
こう見間違えると結構危ないなと思ってて
なんかこうやっぱ カンファレンスとか出てくる
Netflixとかそういうでかい会社のシステムって
メンテナー開催型のシステムだから
絶対にメンテナーチームっていうのがいて
デザインオーダーのチームみたいのがいる
会社の話だと思うんですよね
なんだけどそれが良さそうってマネして
スタートアップの01のまだ本当に0のフェーズの
会社がそれをマネすると
またそれって別の話だと思うから
デザインシステムせっかく作ったけど
全然提供されるコンポーネントが少なくて
使い物にならないとか
でもそれはメンテナーするチーム
組織するほどの会社の規模じゃないとか、そういうことが起こりそうだなと思って
その辺は自分たちのフェーズがどこなのかっていうのを
行き止めた上でどういうアプローチをデザインしても作るかって考えるのが
やっぱ大事なんだろうなっていうふうに思いましたね
そうね
まあっていうような仕事をやってて、今のはだいぶ抽象的な話でしたけど
具体的な話としては、地道にLegacyのシーセスと向き合うっていう、すごく地味な仕事をやらせたんですけど。
これをさっと読んだけどさ、ここのさっと読んだところだけでは伝えきれない大変さが、ぎゅわーってこの余白に入ってるのが僕には見えるからさ。
なんかそこを、もうちょっとなんか書けなかったのかなってちょっと思っちゃったけどね、逆に。
いや、書けないんだけどね。
書けない。なかなかね、込み入った話が多いから。
1:03:03
そうそうそうそう。
書いてもいいけど、誰も読まねえだろうなと思って。
なんかさ、この、なんていうの?
瓶栓にさ、なんかこう、伝えきれない思いをさ、
瓶栓の空白の枚数を増やすことによって伝えるみたいな。
そういう、伝われ!みたいな、そういう大変さ絶対あるだろうなって思いながら見てましたけどね
ありますね。まあ、いいリハビリになりました。最近コード書いてなかったんで
いや、なんか、あー、どうなんだろう、ちょっとPCの方、あんまり僕も覚えてないけどさ、なんか結構僕が触ってた時って、あの、
まあ、このPC用の皿っていうのが割ともう、池田さんがガーンって作って、まあ時々こうね、色々コンポーネント追加したりとかっていうのやってたぐらいだったんだけど、
僕は、なんか、それのモバイル版を作ろうみたいなので、なんか、いろいろ一時期動いてたことがあって、
あれも、茶山さんがやってたんだ。
知らなかった。
そうそう。わりと僕が入って初期の頃にやってたんですよね。
知らなかった。
そうそう。で、モバイル版はモバイル版で、結構今もそうかもしれないけどさ、結構開発が活発で、
で、なんかクックポットの特徴としてさ、なんかこう、気軽にテスト的な開発をぶち込めるっていうさ、そういう仕組みがあったじゃないですか。
ちゃんこね。
あんまり そうそうそう あんまり ああちゃんこは
出てますよ表に
世に出てるか
出てる出てる
ちゃんこっていうなんかこう 気軽 まあ気軽といってもある程度
もちろんね レビューはされるんだけど
プロトタイピングのプロトタイピング をやりやすくする仕組みみたいな
そうそうそうそう そうそう
それをさあこうガンガン突っ込んでくる わけですよ 一つのページ 例えば
一つのページに
はいはいはい
なんかちょっと試しにこういう の入れてみたいんだけどみたいな
でガーンと入れるみたいなのを
それがさ、積み重なって、とんでもないことになってた時期があって、一時期確か。
その一つのモバイル、例えばトップページみたいなものとか、メニューって言われてる、右側から出てくる、ナビゲーションがいっぱい出てくるメニューのページがあったりするんですけど、
そこがとんでもないことになってて、CSSもぐじゃぐじゃになってるし、CSSどころじゃなくて、Rubyのコード自体もそのチャンコで入ったテスト的なやつがグワーって入ってて、
一時期もあれがもう、これは手をつけられんみたいな、しかもさ、本当はあれ確か、ちゃんとこれ検証が終わったら本番に生かすっていう意味で、
っていう意味で、ちゃんと実装するのか、それとも取り下げて消すのかっていう、やんなきゃいけないっていうさ、なんとなくルールはあったんだけど、
それがちゃん、厳密には運用されなかったから、なんかこう、ナーナーで残ってるみたいなさ、なんかずっと。
1:06:05
で、そのナーナーで残った上に開発がされていって、どんどんこう、プロトタイプ的に作ったものの上に塗り重ねられていくみたいなのが出来上がって、
で、なんか、それを、なんとかこれをもう直さないと、この、今後開発していくのが大変なんじゃないかっていうので、
なんか、ある程度さ、こう、クックバットもさ、評価の時期ってあるじゃん。
なんか半期か、それぐらいに一度ぐらい。
で、もう、これ以降仕事してもそんなに評価に反映されないみたいなさ、なんかそういう微妙な時期あるじゃん。
あるじゃないか。 評価が全部終わっちゃって、あとは打世で仕事するみたいな時間みたいな。
なんとなくあるじゃないか。その期間に、僕の仲が良かったとも言えないけど、知り合いというか、一緒にやったことがある仲間の演じんにあった人は、
「これなんとかしないとダメですよ」みたいなことを言って
一個ずつ解き放すっていう
なぜかその期間にやるっていうのを
すごいやってた記憶がありますね
なんか、デザイン的な不才能って
評価と評理一体だなと思うんですよ
特に、本当にさっきの冒頭の評価の話
本当に紐づく話だなと思ってて
特にCSSって特徴として
偉いなら偉いならないっていうのが
やっぱり特徴としてあると思うんですよ
デザインがどんだけめちゃくちゃぶっ壊れてても
さすがに激しく使い物にならないぐらいぶっ壊れてたら
ユーザーに影響あるから
それはなんか不在として
県庁にやられていくわけなんだけど
基本的にちょっとだけボーダーが消えてるとか
消えてるとか、なんかちょっとだけマージンが広がってるとか、
そういうのって全然気づかないから、
で、エラーにもならない、だから、
不済としてフィーチャーされない、
だからそれを回収しても評価されないっていうようなループが発生すると思うんですよね。
だからどんどん積み重ねて溜まっていくっていうようなものがあるなと思ってて、
で、これがバックエンドのコードとかになってくると、
やっぱこう 開発のしづらさとか
例えばパフォーマンスの影響がありますとか
セキュリティ上の問題がありますとか
そういう結構フィーチャーされるタイミングが
結構いろいろあるから
付債の回収されるタイミングも結構あったりして
ちゃんとそれが評価されるとかもあるんだけど
なかなかデザインの付債って
それがなかなか顕著にならない
付債として顕著にならないから
評価されづらいっていうのがすごくあるな
っていうのを今回コード見てても思いましたし
1:09:01
別にそれがね 別に組織として悪いってわけじゃ
ディスってるわけじゃないんだけど そういう傾向があるっていう
自称としてはそういうのがあるなって思いましたね
なんかでも そんなさっき言ってたやつを解決してた時も
めちゃくちゃ 周りからの評価が上がるみたいなさ
それはあると思う
あの人神だわみたいになって
すげえ開発主役少なったみたいになって
「うわー、あの人神だわ」みたいな、周りからの評価があるみたいなのがあったりするから、
だからそういう意味でも、やっぱりその上長とか、なんか関係ない部署の人からの評価っていうのも入ってないと、
それが評価されなかったりするんだよね。
確かにね。
そうそうそう。本当にそうで。
いや、ほん…
確かに僕も今回、僕らもこの、今回のプロジェクトやってて、
なんか他の人から、なんか社内からこう「ありがとう」みたいに言われたりとか、
したりとかっていうのは、うん、あったみたいですね。
いや、そうなんだよね。
だからそういう意味でもやっぱり評価する人っていうところが複数軸なしと
それが評価に繋がらなくてモチベーションがないからやらないっていう風になっちゃって
どんどん負債がたまるってことになっちゃうんだよね
そういうのやっぱ大事にしないって
実際さそういうの大事じゃん
結局なんかその後の開発スピードに繋がったりとかっていうのがあるから
地味なんだけどなんか地味に効いてくる部分だから
そういう仕事をね、そういう仕事がないのが一番だけど、
やっぱり誰かがやらなきゃいけないみたいなのがちゃんと評価されるっていうのが必要だよね、仕組みとして。
やっぱ、不細は絶対にたまるんで、それをちゃんと評価されるのもそうだし、
あと大事なのがいつか不細化するって前提でそもそも設計するっていうのが大事だよね。
大事だなと思ったんですよ。
だから今回の新しいデザインシステムで言えば、
結構クラス名にプレフィックスみたいなのがついてるんですよね。
その辺は設計した富士山という、富士堅がちゃんとやってたと思うんですけど、
それを例えばエプロンだと、APRっていうプレフィックスが全てクラス名についてるんですけど、
それってすごい地味なんだけど、すごく大事なことだと思ってて、
そのAPRってついてることによってクラス名にグレップしやすい、
コードベースでAPRってやれば、
エプロンが使われているクラス名がガガガっと出てくるっていうだけですごくメテナンスビリティが上がるし、
いざいらなくなったり、将来不再開して削除したいってなったら、
それを一括で削除するってこともやりやすい、
まあ、そんな単純には行かないと思うけど、
でもないよりははるかにマシなんですよね、そのプレフィックスがあるかどうかって。
とか、そもそも今回のアプローチで拡張させないっていうアプローチを取ったのも、
やっぱこう、どうしても拡張されると、それを入れ替えたときに、
1:12:03
オンワーヌーの影響が出るとかってことが起こり得るから、
なんか、なんていうのかな、たまにもとやまさんとポータビリティみたいな話をすると、
なんかこう、なんていうの、IoT機器を家に入れるときも、 それを完全に作り込んじゃうと、そのIoT機器が古くなったときに、結構大きな工事が発生するけど、
最初から取り除きやすいように設計しておけば、そこは大事。 IoT機器が古くなっても取り替えやすいよねみたいな話。
それと全く一緒だと思ってて。
だからデザインしても、もう絶対いつかは不再化するんで、その不再化した時に新しいものに取り替えやすいかどうかみたいなところっていうのは結構設計陣に考えておくべきなんだろうなっていうのが今回やってて思いましたね。
なるほどね。
あまりにも汎用的なクラス名とかそういうものにしすぎると、
これはどっちのことを言ってるんだろうみたいなのが分からなかったりする時もあるしね。
これはサラの方のタイトルの話をしてるのかみたいな。
例えば、UIで言うとボックスとかカードとかベースとかめちゃ使うんですよ。
僕もモバイル向けのCSSフレームワークというかサラーでいっぱいそういうの作ったもん確か
サラーに流ってねそこは
だからそういう風にしちゃうと、あとあと取り除くのがなかなか大変とかね、確かにあるよね
だから本当にちょっとした話なんですけど、名前に気を使うとかアプローチ
今は結構技術も進化してるから、例えばCSS in JSとか、上書きされづらくて、コンポーネントとして強度が高いようなUI提供の仕組みって結構いろいろあると思うから、だいぶ状況は変わってるけど、
上書きされやすいというCSの特性をどうカバーするというか、どうコントロールするかというところが、
結構取り除きやすさに直結するなデザインシステムは、というふうに思いましたね。
そうだね。お疲れさまでした。
いやいや、これは仕事なんで、お金たらやってるんだよ。
でもなんかさ、このブログにも書いてあるけどさ、ちゃんとこう、その後の計測して、そのスコアが良くなってるみたいなさ、数値に表れているのが良かったね、これ。
ああ、そうですね。それこそ、CSのリファクタリングとか、デッドコードの削除、使われてないスタイルの削除とか、別に頼まれてたわけではないんですけど、やっぱりやった方がいいだろうなと思ってやってたんですよ。
でもそれがちゃんとLighthouseっていう Googleが出してるスコアリングのツールを目安定度にとってたら
1:15:05
それにもちゃんと反映されて、いい方向で反映されてたんで
やっぱりそういうのやっててよかったなと思いましたね
なんかね、それをちゃんと数値目標的なものも、数値目標があったかどうかわかんないけど
そういうものとしても、ちゃんと目に見える形でできてて、これは評価しやすいプロジェクトだったんじゃないですか。
僕は業みたいな誰なんですけど、社内にいる人は評価してほしいなって思ってます。
内部の人がこれをやるっていうのは、なかなか大変だと思う。
なんかモチベーション的にも評価されるかどうかっていう的な部分。
だからね、僕みたいな、フラフラしてて、昔のことをよく知ってる人が、こう選ばれたっていう話だと思うんですけど。
でも、そういうのはあるよね、やっぱり。
外部の人の使い方っていう意味では、そういうのもあるんじゃないかなって僕は思うんですよね。
なかなか内部の人ができないっていう部分に対して、ちょっと手を貸していくみたいなのができるっていうのが、やっぱりいいところだったりするし。
ぶっちゃけこうやって ある意味お金で解決してるっていう話だと思うんですけど
全然ありだと思うんですよね この不採用解決するっていう上で
いやぁ 大変そうだな これは
いや なかなか個人的には イケイケになった仕事でしたっていう
でも ちゃんと運用されるといいですね その新しく入ったエプロンも
これもなかなかまたメンテナーがいなくなってとかなっていくと、
で、あの頃の知ってる人がいなくなってみたいになって、
こう、すたれていってしまうと、また同じような悲劇が生まれていってしまう可能性があるから。
まあ、そうですね。
まあ、なかなかこの10年で何台もデザインシステムを運用してる会社もなかなかないと思うんで、
ないねー
先行ってる感じがして、その辺は先を行き続けてほしいなと、OBとして思います
また10年後呼ばれるんじゃないですか?ちょっとエプロンがみたいな
まあじゃああれっすね、本当に神社を式年宣告する人みたいな
そしてなんかあの人あの時のあの人が来たみたいな感じでこうさ 職人が来たみたいな
伝統芸能になっちゃうね本当
そうならないことを祈りたいですね
そうですね
っていうまあちょっと冒頭の話にも繋がって良かったんじゃないでしょうか
1:18:02
こういうのも評価されるような、やっぱり多次元的な評価軸、評価する人みたいなのが組んであると、
まあいいんじゃないかなっていう風に思いますね。
まあ、はい。
ちょっと長くなっちゃったんで。
こんなところで終わりましょうか。
はい。
リサイズ編のご質問やご感想、リクエストなどはハッシュタグ#リサイズ編でTwitterにつぶやくか、
ショーの音にあるお便りのリンクから送っていただければ 今回みたいに配信内で取り上げてお答えしたりしますので
どうしどうしいただければと思います リサイズ編は毎週金曜日に配信します
spotify itunes のフォトキャスト google ポッキーとキャスト youtube などで配信していますのでよかったらチェックしてみてください
ということで今回はここまでまた次回お会いしましょうさよならさよなら
♪~
ご視聴ありがとうございました!
