プロダクトリニューアルと同時に進める初めてのデザインシステム

プロダクトリニューアルと同時に進める初めてのデザインシステム 2025年07月04日 ※本資料は2025年07月時点の情報です v1.0.2

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. 自己紹介
2 #フロントエンドエンジニア #React #UI設計 #家族持ち #飼犬有 #お酒 #ギター #バンド #DIY #アニメ #ゲーム #SF大好き所属在籍期間主な業務内容パーソルキャリア 2024年1月～（約1年半） - Webフロントエンド開発 - dodaダイレクトのリニューアル（DB含むリアーキテクチャ） - プロダクト横断でのデザイン整備プロジェクト（今月より参画）スタートアップベンチャー約10年 - Webフロントエンド開発 - iPhone / Android アプリ開発 - サーバーサイド・インフラ（AWS）少々ソーシャルゲーム開発会社 2年 - Webフロントエンド開発 - Flasher（今は亡きFlash(´;ω;｀)）ニ◦動のグループ会社的な所 4年 - Webフロントエンド開発 - Flasher（今は亡きFlash(´;ω;｀)）それ以前不明 - ウェブデザイナー～ディレクター（UI設計） - HTMLコーダーとして大学卒業後からWeb分野で経験蓄積 T氏パーソルキャリア株式会社リードエンジニア（フロントエンドエンジニア）名前：T氏年齢：43歳経歴：ここ最近はWebフロントエンド中心にやってます

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. 社
名本社創業資本金事業内容従業員数パーソルキャリア株式会社東京都港区 1989年6月 1,127百万円人材紹介サービス、求人メディアの運営、転職・就職支援、採用・経営支援、副業・兼業・フリーランス支援サービスの提供 7,048名（有期社員含むグループ会社出向中の者は除く 2025年3月1日時点）会社概要 3

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. サービス概要
4

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. 前提
導入背景どれくらい導入できてるの？本題/導入にあたって悩んだ（でいる）ところ4選 SUMMARY 5 • UIコンポーネントライブラリベース vs 自作 • 複数プロダクトでの導入 • コンポーネントの配布方法 • 改善点/汎用化ポイントたくさん今後

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. 6
前提

前提 • デザインシステムを今まさに構築/導入中で、その導入過程の話がメインとなります。 • 組織 • 開発環境や開発者スキルセットなどこれを機にプロダクト間で共有中 • UIフレームワーク/UIライブラリなどプロダクトごとにけっこうバラバラのようだ • バックエンドメインの方がフロントエンド部分の実装を行っているところが多そう（フロントエンド専任のエンジニアはあまりいない） • 人員の入れ替わり（プロジェクト間での移動）は多めな印象。キャッチアップコストに配慮する必要あり • 組織や事情が異なるとデザインシステムに求められる解も変わってくる • デザインシステムについてある程度知っている方向けのイベントとうことで、用語や概念などの細かい説明は省きます • 本プレゼン内では、便宜上 React のことを「フロントエンドフレームワーク」と呼びます。

導入背景

導入背景 • バックエンドもフロントエンドも負債が積み重なり、事業継続性や事業スケールに支障が大きいということで大規模なプロダクトリニューアル（リアーキテクチャ）中。その流れで導入していました。画面数30程度企業が直接転職希望者をスカウトするサービス React旧 React新 C#サーバサイドレンダリング Atoms Molecules Organs Atoms Molecules Organs 独自のUIパーツ群

導入背景 • デザインルール、コンポーネントの使用ルールを明確化して開発（運用）効率/品質向上を狙うにあたり「デザインシステム」という考え方が良さそう • 1プロダクトで始めて、開発効率/品質向上が確認できたら他プロダクトへの展開をもくろむ • しかしリリース前に、複数プロダクト間でのデザインシステム一貫化プロジェクトが発足 dodaダイレクトで作ってきたものをベースにしつつ横展開する方向に（もくろみどおり！）小話 • 「デザインシステム」という言葉を業界でよく聞くようになったのは2015年過ぎ頃？セールスフォースがLightning Design Systemを発表したあたり？ • 2006年ごろから、CSS/HTMLをセットにしたパーツ（クロスブラウザ対策）、レイアウトルールを組み合わせて効率的な運用が行われており、デザインシステムってそれに似てるな、導入したら色々向上しそうだなと。。。 • そもそもWindowsアプリのWin32 UIなど、似た考えはもっと昔からある

どれくらい導入できてるの？

どれくらい導入できてるの？ ◎大体できてる • デザインガイドライン • デザイントークン • 汎用的なUIコンポーネント群 • Storybookで一覧化＆ドキュメンティング ×できてない/検討中 • デザインシステムの運用体制 • ポータビリティの確立 • 複数プロダクトで使用時の考慮 • 絶賛導入中でまだリリースには至っていない状態でした

導入背景皆さんの組織ではどうしてますか？チャットに番号を投稿して教えてくれると嬉しいです 1. 1つのプロダクトのみで利用している 2. 複数のプロダクトで利用している 3. 1つのプロダクトのみで利用しているが今後の横展開/共通化を考えている 4. 導入中、検討中

本題

本題複数プロダクト向けデザインシステムを構築＆導入していく際の、悩みや方針決めにかかわるアレコレを着飾らずお話しできればと思います気になった話題があればチャットで気軽に発言いただけますと！

本題デザインシステム導入運用経験のあるベテランの方々、アドバイスください • 「こんなことで悩んでるの？」こうすれば良いと思いますよ • 今ならまだ引き返せる、その方針はやめとけ • 似た方針でやってるけどうまく機能してるよこれから導入＆導入検討中の方々、導入していく際の参考になれば嬉しいです • こんなこと検討する必要があるのか（気づき） • うちで導入する場合はどうだろ？（検討の種） • こんな場合はどうですか（質問） • 御覧の皆様、こんな感じで気軽にチャットに書き込みつつ聞いていただけると嬉しいです

導入にあたって悩んだ（でいる）ところ4選

【その1】UIコンポーネントライブラリベース vs 自作

UIコンポーネントライブラリベース vs 自作皆さんの組織ではどうしてますか？チャットに番号を投稿して教えてくれると嬉しいです 1. ライブラリベース（Themaでカスタム） 2. ライブラリベース（ヘッドレス） 3. 自作

UIコンポーネントライブラリベース vs 自作自作ライブラリベース（MUI、ヘッドレスUIなど）メリット・自分たちでルールを策定できる・ライブラリの流行りに依存しない・組織の都合を反映させやすい・初期設計・実装コストの節約・充実したエコシステム（マニュアル等）デメリット・初期設計・実装コスト・諸々考慮し設計する知識と技術力・作法に則ってカスタムしないと、アプデ時に大変・Thema使わずゴリゴリDOMカスタム・ラップして魔改造・ライブラリ＆依存パッケージと一蓮托生すぎる・利用シーンまで明記されていないのでそこは別途策定する必要ありエンジニア/デザイナー双方がベースにするUIライブラリの設計思想を理解して活かす、これができるならライブラリベースもOK。我を出そうとして一部しか理解しないままカスタムし破綻していく経験多い特にこだわらずデフォルト状態のbootstrapで作られた社内ツールなどはアプデや運用を長年続けても破綻しにくい結論（まだ組織的に合意ができたわけではなく、この方向で進めていきたいという意味）壮大なものは作らず、ミニマムで自作していく。その分、デザインルールや各UIコンポーネントの使用ルールを明確にする。

UIコンポーネントライブラリベース vs 自作その他 • 当初は MantineUIをベースに開発を進めていたが、メリットよりデメリットの方が大きくなってきたので自作に変えた • 特定のUIフレームワークに依存しないwebComponentも検討。Reactから使いにくいので見送り。 • プロパティにstringしか設定できない点と、コード補完関連が使いにくい • あまり普及しておらず、相応して問題点も多かった • webComponent使ってうまく運用できている方いたらぜひチャットで教えてください！ • 評判を耳にするshadcn/uiも検討。フロントエンド（特にHTML/CSS設計周りが得意な）人材が薄いので tailwindベースのこれは使わない方針。 • tailwindはしっかり理解して、作法に則って利用しないとひどいことになる経験 • フロントエンド専任エンジニアが多くない組織なので、難しいことは極力避ける

【その2】複数プロダクトでの導入

複数プロダクトでの導入 • プロダクトごとに開発環境が違う（使用するUIフレームワーク等） • 情報量（密度）、デザインテイスト、レイアウトルールが違う • デザインシステムとして何をどこまで共有したら良い？プロダクトA プロダクトB ・React ・CSS Modules ・CSHTML （C#のUIライブラリ）・Angular ・Angular Material ・Tailwind

複数プロダクトでの導入 • コアとなるパーツのみをデザインシステムとして共有 • レイアウトルールは含めない（プロダクトごとで策定） ※段階導入を考慮

複数プロダクトでの導入結論以下の各ケースを考慮し、導入しやすいように設計していこうと考えてます・デザインルールだけ導入するプロダクト・デザインルールとコンポーネントを合わせて導入するプロダクト・稼働中のものに↑を段階導入していくプロダクト・プロダクトリニューアル＆一気に導入

複数プロダクトでの導入結論 • デザインシステム使用先では、カラーテーブル以外のデザインカスタムは行わないなどの縛り作り、統一感が損なわれないように配慮。 • 汎用性だけを考慮すればOK、というものではなさそうこれ↑を行わないと「各プロダクトで特定のUIライブラリを自由にカスタムして使ってね」と同じことになる。各所で独自カスタムが行われデザインシステムのメリットの多くが損なわれる

【その3】コンポーネントの配布方法

コンポーネントの配布方法 npmパッケージソースコード直接配布メリット・バージョン管理とアップデートが簡単・カスタムしやすい・ソースをもとに別フレームワーク用に書き換えたりなどデメリット・Theming機能など複雑化・同じフロントエンドフレームワークであることが前提・派生バージョンがどんどん生まれて、全体のバージョン管理が難しくなる・npmパッケージ（npm installして利用） / ソースコード直接配布

コンポーネントの配布方法皆さんの組織ではどうしてますか？チャットに番号を投稿して教えてくれると嬉しいです 1. npmパッケージ 2. ソースコード直接配布 3. その他（どうやってるか概要も教えていただけますと）

コンポーネントの配布方法結論 • 悩ましい。まだ結論は出ていないがおそらくソースコード直接配布で進める？ • 各所ヒアリング＆事例などをさらに調べながら模索していく。

【その4】改善点/汎用化ポイントたくさん

改善点/汎用化ポイントたくさん（デザイントークン周り） • トークン名と実態があってない箇所が多い（装飾目的で使用しセマンティクスが生きていない）要改善 • セマンティックトークン名/体系を整理 • 体系化が難しい場合、セマンティックトークン使用にこだわらない • 誤解を生まぬよう名称と実態の不一致を避けることを優先 • これを気にするエンジニアは多い

改善点/汎用化ポイントたくさん（デザイントークン周り） $color-primary: #1765bdff; $color-primary-5: #e3f2fdff; $color-primary-10: #bbdefaff; $color-primary-20: #91caf7ff; $color-primary-30: #66b5f4ff; $color-primary-40: #45a5f2ff; $color-primary-50: #2696f0ff; $color-primary-60: #2288e2ff; $color-primary-70: #1c76cfff; $color-primary-80: #1765bdff; $color-primary-90: #1155adff; $color-primary-100: #0e489eff; • デフォルトで使用されるデザイントークンの帯域に遊びが無い • default（通常） : $color-primary-80 • hover（オンマウス） : $color-primary-90 • active（押込） : $color-primary-100 デフォルトで使用する帯域を60-80にするなど、遊びを持たせる要改善

改善点/汎用化ポイントたくさん（デザイントークン周り） • 単位 • rem使うケース結構多そうだが、Figmaが対応してない（今のところpxで指定してる） • pxですすめる？実装時にremに変換するルールを作る？ • サイズ $font-size-x-small: 10px; $font-size-small: 12px; $font-size-medium: 14px; $font-size-large: 16px; $font-size-x-small: $font-size-small * 0.8; $font-size-small: $font-size-medium * 0.8; $font-size-medium: 14px; $font-size-large: $font-size-medium / 0.8; VS 昔からよくある設定方法一定倍率で大きさが変わっていく（実数でスタイル指定しない場合は、少数になっても問題ないという考え）意図を共有した上で決める

改善点/汎用化ポイントたくさん（デザイントークン周り） • サイズ（相対？絶対？）意図を共有した上で決めるボタンボタン font-size: 14px; padding: 8px 24px; （今はこっち） font-size: 1rem; padding: 0.5rem 2rem; 皆さんの組織ではどうしてますか？チャットに番号を投稿して教えてくれると嬉しいです 1. 絶対 2. 相対 3.その他（どうやってるか概要も教えていただけますと）

改善点/汎用化ポイントたくさん（デザイントークン周り）デザイントークンの整理、責務決め • デザインシステム内のみで使用するローカルトークン（コンポーネントトークン） • ウェブサイト全体で使用するグローバルトークン • グローバルトークンの体系もデザインシステム側で規定するかどうか • 段階導入する際に、現行版ルールとの不一致を懸念 • それぞれの責務を明確に定義し、実装に落とし込む検討し整理を進める

改善点/汎用化ポイントたくさん（デザイントークン周り）カラー操作のユーティリティ欲しい（色々応用がきいて便利） • 「$color-primary-80: #1765bd;」 <= これの1段階下のカラーコードを取得するsass関数/typescript関数などのユーティリティ≒scss lighten, darken • 色々な面で実装をシンプルにできる • その場限りのカラー指定ボタン作成時 • Chipなど色のバリエーションが多くなりやすいパーツのインタラクション制御時要検討

改善点/汎用化ポイントたくさん（レイアウト周り） • 極力余分なスタイル指定なしで、きれいなレイアウトが組めるように • レイアウト時のオプションが増えてくると管理が難しくなる Mantine （UIライブラリ）揃ってるがちゃつく意図を共有した上で方針決める

改善点/汎用化ポイントたくさん（実機の動作を考慮。スマホは考慮するか） • スマホでの使用時、入力フォームにフォーカスが合った時に画面が拡大されるのを避けるため、テキスト入力フォームの文字サイズを16pxにするケースは結構よくあるお名前山田太郎送信意図を共有した上で方針決める • そもそもスマホをターゲットとするかも決めなくては

Hot Information! （旬な情報）

旬な情報 • 目的を明確化しプロダクト間で共有、理解してもらう • ただ単にデザインリソースを統一し、「効率化を図る」だけを目的にしてしまうと部分最適されたプロダクトごとのUIをAI駆動開発で爆速で作るだけで良くなってしまう • 共通化の必要性をしっかりとかかげて、関わる人にビジョンや成果物に納得してもらいながら進めることが重要そうプロダクトプロダクトプロダクトプロダクト・ビジョン・ビジュアルによるブランディング・その他目的デザインシステム効率化は副産物本日、参加者が多めのMTGの場でこの登壇のことを宣伝したのですが、、、

今後

今後 • AI駆動開発を視野に、そのベースとなるように • 人間にもAIにも分かりやすい明瞭なルール • MCPサーバ化を見越したドキュメンティング • 違うUIフレームワーク用のコンポーネントへのコンバートなども可能性あり？企画の人がvibe codingでUI実装まで行ってる事例なども、現時点でちょいちょい聞きます。UIからむところはまだちょっと弱め？しかしながらAI駆動開発は1~2年でかなり一般化すると思うのでそれに備えるデザインレイアウト Figma MCP server UIコンポーネント Storybook MCP Server デザインガイドライン Confuluence API AI的なもの Copilot, Cursor, Devin等

今後 • 次回（があれば）これらを経てどのようなシステムが完成したのか、実際にできた現物を紹介しつつ • 導入で得れたメリット • 実際使ってみたらうまくいかなかった点/要改善点などをお話しできればと思います

今回のお話が皆様方のデザインシステムの導入にあたって少しでもヒントになれば嬉しいです

最後に日々悩みつつ導入/構築を進めています。アドバイス、もっと話聞きたい、その他お気軽にご連絡ください https://member.techstreet.jp/m/contact （tech street窓口に連絡すると私につないでくれます）ご清聴ありがとうございました！

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. さまざまなテーマで事例や知見を学ぶ
IT・テクノロジー人材のための勉強会コミュニティ「TECH Street」でも当社の事例を公開しています。「techtekt（テックテクト）」は、パーソルキャリアのエンジニアブログです。 “みんなの「はたらく」をテックでつくる”をコンセプトに、技術、組織、学びなど、さまざまな情報を発信しています。エンジニアブログのご紹介 47

プロダクトリニューアルと同時に進める初めてのデザインシステム

プロダクトリニューアルと同時に進める初めてのデザインシステム

More Decks by PERSOL CAREER Dev | techtekt

Other Decks in Design

Featured

Transcript