バックエンドエンジニアがデザインシステムを導入してみた話 #PERSOL CAREER Advent Calendar2025

 

皆さんこんにちは、テクノロジー統括部プロダクト開発1部法人サービスアプリ刷新グループの佐藤です。法人企業様にご利用いただいている、弊社採用管理システムの「doda CONNECT」にデザインシステムを導入したので本記事に取り組み内容を記載していこうと思います。

 

 

体制

PoCから開始したので、当初は以下の体制で進めました。
デザイナー:1名
エンジニア:1名

現在は、継続開発のスクラムチームに引き継いで運用してもらっています。

デザインシステムとは?

デザインシステムって聞きなれない…という方もいらっしゃるかもしれないので触れておきます。
デザインシステムとは、Webサイトやアプリなどのプロダクトのデザインと開発を効率化し、一貫性を保つための仕組みです。

システムと言っておりますが、何か特定のシステムやツールの指すわけではなく、ガイドラインやツール、コンポーネントなどの色々な要素を含んだ集合体をデザインシステムと呼びます。

デザインの一貫性を保つための「フレームワーク」と解釈していただいた方がイメージしていただきやすいかもしれません。

デザインシステム
ガイドライン
UIコンポーネント
ツール

ここで言う、ガイドラインは、デザイン原則・スタイルガイド・デザイン&ライティングガイドラインなどの指標となる情報。ツールは、Figmaなどのデザインツール・開発の技術的な要素。コンポーネントは、上記を前提として作成された実際の画面部品パーツや使い方を記したコンポーネント集ページ(StoryBookなど)となります。

デザインシステムの目的

一貫性のあるユーザー体験を提供する

ルールが未整備のままプロダクトを成長させると、デザイナー・エンジニアの各メンバーがそれぞれの見解や判断で、新たな機能や画面を作成せざるを得ず、見た目やソースコードがバラバラになるリスクが高まります。

デザインシステムを使うと、どの画面でも同じルールやスタイル、ソースコードが適用されるため、ユーザーに対して一貫性のあるユーザ体験を提供できます。


デザインと開発の効率を向上させる

毎回ゼロからデザイン・ソースコードを書くではなく、用意されたコンポーネントやデザイントークンを利用することで、作業時間を大幅に短縮できます。​

 

チーム全体の連携を強化する​

弊社では、デザインシステムはデザイナー・エンジニア・ディレクターといった、異なる職種間でスムーズに連携するための、「共通言語」であると表現しています。これにより、コミュニケーションロスや認識のズレを減らすことができます。​


例えば、主要なボタンはdoda CONNECTでは、青色となっておりますが、
Button コンポーネントの「Primary Filled」を使いたいとコミュニケーションすることで、
スムーズにやり取りできます。
※Primary(主要カラーの青)でFilled(塗られている)のイメージです。

発生していた課題

前述した、目的と逆のことを記載する形となりますが、一貫性・効率・チーム連携全てにおいて、課題がありました。
以下は、「エンジニアが製造 ⇒ 画面成果物をデザイナーがデザインレビュー」した際に、実際に発生していたの指摘コメントの抜粋です。

デザインの不一致に関する課題

・テキストボックスエラー時の赤色がFigmaと違う
・黒のテキスト系が#333333じゃない、文字のカラーがFigmaと違う
・文字サイズが違う


レイアウトとマージンに関する課題

・テキストと要素のmarginが狭い、margin誤り


インタラクションとホバー効果に関する課題

・ボタンにホバーした時にカーソルが指にならない
・ボタンホバー時の色が変わらない


他のケースの課題

デザイナーがデザインを単純に誤るケース

以前デザインしてもらった内容とカラーコードなどが異なる場合があり、エンジニアが都度確認しないといけない状況などが発生することがありました。
(最悪の場合は誰も気づかないです…)


同じ見た目の機能を作る際、この画面と一緒で大丈夫!という依頼の仕方

実は同じ見た目でも、カラーコードが微妙に異なっているケースがあり、技術負債を生んでしまっておりました。

 

デザイントークンとは?

「デザインシステムの目的」の部分で、デザイントークンというワードが出てきたので、こちらも触れておきます。

デザイントークンとは、「色や大きさ」といったデザインに関するルールや値を名前として整理することで、デザインやコードを分かりやすく管理するための仕組みです。

例えば、ボタンや背景の色、余白(スペース)、文字のサイズなど、デザインで使うものを決めておくイメージとなります。こうすることで、「どんな色を使うか」「どの部分でどの値を使うか」をルール化して、簡単に再利用したり変更したりできるようになります。

トークンは、プリミティブトークンとセマンティックトークンの2種類があります。説明のトークンの名前は例なので、違和感がある箇所あるかもしれないですがご了承ください。

 

プリミティブトークン:色鉛筆のようなもの

プリミティブトークンは、具体的な色や値を定義したものです。
現実でいうと、たくさん入った色鉛筆を買ってきて、使いたい色にラベリングシールを貼って名前を付けていくイメージです。
プロダクトで言うと、使いたいカラーコードに色の名前を付けていくイメージです。


blue-500:薄い青
blue-300:中間の青
blue-900:濃い青

色鉛筆の画像


セマンティックトークン:名前に意味を持たせるもの

セマンティックトークンは、プリミティブトークン(具体的な色や値)に「意味」や「役割」を与えたものです。
例えば、ヘッダー背景色、フッター背景色、コンテンツ背景色という役割の名前を付けて、プリミティブトークンを代入して利用します。

セマンティックトークン(役割) プリミティブトークン
color-background-header blue-900:濃い青
color-background-content blue-500:薄い青
color-background-footer blue-300:中間の青

役割毎にセマンティックトークンを用意して設計しておくことで
例えば、ブランディングカラーが変更になり、プロダクト全体のカラーも変更したいといった、要望にもスムーズに対応することができます。

デザインとソースコードの連携

デザイントークンはデザインツールとソースコード連携して利用します。
弊社だと、FigmaとScssで連携して、Scssファイルをコンポーネントファイルから読み込んでいます。

ツール構成の画像

今回のスコープ

今回取組んだ箇所のスコープです。デザインシステムと一緒によくアトミックデザインの話があがりますが、今回のスコープは、原子(Atoms)・分子(Molecules)までとしました。

原子(Atoms)
分子(Molecules)
有機体(Organisms)
テンプレート(Templates)
ページ(Pages)

バックエンドエンジニアとして、どのように進めたのか

前置きが長くなりましたが、主要なタスクについて記載します。
バックエンドエンジニアとしてのキャリアがメインだったので、デザインシステムって何ですか…?という状態からスタートしました。

デザインシステムを提案いただいたデザイン部署の方に、前述した部分や、フロントエンドエンジニアのアサインができなかったので、Scssやコンポーネント化を実現するフレームワーク等の情報を随時キャッチアップしつつ、以下のように進めていきました。

念のため、デザイナーのタスクも記載しておきます。

エンジニア

  • デザインシステムのキャッチアップ
  • Scssやコンポーネント化を実現するフレームワーク等の情報キャッチアップ
  • 課題整理
  • ツール、ライブラリ選定、構成検討
  • コンポーネント製造、コンポネント集作成
  • 運用フロー、ルールの整備
  • 継続開発スクラムチームへの展開
  • 効果検証方法(PcCのため)

 

デザイナー

  • インターフェイスインベントリ(既存のデザインパーツの棚卸し​)
  • スタイルガイドの作成
  • スタイルガイドの開発
  • パターンライブラリの作成
  • コンポーネントデザイン作成

上記以外にも、実際に既存画面に適用する際には、単純に適用するなども発生することもありましたが、随時コミュニケーションし、運用が軌道に乗るように調整しました。

PoCの効果検証結果はどうだったのか?

ジャストタイムでデザインリニューアルの案件があったので、
これまでの製造方法と、デザインシステムの製造方法で工程をピックアップして、
作業時間の計測を行いました。

定量の結果については、約1/3まで短縮でき、
定性面に関してはも、以前より実装が楽になった、
また当初出ていたデザインレビューの指摘も入らずに開発がスムーズになることを証明できました。

最後に

デザインシステムは「共通言語」と表現しましたが、チーム全体で育てていくものと認識し、改善していくマインド面も大事になります。一部のメンバーのみが理解しており、作りっぱなしの置物にならないよう注意が必要です。

また、職種毎に個人のミッションも異なってくるので、相互理解も必要です。
時には、ぶつかり合うこともあるかもしれませんが、プロダクトはどの職種が欠けても良いものはできあがりません。
お互いに歩み寄る姿勢も大切だと感じました。

佐藤 直孝 Naotaka Sato

テクノロジー統括部プロダクト開発1部法人サービスアプリ刷新グループ

2022年 中途入社 現在は技術負債改善等をミッションとする品質改善チームに所属

※2025年12月現在の情報です。