この記事はtechtektアドベントカレンダー2022の9日目の記事です🎄

下記の登壇内容について、資料起こし + 発表しきれなかった部分について記載できればと思います。

# はじめに

こんにちは。

テクノロジー本部エンジニアリング統括部サービス開発部でエンジニアをしている kanekoです。

自己紹介

金子広大

役割：アプリ系 iOS Swift Android Kotlin Flutter dart Vue React

現在、GCP やら React やらに挑戦中

UXE として活動中

# 小さなデザインシステム設計のナレッジシェア

発表した内容のスライドです。

上記に至るまでの過程など話しきれなかった部分（コンポーネントの分割単位についての部分）を記載していきます。

# ことの発端

上記のエンジニア側の発表でも章立てが分かれている部分ですが、デザインシステムの構築にあたって主に2つの項目になっている認識です。

- Atomicデザインへのアプローチ

- デザインルールとMuiThemeと親和性を持たせる

この記事では、Atomicデザインへのアプローチで書ききれなかった部分についてお話しします。

# Atomicデザインの問題点

こちら、一度でも運用をやったことがある人だとわかると思うのですが、まだ未成熟だと言える部分があります。

コンポーネントの再利用性を高めることのメリットはデザイナーもエンジニアにもメリットがあり、理解が得られる部分ではあります。

ただ、分割単位を考えるときに従来の要素数で検討するアプローチでは筋が悪く、コミュニケーションコストがかかるケースが多く見受けられます。

スライドでも語りましたが、以下のようなIconButtonは命名の時点で「Icon」と「Button」が入っています。

このようなコンポーネントを考えた時に、Atomsに入れるのか、Molecules に入れるのか。

これらは、ネット上でもさまざまな議論が交わされていますが、上記のコンポーネントを、

1つのボタンとして考える
1つのアイコンが入った1つのボタンとして考える
1つのアイコンと1つテキストと1つのボタンとして考える
1つのアイコンと1つテキストと1つのアクションと1つとして考える

で最大4つの考え方が可能で、人によって回答が変わってしまうと言うのが自分の見解であり、デザインシステムを考える上での大きな課題でした。

## 悩む...

プレゼンでも発表しましたが、上記の分割単位で1ヶ月くらい悩みました。

スライドでは分かりやすくIconButtonを例に出しましたが身近なコンポーネントで、さらに非常に複雑になってしまうものもあります。

TextFieldがかなり良い例になるのですが、

「入力受付領域」「入力された文字列に対するAction」「プレースホルダー」「入力された時にフィールドの右端に出すアイコン」「テキスト表示領域」など、他にもさまざまな要素で構成されており、分割しようと思うとかなりの数に分割することが可能です。

## 人はなんで１つの物体を「１つ」として認識できるか

発表を見ていただいた方はもう既にご理解いただけている内容になるかと思いますなりますが、上記の方法論でいくら考えても良い答えが出ませんでした。

そもそも「人はなんで１つの物体を「１つ」として認識できるか」がはっきり分かればよいのですが、これが難しい認識です。

基本的には色などの境界で「1つ」として認識すると思うのですが、上記のIconButtonのように「複数の要素が入っている物」となると、認識が人によってバラけてきます。

さらに、明らかに1つの物体であっても、バラバラにすることも可能です。

※ 1つのリンゴでも半分にカットすることも可能ですし、ヘタや皮に分けること、果ては分子レベルで分解することも可能です

おおよそ、Atomicデザインの運用で躓いたり、失敗する部分はここになるのかと思います。

### チームで行うからこそ発生する問題でもある

筆者は、少数もしくは個人で開発するケースがそれなりにあるのですが、それらの時に立ち返って考えてみました。

すると、これらのコンポーネントの分割単位については個人開発では絶対に悩まない問題であることに気づきました。

当たり前のことなんですが、1人でデザインもシステム構築も行っているケースであれば、意見の対立のしようがないからです。

つまり、上記は「チームで開発を行うからこそのデメリット」であり、個人開発では発生し得ないのです。

ただ、当然1人で開発するには限度があります。

そうであるなら、「一つの意思の元で既に決定されている枠組み」があれば、個人開発とチーム開発の双方のメリットだけを享受できるのでは？と思いました。

また、チームに即時で浸透させるには「ある程度トップダウンのような形になる」ことが望ましいです。

上記を満たすものを探した結果「Muiの定めた分割の定義」に乗っかることが最良だと判断しました。

「Muiの定めた分割の定義」であれば、

1. Muiの公式の意思に基づいて決定できている

2. Googleの権威を借りるのでトップダウンの形になる

ので、上記を満たせると考えました。

## 運用してみて

あとはスライドにも記載している通りですが、上記の目論見はそれなりにうまくはまって、Atomicデザインの運用の負荷も全体的に下がった認識です。

ここら辺で困っている方や「こんなケースもあったよ！」などありましたら、是非ご連絡ください。

改めて、UX Digチームの皆様、開発に携わっていただけているメンバーに謝辞を述べさせて下さい。

ありがとうございました。

金子広大　Kodai Kaneko

エンジニアリング統括部サービス開発部第2グループエンジニア

iPhoneとAndroidのネィティブアプリで、アプリの企画 -> デザイン -> 開発 -> リリース -> グロースまでの経験を生かして、活動中。現在、React Next TypeScriptにも挑戦中。

※2022年12月現在の情報です