こんにちは😃
千株式会社でソフトウェアエンジニアをしているh_rym(@RyMer_9)です。
SEN Advent Calendar 2025 13日目の記事を担当します。
私は普段、幼保園の先生向けに撮影の依頼などをサポートするプロダクトの開発に従事しております。
今回はそのプロダクトに対してデザインシステムを反映した話と今後の展望をお話しようと思います。
👇これまでの取り組みはこちらをお読みください👇
第1回
プロダクト横断デザインシステム導入のあゆみ／（１）輪読会で共通認識を作る篇 - SEN PRODUCT BLOG第2回
プロダクト横断デザインシステム導入のあゆみ／（２）共通スタイルガイド・個別コンポーネント作成 篇 - SEN PRODUCT BLOG第3回
プロダクト横断デザインシステム導入のあゆみ／（３）構築開始から本格始動までの苦悩 - SEN PRODUCT BLOG
第2回の撮影事業者向けプロダクトで作成されていたデザインシステムを弊社デザイナーのいちごさん（@suigyooza_）に抽象化、弊チームプロダクトへの適用をしていただき、Figma上でレイアウトがおおよそ出来上がったタイミングで私もデザインシステムチームにジョインしました。
弊チームプロダクトは20年前からのコードベースで運用されており、リプレイスが走り始めた段階だったためデザインシステムを導入するにはかなり都合の良いタイミングでした。
やったこと
コンポーネントの洗い出し
リプレイスが走り始めたタイミングと言いましたが全く同じではなく、既に数ページ実装完了し本番稼働している状態でした。まずは、それらのページの置き換えから進めることにしました。Figma、現行システムとにらめっこした結果、ボタンやフォームなど30を超えるコンポーネントが必要であると判明しました。
デザイントークンの導入
既存画面はMUIで実装していたため、tailwind CSS + Headless UIの構成に変更することにしました。色や余白など既にデザイナー間で合意を取ってくださっていたのでそれをtailwind CSSのコンフィグに反映させました。
その際気をつけたことは意味を持たない命名にすることです。
例えば、グレーという色。
デザイナー間ではコミュニケーションを取りやすくするために「背景色に使うグレー」、「非活性要素に用いるグレー」など利用して良い箇所を限定するような名前がついてますが、コンフィグにはgray-80、gray-20と定義しています。
将来、disabled-1、disabled-2のようなデザインシステムの使い手に混乱を与えるトークンが作られないようにするためです。
ただ、エンジニアが別の名前を暗黙的に使ってしまうとデザインシステムが達成したい『デザイナーとエンジニアのコラボレーションによる開発生産性の向上』に悪影響ですので、デザイナーさんに相談しfigmaで両方確認できるようにしていただきました。
コンポーネントの実装・置き換え
ボタンやフォームなどのコンポーネントを使い回せるよう、共通コンポーネント用のディレクトリを切ってそこで実装を進めました。
その際以下2点のことに気を付けました。
- 自プロダクト特有の事情が共通コンポーネントに漏れ出さないこと
- 今回追加する画面以外のことを考慮して作り込みすぎないこと
前者は共通コンポーネントをプロダクトリポジトリ外で管理するように変更した際の置き換え負担を軽減させるためです。
後者はやることが大きくなりすぎて何も手がつけられなくなる状態や工数肥大化を避けるためです。また、早すぎる抽象化で結局利用時に手直しが必要になるといった事態も避けたかったためです。
抽象化し過ぎず、でも個別具体に踏み込み過ぎないバランス感覚を求められる実装はエンジニアとしての腕を問われているようでやりがいがありました。
上記を約1ヶ月で完了させ、その後の画面追加でも都度必要最小限で共通コンポーネントを拡充させていきました。4,5ヶ月も経つとかなり共通コンポーネントも増え、ページ上でコンポーネントを組み合わせるだけでレイアウトが完成する場面も増えてきました。
デザインシステム導入の効果
今までの開発は、
デザイナー 「（Figmaを見せつつ、）このデザインで作れますか？」 エンジニア「UIフレームワーク依存なので、一旦それっぽく実装してみます」 ~数日後~ エンジニア「出来ました」 デザイナー「余白はXXにして欲しいです。ここの色は〇〇に出来ませんか？」 エンジニア「色は出来そうです！余白は厳しいかも」 デザイナー「(´-ω-`)」 エンジニア「(´-ω-`)」
といった感じで、なんともツールに振り回されてる感が強い話題が必ず発生し、デザイナーさんのこだわりをそのままプロダクトに反映できず口惜しく感じることも少なくなかったです。
それが今ではFigma上に定義されているデザイントークンと同じものを指定するだけでそっくりそのまま同じものが出来上がるようになり、UIの微調整から解放されたエンジニアは実際のデータを元に改修対象前後のフローも考慮した最初のテスターのように振る舞う余裕が出てきました。
下記のような、デザイナーさん一人に丸投げせずチームで「このUIはユーザにとって使いやすいものだっけ？」の議論が出来ています。
デザイナー コンポーネントをReady for devにする。 エンジニア dev modeのインスペクト見ながらバリアブルの名前をそのままclassNameに与えつつ実装を進める。 エンジニア「登録ボタン押下時に未完成状態でも『完了しました』と表示されると誤解を招かない？『保存しました』にしません？」 デザイナー「そのとおりですね！！」 エンジニア「(｀･ω･´)b」 デザイナー「(｀･ω･´)b」
また、Figmaと同じデザイントークンを指定するだけで良いということもあって、Figma MCPによりAIで多くのコンポーネントを自動生成できるようになり工数の削減につながったのも嬉しい誤算です。
今抱えている課題
いちごさんの働きかけにより、デザインシステムに賛同してくださるチームが増えてきておりますが、Figma上でのみ共通のコンポーネントを参照しており、それを実装したボタンやフォームなどは各プロダクトのリポジトリに散り散りになっているのが現状です。
この現状が抱える課題としては、『デザインシステムの改善がやりづらくなってしまうこと』が一つ挙げられます。
デザインシステムを十分機能させるためにはSingle Source of Truth*1の状態にする必要がありますが、情報源を一つにするには抽象化が不可欠で、抽象度を上げるうえで共通化のステップは重要な役割を担っています。共通化の過程における衝突や議論が質の高い抽象化を生み出すからです。
デザイナー間ではそれが出来ているものの、エンジニア間で出来ていない現状は、将来「プロダクトAの実装の都合上、デザインシステムの変更に賛同・追従できません。」といったデザインシステムの本来目的である『ユーザの使いやすさ』や『ブランドイメージの統一』とかけ離れた意思決定を招きかねません。
また、共通化出来るコンポーネントに対し各チーム別々で工数をかけてしまっているのももったいないです。
そのため、弊社では有志で共通コンポーネントを提供するライブラリの開発に着手し始めていますが、皆他プロジェクトとの兼任であるため中々思うように進んでいない実情もあります。
終わりに
弊社のデザインシステムは今まさに正念場を迎えています！ここで改善のサイクルを回せなければそのまま尻すぼみで新たな負債となる未来もありえます。ただ、デザインシステム導入を推し進める土台は出来上がっています。
デザインシステムが文化になるか負債になるか、この苦境を一緒に楽しんでくださるデザイナー・エンジニアを募集しております。
we are hiring !! sencorp.co.jp
明日はInabassさんです！
*1:情報の矛盾や重複を防ぐため、参照先が一つにまとまっていること
