※この記事は、2025年7月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
T氏
パーソルキャリア株式会社
リードエンジニア（フロントエンドエンジニア）
Webデザイナー、Webディレクター、HTMLコーダー、Flasherなどを経験しフロントエンドメインのエンジニアに。目に見えるとこ作るのが好き。 2024年2月パーソルキャリア入社。前職は10年ほどファッションテック系ベンチャー企業でWebフロントエンドやスマホアプリの開発を行う。現在はdodaダイレクトのリアーキ（根本の仕組みから作りかえる）プロジェクトに従事。
T氏：私の発表では、「プロダクトリニューアルと同時に進める 初めてのデザインシステム」についてお話しできればと思います。
前提
デザインシステムを今まさに構築／導入中で、その導入過程の話がメインとなります。
＜組織の状況＞
- 開発環境や開発者スキルセットなどこれを機にプロダクト間で共有中
- UIフレームワーク／UIライブラリなど、プロダクトごとにバラバラです
- バックエンドメインの方がフロントエンド部分の実装を行っているところが多そう（フロントエンド専任のエンジニアはあまりいない）
- 人員の入れ替わり（プロジェクト間での移動）が多めな印象。キャッチアップコストに配慮する必要あり
- 組織や事情が異なるとデザインシステムに求められる解も変わってくる
*本プレゼン内では、便宜上 React のことを「フロントエンドフレームワーク」と呼びます。
導入背景/狙い
「dodaダイレクト」というサービスにおいて、バックエンドもフロントエンドも負債が積み重なり、事業継続性や事業スケールに支障が大きいということで大規模なプロダクトリニューアル（リアーキテクチャ）を行っています。その流れでデザインシステムを導入しました。
- デザインルール、コンポーネントの使用ルールを明確化して開発（運用）効率/品質向上を狙うにあたり「デザインシステム」という考え方が良さそうだと考えました。
- 1プロダクトで始めて、開発効率（品質向上が確認できたら他プロダクトへの展開を考えています。
- しかし、リリース前に複数プロダクト間でのデザインシステム一貫化プロジェクトが発足しました。
どれくらい導入できているのか？
「デザインガイドライン」や「デザイントークン」については大体完了していますが、「デザインシステムの運用体制」や「ポータビリティの確立」などについてはこれから対応が必要です。
導入にあたって悩んだ（でいる） ところ4選
【その1】 UIコンポーネント （ライブラリベース vs 自作）
今のところの方針としては、自作の方向で進めています。一番の理由はライブラリベースで作る際に、作法に則ってカスタムしておかないと、アプデ時に大変になるからです。
- 当初は MantineUIをベースに開発を進めていましたが、メリットよりデメリットの方が大きくなってきたので自作に変更しました。
- また、特定のUIフレームワークに依存しないwebComponentも検討しましたが、Reactから使いにくいので見送りました。
- shadcn/uiも検討しましたが、フロントエンド（特にHTML/CSS設計周りが得意な）人材が薄いのでtailwindベースのこれは使わない方針にしました。
【その2】 複数プロダクトでの導入
- プロダクトごとに開発環境が違う（使用するUIフレームワーク等）
- 情報量（密度）、デザインテイスト、レイアウトルールが違う
などの問題がある中で、デザインシステムとして何をどこまで共有したら良いのか、という点で悩みました。
現在のところは、コアとなるパーツのみをデザインシステムとして共有する、という方向で考えています。
結論
以下の各ケースを考慮し、導入しやすいように設計していこうと考えています。
- デザインルールだけ導入するプロダクト
- デザインルールとコンポーネントを合わせて導入するプロダクト
- 稼働中のものに↑を段階導入していくプロダクト
- プロダクトリニューアル&一気に導入
- デザインシステム使用先では、カラーテーブル以外のデザインカスタムは行わないなどの縛り作り、統一感が損なわれないように配慮しました。
- 汎用性だけを考慮すればOK、というものではありません。
【その3】コンポーネントの配布方法
npmパッケージを使うのか、ソースコードを直接配布するのか、それぞれに下図のメリット・デメリットがあり、迷うところだと思います。
まだ結論は出ていないのですが、おそらくソースコード直接配布で進めようと思っています。
【その4】改善点/汎用化ポイントたくさん
要改善点ポイントとして、 デフォルトで使用されるデザイントークンの帯域に遊びが無いこと。
また、サイズの単位として、remを使うのか、もしくはpxを使うのか？など悩みがあります。
デザイントークンの整理、責務決め
・ デザインシステム内のみで使用するローカルトークン（コンポーネントトークン）
・ ウェブサイト全体で使用するグローバルトークン
・ グローバルトークンの体系もデザインシステム側で規定するかどうか
・ 段階導入する際に、現行版ルールとの不一致を悪念
・ それぞれの貢務を明確に定義し、実装に落とし込む
レイアウト周りについても極力余分なスタイル指定なしで、きれいなレイアウトが組めるようにしたいと考えています。
旬な情報
本日、参加者が多めのMTGの場でこの登壇のことを伝したのですが、以下の点が重要だと思いました。
- 目的を明確化しプロダクト間で共有、理解してもらう
- ただ単にデザインリソースを統一し、「効率化を図る」だけを目的にしてしまうと部分最適されたプロダクトごとのUIをAI駆動開発で爆速で作るだけで良くなってしまう
- 共通化の必要性をしっかりとかかげて、関わる人にビジョンや成果物に納得してもらいながら進めることが重要そう
今後
Al駆動開発を視野に、そのベースとなるように以下について、実施したいと考えています。
- 人間にもAIにも分かりやすい明瞭なルール
- MCPサーバ化を見越したドキュメンティング
- 違うUIフレームワーク用のコンポーネントへのコンバートなども可能性あり？
私からの発表は以上となります。
▼▼ ぜひ他登壇者の発表レポートもご覧ください
