ノゾエです（@conoito）

最近お世話になっている坪田さん（@tsubotax）の手配で、
吉竹さん（@ryo_pan）をお招きし、
デザインシステム勉強会を開催していただきました。

坪田さん：「これって内容をnoteとかにまとめて書いたりしても大丈夫ですよね？」
吉竹さん：「いいですよお」

とのことでしたので、ありがたくまとめさせていただきました〜〜〜感謝です🙏

ちなみにこの勉強会

開催は１ヶ月前の話です。遅くなってすみません

（ずっと下書きに書きかけが眠っていた。）

まずデザインシステムとは何か

プロダクトのためのプロダクト

「デザインシステムさん」という人格を作っておく感じかなと思いました。
「わからなかったら絶対的存在のデザインシステムさんに聞こう」的な。

一貫したデザインのための定義どこにも明記されてなかったりフワッフワしてると、これってこのプロダクトらしさにちゃんと沿えてるのだろうか？っていう時に答え合わせができないことになってしまうなあというやつです。

そういえばこのあいだGoodpatchさんのところでやってたMaterial Design勉強会（I/O Extended 2018 Shibuya）で、Material Designはデザインシステムのためのデザインシステムっていう話してたなあというのを思い出しました。

で、そのデザインシステムさんには、スタイルガイドやパターンライブラリとか目に見えるものの他にも、
組織がプロダクトを一貫して作っていくためのルールとか、それをどう運用するかとか、そういうのを考えた時に出てきたいろんなアウトプットたちみたいな、目に見えないものもあったりするそう。

しかしこの目に見えないもの、
テキストなりなんなり、ちゃんとみんなが立ち戻りやすく、気付きやすく、端的に、目に見えるようにしてあげないと、なんとなく目に見えないから好き放題されてガバガバになるのだろうなあと想像がつく。
どうやれば立ち戻りやすく、気付きやすく、端的に、目に見えるようになるのか…ギギギ😇

デザインシステムは誰のためのものか

社内ユーザーがデザインシステムを使って作った一貫性のあるプロダクトは社外ユーザーにとっても心地よいものになるよね。

だからデザインシステムは社内ユーザーと社外ユーザーのためのものだよ！

デザインシステムが提供するものと
それによって解決すること

デザインシステムは、「信頼できる唯一の情報源」として
「一貫性」と「同期性」をもたらしてくれる！

「一貫性」と「同期性」をもたらすことで、
下記のようなことが解決します

・サービスを構成する抽象的・具体的な要素の一貫性の欠如
・プロダクトを利用するユーザーの混乱
・メンバー同士の思い込みによって行われるコミュニケーション
・スピード感のないデザイン・開発プロセス
・新しいメンバーが全体像を理解するまでの速度

やば〜い全知全能〜〜〜🕺💃
でも実際、プロダクトって「これってこうした方がいいね」って感じで常にアップデートされていくので、その都度、最適なデザインシステムとしていられるように改良＆運用＆活用しなきゃならんので、「生かす」必要があるそうです。

常に同期させる＝生きた状態を保つことで
一貫性を提供することができるとのこと。

しかしどれくらいの粒度でどうやって生かすかがめっちゃむずい
チームによってやれる範囲、やり方も全然変わってくることとであろう。。

みんなどんな風にやってるの

以下、勉強会の中で紹介された、生きてるっぽくてシステムが作られた背景がわかる他社事例たちです🙏（私が気になったものだけ抜粋しました）

とはいえ

事例はわかったけどどう始めればいいの…

このギギギを回収するために、以下の４点を意識しながらはじめてみるのがよさそうとのことでした

1. 目的を定める
　なぜ必要なのか、なぜ今なのか？
　今の自分たちに適した理想像は何か？
2. 社内の賛同を得る
　誰を巻き込むか？
　承認と支援を得るため、誰を説得するか？
3. 原則を見つける
　個々の感覚に頼らずチームが立ち戻れる原則を見つけよう
4. ちいさくはじめる
　まずは一部だけ導入しよう（一気にやらない）

特に、2. 社内の賛同 と 4. ちいさくはじめる にわかりみを感じました。

2. 社内の賛同 を得ることができず
それをやることに対して誰もメリットを感じていない状態になると
「じゃあ適当に片手間で好きにやっときなよ。でもこっちの仕事はやってね」的な感じで時間を与えてもらえなくなる状況に陥ることがあるからです。
時間がなければ自分がどんなにやりたいと思ってもできなくなるのじゃ…

「チームの中で起こっているこの問題をいま解決すべきなのです！」

と、ちゃんとチームに受け入れてもらえるようにちゃんとした理由で説得するパワーもついて一石二鳥。がんばろう。

4. ちいさくはじめる ができないと、
目的を達成できない期間がずっと長く続いてしまい、途中で誰かが「終わってなくない？進んでなくない？やっぱやらなくて良くない？」って言い出します。やばい！

下は、徒歩より早く移動する手段をちいさく回せてない図（上）とちいさく回せてる図（下）。

まじでその通りだなと。私は上の図のようなやり方をしがちなのです。経験浅いのに最初から「４」が作れるわけなくて、でも「４」を最初から作ってやるぜ！！！！！という謎の意欲より最終的に何も作れずに死ぬことをやりがちなのです。

この記事が１ヶ月眠っていたのも、私が「４」をつくりがちな人間だからこその結果。

まじでこれ壁紙にします。まだしてないけど。iMacの壁紙にしてもおっけーなくらい高画質なやつを掘り出して壁紙にしよう。まじで。

どんな風に規模を広げるか？

stage.1 隙間時間を利用した個人
stage.2 割り当てられた個人
stage.3 プロダクトチームとしてのシステムチーム

こないだ読んだカイゼンジャーニーを思い出した。

個人でやりはじめたことも、人が見てるところでとりあえずやってみて、「なんかそれいいね」で広がって行くものなのです…

あと、勝手に手を動かすって本当に大切ね。やっぱ実際に形になるのと、形になってなくてまだ言葉ベースなものとでは圧倒的説得力の格差

隙間時間を利用して、すぐ終わるくらいの簡単なものを勝手にビャって作って、人に見せて、「いいね！」って言ってもらって、最終的に「やろうよ」って言わせられたら、協力者がどんどん増えて最強になれますね。

やってみたデザインシステムをどう評価するか？

・システムの評価とプロダクトの評価を持つ
・システムは移行率、プロダクトは顧客満足度で評価
・小規模の指標も探してみる
・チームやコミュニティも評価対象にできる

ちいさくはじめても、それぞれのチームにある、システムが解決すべき事柄（目的）があるので、その目的が果たされる道を辿っているかどうかと、それの移行率が得られればある程度の評価を得られそう。

おわりに

1. デザインシステムを整備するにあたって、チームの状況に合わせた粒度で、みんなに受け入れてもらいやすくなるような目的（理由？）を立てる（立てたい）
2. 時間と目的を持って業務としてやれるために、小さくはじめて、「やるよ！」「やってるよ！」ってみんなに了承を得る。
3. そしてちゃんと評価されるべき。評価軸はシステムの評価とプロダクトの評価。

システムを作るにあたって、「なんか良さげだったらもうそれで評価やん！」みたいなぬるい気持ちがあるので、ちゃんと測れて、可視化できるようにするのは本当に意識しておかなきゃなと思いました。むずそうだけど！

おそらくそのぬるい状態がよしとされている場合、目的そのものがフワッとしたままの可能性もなきにしもあらずな気。

ほんと、なんかいい感じだからで物事を進めるのは良くない。味方はつくっとくべき。
そして、「４」の気持ちで書いたために、
記事がめっちゃ長くなりました。すみません。
早く「１」からはじめられるようにまずは壁紙を作ろう。
セルフおしりペンペンします。引き続き頑張ります色々。
ここまでお読みいただきありがとうございました。

＼生存確認／