こんにちは。UI/UXデザイナーの kotani（こにたん）です。
少し前まで担当していた SALON TOOL （ 以下、サロンツール ）というアプリーケーションのデザインシステムを作った時の話を書きます。
今回はデザインシステムの中でも特に、エンジニアと協力した部分＝コンポーネントの切り分け単位と命名について一緒に試行錯誤したお話です。

サロンツールとは

まず、サロンツールがそもそもどんなものなのかという話です。

サロンツールとは、個人集客できるミニモを、店舗で一括管理をしたいサロン様のニーズに応えた無料で使える予約管理システムです。サロンツールは、PCがあればサロンや自宅等どこからでも利用することができます。
画像：https://minimodel.jp/info/salon
テキスト：https://minimodel.jp/info/faq#salon

サロンツールチームでデザインシステムを作ることになったきっかけ

サロンツールは諸々の事情によりリニューアルをすることが決まり、エンジニアとデザイナー2人のチームができました。（リニューアルの理由はまた別の機会に）

それまで、私は別アプリのデザインを担当していたのですが、下の絵のように、デザイナーが思っているコンポーネントの分け方と実装で分け方が異なっていて、エンジニアとコミュニケーションがうまくいかないことが何度かありました。

二人きりのチームなのでリソースが少ないこともあり、こういった手戻りはなるべく避けたいということでチームのエンジニアが「デザインシステムというのをしっかり作るのが良さそう！その中でも特にコンポーネントの単位と命名をデザイナーエンジニアで同じ認識を持とう！」と提案してくれました。

たしかに、同じものを一緒に作っているのだから、2人の認識をしっかりと揃い、チームがデザインもエンジニアリングもできる1人が作ってるように振る舞えれば、今まで自分がぶつかっていた課題は解決できそうだと思いました。

コンポーネントの切り分け単位と名前をエンジニア、デザイナー間で一致させるためにしたこと

いざデザイナー / エンジニアで同じ分け方と名前のコンポーネントを使おうとしたときに行ったフローはこんな感じです。

【コンポーネントづくりのフロー】
① デザイナーが 1 つのページ（機能）のリデザインをする
② デザイナーが設計意図や法則性をすべてエンジニアに説明する（この時に、このへんで分けると良さそうだと思っているというのも伝える）
③ エンジニアがコンポーネントの切り分け方と命名の叩きを作る
④ 二人ですり合わせて合意が取れたら完成（合意が取れない場合は ② 〜 ④ を繰り返す）

キャッチボールのように作業を進めたおかげで、デザイナー / エンジニアのどちらかしかわかっていない。という本末転倒なことが、起こりませんでした💯

また、デザインはページごとではなくひとつのアプリ全体で一貫性を持たせなくてはいけないので、デザイナー間であればなんとなく分かるようなことでも丁寧に伝え、下記の画像のように資料として残しました。

ここで伝えておきたいのが、これらの全体にかかる設計思想についての資料を最初に作ったのかというと、そうでは無いということです。
もちろん設計思想は、初めに固めないとデザインができないので、プロジェクトの最初から自分（デザイナー）の頭にはありました。
しかし、それを反映させたモノがない状態でいくらエンジニアにそれを説明し理解してもらおうとしても、それは机上の空論でしかなく理解に時間がかかると思いました。
そのため、全体理解については思想が反映されたモノを見せながら一緒に説明し、しっかりとまとめた資料はその説明をしながら徐々に完成していく。という風になりました。

atomic design を参考にしたけど、完全にそうではなかった。

コンポーネントの切り分け方は atomic design を参考にしました。（ atomic design のわかりやすい記事 ）

atomic design では、要素を「Atoms」「Molecules」「Organisms」「Templates」「Pages」の5階層に分けますが、コンポーネントとして用意するものは使いまわし可能な部分のみと決めていたので、実際に作って命名したのは、主に「Atoms」「Molecules」の2階層でした。

作りながら「Atoms」はパーツ、「Molecules」はパーツの配置方法＝マージンという感じだね。と言う気付きもありました。

落とし所を探すのが難しかった部分

コンポーネントの最小単位を決めるのはかなり難しかったです。

例えばのボタンの場合、デザイナーはベタ塗りの色面に文字が載っている（ 2 つのパーツの集まり）。エンジニアは文字の周りに色がついている（周りに色のついた文字）といった具合に、使っているツールが違う故の認識違いが起きていたからです。

こういった部分に関してはお互い根気強く説明して解決しました。
ちなみにボタンについては、ベタ塗りの色面と文字をバラバラには使わないので、エンジニアの考え方を採用しました。

コンポーネントの完成によって得られたこと

- 狙い通りスピード感があり手戻りの少ない開発ができるようになった
- ルールが決まっているので、UIの基礎設計に迷いがなくなり、結果的にUX設計や細かな表現に使える時間が増えた
- エンジニアと喧嘩しなくなった（大事）

なかなか分かりづらい部分も多いと思うので、質問等ありましたらコメント欄や twitter（ ＠asamikotani ）にぜひお願いします！
また、余力がある時に atomic design を使ってみて感じたことも書いてみたいと思います。