XD から Figma への移行 — エンジニアリングチームのための 5 ステップ プレイブック

「XD から Figma への移行」というテーマで議論を始めると、話題は自然と見た目の忠実度に流れがちです。Auto Layout はちゃんと変換されるか、コンポーネントは生き残るか、プロトタイプのリンクは引き継げるか。どれも重要な問いですが、これらはプロジェクトを期限内・予算内で完遂できるかを決める意思決定の下流にある論点です。

その上流の意思決定を握っているのは、多くの場合エンジニアリングチームです。誰が移行についての指揮をとるのか？「完了」をどう受け入れテストとして定義するか？数十〜数百ファイルにスケールする変換パイプラインはどれか？リリースブランチに不具合が紛れ込んでしまう前にリグレッションをどう拾うか？そしてカットオーバー後、デザイントークン / Storybook / Dev Mode ハンドオフを含むツールチェーン全体と Figma をどう同期させ続けるのか？

この記事は、そのロールアウトを統括するエンジニアリングマネージャーと開発者向けの 5 ステップ プレイブックです。デザイナー向けの一般的な Figma 移行ガイドではありません — そちらは実践ガイドを参照してください。本稿が扱うのは、変換そのものではなくその周辺のエンジニアリング的な足場、すなわちオーナーシップ / 成功基準 / ツール選定 / QA ループ / 長期メンテナンスです。

🧭 なぜエンジニアリングチーム向けのプレイブックなのか

デザイナー主導の移行とエンジニア主導の移行は、内部から見ると別物です。

デザイナー主導の移行はビジュアルの再現度を最優先事項として作業が進められます — アートボードの見た目を保ち、コンポーネント階層を設計通りの形に保ち、再学習コストを最小化する。成功の基準は「Figma と XD で同じように作業を進められる」ことです。

エンジニア主導の移行はプロセスの再現度を最優先事項として作業が進められます — リリースサイクルを止めず、ハンドオフ パイプラインを維持し、デザイン⇄コードのリンクを切らさない。成功の基準は「チームが同じ速度で、もしくはそれ以上でアウトプットの提供・創出を続けられる」ことです。

どちらの視点も妥当で、現実の多くの移行では両方が必要になります。ただしエンジニアリングがロールアウトを統括する場合、プレイブックの形はエンジニア的になります — 明確なオーナー、書面化された受け入れ基準、感覚ではなく決定マトリクス、ワンショット レビューではなく QA ループ、そしてカットオーバー後も生き残るメンテナンス計画。

この記事が扱うのはそこです。

📋 ステップ 1 の前に決める 3 つのこと

プレイブックに入る前に、3 つの重要な事項を先に決定しておきます。これだけで後の手戻りが何日も減ります。

1. 誰が移行のオーナーか

「全員でオーナーシップを持つ」は「誰もオーナーシップを持たない」と同じ意味です。単一の説明責任者を 1 人選びます — 多くの場合、デザインシステムの文脈とリリース権限の両方を持つエンジニアリングマネージャーかスタッフエンジニアです。そのオーナーがすべてのタスクを実行する必要はありませんが、スコープ / ツール / 出荷日の最終判断はオーナーに集約します。

実用的なパターンは、オーナーをデザイン側の責任者（リードデザイナー or デザインシステム オーナー）とペアにして、ビジュアル系の判断をデザイン側で承認できるようにすることです。これで「XD と Figma のどちらに合わせるか」という細かい判断がエンジニアリングに流れて詰まる事態を避けられます。

2. 「完了」をどう測るか

これが最も過小評価されがちな決定です。「100% 移行」はめったに達成できず、ほとんどの場合不要です。実用的なターゲットを 3 つから選びます:

多くのエンジニアリングチームは Tier 2 に落ち着きます。ステップ 1 の前に Tier を明示的に決めて、インベントリと QA のスコープがターゲットと一致するようにしてください。

3. ロールバック経路はどうなっているか

移行の途中で何かがうまくいかなかったとき — クリティカルなコンポーネントが誤変換された、選んだツールがスケールしなかった、チームの速度が落ちた — 何にフォールバックしますか？2 点を固めておきます:

• カットオーバーまで .xd ファイルを読み取り専用に保つ。 2 つのソースを並行編集してはいけません — デザインシステムが分岐します。
• プロジェクトごとに「カットオーバー日」を定義する。 その日までは XD ファイルが信頼できるソース。それ以降は Figma ファイルが信頼できるソース。これで「どちらのバージョンが正本か」という問いがなくなります。

この 3 つを決めたら、ステップ 1 に進める状態です。

🔍 ステップ 1 — XD アセットの棚卸しとインベントリ作成

インベントリに何を記録するか

スコープ内の各 XD ファイルについて以下を記録します:

• ファイル名と保存場所（Creative Cloud / ローカルドライブ / 共有ドライブ など）
• アートボード数 — ファイル複雑性の簡易的な指標
• コンポーネント ステータス — ファイルがコンポーネントを定義しているか、ライブラリから消費するだけか
• プロトタイプ ステータス — プロトタイプリンクとトリガーに依存しているか（最も変換が難しい部分）
• リンク依存関係 — このファイルはクラウドドキュメント経由で他の XD ファイルにリンクしているか
• 最終更新日 — 6 ヶ月以上触られていないものはアーカイブ候補
• 優先度 — Active / Design System / Archive にタグ付けし、「完了」 Tier にマッピング

ファイル数が多い場合もスプレッドシートで十分です — ここをカスタムツールで作り込むのは時間の無駄。要点はスコープを可視化してカットオーバーで取りこぼしを防ぐことです。

優先順位フレームワーク

インベントリを記録したら、3 つのバケットに分類します:

1. クリティカル パス — 移行しないと現行開発がブロックされるファイル（Tier 2 のアクティブ + デザインシステム）
2. あれば便利 — Figma にあると便利だがブロッカーではないファイル（優先度低のアクティブファイル）
3. アーカイブのみ — 参照用に残すだけで移行不要のファイル（残り）

ステップ 2〜5 はまずクリティカル パス バケットに対して実行します。あれば便利ファイルは後続段階。アーカイブのみファイルは移行せず、XD で読み取り専用の参照として残します。

🎯 ステップ 2 — 移行スコープと成功基準の定義

スペックをテスト プランとして書く

移行スペックは戦略ドキュメントではなく、テスト プランに近いものです。クリティカル パス バケットの各アイテムについて以下を書きます:

• ソース ファイル — 変換対象の XD ファイル
• ターゲット Figma ファイル — 出力先のファイル名とファイルの格納場所
• 受け入れ基準 — このファイルにとって「変換成功」とは何を意味するか？（例: 「全アートボード保持、コンポーネントはライブラリにリンク、プロトタイプ フロー保持、フォントは Figma 同等品にマッピング」）
• スコープ外項目 — 明示的に不要なもの（例: 「プロトタイプのマイクロ インタラクションは保持しない」「ラスター エクスポート サイズは再生成しない」）
• 検証者 — 基準が満たされたことを承認する人

これを事前に書くことで、ステップ 4（QA）が機械的になります。これがないと、各ファイルが「これで十分か」という議論になってしまいます。

3 段階の成功水準（ファイル単位）

各ファイルについて、3 つの段階で成功を定義します:

ほとんどのファイルはパス 水準で十分です。全ファイルを本番投入可にしようとすると、移行は数ヶ月単位で遅延します。

⚙️ ステップ 3 — 変換パイプラインの選定

4 つの選択肢を俯瞰する

XD から Figma への変換には、意味のある違いを持つ 4 つの方法があります:

エンジニア主導の移行のほとんどでは、Figma プラグインとプログラミングの二択になります。手動リビルドは小規模スコープ限定、間接エクスポートは編集不要のアーカイブ用です。

エンジニアリングチーム向け 決定マトリクス

プラグイン（または自前パイプライン）を評価する際は、エンジニア視点で関係する 5 軸でスコアリングします:

主要コンバーター プラグインの詳細比較は XD → Figma コンバーター プラグイン 徹底比較 を、より広いプラグイン エコシステムは Adobe XD 移行者のための Figma プラグイン 10 選 を参照してください。

複数アプローチを組み合わせるとき

多くのエンジニアリングチームにとって最適解は「メインのプラグイン 1 つ + フォールバック 1〜2 つ」です:

• メイン: 上記マトリクスで最高評価のコンバーター プラグイン。80〜90% のファイルをこれで処理。
• アーカイブ向けフォールバック: Figma で表示できればよく編集不要なファイルは SVG / PDF エクスポート。
• ロングテール向けフォールバック: 上 2 つで失敗する少数ファイル（プロトタイプ重視 or 複雑なマスクのファイル）は手動リビルド。

複数アプローチの組み合わせは戦略の失敗ではなく、複雑なスコープに対する最も効率的な進め方です。

✅ ステップ 4 — 変換実行と QA ループの確立

バッチ変換戦略

全ファイルを一気にではなく、複数の段階で処理します:

1. 第 1 段階 — パイロット バッチ（5〜10 ファイル）: ファイル複雑性の範囲を代表する数ファイル。変換 → 全 QA を行い、出てきた問題を踏まえて QA チェックリストを精緻化。
2. 第 2 段階 — デザインシステム ファイル: 最重要の単一ファイル。整備済み or 本番投入可 Tier の QA を実施。結果を確定してから第 3 段階に進む。
3. 第 3 段階 — クリティカル パス 残り: アクティブ ファイルの大半。パス Tier QA で十分。
4. 第 4 段階 — あれば便利ファイル: 時間と予算があれば。速度がリスクならスキップ。

段階的に処理を行うことで「全部変換してから 200 ファイルに同時に問題が見つかる」失敗を避けられます。

変換ファイルの QA チェックリスト

各変換ファイルについて以下を確認します:

• ✅ アートボード数の一致 — ソースと同じ数のアートボード / フレーム。
• ✅ レイアウト構造の保持 — ネストされたグループ / フレーム / 制約が保持されている。
• ✅ フォントのマッピング — すべてのテキスト レイヤーが意図したフォントでレンダリング（「フォント欠落」警告なし）。
• ✅ コンポーネント リンク — インスタンスがローカル コピーではなくライブラリを指している。
• ✅ カラーとスタイルの整合性 — 塗りとテキスト スタイルがデザインシステムと一致。
• ✅ サイレント リグレッションなし — 代表アートボードを開き、XD オリジナルと並べて比較。
• ✅ 受け入れ基準の承認 — 移行スペックの検証者がレビューし承認済み。

選んだコンバーターが Auto Layout ヒューリスティックをサポートしているなら、デザインシステム ファイルに対しては第 2 フェーズで Auto Layout 適用を特にチェックします。Auto Layout のリグレッションは「見た目は良いがレスポンシブ変更で崩れる」問題の最大の原因です。

リグレッションへの対処

QA でリグレッションを発見したら、3 つのバケットに分類します:

• 変換側の修正 — コンバーターが何かをミスハンドリングした。再現性があればプラグイン メンテナーに Issue 投稿、なければ Figma 側で回避。
• ソース側の修正 — XD ファイル側に根本的な問題（例: コンバーターがマッピングできないフォントを使用）。可能ならソースを修正、不可能なら回避を受け入れる。
• スコープ外 — 受け入れ基準で明示的に除外されたもの（例: プロトタイプのマイクロ インタラクション）。記録して進む。

要点は素早く分類することで、毎件議論しないこと。移行スペックの段階でスコープの内外は既に決まっており、QA はそれを適用するだけです。

🚀 ステップ 5 — カットオーバーと移行後メンテナンス

本番カットオーバー プラン

カットオーバーはプロジェクト単位の 1 日イベントです:

1. 午前 — XD 編集を凍結。 以降の編集は XD ではなく Figma に行うことをチームにアナウンス。
2. 昼 — 最終同期。 ステップ 4 承認とカットオーバーの間に XD 側で土壇場の変更があった場合、そのファイルのみ変換をやり直す。
3. 午後 — ハンドオフ リンクの切り替え。 XD ファイルを指す内部ドキュメント / チケット テンプレート / Slack チャンネル / wiki ページを更新し、Figma URL に置き換える。
4. 終業時 — XD ファイルを読み取り専用としてアーカイブ。 .xd ファイルを読み取り専用の場所（例: 別の Drive フォルダで「archive — 編集禁止」とマーク）に移動。

カットオーバー後は、XD ファイルを git history と同じように扱います — 参照には有用、編集はしない。

Dev Mode とデザイントークン

Figma が信頼できるソースになったら、ハンドオフ周りの足場を整えます:

• Dev Mode — ファイルをメンテナンスする編集者を割り当てる。デザインシステム Tier のファイルの場合はコンポーネント ドキュメントもセットアップ。
• デザイントークン — トークン パイプライン（Tokens Studio / Style Dictionary など）を使っているなら Figma 変数と配線する。多くの場合これは 1 回のセットアップで以後すべての変更に効くため、ROI が高い。
• Figma API インテグレーション — デザインからコードやアセットを生成している場合（例: アイコンを repo にエクスポート）、インテグレーションを XD ではなく Figma に向け直す。チームが最も忘れがちな部分。

長期メンテナンス プレイブック

6 ヶ月後にチームが見て動けるように、短いメンテナンス プレイブックを書き残します:

• ✅ デザインシステムの所在 — Figma ファイル URL、編集権限、コメント権限。
• ✅ 新規コンポーネント追加の手順 — 命名規則、ライブラリ内の位置、承認者。
• ✅ デザイントークンがコードに流れる経路 — パイプライン図、オーナーシップ、障害時のリカバリ。
• ✅ コンバーター プラグインが壊れたときの対処 — カットオーバー後も XD ファイルを変換する必要が残っている場合のみ関係（多くの場合は不要）。
• ✅ Figma の新機能評価方法 — 新リリース（変数、コンポーネント プロパティ など）を採用するかの判断基準。

このプレイブックの有無が、「移行が出荷されただけ」と「Figma 運用が健全なまま続く」の分かれ目になります。

⚠️ エンジニアリングチームがハマりがちな落とし穴

繰り返し見てきたパターンをいくつか:

「空き時間でやる」。 サイドワーク扱いの移行は出荷されません。たとえ週 1 日でもいいので、実際のエンジニアリング工数をスケジュール上で確保し、他のプロジェクトと同じように扱う。

「自分たちが持っているファイルは把握している」と言ってインベントリを省略する。 していません。インベントリは多くの場合、誰も覚えていなかったファイル / 誰も追っていなかった依存関係 / アーカイブされたはずなのに残っているプロトタイプ リンクの存在を明らかにします。1 日かける価値があります。

間違ったファイルで忠実度を上げに行く。 アーカイブされた 1 ファイルの変換を 3 日かけて完璧に仕上げる一方でクリティカル パスのファイルが待っている、というのはリソース配分のミスです。ファイル優先度と工数を一致させる。

ロールバック計画なしで 2 つのソースを並行編集する。 これはデザインシステム分岐を招きます。プロジェクトごとのカットオーバー日を決めて守る。

カットオーバーを「完了」と扱う。 カットオーバーはメンテナンス フェーズの開始であって、ゴール ラインではありません。メンテナンス プレイブックを書かないと、2 年後、3 年後にデザインシステムが一貫性を失った理由を思い出せないことになります。

🎯 まとめ

エンジニア主導の移行は、作業をオーナーシップ / 書面化された成功基準 / 文書化されたロールバック経路を持つプロジェクトとして扱ったときに成功します。上の 5 ステップのプレイブックは、移行作業全体をスムーズに進めるための土台であり、移行が期限内に完走されるかどうかを決める部分です。

ステップを再掲します:

1. 棚卸しとインベントリ — スコープを可視化する。
2. スコープと成功基準の定義 — スペックをテスト プランとして書く。
3. 変換パイプラインの選定 — マトリクスで明確にツールを決める。
4. 変換実行と QA — 段階単位の実行とチェックリスト。
5. カットオーバーとメンテナンス — Figma を信頼できるソースにし、健全に保つ方法を文書化する。

ツール選定（ステップ 3）は、エンジニアリングチームが変換品質の不足が招くコストを最も過小評価しがちな部分です。Pixel Fine Converter は本プレイブックが描く QA ループ — 再現性のある出力 / 複雑なファイルでも構造を保ちやすい Auto Layout ヒューリスティック / 単なるプレミアム機能のオン/オフではなく、手戻りコストを抑える保険として設計された Pro 機能 — を意識して設計されています。

変換ステップそのものについては 実践ガイド と XD → Figma コンバーター プラグイン 徹底比較 を、カットオーバー後に必要になる広いプラグイン エコシステムについては Adobe XD 移行者のための Figma プラグイン 10 選 を参照してください。