🪄
【イベントレポート】なぜ今必要？Figma×SmartHR×DMM.com×一休 エンジニア視点で考えるデザインシステム
公開
2025-02-19
文章量
約4859字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
2025年1月23日、エンジニア向けサービス「Offers」が主催するオンラインイベント「なぜ今必要？Figma×SmartHR×DMM.com×一休 エンジニア視点で考えるデザインシステム」が開催されました。
近年、UI/UXの統一や開発効率向上、デザインとエンジニアリングの協業を円滑にする手段として注目される“デザインシステム”。
しかし、実務で運用していく上では「具体的にどう始めるか」「エンジニアにはどんなメリットがあるのか」など、まだ不透明な部分も多いのではないでしょうか。
本イベントは、デザインシステム活用の一線で活躍する Figma Japan, SmartHR, DMM.com, 一休 の4社が集結。デザインシステムの「今」と「これから」を、エンジニア目線で解き明かす貴重な内容となりました。
【基調講演】Figmaで効率化するデザインシステム開発と運用（谷 拓樹氏）
はじめに Figma Japan アドボケートの谷氏より、Figmaが提供するデザインシステム関連機能の概説がありました。
- Variable / Components / Documentation
- ローカルバリアブル（Variable）により、色やタイポグラフィなどの“デザイントークン”を一元管理できる。
- 「コンポーネント・プロパティ」「バリアント」といった機能を活用すれば、ボタンやカードなどのUIバリエーションをスムーズにデザインし、かつ開発者にも意図を伝えやすくなる。
- ドキュメント機能を駆使して、コンポーネントごとの用途・リンクなどをフィグマ上で表示し、チームメンバーがすぐ参照できる。
- コードコネクト
- Figma上のコンポーネントと実装コードを関連付け、コンポーネント選択時にリアクトなどのコードスニペットを表示できる先進機能。
- 開発時のミスや重複を減らし、エンジニア・デザイナー間の齟齬を解消する効果が期待できる。
谷氏は「Figmaの機能すべてをフルに使う必要はなく、自社のデザインシステムの成熟度や目的に合わせて選択・導入してほしい」と強調。各社のフェーズや課題に応じた取り組みが、結果的にデザインシステムの成功につながると述べました。
【LT①】エンジニア主導でデザインシステムを導入してみた（矢澤 明佳氏）
一休が展開する飲食店向けSaaS「レス在庫」では、3つのプロダクトが並行して開発・運用されてきたが、UI/UXの不統一やデザイナー1名への過度な依存など、さまざまな課題が顕在化。
そこでエンジニア主導でデザインシステムの導入に踏み切った事例が紹介されました。
- 導入の動機
- デザインレビューが毎回必要になり、スピード感が落ちる
- プロダクト横断でUIの共通化ができず操作に違和感
- デザイン品質が担保されない
- 実践プロセス
- スマートHR「小さく始めるデザインシステム」を参考に、目的・コンセプトを明確化
- 構成要素（デザイントークン、コンポーネント、デザインルールなど）を厳選して先に着手
- フィグマ上でトークンやコンポーネントを作成・定義し、デザイナーと週1ミーティングで合意形成
- 導入後の変化
- 「コンポーネントの使い方が決まっているから、いちいちデザイナーに聞かなくてもよい」という効率化
- 「デザイナーとエンジニアのコミュニケーションがテキストベースで完結する範囲が増え、レイアウト崩れ等の認識齟齬が減った」
- エンジニア主体でもデザインを推進できる実感を得た
とはいえ「パッケージ化がまだで、プロダクト毎にコピペ実装状態」「切り替えコストはかかる」などの課題も。
矢澤氏は「今後も運用しながら、各プロダクト間の統一と開発効率の両立を深めたい」と展望を語りました。
【LT②】DMM .comでの Figma を活用したデザインシステム開発と情報の一元化（高井 実氏）
事業数が60以上、従業員5000名規模のDMM.comでは、共通のデザインシステムを推進するチーム「タートル」が活動。彼らが「タートルデザインシステム」を構築・運用するにあたっての具体的な仕組みを紹介しました。
- デザイントークンの一元管理
- スプレッドシート上でカラーやフォントなどのトークンを定義 → JSON出力で各リソース（フィグマ、実装、ドキュメント）へ自動反映
- フィグマには標準でJSONインポート機能がないため、プラグインを自作して取り込む
- ドキュメントの一元化
- 以前はConfluenceとストーリーブックが混在していたが、ストーリーブック(MDX)に集約することで「見た目＋ドキュメント」を同じUIで確認
- 結果、エンジニアが学ぶべきリソースを一本化し、運用負荷を軽減
- Figma コードコネクト
- Figmaのコンポーネントに「リアクトの実装コード」を紐づけ、右パネルでスニペットを表示
- 「Figmaでデザインを確認したら、すぐリアクトのコードがコピーできる」状態を実現し、全事業チームのUI実装を効率化
高井氏は「未完成の部分も多いが、まずはエンジニアが“活用したい”と思うレベルの価値を届けていくのが大事」と強調。
今後はビジュアルリグレッションテスト等の保守体制とも組み合わせ、さらに開発者体験を向上させる狙いだと話しました。
【LT③】活きたデザインシステムに必要なたった一つのこと（uknmr氏）
5年以上前から「SmartHR UI」を軸にデザインシステムを展開してきたSmartHR。
プロダクトデザイナー兼“コンポーネントの中の人”として活動するuknmr氏からは、原理原則の視点で「デザインシステムを生かすために必要な考え方」が語られました。
- デザインシステムという言葉に惑わされない
- そもそも“デザイン”や“システム”が曖昧で解釈ずれを招きやすい。自社が本当にやるべきは「色のガイドライン」や「開発効率アップ」のように、もっと具体的な言葉を使うべき
- 構成要素を埋めに行かない
- 他社のデザインシステムをまねして「トークン」「コンポーネント」「ガイドライン」などを形だけ揃えても意味がない
- “何を解決するのか”という目的や組織のコンテキストに合った要素を選び、ルールでなく“ガイドライン”として柔軟に活用する
- 成果を第一に考える
- 開発者にとってメリットを実感できないと使われず死蔵してしまう。
- 小さい成功体験を積み重ね、チームの生産性アップや品質向上につなげることで「生きたデザインシステム」へと育てる
uknmr氏は「デザインシステムを推進する個人の情熱や専門性は大事だが、最終的には自社プロダクトの成果に寄与することが鍵。“活きた”システムとして運用し続けるには、本質的な目的意識と検証が欠かせない」とまとめました。
ディスカッション & Q&A
1. エンジニア目線で恩恵を感じたのはいつ？
- 一休 (矢澤氏)
- デザイナーに確認せずとも“決まったコンポーネント”を使えば一定のデザイン品質が担保されるように。コミュニケーションコストが下がり、開発速度が上がった。
- DMM.com (高井氏)
- セキュリティ/アクセシビリティといった“非機能要件”をコンポーネント側に組み込めるのが大きい。専門知識がないエンジニアでも一定以上の品質を保てる。
- SmartHR (uknmr氏)
- ボタン・余白設定など細かなUI要素を気にする時間が減り、プロダクトの本質的な部分に集中できるようになった。
2. デザイナーとのやりとりで困ったことは？
- SmartHR (uknmr氏)
- 組織が大きくなるにつれ、各プロダクトで発生する課題を中央のデザインシステムに還元する仕組みが必要。早く動きたいプロダクトがローカル対応で済ませがちになるリスクも。
- DMM.com (高井氏)
- デザインと実装を厳密に100%合わせ込むには手間がかかるが、基本は“ガイドライン”と捉え、柔軟に改変できる余地を残している。
- 一休 (矢澤氏)
- エンジニア主導で導入したため、フィグマ操作を習得しつつデザイナーに助言を仰ぐプロセスに苦労。ただし週1の連携で徐々に習熟度が上がり、双方のすり合わせも円滑化した。
3. デザインシステムはいつから？何から始める？
- 一休
- チーム内に課題感が高まり始めたタイミング（UIがバラバラで開発効率が落ちたなど）で着手。まずは“目的（なぜ作るのか）”を明確にし、デザイントークン等から小さく導入。
- DMM.com
- 大規模事業が多いため、一気に完成形を作るのではなく「少しずつ作り、少しずつ使ってもらう」を繰り返すアジャイルアプローチ。
- SmartHR
- 市場にフィットし、組織が人やコストを割ける段階で自然に生まれるケースが多い。どのフェーズでも、まずは“デザイントークン”の整備がコスパよい。
4. 俗人化しがちでは？どう防ぐ？
- 一休
- 現状、実質的にエンジニア1～2名がメイン運用しており、対応が偏り気味。今後はリポジトリを整え、他のチームメンバーも巻き込みやすくする予定。
- SmartHR
- 俗人化を悪としすぎず、熱量や専門性を発揮する“個”が推進力になる面もある。最終的に成果物が誰でも使える形に整っていれば問題ない。
- DMM.com
- デザインシステム開発を専任チームで進めているが、メンバー全員が運用を把握できる体制にしており、特定個人の退職でも支障が出ないよう配慮。
まとめ
本イベントでは、Figmaによる最先端のデザインシステム構築機能から、エンジニア主導で導入してみたリアルな事例、運用で直面する課題や効果検証まで幅広く議論されました。
- Figma Japan（谷氏）:デザイントークンやドキュメント機能、コードコネクトなど、Figmaが提供する多彩な機能の概要を紹介。「すべてをフル活用するより、自社のフェーズ・目的に合った機能を選ぶのが大切」とアドバイス。
- 一休（矢澤氏）:飲食店支援SaaS「レス在庫」で、エンジニアがデザインシステム導入を推進したユニークな事例。最初は「小さくスタート」し、週1のデザイナー協業でコンポーネントやルールを整備。動き出しだけでも大きな効率化を実感。
- DMM.com（高井氏）:多事業を支えるデザインシステムチーム「タートル」が、トークンをスプレッドシートで一元管理 → JSON出力 → フィグマ/実装/ドキュメントへ反映、さらにコードコネクトを駆使してUI実装を効率化。「まずは作りながら、使いながら」で運用の輪を広げている。
- SmartHR（uknmr氏）:デザインシステム歴5年以上の観点から、「構成要素を形だけまねても意味がない。自社の本質的な課題と目的を見極め、小さな成功体験を積むことが“生きた運用”につながる」と力説。
「デザインシステムはゴールではなく、プロダクトの品質や開発者体験向上のための手段」というメッセージは、4社共通で強く打ち出された印象です。
チームのコンテキストや課題にしっかり向き合い、メリットを共有しながら少しずつ進めることこそが、生きたデザインシステムのカギと言えるでしょう。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
