#201 デザインシステムの育て方

ゴミ拾いと出会い

スピーカー 1

こんにちは、Deguchiです。

スピーカー 2

こんにちは、Motoyamaです。resizefmは、MotoyamaとDeguchiが最近気になっているサービスやデザイントピックスを取り上げてのんびり話すポッドキャストです。よろしくお願いします。

スピーカー 1

お願いします。

スピーカー 2

最近、朝、結構起きて運動してるんですけど。

スピーカー 1

うん。

スピーカー 2

まあなんか、運動ってもいろいろ、まあ普通に散歩してるだけの時もあれば。

スピーカー 1

うん。

スピーカー 2

あの、ビーチの方にバスケットコートがあるんで、バスケットのコートの方に行って、まあコート空いてればシュート練習したり、空いてなかったらまあそこでランニングするなり筋トレするなりするみたいなことを早朝にやってて。

で、まあ結構前はずっとそれ、ただそれだけをやってたんですけど、まあなんかちょっと前に、友達をが、なんか海、海見たいみたいな感じで、まあ家に呼んで海見に行ったりとかした時に、まあちょうど雨の日の、雨の次の日だったのかな。

まあその日は晴れてたんですけど、前日雨降ってたみたいな感じで。

まあ前日雨降るとね、どうしても海が濁りがちだったり、まあ特にするんですね。まああの川沿いっていうかね、あの河口あたりだと特にそうなんですけど。

スピーカー 1

うん。

スピーカー 2

とか、まあやっぱりあと水漁部が多かったりとか、あの荒れたりする、あれ、前日荒れてたりすることが多いんで、そのなんか漂着物が結構多かったりして。

スピーカー 1

うん。

スピーカー 2

まあだからなんか結構その日は、友達誘っ、呼んでその海見に行った日は、まあ結構ゴミとかもいっぱい散らばってたんですよね。まあそれは誰かが捨てたっていうよりは、なんていうの、その流れてきたやつみたいな感じで。

スピーカー 1

うん。

スピーカー 2

まあだからそういうのもなんかちょっと気になってたところもあったんで、最近はその運動して最後にゴミ拾いして帰るみたいなことをよくやっていて。

スピーカー 1

うん。

スピーカー 2

まあ毎に、毎回じゃないんですけど、まあ週に1,2回はそんなことをしてるんですけど。

スピーカー 1

うん。

スピーカー 2

なんかそういうことやってたら、なんかこうたまたま同じようにゴミ、ゴミを拾ってる人というか、まあなんか別にゴミ拾いをしようみたいな人じゃなくて、まあ多分こう同じような感じのテンションで、まあ今日はゴミ拾いしてるみたいな人に出会って。

スピーカー 1

うん。

スピーカー 2

まあなんかちょっと話す機会があったんですよ、この前なんかちょっと。

スピーカー 1

へえ。

スピーカー 2

で、まあなんかちょっと、なんかランチでも行けません?みたいな感じになって。

スピーカー 1

へへへ。

スピーカー 2

ランチ食べに行ったんですよ、なんかそれで。

スピーカー 1

どういう人なんですか?

スピーカー 2

で、まあなんか、いやなんかそれが、まあその会った時は全然なんかようわかんないおじさん、おじさんだなみたいな。まあでもなんかね、そのゴミ拾いしてるし。

まあなんか、まあその時はあのペットの散歩かなんかしてたんだと思うんですけど、散歩しながらみたいな感じっぽかったんですけど。

スピーカー 1

うん。

スピーカー 2

なんかそんなこともあるんだと思って、まあ僕も別にそんなね、あのご飯食べに行くことになると思わなかったけど。

スピーカー 1

うん。

スピーカー 2

まあでも別にゴミ拾いしてる人だし、なんか面白そうだなと思って、ちょっと行ってみようと思って、まあご飯食べに行ったんですよ、なんか。

スピーカー 1

うん。

スピーカー 2

いろいろ話してるうちに。

スピーカー 1

うん。

スピーカー 2

そしたらなんか、どうもなんか、まあよくみんな知っている、その大企業のなんか割と偉い人みたいな感じだったっぽくて、実際は。

へえ。

で、なんかまあ僕もその仕事とかの話とかをまあお互いにしてる中で、まあなんかじゃあちょっと仕事でもお願いしようかなみたいな感じの話になって。

まあでもちょっと僕は、僕はなんかあの、あの、ちょっといっぱいなんで、今受けられませんみたいな感じで結局こたわったんですけど。

デザインシステムの重要性

スピーカー 1

うん。

スピーカー 2

全然。

スピーカー 1

すごいなそれ。

スピーカー 2

うん。

で、でもなんでそんなね、まあ一応あのどういうことやってるとかって話はしたけど、なんでそんな、いきなりお願いしようと思ったんですかみたいなことを聞いたらなんか、いやなんか別にゴミ拾いしてる人だからいい人そうじゃんみたいな、なんかそんな感じの。

スピーカー 1

それどういう仕事の依頼だったんですか。

スピーカー 2

まあまあまああの、まあいわゆるまあ僕はね、そのウェブというかデジタルプロダクトのデザインとかやってるんで、それ系ですよ。

スピーカー 1

うーん。

スピーカー 2

それ系のデザインの話ですけど、仕事としてはね。

スピーカー 1

へえ。

スピーカー 2

いやでもなんかね、ゴミ拾いもしてみるもんだなと思うふうに思いましたよね。

なんかそう、ね、よく、よくていうか前なんか大谷翔平もさ、なんかゴミ拾いしてて。

スピーカー 1

ああそうなんだ。

スピーカー 2

なんかこれは運を拾ってるんだみたいな話をしてることがあった気がしたんですけど確か、ちょっと潤覚えですけど。

スピーカー 1

うーん。

スピーカー 2

いや確かにゴミ拾いは運を拾ってるのかもしれないなっていうふうに思いましたね。

スピーカー 1

すごいですねそれを。

なかなかないですね。

スピーカー 2

うーん、まあなんか、別にね、その正直僕がゴミを拾ってるから海が綺麗になってるかって言ったら全然なってないような気がするしかない気がしてるんですけどね、毎回毎回。

もう膨大すぎて。

まあ特にね、雨の雨上がりとか、まあ嵐の跡とかはもうすごいんでやっぱり、ビーチに漂着物みたいなのが。

スピーカー 1

はいはい。

だからもうそれ、それ拾ってるだけでもう普通にゴミ袋すぐいっぱいになるっていうぐらいやっぱり多いんでね。

スピーカー 2

だから全然綺麗になってる感じがしない。一向に綺麗になってる感じはしないんだけど。

スピーカー 1

それ普段、普段っていうか、なんか市とかが集めてるんですかね。

スピーカー 2

いや、なんかでも、ボランティアみたいなのがあるのは知ってますね。そういうボランティア団体みたいな、なんかビーチを綺麗にする団体みたいなのがあるのは知ってるけど。

市がやってるとかっていうのはどうなんですかね。あんまり見たこともないですから、やってないんじゃないかな別に。

スピーカー 1

うちも川が横にある、川っていうか運河があって、まあ運河なんですけど、まあやっぱ河口だから雨が降るとゴミがいっぱい来るんですけど。

なんか多分、市の人が頑張って船に乗って網ですくってますね。

あーはいはいはいはい。

そう、運河だから近づけないんですよね、一般の人が。だから、まあずっと浮いてる状態になってるからゴミが。それをこう船で拾うみたいなのをよく見ますけど。

スピーカー 2

うーん、なかなかないですね。うーん、まあでも最近でもだいぶ涼しくなってきたんで、なんかすごい良い、良いですね。

やっぱ秋って良いね。まあ今が秋なのかどうかちょっとわかんないけど、9月っていう、また残暑が残る季節だと思うんで。

秋ってやっぱりなんか、よく言うじゃん、なんかその運動の秋、食欲の秋、読書の秋だとか。でも何するにしてもやっぱり良い時期だなみたいな。気持ちが良いですね。

スピーカー 1

そうですね。そうですね。と言いつつ、またずっとエアコンつけてますけど。

日中は。まあ日中はまだ暑いからね、30度超えてたり普通にするからね。だからあれですけどね。

スピーカー 2

でも朝晩はだいぶ涼しくなったし、ちょっと。気持ち良さそうですね。僕なんか最近その朝だけじゃなくて、夜もなんか散歩出るように、たまになって。

まあ散歩しながら色々と経済情報を見てたりするんですけど。なんか、やっぱり気持ちが良いよね。

スピーカー 1

なんか夏の夜はまだちょっと蒸し暑い感じで、もう眠れないなみたいな感じで散歩することあったり。最近はちょっと気持ちが良いから散歩、なんか海の方まで行って歩いて帰ってくるみたいなことをやったりしてて。

良いですね、やっぱり。

なんか社会に接してますね。

スピーカー 2

社会に接してんの?

いや、わかんないけど。自然に触れて、ゴミ拾いして、知らない人とランチに行くって。

まあそれは確かにそうかもしれないね。そんなことなかなかないからね。なんか僕もだってもう2年ぐらい住んでるけど、2年ぐらい住んでて初めてだもんね、そんな。

スピーカー 1

近所の人と話すとかなかなかないな。

スピーカー 2

まあ基本あんまりないよね。たまにちょっと挨拶するぐらいでしかないからな、やっぱり。

スピーカー 1

家買ったからそういうのあるのかなと思ったけど、全くないっすね、うちのマンションは。

しかも結構やっぱり外国人所有者が増えてる感じがするんだよな、エレベーターとか。

スピーカー 2

なるほどね。

スピーカー 1

たまにすれ違うと。

スピーカー 2

で、うちからそういうのはもうちょっとやりたいなみたいな感じもあるってことですか、それは。

スピーカー 1

いや、全然ないっす。

スピーカー 2

じゃあいいじゃん、別に。じゃあ別にいいじゃん。

スピーカー 1

いや、全然ないっすよ。だからここちょうどいいっすよ、そういう意味では。

スピーカー 2

だからそういう人が多いんじゃないですか、結局。

スピーカー 1

そうそうそう。なんかちょうどいいなと思ってるんですけど。

じゃあ今日はちょっとまた本の紹介をしようかなと思うんですけど、

デザインシステムの育て方っていう、つい最近出た本なんですけど、8月28日発売。先週か。

前々週ぐらいに出たやつですね。

で、結構この本なんか、原著がDesigns at Scalesっていう、原著はいつ出たんだ?

2023年11月に出た本で、なんか割と原著の時点で評判が良かったらしく、

なんかダンモールっていうデザインシステム関連のコンサルをやってる人が書いてるんですけど、

で、そこから評判が良かったからなのか、すぐに日本語版も先々週出たっていうような感じみたいですね。

で、僕もちょっと最近デザインシステム関連の仕事してるから気になってて、それでちょっと読んでみたんですけど、

この本はタイトルの通り、作り方とかではなくて、育て方とか、チーム作りとか、

どういう役割の人を入れた方が良いかとか、そういうような本なんですけど、

ただコンテキストとしては、なんか大きい会社、もう大きいっていうのは数千人とか数万人とか、

それぐらいのオーダーの規模を想像して読んだ方が良いかなっていう気はしてるんですよね。

で、これ結論にも近いんですけど、最近デザインシステムの案件やったりとか、個人でもちょっとやったりとか、

大なり小なら色々やってると、やっぱデザインシステムをやっていくっていうのは、

本質的には組織を変えることなんだなっていうのが最近分かるようにようやくなってきて、

だからDXとかそういうのと文脈が近いのかなと思ってて、

DXするための一つとしてデザインシステムがあるみたいな感じ。

そういう依頼も結構大きい会社からだと多いし、文脈としては似てる言葉なのかなと最近思うようになってきて、

だからそういう大きい会社のようなコンテキストを想像しながら読んだ方が、

多分言ってることがしっくりくる本かなっていうふうに思うんですよ。

逆に育て方自体がそんな大事にならないケースもあるなと思ってて、

それがすでにカルチャー的に会社の組織ができてる場合、

例えばエンジニアが当たり前のようにOSSに貢献するとか、

あるいは自社のライブラリーみたいなのをGitHubで社外の人も使えるように公開するとか、

あとエタのカンファレンスで話すとか、

エンジニアがデザインの仕事もするし、デザイナーがエンジニアの仕事もするしみたいな、そういうシームレスな状態になってるみたいな、

わりとインターネット系の会社にあるような状態。

あとはそもそもビジネスとして、ソフトウェアを中心にしてビジネスをしている。

要はインターネットの会社とかそうだと思うし、サースの会社とか最近だとそうだと思うんですけど、

そういうような環境だとかなり措置ができている状態だと思っていて、

そうするとそこにデザインシステムをたとえやってなかったとしても、後からやったとしても、

それって便利なツールが1個できたよねぐらいな感覚で、みんなで使おうよぐらいの話になってきて、

何もしなくても使われるみたいなことになりやすいのかなっていうふうに思うから、

その環境の中にいるとデザインシステムってそんな大ごとにするべきなのかみたいな感覚って、

僕はあったんですよね、昔。

特にさっきの話、OSSみんな使ってるし、エンジニアがライブラリとか社会に効果するのが当たり前だよねみたいなのって、

Cookpadそうだと思うんですけど、そういう感じの環境に僕もいたから、

だから結構デザインシステム自体はCookpad取り組むの早かったから、

2010年代頭ぐらいからやってて、自分も会社入って触れることが多くてっていう環境だったんだけど、

世の中的に覚えてるのが2018年ぐらいに徐々にテク系の企業、当時Airbnbとかね、

そういうところが当たり前のようにデザインシステム作ってて、

そこから徐々に組織でいかに育てていくかみたいな話題に結構大きめのカンファレンスとかが徐々にシフトしていったのが、

2018、19ぐらいだなっていうふうに覚えてるんですけど、

デザインシステムとOSS

スピーカー 1

僕はその頃に興味を失ったんですよね。

組織論ばっかりになってきて、あんま面白くないなっていうふうに思うようになっちゃって。

当時、2018ぐらいのときにデザインオプスっていうキーワードもバザード的に流行り始めていて、

そのときにちょうどデザインオプスサミットっていうのがあるっていうのが1個トピックとしてあったんですよね。

そのサミットも結構中身開けてみると結構組織論の話がすごい多くて、

僕はあんまそういう感じかと思って一回興味を失ったんですよね。

その後僕スタートアップに行って、スタートアップに行くと当然そもそも人数少ないし、

デザインシステムっていうものを作る必要性があんまなかったし、

システムを作るっていうよりは経営メンバーみたいな感じだったから、

自分自身が組織に対して直接アプローチするみたいなほうが早かった。

人採用するとかね。

そういうほうが早かったから、あんまりデザインシステムっていうのに興味が、

必要性がなかったっていうか興味がなかったんですけど、

ただそこからここ1,2年ぐらい大きい会社、JTCと呼ばれる会社と付き合うようになって、

ようやくさっきのデザインシステムをやっていくっていうのは組織を変えるってことなんだなっていうのが

ようやくピンときたっていうか。

デザインシステムっていうそれ自体が大事っていうよりは、

それを切り口に、例えばビジネスのやり方をソフトウェア中心に変えていく、

サブスクリプションでアップデートが随時走るようなやり方に変えていくとか、

それに伴ってエンジニアとかデザイナーをよりプロダクトマネージャーも含めて

アジアルにものを作っていくみたいなそういうやり方に変えていくとか、

それが大きい会社にとってのデザインシステムの価値なんだなっていうのが

ようやくピンときたっていうか。

だからやってることはDX。

DXってのはCookpadとかスタートアップとかに行った頃はあんまり意味がよく上がらなかった。

単なるバズワードなのかなみたいな感じで思ってたんですけど、

それってデジタルトランスフォーメーションした結果の世界線に生きてたから、

インターネット業界の場合は。

だからあんまりそれはピンとこないっていうか。

リープフロック現象みたいな、

後からできた業界だからしがらみとかなく理想の状態に行き着くのが早かったのっていうのと

なんか似てるのかなと思って。

そっちの世界線にいるといろんなしがらみとか既存事業とかいろいろあって、

なかなかDXできない状態の会社にはあんまり視野が広がらないっていうか感じだったんですけど、

ようやく最近そういうような会社と付き合うようになって、

育成の課題

スピーカー 1

なんかその辺の温度感が分かってきたっていうのがここ最近なんですよね。

で、なんかそう考えるとやっぱりなおさ作ることより育てるのが難しいなって思うのがすごいあって、

なんかやっぱまあそういうOSSとかが当たり前に存在しているような会社、

エンジニアとデザイナーが当たり前に共同で何か作業しているような会社、

カルチャーが上がるような会社だと育てるっていうのはそこまでなんかそんなに大事なのかみたいな気持ちになるんですけど、

やっぱりそういうなかなかまだDXなんだろうな、すごい部門間で再録がすごい進んでいるとか、

なんかそういうような大きい会社、数千人数万人規模の会社の中だとやっぱり本当に育てるのって難しいなと思うのが思っているので、

まあちょっとこの本を出てすぐ読んでみたっていうような感じなんですよ。

で、やっぱ作ること、デザインシステム作ることってなんか結構ほぼほぼもうベストプラクティスとかノウハウがもうたまりつつあるのかなと思ってて、

まあそれこそFigmaが発展してきていて、Figmaワリアブルズみたいなものができたりとか、

またFigmaがもうほぼそこ、デザインシステムを効率よく作るところでビジネスしていこうとしてるから、

だからそれに伴っていろんな機能ができてきて、前もちょっと紹介したシンプルデザインシステムっていうFigmaが公開してるホワイトレベルデザインシステムっていう類の、

デザインシステムを自慢で作るときの下敷きとして使おうみたいなやつですね。

まあそういうのに乗っかっていけば、なんか作ること自体はそんな難しくないのかなとは思うんですよね。

技術的にもフロントエンドの技術が結構発展してるから、

まあシャドウCNとかそういうフロントエンドのUIライブラリみたいなものとかもあるし、

あとスタールディクショナリーとかね、なんかそういうものもあったりするから、

フロントエンドっていう文脈にも作りやすくなってきてるし、

しかもこの辺のノウハウが多分この1年、2年後ぐらいにはAIにどんどん置き換わって、

それこそFigmaのAIがデザインシステムをベースにしてUIを生成するって話もそうだし、

なんか最近VZERO、バーセルがやってるVZEROっていうのも、

なんか最近いろいろ大型のアップデートがあって、

なんかAI界隈でまた盛り上がってるんだけど、

なんかそういうところもあるから、

なんか作ることっていうのはもう本当この1年ぐらいでどんどんどんどんコストが少なくなってくんだろうなと思うので、

やっぱなおさらポイントとなるのが育てるってところ。

プロダクトとフィット

スピーカー 1

で特にソフトウェアを削ぎ落としないような会社の場合でいかに育てるかってところが、

やっぱポイントになるんだろうなというふうに思うんですよね。

スピーカー 2

はい。

スピーカー 1

だからソフトウェアを削ぎ落とすような会社の場合は、

デザインシステムをやるのはローリスク、ミドルリリターンみたいな、

ローリスク、ローリターンなのかミドルリリターンなのか、

それぐらいなのかなと思うんですけど、

そうじゃない会社の場合、大きい会社でソフトウェアを削ぎ落としない場合は、

ハイリスク、ハイリターンな取り組みなのかなっていうふうに思うので、

そこをいかにやるのかっていうのがこの本になってくるのかなっていうようなところなので、

スタートアップとかインターネット系の会社にいる人にとっては、

そんな大事にするべきトピックかと思う本でもあるのかなっていうふうには思うんですけど、

この本を読む上でのコンテキストとしては、

割とそういう大きい会社っていうのを想像しながら読んだほうが、

多分ピンとくるだろうなと思ったっていうのがそういうところですね。

この本、翻訳が長谷川康久さんがしてるんですけど、

絵描きの中で結構うまくまとまってて、

デザインシステムっていうのはプロダクトであって、

育てるっていうのは要はPMFさせるっていうことだっていうふうに書かれてて、

これは投資でこの本を読んでみて、

この本の中身を端的に言ってるなとすごい思ったんですよ。

スタートアップとかで01でプロダクト作ってっていうことをやっていくと、

結構やっぱり意識するのって、

いかにPMFさせるかみたいなところがあるじゃないですか。

その前段階にPSF、プロブレムソリューションフィットみたいな話がよくあると思ってて、

これが要は社内で起きてる、デザインシステムで言うなら、

社内の開発フローで起きてる課題とかを捉えて、

いかに作ってそのプロブレムを解決するかっていう話、

いかに作るかの部分の話で。

PMFっていうのはその後にある話で、

ここで言うPMFってプロダクトマーケティフィットですけど、

ここで言うプロダクトっていうのがデザインシステムで、

ここで言うマーケットっていうのが組織だと思うんですよ。

だから組織が大きければ大きいほど、

マーケットが広いっていうことになると思うので、

だからその分難易度が上がるし、

その分そこにフィットできればインパクトが大きいっていう、

そういう整理になるのかなっていうふうに思うんですよね。

PSF、PMFみたいに捉えると、

要はプロダクトを育てていくっていうことは、

そのための資金調達が必要で、

じゃあその資金調達っていうのはやっぱり会社の予算があって、

そこから予算をどうやって確保するのかっていう話になってきて、

そこから継続的に予算を確保できないと、

なかなかPFまで行き着く前に力絶えて死んでしまうみたいなこと。

要はそこの辺ってプロダクトを作って育てていく、

伸ばしていくっていうのと全く一緒だなっていうふうに、

この前書きを見て思ったんですよね。

だから結構僕今クライアントワークとして、

デザインシステムをやることが多いんですけど、

結構自分のやってきたことにフィットしてるなって思う感覚があって、

それって単にデザインとエンジニアリング両方必要になるからっていうだけの話なのかなっていうふうに思ってたんですけど、

それだけじゃなくて結構スタートアップで01でプロダクト作って育てていく、

徐々に育てていくっていう感覚と結構デザインシステムに似てるなっていうふうに思ったっていうのが言語化されたっていうような感覚ですね。

スピーカー 2

なんかあれだよね、よくも悪くもコンサル目線的な話っぽいね、話的には。

スピーカー 1

どの辺が?

スピーカー 2

まずデザインシステムをプロダクトとして捉える。

それをマーケットにフィットさせるっていう捉え方って、

まず製品作るってそっから始めるわけじゃないかもしれないけど、

製品があってそれを売り込んでフィットさせていくっていう考え方って結構コンサルっぽいなっていう感じがしましたね。

もうちょっと本当に内部からそれをうまく作っていこうっていうふうな考え方であったら、

もっと別にデザインシステムまでいかなくても、

ちっちゃいところから始めてちゃんと使えるものを作ってちょっとずつ大きくしていこうとかっていう考え方かもしれないけど、

どっちかっていうとまずデザインシステム的なデジタルプロダクトがあって、

それをマーケットにフィットさせていくっていうような考え方っていうのは割とコンサルっぽいなっていうような印象がありましたね。

スピーカー 1

ちょっとじゃあ説明の仕方が悪かったかもしれないですね。

そういう意味ではもとやまさんが言ってるようなアプローチのほうですね。

具体からいかにちょっとずつ育てていくかっていうような本なのかな。

だから別に決してコンサル的ではない。

むしろそれがNOというような趣旨の本かなというふうには思うかな。

だから多分そのもとやまさんがコンサル的っていうふうに言ったのは、

デザインシステムがすでにあってそれをフィットさせるっていうことが大事というふうに捉えたからってそういうこと?

スピーカー 2

なんかデジタルプロダクトとして捉えるっていうところがすごいコンサルっぽいなって思いましたね。

スピーカー 1

ちょっとなんかそこは僕はミスリードが出るのかもなと思って。

スピーカー 2

まあちょっともうちょっと長身の話聞かないとね、分かんないから。

スピーカー 1

ミスリードがあったらちょっと教えてくださいね。

なんかそこは本位ではあんまないんで。

っていうような感じなんですよ。

中身を言うと、デザインシステムとは何かっていうような話から始まるんですけど、

この辺は別にそんなに世に言われているような話に近いんですが、

特にこの人が強調している、このダンモールって著者が強調しているのは、

組織をつなぐものであるっていうような定義っていうのを結構大事にしていて、

つなぐっていうのは職種間でもあれば部門間でもあれば、

会社と会社、会社と協力会社とかね、

そういうような何かと何かをつなぐっていう役割がデザインシステムであるっていうところですね。

なのでこのデザインシステムっていうのが何なものかっていうと、

基本的にはデザイナー、エンジニア、あとはプロダクトマネージャーとか、

そういうプロダクトに関わる人っていうのは3本柱になってくるんですけど、

デザインシステムのつまずきどころっていうのは、

プロダクトチームから見て別の誰かが管理しているライブラリっていうような、

別の誰かが何かをやっているものっていうふうに見られるっていうところが、

やっぱり一番のつまずきどころになるので、

だから全員の自分ごとにしましょうっていうようなところが大事だっていう話で、

その全員の自分ごとにするためにはどうしたらいいのかっていうのが、

いろんな後から説明する話に散りばめられている課題感みたいなところなんですけど。

ただ改めてデザインシステムとは何かっていうふうに考える上で、

結構デザインシステムって主語が大きいからいろんなものが含められやすくて、

まとめてデザインシステムみたいなラベルが貼り付けられるっていう感じなので、

それはもうちょっと分解していくと、

大体7つに分けられるよっていうふうな話があって、

1つがブランドのアイデンティティとか、

視覚言語、ビジュアルランゲージみたいなものとしてのデザインシステム。

デザインシステムの定義

スピーカー 1

これがよくあるブランドガイドラインとか、

あとはコーポレートアイデンティティとかビジュアルアイデンティティみたいなものを言語化したようなやつ。

この辺はリブランディングのプロジェクトとかやった後に作られるようなものですね。

っていうのが1つ目。

2つ目がプロジェクトとしてのデザインシステムっていうふうにこの本で書かれていて、

プロジェクトとしてのっていうのが、

プロダクト開発上の明確な課題感があって、

それを解決するためにいついつまでにこの目標を達成するために単発でやりましょうみたいな、

単発でナビゲーションを共通化しましょうとか、

そういうような明確な目的と明確な期限が定められているプロジェクトっていうようなもので、

そうしてデザインシステムの出発点になるのはこのプロジェクトとして取り組むっていうところがスタートになるよっていうような話ですね。

3つ目がツールとテンプレートとしてのデザインシステムっていうやつで、

これがキーノートのテンプレートとか、あとはなんだろうな、

ボイラープレートみたいな、

LPを作るときの標準セットみたいなやつとか、

作業を効率化するためのツールセットみたいなやつですね。

4つ目がデジタルプロダクトのデザインシステムってやつで、

これが世に広まっているデザインシステムって言われてパッと思い浮かぶような、

ショピファイのポラリスっていうようなデザインシステムとか、

Googleのマテリアデザインとか、よくあるようなデザインシステムですね。

これがプロジェクト型との違いは、

未来のロードマップがあったりとか、継続して育てていくことが含まれているっていうようなもの。

だから単発型のプロジェクト型のデザインシステムと、

継続して育てていくっていうことも含めてデジタルプロダクトのデザインシステムっていう、

そこをちょっと分けて考えましょうっていう話ですね。

デジタルプロダクトの要素

スピーカー 1

あと5つ目がプロセスとしてのデザインシステム。

これが例えばデザインスプリントを、

新しい何か新記事を考えるときはデザインスプリントを会社の中では標準にしましょうとか、

そういうようなサービスデザイン系のプロセスというかワークショップみたいなものも含めて、

会社としての標準的なやり方みたいなのを決めたものですね。

これもコンポーネントとか具体なもの、目に見えるようなものがなかったとしても、

抽象的なプロセスとして何か規定のものがあれば、

それもデザインシステムとして捉えることがありますよねっていうような整理。

6つ目がサービスとしてのデザインシステム。

これ僕も初めて聞いた概念だったんだけど、

これは具体的なものっていうよりは組織の中での一つのサービス。

サービスっていうのはここで言うのは労働力っていう意味のサービス。

例えばリサーチを手配しますとか、リサーチにおいてリクルーティングを手配する役割の人がいて、

その人のお願いする窓口はここですみたいな話があったりとか、

あとデザイナーチームのデザインの採用をサポートする役割の人がいますとか、

そういうようなもの、そういうようなサービスですね。

それをデザインオプスとか最近では言うみたいなんですけど、

そういう役割もデザインシステムの一部として捉える、整理できますよねっていうような話。

最後に実践としてのデザインシステムっていうので、

これは単にツールとかプロセスとかを作るっていうんじゃなくて、

それを徐々に組織の中に馴染ませていく行為。

例えばデザインシステムのシステムの使い方講座をやりますとか、

使い方ワークショップをやりますみたいな、

みんなが会社の中でどうやってデザインシステムを使っているのかっていうのを広めるためのミーティングをやりますみたいな、

デザイン会話をやりますみたいな、そういうようなもので、

それも含めて実践としてのデザインシステム、

それもデザインシステムの一部だよねっていうふうに整理してるっていうことですね。

なのでこうやって7つに分けると、結構デザインシステムって何ですか、

何をやったらデザインシステムなんですかっていうふうに聞かれると結構言葉に困ることが多いんですけど、

こうやって整理すると主語が明確になるし、逆にいらないものも見えてくるかなと思ってて、

別にブランドとしてのアイデンティティとかデザイン言語みたいなものを、

大体のデザインシステム、デザイン原則みたいなものが大体のデザインシステムにあったりするんですけど、

別にそれがなくても別にいいケースもあるし、

そういう7つに整理すると、どこに力を入れるべきなのかとか、

どこが逆に削ぎ落とすべきなのかっていうのが分かりやすいなとは思いましたね。

スピーカー 2

それって全部がないとデザインシステムって言えるものじゃないっていうわけじゃないですよね。

スピーカー 1

いやいや、そうそうそう。わけじゃないので、いらないものは別にやらなくていいですよねっていう話ですね。

じゃあデザインシステムって何なんですかね、やっぱり。

なんか便利なラベルだと思いますよ。

スピーカー 2

やっぱデザインシステムっていう言葉はやっぱり僕は今はもうよくないんじゃないかなと思ってるからね、やっぱり。

なんかやっぱりバズワード化してるところもあるし、

なんかよくわかんない正体不明のものになってしまってるんじゃないかなっていうような気がしてるから。

まあもう使わないほうがいいんじゃないかな。

スピーカー 1

ユーザー体験とか、UXとかDXとか、そういうのと一緒だと思いますよ、基本的に。

ただ僕はバズワードも使いようだと思ってて、なんかやっぱ大きい会社では1個、

大きな方向性を指し示す1個のワードっていうのがあった方がいろんな意味で便利なことがあると思うので、

そういう時にデザインシステムというのを戦略的に使っていくっていうのがいいんじゃないかなとは思いますけどね。

なんとなくデザイン志向。

スピーカー 2

結局濁してるだけで、なんか結局濁してるだけで、

なんか分かった気になって進めるみたいな感じになっていそうだなっていう風にどうしても思ってしまう。

スピーカー 1

分かった気になるのはダメだけど、分かった上で戦略的に使うのはアリかなと僕は思ってますけどね。

スピーカー 2

自分たちは分かってても、その伝える方に分かってないんじゃないかなみたいな。

なんかふわっと、なんか良さそうやんみたいな感じになるんじゃないかな。

スピーカー 1

会社の大きい、例えば社長とかに何かを伝えるときって、細かい話を全部細かく細かいに伝えるのって難しいじゃないですか。

そしたらなんとなく向かうべき方向性を表す言葉を1個付けて、そっちに向かうように話した方が何かとこう、話は通りやすいのかなとは思いますけどね。

なんか世の中にあるそういうDXとかそういう言葉って、なんかそういう役割の言葉なのかなという風には思ってて。

僕もなんか昔はそんなバズワードとか使って何も何にも言ってないようなもんじゃんみたいに思ってたんだけど、

やっぱ大きい会社の中で物事を進めていく上では、そういうバズワードもやっぱり上手く使ってくるのって大事だなとは、

大きい会社に触れてみて分かったことでもありますね、その辺は。

まあだからポイントとしてはさっき言ってるように7つ、さっき言った7つの中の全部やらないといけないというわけではなくて、

まあその一部でも全然いいかなと思うんですけど、

ただその7つの中でもやっぱまあ一番取り組むケースが多いっていうか、

必要とされるケースが多いのが4つ目のデジタルプロダクトとしてのデザインシステムっていうところだと思うんですけど、

その中の構成するパーツとして大体6つあるよっていう風に言っていて、

まあこれも別に6つなきゃいけないってわけじゃなくて、

まあ大体6つやることが多いですよっていう話なんですけど、

まあその一つがUIキット、まあこれがまあFigmaのコンポーネントみたいな話ですね、

まあ別にFigmaに限んないんだけど、ここが別にスケッチでもなんでもいいんだけど、

まあUIキット。

で2つ目がコンポーネントライブラリー、まあこれはコードコンポーネントとも呼ばれる、

まあこの本で言うとコンポーネントライブラリーっていう風に書かれてるんだけど、

まあこれはまあコード上で動作するコンポーネントって意味ですね。

あとはガイドライン、まあ使い方説明書みたいなやつと、

あとはそれらをまとめてはウェブサイトと、

あとはちょっと順番前後するけどデザイントークンと、

あとはそれらをデジタルプロダクト、それらをデザインシステムとした場合に、

それを実際参照する、実際使っているデジタルプロダクトっていうのもあるよねっていう話、

まあパーツとしてはあるよねっていう話で、

まあ大体なんかまあここに関して、

これは別になくてよくないみたいな議論の余地はそんなないのかなとは思うんですけど、

唯一あるとしたら、やっぱりそのリファレンスサイトの必要性みたいなところっていうのは、

まあ結構なんか僕がデザインシステムを作る上でも、

本当に必要ですかみたいな議論になりやすいというか、

何だろうな、説明が求められるポイントでもあると思ってて、

リファレンスサイトっていうのは要は、

例えばなんだ、

スマートHR.デザインみたいなそういうURLからアクセスできるあのサイト、

パッと思い浮かぶようなデザインシステムがまとめられているサイトのことですね。

であれって、なんか多くのデザインシステムって公開するみたいなところ、

まず作る、大事にそれを作るっていう話と、

あとはそれを外部公開するか否かっていう2つのトピックがあると思うんですよね。

で、そこってなんか結構僕もあんまそれの必要性について言語ができてなかったというか、

なんとなくやっぱWebでまとまってた方が良くないっていう話と、

なんとなくそれがやっぱり外部公開された方が、

いろんな意味では存在感が高まるし、

いろんな波及効果を生み出すんじゃないっていうふうに説明してたんだけど、

それについて言語がされてて、

一つ目のメリットがやっぱ目に止まりやすくなる、

目に止まりやすくなるメリットっていうのは確実にありますよねっていうところで、

やっぱサイトっていう形でまとめられることによって目に止まりやすくなって、

結果としては使われる可能性が高まるっていうところはあるよねっていう話。

スピーカー 2

目に止まりやすくなるっていうのはそれ誰に対してですか?

スピーカー 1

ユーザーですね、社内のユーザー。

スピーカー 2

社内の人間にってことね。

スピーカー 1

そうそうそうそう。

これもさっきのコンテキストを想像してほしいんだけど、

何万人に何万人という会社の中での話ってことですね。

だからスタートアップだったら、

例えばNotionにデザインシステム作りましたっていう記事書いて、

そこにFigmaのライブラリはここですみたいにリンクを貼っておくだけでも全然いいと思うんですけど、

それだと効果が限定できないような大きい会社の場合っていうようなケースの話ですね。

あとは2つ目が責任を果たせるっていうようなふうに書かれてて、

ここがより公開することに、公開できるぐらいの品質にすることによって、

よりちゃんと作らなきゃみたいなその品質、

外部公開することに対する責任みたいなものが生じますよねっていう話。

3番目がプロダクトの価値観とかどういうふうに考えてものを作ってるのかとか、

どういうふうなコンポーネントが出されるのかみたいなことを示すことによって、

採用にも強化的につながりますよねみたいな話。

外部公開の重要性

スピーカー 1

だからこの辺もその3つっていうふうに書かれてて、確かにそうだなと思うんですよ。

銀行とデザインっていう三井住友銀行の人が書いてた本でも書かれてましたけど、

結構そういうふうに外向けに発信することによって、

それが中に跳ね返って中を変えていく効果があるみたいな話が本の中に書かれてましたけど、

やっぱりそういう効果ってリファレンス、

このデザインシステムのウェブサイトっていう意味では結構強いのかなっていうふうには思ってるので、

中向け中向けって考えると、

じゃあ別にノーションに記事まとめたらよくないとか、

そういう社内のブログの2個記事開けとけばよくないみたいなふうに思うんだけど、

大きい会社を動かすみたいなことを考えると、

外向けに発信することによって中を変えていくみたいな、

そういうような力学をうまく使うっていうのは結構大事なのかなっていうふうに思いましたね。

この辺は僕もそうやって説明することが多かったんだけど、

やっぱそうだよねっていうような感じでしたね。

デザインシステムの導入

スピーカー 1

この辺もさっきの冒頭のPMFみたいに捉えるのが大事っていう話と似てるのかなと思って、

PMFさせるみたいなことを考えると、

ちゃんとオンボーディングに力を入れたような、

LPが1枚サースってプロジェクトを作ってたとしたら、

当然そのLPの改善にも力を入れますよねみたいな感覚。

やっぱ近いのかなっていうふうには思いましたね。

ただそこの公開したほうがいいよねっていう話になってくるんだけど、

そこの公開と非公開は日で託一じゃなくて、

そこにグラデーションはあっていいよねっていうようなことも書かれてて、

例えばフル公開するっていうふうになると、

例えばUIキットとかコンポーネントライブラリとかが外部の人も使えますみたいな、

スマートHRとかやってるようなやり方になってくるのが、

理想系ではあるかもしれないんだけど、

その手前として、

例えばドキュメントは公開されてるけど、

コード自体はプライベートの状態ですとか、

あるいはコードはオープンになってるんだけど、

ダウンロード型になってて、

必ずしも社内で活発にコミットしてるリポジトリと、

社外に公開してるリポジトリと、

イコールではありませんみたいなデザインシステムも結構あったりするし、

あともっと言えばリードオンリーな状態、

例えばコンポーネントがストーリーブックで公開されてますって言うけど、

中身のコンポーネントについては見えない状態ですっていうようなものもあっていいし、

あるいはコードは公開しなくて、

Figma上でFigmaコミュニティにライブラリだけパブリッシュしてますみたいな、

そこはリードオンリーで使ってくださいみたいな、

まあそういうようなやり方もあると思うし、

その辺はグラデーションは全然合っていいと思いますよみたいなことが書いてありましたね。

それは本当その通りだなというふうに思ってて、

やっぱ2社卓越で考えると、

多くの大きい会社は、

じゃあ非公開でっていうふうになりやすいと思うんだけど、

そこをちょっとでもオープンにしていくっていうのが、

さっき言った、

全公開は難しいかもしれないけど、

やっぱ何かしらオープンな状態にできないかっていうのは、

やっぱ考えた方がいいのかなとは思ってますね、僕も。

で、まあそういうような背景の中で、

フィギュアに関しては、

していきましょうとかあるいはそのプロダクト主力事業が出している

なんか iOS 向けのサブプロダクトから着手しましょうとかなんか

そういうような具体のプロジェクトっていうのをまず見つけてそこ

からスタートするっていうのがやっぱ大事ですねっていうのが

結構この本の中で透視で書かれているような話ですね

うん

だからこの辺はさっきモデルさんが言ってた話と近いのかなと思

うんですけどなんか抽象的な何かから始めるんじゃなくてまず具体

の一つを見つけてそこから具体にまず着手してそこから一つ何か

抽象化してまた具体の別のに着手してみたいなループをしてした

上でデザインシステムを広げていくっていうようなそういうような

育て方をしていきましょうっていうような話ですね

じゃあなんかそのパイロットプロジェクトっていうのをどう

見つけるのかどう設定するのかっていうのがやっぱポイントになって

くるっていうところでここで考え方で一個大事なのが何かデザイン

システムっていうのを主語にするんじゃなくて何かしらプロジェクト

チームの抱えてる課題感とデザインシステムを紐づけて立ち上げる

のがいいっていう話ですっていうふうに書かれてて例えば例えば

組織がすごい大きく再編されましたっていうのも一個のタイミング

ですっていうふうに書かれてて例えばプロジェクトチームのやり方

をがらっとこれまでと変えなきゃいけませんみたいな他社と合併

しましたとか他社に売却されましたとか経営者が変わりましたとか

何かそういうタイミングと組織がどんがらがっちゃんとなる

タイミングだと思うのでそのタイミングで合わせてやるっていうのも一個

ありますっていう話とかあるいは何か主力力を入れるプラットフォーム

を変えるタイミングウェブでこれまでやってきたんだけど iOSに変えます

とか何か分かんないけどVision Pro に変えますとか何かそういうような

プラットフォームを大きく変えていくっていうタイミングっていう

のはプロダクトを大きく作り変えるタイミングでもあるのでそれも

デザインシステムを作るタイミングとしてはいいですねっていう話

あと三つ目がリブランディングをするタイミングっていうので

これもよくあるかなと思うんですけど特にデザイン会社にいるとよく

ある話ではあるんですけど何かこれも大きく言えばやっぱり組織

の課題感と紐づいてる話で例えば会社の事業のやり方これから大きく

変えていきますとか大きく変えたので見え方も変えていきたい

ですみたいな話があってその前にブランディングのやり方を

変えますみたいなそうするとリブランディングするので最初に紹介したブランド

としてもデザインシステムっていうのを作りますみたいな話になって

きてそうするとそれのブランドの結果をプロダクトのほうに反映

しなきゃいけないですねっていう話になってきてそうするとリブランディング

した結果を例えば5個プロダクトがあってそれぞれに対してロゴ

なりVIなりを差し替えていくっていうのが大変なので一つのデザイン

システムを作りましょうそれを基本的に使うように構成構造を

変えていきましょうみたいなそういうような話っていうのは

ストーリーとしてはすごい進めやすいし納得感もある逆にユーザー

からしてみれば例えばVIが大きく刷新されましたみたいなタイミング

があったとしたらそれを1個1個カラーコードがどうのこうのとか

ロゴがどうのこうのっていうのを 1個1個差し替えていくと大変だけど

デザインシステムが用意しているこのコンポーネントに乗っかれば

楽できますよみたいなそういうプロダクト側が抱えてるペイント

何かしら整合性がとられる形でスタートできるとやっぱりデザイン

システムっていうのは浸透しやすいですよっていうような話ですね

だからそうして会社が全社規模で変わろうとするタイミングっていう

のはデザインシステムに何かしら着手するタイミングとしてはちょうど

良いですよっていうことが書かれているいましたね

パイロットプロジェクトの選定

スピーカー 1

その上でじゃあパイロットプロジェクトっていうのは何個か候補があった

としたらどの候補を選ぶべきなのかっていうのは定量的に判断できます

というふうに書かれていてこのパイロットプロジェクトっていう

のはパイロットプロダクトとして捉えてもいいと思うんですけど

会社の中で何個もプロダクトがあったプロダクトなりそのプロダクト

内に管理画面とか投稿機能とか何か大きな機能があったとしたら

どこからスタートしていくのが良いのかっていう話ですね

基準としては8個あるんだけど 1個が他のプロダクトでも使えそうな

コンポーネントが含まれているかどうかっていう観点これはそれは

そうですよねっていうところでいくらパイロットプロジェクト

とはいってもすごい会社の中で見ると全体の10%にしか使えなさ

そうなコンポーネントしか使ってないようなプロダクトすごい支流の支流

みたいなプロダクトの場合だとそれをパイロットにしたところ

で全社に展開しづらいですよねっていう話があると思うのでなる

べく汎用性の高いようなコンポーネント汎用性が高くなりそうなコンポーネント

が含まれているかどうかっていうところはポイントになってきます

よねっていう話とあとはコンポーネントっていう軸だけじゃなくてパターン

っていってるのが決済フローとか投稿フローとかそういう他のプロダクト

でも汎用的に使えそうなパターンが含まれているかどうかってところ

が二つ目の観点三つ目がそのコンポーネント

かパターンとかがビジネス的に大きな価値を生んでるかどうか

生んでるようなパターンコンポーネントがどれくらいあるかっていうのも

定量判断の軸になりますよっていうところでこれは何だろう例えば

大事なアクションを示すボタンとかプレミアム界に加入するための

ボタンとかっていうのは大体色使いとか見せ方とかもかなり

A Bテストとか繰り返されて会社の中でオードパターンみたいな

のが大体あることが多いじゃないですかだからそういうのがどれ

くらい含まれてるかっていうのも一個パイロットプロジェクト

の判断軸として含まれてますよとかあとは観点を変えて実装的にその

プロジェクトがどれくらい難易度高いのかみたいなすごいレガシー

なものばっかり使っていてそもそもデザインシステム化する上でも

大がかにリファクタリングが必要になってくるっていう場合だと

後回しにしたほうがいいですよみたいな話になってくるのでその

技術的な観点あとはそのチームのそのパイロットプロジェクト候補

プロジェクトの具体的な考慮事項

スピーカー 1

のプロジェクトチームの中にどれくらいデザインシステムに対して

意欲的っていうか協力してくれるそうな人がどれくらいいるかっていう

話あとは妥当な機関内で進められるかどうかっていう話とあとは独立性

技術的とか技術不採とかデザイン不採からどれくらい切り離して

考えられるかみたいなあと最後がこれマーケティング

のポテンシャルっていうふうに書かれてたんですけどここがマーケティング

のポテンシャルっていうのがそのデザインシステムを徐々に前者

的なものにパイロットプロジェクトから前者プロジェクトに徐々に

広げていかなきゃいけないのでそのときにどれぐらいインパクト

があるのかっていう観点例えば 5個プロダクトがあったとして

最初から本丸のプロダクトにデザインシステムが使われてますよっていう

のだったら当然管理画面にも適用するのは簡単ですよねみたいな

ことに使い手からしてみれば思うと思うのでそういう意味でのマーケティング

ですね社内で広めていく上でのポテンシャルがどれぐらいパイロット

プロジェクトにあるかどうかっていうところだから裏側の管理画面から

スタートしますみたいな話になっていくと独立性とかっていう観点

では結構ポイントが高いのかもしれないけどマーケティングっていう意味

ではポイントが低いのかもしれないとかそういうようなポイント付け

してみて点取り表星取り表みたいなバーッと何点何点みたいに付けて

みてそれでパイロットプロジェクトを選んでいくっていうのが1個ポイント

ですよっていうふうなことが書いてありましたねこの辺は確か

パイロットプロジェクトの選定とアプローチ

スピーカー 1

になというところでしたね結構プロダクトのトレ高コンポーネント

のトレ高みたいな汎用コンポーネントがどれぐらいあるかみたいなところ

ばっかりで考えてたけど確かに広めていく上での観点とか協力者

がどれぐらいチーム内にいるかとかっていうのは結構確かに大事

だなっていうふうには思いますその上でじゃあパイロットプロジェクト

1個決めました例えばメイン事業の中で投稿をサポートするための

管理プロダクトから着手しますみたいなそれをパイロットとします

みたいに決めたとしてじゃあそれをどうやってデザインしてもそこの

具体プロダクトからデザインしてもどう作り上げていくかっていう

戦略もいくつかあるよねっていうふうに書かれていて例えばリファクタリング

中心でアプローチする方法それを置き換え型っていうふうにこの

本では呼んでますけどだいたいデザインシステムがない状態の

プロダクトが1個あったとしたらそれって汎用性とかがあんまり

書かれてない汎用的な観点で作られてないからカスタムメイドされたオーダーメイド

された超具体のコンポーネントがいっぱい詰まって 1個のプロダクト

が出来上がってる状態っていうのになってると思うのでそれを

1個1個抽象化できそうなものを取り出して抽象化した上でそれを

1個1個置き換えていくっていうようなアプローチだからこれはあくまで

リファクタリングだからユーザー体験できないのに何も変更しない

っていうのが1個ポイントかなっていうふうに 2つ目がお色直し型っていう

ふうに呼ばれていてこれは単純にビジュアル表現を変えるっていう

やり方だからさっき言ったリブランディングのプロジェクトやった後とかに

こんなアプローチを取るのかなって思うんですけど単純にフォント

とタイプグラフィーとかカラーとかを変えていくっていうような

アプローチもあるしあとはもうちょっと何だろうな人的なアプローチとして

は代行型っていうようなアプローチもあるよっていうふうに書かれて

て例えばデザインシステムチームが既にチームが創設されていた

としたら一定期間プロダクトチームの作業を一部代行して一部デザイン

システムを使いながら例えばリニューアル作業を一緒にしていくとかそういう

ようなアプローチもあるよっていうような話ですね

あと4つ目が周辺型っていうのでこれは収録プロダクトじゃなくて

周辺の主流のプロダクトから始めるっていうような話でなるべくハードル

が低いものから着手してそういうデザインシステムに置き換えた

っていう事例を大量に作っておいて徐々に実績を貯めていくっていう

ようなやり方その上で本番に向かうっていうような周辺から固めて

いくっていうやり方もあるよねっていうようなその4つが紹介されて

いてこれ実際自分の経験としてもクックパッド辞めた後フリーランス

でクックパッド関わってた頃とかだとまさに置き換え型と代行型

ってアプローチとってたなと思ってその時も結構課題感としては

結構クックパッドのPC版のウェブのPC版の見た目が結構レガシー

になってきているっていうデザイン的な負債がいろいろ溜まってる

っていうような状態があったのでそこに対してユーザー関係は

何も変えないんだけどリファクタリングをしていくっていうようなアプローチ

で新しくできたデザインシステムエプロンっていうやつに置き換えて

いくっていうやり方を取ってたりとかその置き換えていくって

やり方をプロジェクトチームがやるんじゃなくてデザインシステム

を作ってるチームが代行してやってくっていうようなアプローチを

取ってたりとかそういうこの4つのアプローチっていうのは結構進め

方として1個に決めてやるっていうよりは2つ併用するとかそういう

ようなやり方もあるのかなと思うんですけどうまく整理されている

具体的取り組みのサイクル

スピーカー 1

なというふうに思いましたねポイントなのはこのパイロット

プロジェクトっていうのを1個に決めるんじゃなくて 3つ同時並行

してやるといいよっていうふうに書かれてましたねそれはやっぱ

1個のパイロットプロジェクトを例えば管理画面をまずデザイン

システム化しますっていうようなパイロットプロジェクトを決め

たとしてもそこから流れとしては1個具体のパイロットプロジェクト

を決めますそこから具体のプロダクトの在り方を見ながらデザインシステム

化これをちょっとコンポーネント抽象化できないかどうかっていう

のを考えながらリファクタリングなりをしていくんだと思うんですけ

どそれってやっぱ1個のプロジェクトだけだとなかなか抽象度をぐっと

上げるのって難しくなってくるのでそこで3つプロジェクトがある

と 3プロジェクト同士で抽象具合をうまくコントロールしながら

やると過度に抽象化しすぎることもなければ過度に具体化しすぎる

こともないみたいなその3つ並行してやるのが1個ポイントだっていう

ふうに考えますなのでそうして早すぎる抽象化

は悪みたいな話でめちゃくちゃ最初から何でも使えるデザインシステム

を作ろうみたいに進めるのでもなく逆に超具体の管理画面にしか使えない

デザインシステムですみたいな感じで進めるのでもなくその間

をどうしても取らなきゃいけないデザインシステム作る上で一番

ポイントになるのが抽象と具体のコントロールをいかにするか

というところが相次いで何をやるにしても大事になってくるコンポーネント

の設計にしてもデザイントークの設計にしても大事になってくる

んですけどこのプロジェクト全体の進め方っていう意味でもその

抽象と具体のコントロールをやっぱりすることが大事でその1個のチップス

としてバルトプロジェクトっていうのを3つ選定して3つ社の中で進めて

いくっていうのがポイントだっていうふうに書かれてましたね

この辺がさっきのコンサルテキーみたいな話とそこに対するイメージ

のそこのギャップの何だなっていうのをさっきもお互い話してた話

との交代になってるのかちょっとわかんないですけど

スピーカー 2

でもそれが結構コンサルっぽいなって感じがしますね目線として

それがいいか悪いかは別ですよ全然その方法がいいっていう可能性

もあるんで目線としてやっぱりデザインシステムを導入していこう

っていう側の目線です目線というか売り込んでいこうっていう目線

のやり方だなっていう印象があるっていうことですね

スピーカー 1

なるほど

スピーカー 2

はいなのでこれが別にそのやり方が悪いって言ってるわけじゃなくて

全然その方法がいい可能性もあるしもしかしたら大きい会社だったら

結局なんかやっていこうと思ったらそういうふうにしていかないと

いけないのかなっていうところもあるだろうしでも全体として

やっぱ目線としてそういう感じの目線からの書き方なんだなっていう

印象ですね

スピーカー 1

そうですね書いてる人がデザインシステムコンサルですからね

スピーカー 2

うん

スピーカー 1

であと具体からやろうっていうふうになるととにかく大事なのは

具体抽象から着手するんじゃなくて具体的なものから着手してそれを

抽象化してそれをまた具体化してみたいなそのサイクルを繰り返す

具体からスタートするサイクルを繰り返すってところがやっぱ一番

大事なポイントなんですけど何か例えば結構十数年やってる具体

的なプロダクトがあったとしてそこからデザインシステムを作ろう

っていうふうに思うと一番最初にやろうと思うのがインターフェース

インベントリっていう似たUIを集めてみるっていう整理をする

と思うんですよね 1個のプロダクトの中でサブミットをするボタン

がどれぐらいパターンがあるかみたいなのを洗い出してみるみたいな

ことをよくしてその中でじゃあデザインシステム

として提供するサブミットボタンっていうのはこういうものですよ

っていうのをちょっと抽象化 1歩引いて考えてみるっていうアプローチ

をよく取ると思うんですけどただ結構それもいいんだけど大事

なんだけどそれをやるのはそれをやるの大事なんだけど結構やっぱ

いらないものの中に紛れ込んだ優れたものっていうのを見落とし

がちだよっていうことが書かれていてそれが4つ観点があるっていう

話でそれがパフォーマンス顧客満足度技術的な性能美観っていう

4つの軸があるよっていうふうに書かれててパフォーマンスって

のは何だろうなパフォーマンスが良いっていうのは何かっていう

と要はロードが例えば早いとかユーザーが何かアクションしたい

ときに待つ時間が少なくできるみたいな観点だからそういうの

を実現するコンポーネントが良いですよっていうような観点とあと

は何だろうな顧客満足度っていうのはユーザーの不満が最も少ない

ページのコンポーネントが良いですよっていうような考え方あと

技術的な性能っていうのは行動的に何だろうなすごい綺麗に作ら

れてるコンポーネントっていうのはやっぱり良いですよねっていう

話それは何だろうなすごいヒデのタレがいろいろ詰まった見た目

的にはすごいチップスが詰まった会員登録フォームなんだけど技術

的にはすごい複雑なこといろいろやっててそれをそのまま汎用化

するのは難しいみたいな観点だとベストとは言えませんよね

みたいな話ですね美感っていうのは単純に美しい UIとしてデザイン

的に良いですよねっていうコンポーネントだからインターフェースインベントリ

っていうふうにやると特に美感とかそういうところが優先しが

されがちなんだけどそうじゃなくてパフォーマンスとか満足度とか

技術的な部分とかも含めて考えていくっていうのが大事ですよね

その四つの観点で良いものっていうのを抽出してコンポーネントに

落とし込んでいくっていうのが大事ですよねっていうような話

ですねそうしてその四つの観点っていうのはもうちょっと整理

するとこの著者がもともと言っているデザインシステムっていう

のは繋がりが大事でその繋がりっていうのはデザインシステム

の目的と取り組みをもっと大きな組織的な優先事項と繋げるって

ところが大事だよねっていう話にここも繋がっていてさっきの

例えばリブランディングが会社として大きいトピックなのであれば

そこに対してデザインシステムを紐づけていくっていうのが大事

だしコンポーネントを選んでいくっていう観点でもやっぱり美観

だけじゃなくてパフォーマンスとか例えばコンバージョンレート

デザインシステムの基本概念

スピーカー 1

とかそういうところもやっぱ大事だよっていうのが繋がるっていう

話と繋がるっていう話ですねインターフェースインベントリ

していくと大体似たようなボタンがいくつか集まってたり似たような

インプットフィールドがいくつか集められたりとかするのでその

中でどれをデザインシステムで採用するのかっていうのを決めて

いかなきゃいけないんだけどその時に大体四つ基準があって一つ

は例えばログインフォームみたいなものを想像してこのログインフォーム

は例えばログインフォームの中で使うインプットフィールドがいく

つかパターンがあったとしたら絶対に全部の特徴に当てはまる

ものっていうのもあれば一部のプロダクトに使わないようなインプット

フィールドっていうのも当然あると思うんですよねなので簡単

なのは全てのものに当てはまるものはもちろんコンポーネント

化すればいいし極一部にしか集まらないものは切り捨てるっていう

ような判断が必要になってくると難しいのは間に位置するグラデーション

の部分で大体一番迷うのが大体 3 4割のコンポーネントには共通

してるんだけど 6割には共通してないとかそういう部分だからそういう

ところはやり方としてはデザインシステムのチームが独断でこれは

これにしますみたいに決めるってこともできるんだけどこの本的

にはそこは丁寧にワークショップとかなんなりして共通のコンセンサス

っていうのをデザインシステムチームと各プロジェクトチーム

で共通認識みたいなのを話し合って作ったほうがいいですよみたいな

ことが書いてありましたねそうするとデザインシステムチーム

から見てこれは自分たちのこれまでやってきたノウハウが詰まっている

デザインシステムだっていうふうに見られるから自分ごとになる

っていうような話ですね具体からスタートしてそこからプロジェクト

1個 3個ぐらいプロジェクト走らせて抽象化してそれを1つにまとめて

デザインシステムとするっていうようなそのサイクルをずっと回

していくっていうのが基本的には育てるっていうふうに言ってる

のの中身なんですけどアプローチなんですけどこれはアプローチ

の話であとはチーム作りっていうかどういう組織体制を取るのかとか

どういうガバナンスをするのかみたいな話ももう1個考えなきゃ

いけないポイントですよねっていう話ですね

なんかパターンとしていくつかあるよねっていうふうには書かれて

いて例えばプロジェクトチームから代表者を集めてデザインシステム

の専任チームと合わせて専任と兼任の人を合わせて1つのチーム

デザインシステムチームを作るっていうようなやり方それが連合

モデルっていうふうに読んでましたけどそういうようなやり方もあれば

あるいはこの本だとサイクル型モデルって紹介されてるんですけど

デザインシステムチームとプロジェクトチームの間で役割を定期的に入れ

変えるっていうようなやり方をするっていうようなやり方もあります

よっていうふうに書かれてましたねなのでそうしてデザインシステム

チームがずっとデザインシステムだけをやってますとかプロジェクト

チームの人はプロジェクトチームをずっとやってますっていう完全

分離でやっちゃうとそもそもサイロ化しちゃうしそうするとなかなか

うまくデザインシステムがフィットしていかないよねっていう話が

あるのでやっぱりそのデザインシステムと作る人たちとプロジェクトを作る

人たちってのをいかに混ぜるかってところがやっぱり組織体制

を考える上ではポイントになってくるよねっていうような話ですね

プロジェクトチームとの協力

スピーカー 1

ただやっぱりその性質としてデザインシステムを作る人たちとプロジェクト

を作る人たちっていうのはやっぱり性質がちょっと似て非なるところ

があるっていうふうなところが書かれててシステムを作る人たち

はやっぱり何か物事を抽象化して汎用化するみたいなところに思考

が及ぶっていうかそういう発想しやすいし逆にプロジェクトを

作る人たちっていうのはやっぱり具体なもの新しい何かアイデア

を形にするところってのをどんどん追い求めていくことが好きだったり

するからそこの性質っていうのがあるよっていうのはやっぱり

理解しておいたほうがよいっていう話とあとはデザインシステム

を作ってるチームっていうのはどうしてもプロジェクトチーム

に対して何か貢献してほしいデザインシステムを作ることに

みんな協力してよっていうようなマインドにどうしてもなりがち

なんだけどそれは何かそういう幻想っていうのはあんま持たない

ほうがいいっていうふうにシビアに書かれてましたねそういうもともと

性質の違いがあるしそもそもプロジェクトチームはプロジェクト

を作るのが仕事なのでシステムに貢献するのは全然仕事じゃない

からその辺はシビアに捉えたほうがいいですよっていうことが

書かれててそれは本当にそうだなというふうに思いますねこの

著者のダンモールさん的なおすすめとしてはやっぱりこの混ぜこぜ

にするっていうのは大事なんだけどその中でもパイロットプロジェクト

1個 3個ぐらい選んだとしたらそれぞれのプロジェクトに対して

フローウィークってのとシステムウィークってのを定めてそれぞれ

を交互に繰り返すのがいいよっていうふうに書かれててフローウィーク

ってのはプロジェクトチームが何か機能を追加するとか何か

機能を改善するとかそういうプロジェクト開発を普通にしていく週間ウィーク

ですねそのときにプロジェクトチームはそういうプロジェクト開発を

どんどん普通にいつも通りやってくんだけどその横でデザインシステム

チームが伴奏していてこのコンポーネントを使ったらもうちょっと時間の節約

になりますよとかここのプロジェクトちょっと抽象化しやすいんでこっち

で抽象化しときますねとかそういうふうにプロジェクト作りっていう

のを一緒にやっていくけどちょっと役割分担をしてやるみたいなところ

っていうのを2 3週間まず設けるのがいいですよっていう話をして

いてそれをやった後に今度はシステムウィークっていうのを設けてプロジェクト

チームは並行してプロジェクト作りをやってるんだけど今度

デザインシステムはちょっと伴奏一旦やめてその中でプロジェクト

チームが作ったものを精査してリファクタリングするっていう

ここはちょっと抽象化してボタンコンポーネントとして抽象化できる

なとかカードコンポーネントとして抽象化してもこのプロジェクト

でも使い回せそうだなっていうのは一歩足を止めて俯瞰して考え

なきゃいけないからそこはシステムウィークとしてまた2 3週間時間

を設けてやるのがいいよっていうふうに言っていてなのでプロジェクト

チームのほうは普通にプロジェクト作りをずっとやってるんだけど

デザインシステムチームのほうはフローウィークとシステム

ウィークっていうのを交互に繰り返していくっていうことでデザイン

システムを作るといいんじゃないっていうふうに言ってましたね

フロントエンドエンジニアの重要性

スピーカー 1

これは確かにそうかもなっていうふうに思っててエンジニアって

結構俯瞰して考えるっていうのと具体で考えるっていうのを結構

繰り返してやるっていうのが草になってる設計を考えるとき

とガリガリ実装していくっていうところが結構草になってるんだけど

やっぱデザインシステムでも同じことが必要でこのボタンのよし

よしだけを突き詰めていくフェーズとそのボタンの抽象化して他の

バリアントを展開してみたいなことを考えていくフェーズって

やっぱちょっと時間を分けてやんないとデザインって特に難しい

かなっていうふうに思うんですよね

だからデザインをしていく上でも自分僕がデザインシステムを作る

とき何だろうデザインシステムを作りがちな僕もやっぱ何かプロダクト

の01でデザインをするってときはやっぱデザインファイルぐちゃ

ぐちゃになりがちだしそれはやっぱ整理する時間っていうのがどうしても

必要になってくるからそこを分けてバイウィークリで繰り返していく

っていうのがやっぱ大事ですよっていうふうに書かれてましたね

あとは役割と職責みたいな話どういう役割の人がデザインシステム

チームには必要なのかみたいな話ですね

この本の著者的には結構やっぱデザインシステムってアジャイル

開発の流れを組んでいることが多いだいたい組んでるのでアジャイル

開発ってアジャイルソフトウェア開発宣言っていうのがあってその

中でアジャイル開発の中では例えば包含するフォーカス的なドキュメント

めっちゃ頑張るよりもソフトウェアをとにかく作りましょう動くソフトウェア

を作りましょうっていうのが1個そういう開発宣言っていうの中で

宣言されたりするんですよねだからアジャイルの中ではドキュメンティション

めっちゃ頑張るよりも動くものでやっていこうぜみたいな精神が

1個あったりするんだけどやっぱそういう精神もデザインシステム

作る上ではやっぱ大事だよねっていうふうに言っていてデザインシステム

って結構世に広まっている成果物だけ見ると立派なリファレンス

サイトがあってその中でこのデザインシステムはこういうふうな考え方

で作られてますとかこのコンボチャンスはこういう感じで使ってください

みたいな取扱説明書みたいなのがめっちゃ充実してることが多いん

でどうしてもそっちにフォーカスしがちなんだけど実際組織の中で

育てていくってことを考えるとそういうドキュメントよりもやっぱ

動くものがいかにあるかってところと動くものを中心にして例えば

デザイナーとエンジニアが一緒にそれを使ってみてデザインシステム

に対する理解を深めていくとかそういうようなアクティビティ

のほうがやっぱりよっぽど大事だっていうふうなことが書かれて

ましたねなのでそういう観点でいうとデザインシステム

チームの中で一番大事というか考えなきゃいけないのがフロント

エンドエンジニアの存在だっていうふうに書かれていてフロント

エンドエンジニアの中でも特に今 React というか JS というとこは

TypeScript とかあとは Node.js とかできることがいろいろ広がってる

からフロントエンドエンジニアっていう役割の中でもフロント

の中でもバックエンドが得意な人とフロントの中でもやっぱより

フロントが得意な人ってのがやっぱいるんですよね実際僕はどっち

かっていうとこの本の中でフロントオブフロントエンジニアって書いて

るんだけど僕もそっち側で UI がどうあるかとかそこには関心

はあるけど逆に言うとパフォーマンスチューニングとかフロントエンド

のパフォーマンスチューニングとかはほぼ経験ないし関心も

あんまないかったりするんですよねあとフロントエンドエンジニア

の中でもアクセシビリティにすごい長けてる人とかもいると思って

て僕も UI のほうには関心はあるけどアクセシビリティはそこまで

そんな関心が強いタイプではないみたいなだからその中でやっぱ

その子のグラデーションってのすごいあってほんとそのグラデーション

がどんどん広がってるのがフロントエンドエンジニアの今の領域

だと思うんですよねデザインシステムっていう意味ではやっぱそのフロント

オブフロントエンジニアっていう一番 UI とかユーザーフェンシング

の部分に一番関心があるエンジニアっていうのをまずは仲間に入れる

っていうのが大事だっていうふうに書かれてましたねこれはほんと

本当にそうだなっていうふうに思ってて僕もいくつかの会社

で話していく中でやっぱデザインシステムが今必要だと思ってるんですっていう

ような話を持ちかけてくるのはだいたいデザイン組織なんですよ

ねその組織の中にはCDOみたいな人がいてデザイナーが何人か

いるみたいなチーム構成になっていることが多くてそこにはエンジニア

デザインシステムの普及

スピーカー 1

がいないことが大多数だったりするんだけど逆にデザインシステム

がすごい草の根的に広まっていた会社例えばCookpadとかってエンジニア

的なデザイナーがいたりとかユーザーフェンシングの部分に

関心が強いエンジニアチームに初期から入ってたっていうケース

がやっぱあるなと思っていてだからここのフロントエンジニア

フロントオブフロントエンジニアをいかに最初から捕まえるかっていう

のが一番ポイントだし難しいところでもあるなっていうふうに思うん

ですよねこの人のお勧めとしてはフロントエンジニアを例えば

エンジニアの組織からそういう創業がありそうな人を見つけて

きてその人をデザインチームに移動させてデザイナーという名前

に呼び名を変えたほうがいいっていうふうなことを言ってましたね実

はその人が呼ばれた側の人がエンジニアっていうロールのエンジニアっていう

タイトルのままいくのかデザイナーっていうタイトルに実は変える

のかそれはまたその人次第の問題であるんだけどその人の捉え方

としてはデザイナーというふうにむしろ捉えたほうが良いんじゃない

かっていうふうに言ってましたねそうしたほうが活躍するケース

があるっていうふうなことを言っててこれは本当めちゃくちゃ

分かるというか僕自身がそうだったから分かる話でフロントオブ

フロントエンジニア的な人って関心としてはUIだったらよりユーザー

に関心が強い人が多くてだから別にデザイン的な仕事も全然やる

人が多いと思うんだけど逆にでもただフロントエンジニアって例えば

フロントエンドエンジニアっていうふうにラベルがついてるとどう

してもエンジニア評価がされて CTO 的な人に評価される特にCTO的な

人がすごいテックなところに寄ったCTOだとどうしてもそこが評価

として重みが強くなってそういうフロントオブフロントエンジニア

のフロントオブフロントのところがあんまり評価されなかったり

とかすることが結構あるから実際移動しちゃうっていうのはすごい

大事だと思うんですよね僕も実際そういう例が結構ストレスに感じる

ことがこれまでの会社でも多かったから実際池田さんのチームに入って

みたりとかあと実際僕が出向した外の会社に出たタイミング

とかだと実際もうもともと僕サービス開発エンジニアっていう

肩書きだったけどもうそれ捨てて UXエンジニアっていうちょっと

よく分かんない肩書きにもう実際自分で変えたっていうのもやっぱ

そういう課題感だったからなんか今でもデザインエンジニア

っていうふうに働いてるのはやっぱそういうエンジニアっていう

見られ方が強すぎるとどうしてもそういう時点で評価されるので

その本人の意思が別にデザイナーエンジニアっていうのはラベル

なんだけどデザイナーっていうマインドなんだよねっていうのは

全然それはいいと思うんだけどやっぱ肩書きっていうのは見られ方

だからやっぱその見られ方を変えるっていうのはすごく大事

だと思うのでここはデザインシステムを育てていくっていう観点では

見過ごされがちなんだけど結構ポイントなんじゃないかなという

ふうに思いますね

理想のチーム構成

スピーカー 2

なんか周りからの見られ方っていうのもあると思いますけどもちろん

多分本人の意識的な部分も結構変わるんじゃないですかねやっぱり

そういう肩書きで働いているかっていうことで

スピーカー 1

そうですねだから頑張りとか心がけとかじゃなくて肩書きだけ

を変えちゃうとそれがフレームワークとして機能してそっちに

アラインされていくっていうような効果があると思うんですよね肩書き

っていうのはだから結構 Cookpad でも僕が最後

辞めた年に UX エンジニア採用やるぞっつってそこで Takram と一緒に

イベントしてそこが僕が Takram に今いる最初の原点にはなるんですけど

そこから何人か採用されて後々デザインシステムをメンテナンス

というか改善していた中心人物もその人たちだったりするので

そこのラベルとちゃんとデザインチームの中でエンジニアを添えるっていう

のはすごく大事なんじゃないかなと思いますね

スピーカー 2

結構だからあれだよね肩書きとそれに合わせた評価みたいな

のってかなり働き方が変わっていく要素の一つだと思うんだよねやっぱり

それに合わせて自分も動いていくとか実際にそれによって評価が

されていくっていうような仕組みになってると全然多分成果の

現れ方が出てくる部分っていうのが変わってくるんじゃないかな

スピーカー 1

という気はしますね

そうですね僕自身がそこにすごいいろいろストレスもあったしいろいろ

考えてきた話でもあるのでここはすごい共感をしましたねあと逆に

見過ごされがちなのがデザイナーの中でもフロントオブフロント

エンジニア的な人はいるっていうところがポイントここは多分

本山さんとかもそうかもしれないし池田さんとかもそうかもしれない

んですけどコードも書けるデザイナーっていうのはいてやっぱりそういう

人種の人たちっていうのはすごいエンジニアの中でデザイン的仕事

をするエンジニアがなかなかフィーチャーされないっていうのと同様にデザイナー

っていう組織の中でコードを書けるっていうのがなかなかフィーチャー

されなかったりするんだけどただデザインシステムっていう上

ではやっぱりデザインとエンジニアリングの瀬戸際に立つ存在っていうの

がやっぱり大事なのでそうしてデザイナーエンジニアっていう

ゼロ一で考えるんじゃなくてそこの間のグラデーションに立つ

人っていうのを枠にはめずにチームに取り込むっていうのが大事ですよ

っていうふうに書かれてましたなのでポイントとしてはUX的な

部分が得意だけどコードは書ける人は組織内にいませんかとか

あとコードは書けるっていうのは別にゼロから書ける人はなくて

コピペしながらでも書けるっていう人はいませんかとかそういう観点

で組織をみんな押してみるとデザインシステム的には大事な

人が見つけられるかもしれませんっていうような話が書かれてました

ねなのでここも結構大事かなと思って結構やっぱコードを書ける

かどうかって話はデザインシステム作る上では大事なんだけどじゃ

かといってバックエンドとか本当にバックエンドのエンジニア

みたいなザコンピューターサイエンスみたいなそういうバックグラウンド

持ってない人ダメかっていうとそういうことでもないと思うので

今でいうとチャットGPとか頼りながらコードが書けますみたいな人も

全然さっきのフロントオブフロントエンジニアっていう素容には含

まれるのかなと思うのでそういう意味でやっぱコードが何かしら

親和性がある人っていうのはポイントになってくるっていう話ですね

理想のチーム像っていうのが書かれていて組織像みたいなのが図として

この本の中で出てくるんですけどまず一番トップにいるのがプロダクト

オーナーデザインシステムのプロダクトオーナープロダクトマネージャー

と呼んでもいいかもしれないんですけどここの人は大体職責としては

予算を獲得してきたりとかあとは他の部分を調整したりするっていう

ところの人ですねちなみにさっき言ったクックパッドの中でレガシー

なコードをリファクタリングしながらデザインシステムを置き換えて

いくっていう仕事をしたときはここは倉道さんがプロダクトオーナー

の立場に立ってやってましたねあとはデザイナーここは別に

特指すする話じゃないんですけどよりそういうコンポーネント的な

思考に長けたデザイナーたちですねあとはエンジニアこのエンジニア

っていうのはさっき言ったフロントオブフロントエンジニアみたいな

人たちあとはもうちょっとデザインシステムが育ってきたフェーズ

になってくるとプロデューサーっていう人も必要だっていうふう

に言っていてここで言うプロデューサーっていうのはデザインオプス

ってさっき読んだやつをやる人ですねプロデューサーがよくわ

かんないのでデザインオプスってよくわかんないワードを持ち出して

きてあれなんですけどデザインオプスって僕もちょっと捉え方が難しい

言葉だなと思っててこれ2018年ぐらいから出てきた言葉なんですよ当初

はエンジニア界隈でDevOpsって言葉があってそこから発生した言葉

だと思うんですけどどっちかというとデザインとエンジニアリング

の瀬戸内側に立ってデザインとエンジニアリングがブリッジする

ようなツールを整備したりとか例えばFigmaを導入しましょうみたいな

話もそうだしデザインシステムを先導していきましょうみたいな

話もそうだしどっちかというとさっき言ったフロントオブフロント

エンジニアに近いような役割の言葉だったかなって記憶して

るんですけどなんか徐々に最近ちょっと言葉の意味がいろいろ

変わってきたっぽくて最近だとこのデザインオプスっていうのは

どっちかというとデザインチームが最高の仕事をできるようにする

ためのサポートする人たちっていうような役割みたいなんですけどね

役割みたいなんですよだから例えばさっき言ったリサーチをするとき

リクルーティングを支援リサーチの候補者インタビューを集めて

くる候補者を集めてくる人たちとかあとは採用をサポートする

人たちとかそういうデザイナーが本業に集中できるように周辺

の業務を拾う人たちってのがデザインオプスと呼ばれてるらしいんですけど

デザインシステムにおけるデザインオプスっていうのは例えばデザイン

システムチームに新しく入ってきた人たちをオンボーディング

するとかあるいはデザインシステムを社内に広めるためにワークショップ

を運営するとかそのときの司会をするとかそういうような役割

の人たちそういう人たちも必要で結構海外のおっきめな会社の

事例だとデザインオプスっていう人たちが専業でいて実際そういう

人たちはそういうデザインオプスみたいなタイトルを持っていて

採用の枠が設定されてるぐらい確立されたポジションとしてある

っていうような話がありましたね実際デザインオプスサミット

っていうようなやつもあって 2018年ぐらいからそれが出てきて

いてそのサミットの開催されてるのを見て組織論に移ってきたんだ

なっていうのを僕はすごい当時感じたんですけどちなみにそれを

組織の役割と重要性

スピーカー 1

開催してるのがローゼンフィールドメディアっていう出版社なのかな

この本を書いてるこの本の原著の出版社でもあるのでそういうこと

なんですけどそういうような役割もあるっていうような話ですね

あとはもっともっと規模がどんどん大きくなってくるとそこにQAの

人たちが入ってきたりだとかあとはコンテンツストラテジスト

みたいな人が入ってきて UXライターみたいな人ですねここは多分

以前紹介したSmartHRのデザインシステムの小さく始めるデザイン

システムの話とかがまさにそうなのかなと思うんですけどデザイン

システムとしてのコンテンツを考えてくる人でもあればデザイン

システムとして提供するコンポーネントの中身のライティングを考えて

くる人たちでもあるのかなと思いますねただそういう理想的な組織像

としてプロジェクトオーナーがいてデザインオプスの人がいてコンテンツ

の人がいて QAの人がいてとかいっていろいろ考えてくるとそれ

がそうじゃなきゃいけないっていうふうに思いがちなんだけどあく

までそういうのは課外活動として考えればよいっていうふうにこの

本には書かれててまずは大事なのはさっき言ったパイロットプロジェクト

デザインシステムのプロセス

スピーカー 1

具体を設定してそこから抽象を抽出してっていうのを繰り返すその

アクティビティが大事だっていうふうに言っててそこから一定形

になってきて 1年 1 2年とか経ってきたら例えばスラックチャンネル

を開設してよりみんなが使いやすいな状態を作りますとか未来のロード

マップを作りますとかそういうこととかあとはコンテンツを作って

デザインシステムの最近のニュースをみんな社内で広報しますとか

そういうことはそういう課外活動的なことは余裕が生まれてから

やればいいですよっていうふうに書かれてましたねなんで最初の

具体と抽象を繰り返すってところが大事ですっていうのはそういう

話ですねあとはデザインシステムがそういう感じで最終形として

は結構デザインシステムチームっていうのは大体10数人とか人を

抱えることになるんで大きい会社とかだと年間100万ドルとか確保

しろっていうふうに書いてましたねこれは日本円だと1.5億円とか

それくらいになってくるんですけど本当に大きい会社とかだと実際

そうなるんだろうなっていうのは実際自分が受け合う立場として

そういう仕事をやっててだいたい思うところではありますねこの

予算っていうのは全部人件費とか全部込みでの話ですねあとは成功

の指標としてやっぱそのKPIみたいなデザインシステムがどれくらい

成功してるのかっていうのは指標っていうのは当然設定したほう

がいいですよねっていうことが書かれてましたね例えば実際プロダクト

チームがデザインシステムを使ってどれくらい時間が短縮できた

かどれくらいデプロイまでの時間が短くなったかみたいな話とか

あとは何かの機能がプロダクション世に出るまでにどれくらい時間

が少なくなったかリリーススピードがどれくらい上がったかどれくらい

フィーチャーが外に出るようになったかみたいな話とかあとはQAにどれ

くらい時間が短縮できるようになったかとかあとはバグが具体的にどれ

くらい減ったかとかそういう指標の話なんですけどあとはデザイン

システムならではといえば各コンポーネントの採用度合いみたいな

ものも測ったほうがいいですよみたいな話があって例えばボタン

コンポーネントみたいなのであるボタンの中でもゴーストボタン

みたいなのを作ったとしてそれがどれくらいコンポーネント内で

採用されてるのかっていうのは測ったほうがいいですよっていう

話で Figmaだとライブラリアナリティクスっていうのがあって Figma上でどれ

くらいそれがコンポーネントとして使われてるかっていうのが PVみたいな

ものですね取れたりとかしたりあとコードベースでも何かしら

ライブラリがあるのでサースみたいなものがあるのでそれを

採用して採用度合いっていうのを見ながら場合によっては削除

をするとか統合をするとかそういうことをしたほうがいいですよっていう

のは話ですねあとはチームとしての目標設定っていうのはやっぱ

大事ですよっていうのでここは OKR使うといいですよみたいな話

が書かれてたんですがこの辺はちょっと省略するんですがそう

じてプロダクトチームの目標に合わせプロダクトチームの目標

が短縮できるような目標をデザインシステムチームとして設定する

のがいいですよっていうふうなことが書いてましたね例えばプロダクト

チームが何とかの機能をリリースするときに1週間時間が短縮できる

ようにするみたいなそういうような目標をデザインシステムチーム

も持つほうがいいっていうようなだからこの辺は組織とかビジネス

の目標があった上でのプロダクトチームの目標がありプロダクト

チームの目標があった上でのデザインシステムチームがあるみたいな

そういうようなヒエラルキーをちゃんと意識したほうがいい

ですよっていうような話ですねあとは最後に伝えてそれを社内

で広めるっていうような話でこれもコンテキストとしては大きい

会社をイメージしてもらったほうがいいんですけどリファレンス

のサイトデザインシステム用のウェブサイトっていうのを作る

ときにどうしてもデザインシステムチームとしてはコンポーネント

っていうのに意識がいくからやりがちなのはコンポーネント

集みたいなものを並べがちなんだけどただそれってユーザーであるプロダクト

チームのデザイナーエンジニアからしてみると何か魅力がない

っていうか結局そのコンポーネントを使って何ができるのっていう

のがピンとこないのでやっぱりそのサイトにおいて一番最初に

まず伝えるべきはユースケースとか事例要はこのデザインシステム

を使えばどんなプロダクトが作れるのかどんなプロダクトが作って

これまで来られたのかっていうのを示すっていうのがやっぱり

一番大事ですよっていうことが書かれてましたねこれも本当に

プロダクトとしてデザインシステムを捉えた場合にPMFさせるっていう

意味では結局コンポーネントを並べてるだけっていうのはこの

プロダクトってこんなことできるよっていうのを言ってるだけなので

機能一覧みたいなのを作ってるだけなのでそうじゃなくてそれを

採用するとどういうふうに生活が変わるのかみたいのを話した

ほうがいいですよっていうプロダクトとして捉えると当たり前の話では

あるんですけどただ実際コンポーネントだけ並べるっていうようなこと

はやりがちなのでそうじゃないほうがいいですよっていうような

話ですねあとこの辺は最近思うのは以前紹介したかもですけど

フリーの人がFigmaのデザインシステム系のイベントでも話してたんですけ

ど最近パーツ単位でも提供するんだけどそれだけじゃなくてその

パーツを組み合わせたパターンとかフローっていう単位でデザイン

システムを整備しようと思ってるっていうような話をしててそれも

この話に近いのかなと思っていて結局使い手としてはパーツを組み合わせ

ながら一つのプロダクトをビルドしていくっていうことはあんま

なくて大体参考になる類似プロダクトとか類似画面みたいなものを持って

きてそれをベースにして組み立てるっていうことが多いのでなので

アトミックデザインでいうアトム的なものを提供するんじゃなくて

もうちょっと流度の高いテンプレートとかそういう流度で提供したほう

がユーザー的には使い勝手いいですよっていうのはそういう話にも近い

かなというふうには思いますねという感じでこれが大体かいつ

もんだ話でそうして育て方っていうのは何なのかっていうとパイロット

プロジェクトを見つけてそこから具体と抽象化っていうのを交互に

繰り返しながら進めていくそのパイロットプロジェクトっていう

のを社内で3つぐらい見つけてそこからスタートしていくといい

感じの流度感のデザインシステムができますよっていうような話

成功の指標と目標設定

スピーカー 1

とあとはそれを広めていく社内にユーザーを増やしていくっていう

PMFさせるっていう観点では実際会社が持っている課題感に合わせて

いく例えばリブランディングを最近しましたとかあとはデザイン

とか技術的な負担を抱えていて大規模リニューアルが必要です

とかそういうものに紐づけていって大体それにぶら下がってプロジェクト

チームの目標が設定されているのでデザインシステムチームの

目標はそれにさらにぶら下げるべきだっていう話とデザインシステム

チームを作るっていう上ではエンジニアっていうところが鍵になってくる

のでフロントオブフロントエンジニアっていう人たちをどう集めるか

っていうのがやっぱり一番最初の考えどころになるよっていうそういう

感じですねまとめるとですねなので結構この辺の話は冒頭にも

ちょっと話したけどデザインシステムを単に作るっていうだけ捉える

と本当にここ1年2年で変わってくと思うだいぶそんなに特質すら

話がなくなってくる当たり前にこうやったらいいよねっていう

感じになってくると思うのでやっぱその育てるってところがそこ

は汎用的にはしづらい多分この本頑張って汎用化してるけど言って

もそれここまでだと思うんですよね汎用化できるのはそれ以降は

結構会社の事情とかカルチャーによっていろいろ違ってくると思う

のでそこがやっぱ力の先どころになってくるっていうそういう

感じなのかなと思いますねっていう感じでデザインシステム

シビアなコスト判断

スピーカー 1

の仕事をやってる身としてはすごいハッシュタイムでも使えるなみたいな

話が多くてすごいいい本でしたねこれはただデザインシステム作ってない

とかあんま関わってない人にとってはそんな別にピンとくる話じゃない

かなと思うんですけど何かしらデザインシステム今後立ち上げて

いこうとか思ってる人たちがもしいたら実際読んでみるといいん

じゃないかなと思いますねそんなとこです

スピーカー 2

おだしょー多分最初から言ってるように大きい組織向けの話っていうこと

ですよねだからそういうふうになったときに結構評価とか

どう指標を図っていく指標を図っていくっていうかその評価

をどうするのかっていう部分のほうが結構重要になってくん

じゃないかなっていうふうに思っていてっていうのは多分今は

まだノリじゃないけどこれが良さそうだからみたいな感じの突破

ができてるかもしれないですけどそのうちそれがボロが出てくるん

じゃないかなっていう実際になかなかうまくいかないとかうまくいってる

かどうかがよく見えないみたいな感じの話になってきてそのうち

その辺がうまくいかなくなってくるからだからどう評価する

のかっていう部分が多分特に大きい組織としては多分専任のチーム

作るとか人置くとかっていうことするってことはかなり予算さかな

かけなくなるわけじゃないですかスタートアップとかちっちゃい

会社だったら専任までいかなくても僕らがやってたみたいに他のサービス

のプロダクトのデザインもしながらそういうデザインシステム的な

基盤的なものも作って提供していくとかっていうのをみんな

それぞれ兼任でやってたりするかもしれないですけど大きい会社

ってなるとある程度そういうチームも作ってやっていくっていう

ふうになるっていうことは結構そこの目線がシビアになるんじゃない

スピーカー 1

かなっていうふうに思うんですよね

まさにそうだったし

スピーカー 2

だからそういう意味で評価の部分っていうのが多分今後本当は

もうちょっと重要視されなきゃいけないんじゃないかなっていう

ふうに思いますけどね

スピーカー 1

そこはもう多分海外っていうかアメリカのテク系のスタートアップ

とかそうなってるテク系の会社とかではそうなってると思って

て実際この本でもちらっと予算は1.5億とかかかるもんだよっていう

ふうな話が出てきてるんですけどちょうどこの間フィグマの銀座

の農学堂みたいなところでイベントやってたときに佐藤さんっていう

デザインシステム系のコンサルをやってる方が発表しててそこ

でもあったんですけど特に海外だとデザインシステムってバズ

ワードの魔法が溶けかけてるっていうかシビアにコストで判断される

っていうところに来てるっていう話があってニュアンスとしては

そういう話だったんですよだからそれぐらいデザインシステム

シビアに向き合ってコスト判断それ本当に予算かけるぐらい機能

してるのかっていうのはジャッジしていかなきゃいけないっていう

ような話の時代に日本もなってくよっていうような話をしてた

んですよねちょっと細かい匂わせ間違ってるかもしんないけど大

枠そういう話があって多分この本も軽く匂わせがその点あるんだ

デザインシステムの評価と課題

スピーカー 1

けど多分絶対2,3年後には多分日本の大きい会社もそうなって

いくんだろうなとは思うんですよねだから多分デザインシステム

の育て方の次はデザインシステムの評価の仕方とかデザインシステム

のKPIの置き方とかそういう話になってくるんじゃないかなとは思います

ね BuzzwordはBuzzwordの魔法が効いてる

うちはうまく利用したらいいんじゃないかなっていうのが僕の

スタンスだけどその魔法はいつか解けんじゃないかなとは思います

ね

でも評価の仕方って結構むずくないですか

難しいですよ

スピーカー 2

なんかさプロダクト開発がそれで早くなりましたみたいなのって

ある程度は数値化できるかもしれないですけどそれが本当にデザイン

システムのおかげだったのかどうかあんまり測れないじゃないですか

なんかどれぐらい流用されて使われてる

かみたいなのもさっき言ったみたいに PV見るみたいなので何となくは

できるかもしれないですけどじゃあそれがいいのか悪いのかっていう

のが全然判断できなさそうな気がするんですよね

だからどうするんだろうなっていう気はするよねなんかそういう意味

スピーカー 1

でも

たぶんぱっと思いつくのは2つでもう溶けまくってデザインシステム

的な仕事をするのがプロダクトチームとして当たり前だよねみたいな

感じでデザインシステムチームというものが解散するっていう

未来もうそれを作らなくてもいいよね作らないのが普通だよねっていう

ような未来とあとはデザインシステムチームっていうのは確立されまくって

もうそこ専門の職種みたいなのができるエンジニアだとSREとか

そういうサイトの信頼性に責任を持つエンジニアとかの役割が

かなり確立されてきたと思うんですよ多分SREができてきたのも

もともとなんかプロダクトを作るエンジニアとインフラを整備する

エンジニアっていうのがいてインフラエンジニアっていうのはどっち

かというと運用するみたいなニュアンスが強くてでもやっぱその間に抜け

落ちるものって流れあるよねっていうのでDevOpsみたいなのができ上がって

きてそこから多分ちょっと細かい流れは僕もよく分かってないけど

SREっていうものがGoogleとかから出てきて日本のスタートアップ

でもSREっていう職種は当たり前のようにあってっていうのが出て

きたと思うからだいたいこの辺の波ってCTOとかCXとかそういう文脈

もそうだけど結構エンジニアが先行していてそこにデジタルプロダクト

のデザイン領域も追従していくっていう流れが結構あるからそういう

ふうな流れになってくるのかもなとは思いますね

でそうなってくると業界的にデザインシステムチーム僕は公社のほう

が確率高いんじゃないかなその解けるよりも確率されてくって

確率高いのかもなとは思うんですけどそうなってくると評価指標みたいな

ものとかももうちょっとなんか汎用的に使えるものが出てきたり

とかするのかなとかだからやっぱ根本このほうにもあったけどプロダクト

を作るマインドとシステム化するマインドって結構違うから 1人の

人間がやってても2つ人格があるみたいな感覚だからそこが完全に

溶けるっていうのはあんま想像できないなとは思いますね特に

大きい会社だとねそうですねだからデザインシステムの評価

方法とか

役割の変化とデザインチームの未来

スピーカー 2

SREの人たちってどう評価されてるんですかね

スピーカー 1

僕も分かんないですけどでもサイト SREってまだ多分数値化しやすい

方ではあると思うんですよねパフォーマンスとかあとはサイト

のアベラビリティっていうかその可用性みたいなところがどれ

ぐらいなのかみたいな話とかだから完全にデザインシステム

はイコールにはならないとは思うんですけどねあとやっぱその

フロントエンジニア的な人をデザイナー組織に入れたほうがいいとはいえ

それを評価するのって結構難しいとは思っててっていうのは僕が

そうだったからだから結局フロントフロントエンジニアをデザイナー

組織に入れたとしてもそれを評価するのがデザイナーシニアデザイナー

みたいな人だとするとエンジニアが自分のチームに入ってきたけど

この人をどう評価したいかわからんみたいな話は絶対出てくるはず

でだからそこの難しさもあるんだろう

なとは思いますねチーム全体としての評価の難しさ

とチームの中での評価の難しさみたいな

スピーカー 2

まなんかコスト的な評価対コスト的な評価っていうのはなかなか

しづらそうな気もするからやっぱり依然としてやっぱり別のチーム

の一部として存在するしかないような気もするね要は別にそれ

だけの専任チームというか細かく言えばそうなのかもしれないですけ

ど全体として例えばデザインチームみたいなのがあったとしてその

中の役割の一つとしてこういう人たちがいますみたいな形にして

おけばまた存続できる可能性がありそうみたいな他でちゃんとデザインチーム

はちゃんと貢献してますよねっていうのが示していければその一部として

こういう人たちもいますっていう形で生き残っていくっていうの

がありえそうな未来なんじゃないかなっていう

スピーカー 1

たぶん2 300規模だとそうかもしれないですね実際そうだったし過去も

デザイン組織の中で見てますみたいなデザインシステムも整備してます

みたいなもうちょい大きい規模感になってくると例えば僕が

今仕事で付き合ってるような会社だとかだともっと大きい課題感

に紐づけてるところもあるかな DXをするために全社を変えていく

ための一部としてデザインシステムがありますみたいに続けにしてる

ところもあるし

スピーカー 2

それにでもデザイナーのチームは関わっていかないっていうの

も変じゃないですか

スピーカー 1

いやもちろん関わりますよもちろん関わる

スピーカー 2

ですよねだからデザインチームとしてあってその一部としてこういう

人たちもいますっていうのは割とわかりやすい感じなのかな

スピーカー 1

まあ今僕が話した場合のほうはデザインチームはまた別途あって

そっちはプロダクトチームプロダクトデザインをしてるチームがあるん

ですよその上でシステマチックなこのデザインシステムをやる

チームっていうのもまた別途あってそこは全社的なソフトウェア中心

ビジネスの変えていこうっていうのを全社戦略をもう本当経営戦略

に紐づいたようなチームがあってそこについてることがあります

ねだからそういうケースもあるんじゃないかなとは思いますけど

ね

スピーカー 2

だから今の時期はたまたまデジタルトランスフォーメーションによって

予算がついてるっていうような感じなのかもしれないですね

スピーカー 1

そうだしそっちのほうが本質的な気もするけどね特に

スピーカー 2

まあまあそうね

スピーカー 1

JTC的な会社にとってはねたぶんアンチパターンはJTCみたいな会社

トラディショナルな会社の中でデザインそういうトラディショナル

な会社の中であんまDXとかそういう動きが経営としてないのにデザイン

チーム主導デザインチームだけ主導してデザイン的な観点だけ

でデザインシステム立ち上げようみたいな感じだとあんまうまく

いかないかもなとは思いますけどね

スピーカー 2

だからデザインっていうものをどう捉えてるか次第ですよねその

スピーカー 1

チームが

そうだしこの本の趣旨もそうだし僕もそう思うのはデザインっていう

のに捉えず DXとかなんかより大きい経営課題にひも付けたほうがうまく

いきますっていう話かなという感じですね

スピーカー 2

なんかどうしてもデザインっていうとプロダクトのデザインとか見た目

みたいなものに行きがちだからね本当はそういう意味ではないとは

スピーカー 1

思うんですけれども

そうなんですよねそこの辺のニュアンスがやっぱ中小規模の会社だとあん

まイメージできなかったからあんまデザインシステムの組織

論ってピンときてなかったんだけど大きい会社を見てみるとなるほど

っていうのはその辺で思いましたねそもそもデジタルに仕事の仕方

を変えていくっていうのはもう組織のあり方とかビジネスやり方

全体を変えなきゃいけないからそうなってくると大体そういう

会社ってサイロ化してて縦割り組織に長なってて横口で連携取る

じゃないみたいな課題が大体あるあるだからその文脈に寄せると

デザインシステムはコンポーネント化して再利用性を高めて車輪の

再発明を防ぎますっていうロジックってすごい経営的には理解しやすいん

だなとは思ったんですよだから予算が割り当てられやすいなっていう

ここってそんなにDXのバズワードとは直接関連性はないっていう

組織との関係と影響

スピーカー 1

か結構普遍的な話か世の中の全ての会社がDX化されたら別だけど結構

長続きそうな話でもあるかなとは思うのでそういうキーワードとして

は組織がすげえ縦割りになってるってところではデザインシステム

はより効果が高いし予算も取りやすいかなとは思いますね

スピーカー 2

なんかプロセスビジョナリーで話してたビジネスアナリストに

スピーカー 1

近い立場になるんじゃないかなって僕は思うんですけどね

いやそうですね

スピーカー 2

っていうかデザインシステムって言ってるからどうもデザインの

コンポーネントのライブラリーみたいなイメージにどうしても

なってるんですけどただ業務改善してるだけですからデザインシステム

がやってることっていうのはなので別にコンポーネント子を作る

スピーカー 1

ことに何の意味もないんですよねはっきり言って

だからさっき冒頭にも言ったけど 7種類のデザインシステム

っていう中で本当その一部なんですよコンポーネント集っていうのは

だからデザインシステムってのは本当システムでなんか会計システム

を作って会計のやり方を変えるとかそういう話と一緒なんですよ

ねだからあんまデザイナーの持ち物にしないほうがいいんじゃない

かなとも思いますけどねデザインシステムっていうのを

スピーカー 2

デザイナーの持ち物である必要性はないけどデザイナーの中で

スピーカー 1

スター

メッセージを送信

kudakurage

Takaya Deguchi

サマリー

目次

スター

コメント