DXエンジニアのためのFigma_デザインシステム活用術

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

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

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

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

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

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

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

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

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

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

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

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

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