---
title: DXエンジニアのためのFigma_デザインシステム活用術
tags: 
author: [Yukiko](https://image.docswell.com/user/yukiko_it)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/G75MN19G74.jpg?width=480
description: DXエンジニアのためのFigma_デザインシステム活用術 by Yukiko
published: October 06, 26
canonical: https://image.docswell.com/s/yukiko_it/KJWYYV-2026-10-06-055548
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/G75MN19G74.jpg)

USAUSA TRAINING WORKSHOP
DXエンジニアのための
Figma × デザインシステム活用術
レガシーと新UIが共存する現場で、デザインシステムを「刷新の武器」として使うために
DXエンジニア・DXコンサルタント向け研修テンプレート


# Page. 2

![Page Image](https://bcdn.docswell.com/page/9J29512DER.jpg)

AGENDA
本日の内容
01
Why：なぜDXエンジニアにデザインシステムが必要か
02
What：レガシー環境特有の成熟度と共存期の見るべき点
03
How：レガシーUIの棚卸しと段階移行の設計
04
How：デザインリテラシーが低い現場での合意形成
05
How：Notion×Figmaでのレガシー互換仕様書
06
よくある落とし穴
07
まとめと次のアクション
DXエンジニアのためのFigma×デザインシステム活用術
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/DEY4KZYMJM.jpg)

WHY
レガシー刷新の現場でデザインシステムが要る理由
UIの一貫性が崩壊している
新旧の両方を説明する必要が
ある
変更の影響範囲が読めない
画面ごとに異なる実装者・時代の
レガシー仕様と新UIの対応関係を
ドキュメント不足のレガシーでは
コードが混在し、基準がない
言語化しないと移行判断ができない
影響調査そのものがリスクになる
デザインシステムは「新規開発の贅沢品」ではなく、レガシー刷新の混乱を減らす共通言語。
DXエンジニアのためのFigma×デザインシステム活用術
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/VJNYR3P378.jpg)

WHY
デザインシステムがDXの速度を左右する
判断の属人化を防ぐ
「ベテランに聞かないとわからない」UI仕様を、Figma上の記録に置き換えられる
段階移行の進捗が見える
どの画面がどのコンポーネントに置き換わったか、参照状況から追跡できる
複数ベンダー・多拠点でもブレない
共通のVariables・Componentsがあれば、誰が作っても同じ基準に収束する
経営層への説明がしやすい
「刷新の進捗」を画面の見た目で示せ、投資判断の材料になる
DXエンジニアのためのFigma×デザインシステム活用術
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/YE9PM93PJ3.jpg)

WHAT
レガシー環境特有の成熟度チェック
確認ポイント
典型的なレガシー状態
目指すべき状態
UI基準の所在
画面・帳票ごとに暗黙知として存在
Figma上のComponentsに一元化
新旧の対応関係
対応表がなく、担当者の記憶に依存
レガシー画面⇄新UIの対応表を整備
変更履歴
改修記録が散在（メール・紙等）
Version HistoryとNotionで一元管理
利用範囲の把握
「誰がどこで使っているか」不明
Dev Mode参照数で影響範囲を可視化
レガシーの「暗黙知」を可視化する作業そのものが、DXプロジェクトの初期フェーズの価値になる。
DXエンジニアのためのFigma×デザインシステム活用術
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GE8DL9MXED.jpg)

WHAT
新旧UI共存期にFigmaで見るべき4点
移行ロードマップ
対応コンポーネント表
どの画面群を、どの順序で新UIへ置き換えるかのページ
レガシー画面の要素と、新しいComponentsの対応関係
構成
一覧
データ互換性の注記
廃止予定のマーキング
新UIが参照するデータ構造が、レガシーDBと整合して
いずれ消す暫定実装に「暫定」ラベルを付け、負債化を
いるかの記録
防ぐ
DXエンジニアのためのFigma×デザインシステム活用術
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/LELMLW3N7R.jpg)

HOW
レガシーUIをFigmaで「棚卸し」する
1
画面キャプチャを撮り、Figmaに並べる
触れないレガシー画面でも、キャプチャをFrameとして取り込めば分析対象にできる
2
繰り返し出てくる要素をComponent化する
見た目がバラバラでも「役割」が同じ要素（ボタン・テーブル等）をグルーピングする
3
色・余白を計測し、暫定Variablesに落とす
正式なデザインシステムが無くても、現状の数値を一度変数化すると比較がしやすくなる
DXエンジニアのためのFigma×デザインシステム活用術
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/4JMYM9DQJW.jpg)

HOW
段階移行をデザイントークンで実現する
①現状の値を
Variables化
②新トークンを
並行定義
→
③画面単位で
切替
→
④旧トークンを
段階的に削除
→
レガシーの色・余白を
目指す配色・余白を
移行済み画面から
参照がゼロになった
一旦そのまま変数化
別モードとして追加
新モードを適用
旧トークンを削除
Figma Variablesの「モード」機能を使えば、新旧トークンを同一ファイル内で安全に共存させられる。
DXエンジニアのためのFigma×デザインシステム活用術
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/PJR9VG4K79.jpg)

HOW
デザインリテラシーが低い現場での合意形成
起きやすい摩擦
「今のままでいい」と変更の必要性が伝わらない
Figmaのリンクを送っても見てもらえない
「前はこうだった」という感覚的な差し戻しが起きる
DXエンジニアのためのFigma×デザインシステム活用術
対処の方向性
Figmaのリンクではなく、Before/Afterのスクリーンショットを
並べて見せる
変更理由を「業務が楽になる点」に翻訳して伝える（画面の美し
さではなく）
小さな画面から試験導入し、成功体験を積んでから拡大する
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PEXQZX25JX.jpg)

HOW
仕様書に書くべき「レガシー互換」の情報
Notionに書く（言葉）
Figmaに残す（見た目）
置き換え対象のレガシー画面・帳票名
レガシー画面のキャプチャ（Before）
データ移行の要否とその方法
新UIのデザイン（After）
旧仕様からの変更点と業務影響
新旧の要素対応を矢印等で図示
廃止予定日・経過措置の有無
暫定実装には「暫定」ラベルを付与
レガシー案件の仕様書は「何を変えるか」以上に「何を変えないか」を明記すると揉めにくい。
DXエンジニアのためのFigma×デザインシステム活用術
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/3EK98WMRED.jpg)

PITFALL
DX案件でハマりがちな落とし穴
理想形から設計し、移行経路を考えない
将来のあるべきデザインシステムだけを作り、現行からの橋渡しが破綻する
新旧トークンを無秩序に混在させる
モード管理をせず直値で両方を書き足し、どちらが正か誰もわからなくなる
暫定実装に「暫定」と書き忘れる
一時しのぎのコンポーネントが正式版として定着し、技術的負債化する
DXエンジニアのためのFigma×デザインシステム活用術
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/L73W21YG75.jpg)

SUMMARY
まとめと次のアクション
今日のポイント
次のアクション
デザインシステムはレガシー刷新の共通言語になる
1
新旧トークンはモード機能で安全に共存させる
2
仕様書には「何を変えないか」も明記する
3
DXエンジニアのためのFigma×デザインシステム活用術
担当レガシー画面を1つ選び、Figmaに棚卸ししてみる
現状の色・余白を暫定Variablesとして変数化してみる
次の仕様書に「変えない部分」の欄を追加してみる
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/87DKZX5NJG.jpg)

RESOURCES
参考リソース
Figma公式：Variables（モード）ガイド
新旧トークンを共存させるモード機能の公式リファレンス
Strangler Fig パターン解説
レガシーを段階的に置き換える設計パターンの考え方
本シリーズ「一流エンジニアのデザインシステム×Figma活用術」
実装者向けの詳細編。基本的な用語・操作を揃える際に参照
本シリーズ「PMのためのFigma×デザインシステム活用術」
進行管理・合意形成に焦点を当てたPM向け編
うさうさ研修工房｜DXエンジニア・DXコンサルタント向け研修コンテンツ
DXエンジニアのためのFigma×デザインシステム活用術
13