デザインツール（Figma）から直接コードへ。コーダーに求められる「デザインエンジニア」の視点

まず、結論からお伝えします。これからのWEB制作業界で生き残るのは、デザイナーが作ったカンプ（完成見本）の見た目を1pxの狂いもなく再現するだけの「作業者」としてのコーダーではありません。デザインの裏側にある「意図」や「構造」を読み解き、変更に強く保守性の高い設計ができる「デザインエンジニア」です。

「デザイン通りの実装」は、もはやプロとして当たり前の最低ラインです。そこから一歩踏み込み、コードの品質、実装スピード、そしてデザイナーとのコミュニケーションでどれだけ付加価値を出せるかが、あなたの市場価値を決定づけます。

かつて、コーディングといえばPhotoshop（※1）で画像を切り出し定規ツールで測る、あるいはAdobe XD（※2）でスペック情報を確認して書き写す……といった、まるで修行僧の「写経」のような作業が中心でした。しかし、Figma（※3）の登場、そしてDev Mode（※4）の劇的な進化により、数値の計測や色コードのコピー、画像の書き出しといった単純作業は、ほぼ自動化されつつあります。

今、現場で求められているのは、ツールでは完結しない「人間ならではの調整力」と「エンジニアリング視点での設計力」です。

この記事では、世界標準のデザインツールFigmaを活用し、あなたのコーディングスキルを単なる「作業」からクリエイティブな「エンジニアリング」へと昇華させる方法を、初心者から中級者の方に向けて徹底解説します。

これを読み終える頃には、Figmaの画面が単なる「綺麗な絵」ではなく、インタラクティブなWEBサイトの「設計図」に見えているはずです。

1. なぜ今「デザインエンジニア」の視点が必要なのか？

国内外で「一強」状態。Figmaの圧倒的なシェア

まず、私たちが戦っているWEB制作市場の現状を、客観的なデータから正しく理解しましょう。「どのツールを使えるべきか？」という議論は、ここ数年ですでに決着がつきました。

世界のデザインツール調査を行うUX Toolsのデータ（2023 Design Tools Survey）によると、UIデザインツールのシェアにおいてFigmaは約83%（※5）という圧倒的な利用率を誇ります。これは2位以下のツール（SketchやAdobe XDなど）を大きく引き離す数字であり、事実上の「業界標準」です。

日本国内においてもこの流れは顕著です。Figma Japanが「日本は世界で最も成長している市場の一つ」と発表している通り、大手制作会社からスタートアップ、事業会社のインハウスチーム、そしてフリーランスの現場に至るまで、Adobe XDなどからFigmaへの移行が完了しています。

つまり、Figmaを「なんとなく見れる」レベルではなく、「開発ツールとして使いこなせる」レベルになることは、WEB業界での「共通言語」を話し、チーム開発に参加するための必須条件なのです。

「言われた通り作る」だけでは評価されない理由

なぜ今、従来の「写経」スタイルからの卒業が必要なのでしょうか？
それは、AI（※6）やノーコード・ローコードツール（※7）の進化により、単純な「HTML/CSS記述（コーディング）」自体の価値が相対的に下がり続けているからです。

「このデザイン画像をHTMLにしてください」という指示に対して、ただ形にするだけなら、ChatGPTやClaudeといったAI、あるいはSTUDIOのようなツールを使えば、誰でも高い精度で可能になりつつあります。しかし、AIがまだ苦手とし、人間が圧倒的に優位な領域があります。それが以下の3点です。

①「ズレない仕組み」を作る力（コンポーネント設計）

1pxのズレを目視で手動修正するのではなく、テキスト量が増減しても、画面幅が変わってもレイアウトが崩れない「堅牢なCSS」を組む力です。これは、Figmaの構造を理解し、適切なCSS設計（BEMやFLOCSSなど）に落とし込む構成力が必要です。

②「行間」を読む力（インタラクションと状態の補完）

静止画のデザインデータには描かれていない情報を補完する力です。「このボタンを押した時の動き（ホバー、アクティブ）はどうするか」「通信エラー時の表示はどうするか」「極端に文字数が多い時の挙動はどうするか」。これらを想像し、実装に落とし込むのは人間の役割です。

③「翻訳」して伝える力（フィードバック）

エンジニア視点でデザインの矛盾や、実装コストが極端に高い箇所を早期に発見し、デザイナーに対案を提示できる力です。「この実装だとパフォーマンスが落ちますが、こちらの方法なら同等の見た目で軽くできます」といった提案ができる人材は、どの現場でも重宝されます。

これらができる人材こそが「デザインエンジニア」です。デザインとエンジニアリングの境界線（グレーゾーン）を埋められる人は、AI時代においても代替不可能な価値を持ちます。

2. 【実践】Figmaの意図をコードに変換する（Dev Mode活用）

概念の話はここまでにして、ここからは具体的な技術の話に入りましょう。Figmaの情報をどうコードに落とし込むか、実務で明日から使える「思考の変換テクニック」を紹介します。

まず大前提として、Figmaの右側にあるプロパティパネルには、「Dev Mode（開発モード）」というスイッチがあります（トグルスイッチのアイコン、またはShift + Dで切り替え）。コーディング時は必ずこのモードをONにしてください。CSSのプロパティがそのまま表示されるだけでなく、パディングやマージンの可視化が非常にわかりやすくなります。

① オートレイアウトを「Flexbox」として読み解く

Figmaにはオートレイアウト（Auto Layout ※8）という強力な機能があります。これは、要素の並び順や余白を自動調整する機能ですが、実はこれ、CSSのFlexbox（※9）の概念とほぼ100%一致しています。

デザイナーがオートレイアウトを使ってデザインしている場合、それは「意図された構造」です。「とりあえずここに置いた」のではなく、「こういうルールで並べた」という意思表示です。Dev Modeのパネルを見たとき、脳内で以下のようにコードへ変換しましょう。

変換対応表：Figma → CSS

Figmaの設定アイコン・名称	対応するCSSプロパティ	役割と実装の考え方
下向き矢印 (↓)	flex-direction: column;	要素を縦に積みます。スマホのカード型レイアウトや、セクション全体の積み上げで多用されます。
右向き矢印 (→)	flex-direction: row;	要素を横に並べます。PCのナビゲーションメニューや、アイコン付きボタンなどが代表例です。
アイテムの間隔 (Gap)	gap: 〇〇px;	要素間の余白です。昔のようにmargin-rightで個別に指定するのではなく、親要素で一括管理します。これにより、要素の入れ替えが容易になります。
パディング (Padding)	padding: 〇〇px;	コンテナの内側の余白です。上下左右個別の値もDev Modeで確認できます。
整列 (Align / Distribute)	align-items / justify-content	中央揃え、端寄せ、均等配置（Space Between）などのルールです。9つのドットアイコンで視覚的に確認できます。
幅：コンテナに合わせて拡大	flex: 1; または width: 100%;	親要素の幅いっぱいに広がる設定（Fill container）です。レスポンシブ対応の要になります。
幅：中身に合わせて抱擁 (Hug)	width: fit-content;	中のテキストや画像のサイズに合わせて、親要素のサイズが決まります。ボタンの幅などで使われます。

実装のポイント：絶対配置（Absolute）からの脱却

初心者がやりがちなのが、Figma上の座標だけを見て position: absolute; top: 50px; left: 20px; のように絶対配置で見た目を作ってしまうことです。これでは、見出しの文字数が一行増えた瞬間に、下の要素と重なってレイアウトが崩壊します。

Figma上でオートレイアウトが設定されている箇所は、必ずdisplay: flex;（あるいはGrid）で実装してください。そうすることで、コンテンツの増減に耐えうる、堅牢なレイアウトが完成します。

【コード例】カードコンポーネントの実装

Figmaで「縦並び、Gap: 16px、Padding: 24px」のオートレイアウトが設定されている場合：

.card {
    display: flex;
    flex-direction: column; /* 縦並び */
    gap: 16px; /* 要素間の余白 */
    padding: 24px; /* 内側の余白 */
    background-color: #fff;
    border-radius: 8px;
}

このように、Figmaの設定値をそのままCSSプロパティに「翻訳」する感覚です。

② 変数（Variables）を「意味のあるCSS」にする

Figmaの最新機能である変数（Variables ※10）やスタイル（Styles）は、CSSの設計思想そのものです。これらは、デザインシステム（※11）の基礎となる部分です。

Dev Modeで色や数値をホバーしたとき、#3B82F6 というカラーコードではなく、Primary / Blue や Text / Main といった名前が表示されることはありませんか？
これはデザイナーが「この色には意味がある」として定義したものです。これを単なる色コードとしてコピーするのではなく、そのままCSS変数（カスタムプロパティ）として定義しましょう。

ここで重要なのは「セマンティック（意味論）」です。

NG例：見た目だけの命名（Presentational Naming）

:root {
    /* 色コードが変わったら名前と実態がズレてしまう */
    --blue-500: #3b82f6;
}

.button {
    background: var(--blue-500);
}

これだと、デザインリニューアルでブランドカラーが「赤」になったとき、--blue-500 という名前なのに中身は「赤色（#FF0000）」という悲劇が起きます。あるいは、すべてのコードを書き換える必要があります。

OK例：役割による命名（Semantic Naming）

:root {
    /* ブランドカラーが変わっても、この1行を変えるだけでサイト全体の色置換が完了 */
    --color-primary: #3b82f6;
    --color-text-main: #333333;
    --size-spacing-md: 16px;
}

.button {
    background: var(--color-primary);
    padding: var(--size-spacing-md);
}

Dev Modeで変数名を確認し、--color-primary（主要色）、--text-body（本文色）、--surface-bg（背景色）のように「役割」で定義してください。これができると、将来的なデザイン変更（ダークモード対応など）に強いコードになり、クライアントやチームからの信頼が一気に上がります。

3. 日本の現場で役立つ「ズレ」解消テクニック

「Figma通りに完璧に作ったはずなのに、なんか違うと言われた……」
コーダーなら誰もが一度は経験する道です。特に日本語環境では、Figmaとブラウザのレンダリング（描画）エンジンの違いにより、どうしても微細なズレが発生します。

中級者は、この「ズレ」を予期して先回りして調整します。ここでは、プロが実践している、クオリティを一段階引き上げるための微調整テクニックを3つ紹介します。

① フォントの「太って見える」現象を防ぐ

macOSやiOSのブラウザ環境では、Figma上の表示よりも、ブラウザで実装した文字の方が「少し太く、濃く」描画される傾向があります。これが原因で、全体的にボテッとした、野暮ったい印象になってしまうことがあります。

デザインの繊細なニュアンス（S・M・Lサイズの微細なウェイト差など）を守るため、ベースのCSS（リセットCSSなど）に以下のプロパティを入れておくことを強く推奨します。

body {
    /* WebKit系ブラウザで文字のアンチエイリアス処理を有効にし、太りを抑える */
    -webkit-font-smoothing: antialiased;
    /* Firefox (macOS) 用の設定 */
    -moz-osx-font-smoothing: grayscale;
}

これを入れるだけで、デザイナーがFigmaで見ていた景色に近い、シュッとした文字の太さを再現できます。「なんか文字が重いな」と思ったら、まずこれを疑ってください。

② 行間（Line Height）は計算して「単位なし」にする

FigmaのDev Modeでは、行間（Line height）が 24px のように固定値（ピクセル）で表示されることが多いです。しかし、CSSで line-height: 24px; とそのまま書くのは推奨されません。
なぜなら、レスポンシブ対応でフォントサイズ（font-size）を変えたとき、行間が固定されたままだと、文字が重なったり、逆に広がりすぎたりする事故が起きるからです。

CSSでは必ず「倍率（単位なし）」に変換して記述しましょう。

計算式

具体例

• Figmaの数値: フォントサイズ 16px、行送り（Line height） 24px
• 計算:
• CSSの記述: line-height: 1.5;

こうしておけば、フォントサイズが 20px に大きくなっても、自動的に行間は 30px （1.5倍）になり、美しい比率が保たれます。FigmaのDev Modeの設定（Code settings）で、表示単位を「Pixels」から「Unitless（単位なし）」に変更できる場合もあるので、確認してみましょう。

③ 画像は必ず「2倍」で書き出す

現代のスマートフォンやPCは、高精細なRetinaディスプレイ（※12）が標準です。Figma上で綺麗に見えていても、そのまま等倍（1x）で書き出した画像をWEBに貼ると、ぼやけて安っぽく見えてしまいます。

画質の劣化は、サイト全体の信頼感を損ないます。以下のルールを徹底しましょう。

PNGでアイコンを書き出しているなら、今すぐSVGに切り替えましょう。ファイルサイズも軽量化できる場合が多いです。

写真（JPG/WebP）： 必ず2x（2倍）サイズで書き出します。

例：画面上で300px幅で表示したい画像は、Figmaから600px幅（@2x）で書き出し、CSSで width: 300px; と指定します。

srcset 属性を使って、デバイス解像度に応じた出し分けを行うのがベストプラクティスです。

アイコン・ロゴ・イラスト（SVG）： 可能な限りSVG（※13）形式を使用します。

SVGはベクターデータなので、どれだけ拡大しても画質が劣化しません。さらに、CSSで色を変更したり（fillプロパティ）、アニメーションさせたりすることも可能です。

4. デザインエンジニアとしての「コミュニケーション術」

技術的な変換ができたら、次は「対話」です。ここがAIに代われない最大のポイントです。
デザインデータは常に完璧とは限りません。時には実装が困難なレイアウトや、論理的に矛盾している箇所（PCで5つの要素が並んでいるが、スマホでどう並べるか指定がない等）が見つかります。

このとき、どう伝えるかであなたの評価が決まります。

NGなコミュニケーション（作業者の発言）

• 「これ、実装できません」
• 「スマホのデザインがないので作れません」
• 「ここズレてますけど直していいですか？」

これでは「指示待ち」の姿勢と受け取られかねません。

デザインエンジニアのコミュニケーション（パートナーの発言）

• 「この部分、画面幅が狭くなると文字が溢れる可能性があります。改行を許可するか、あるいは3点リーダー（…）で省略する形にしますか？」
• 「スマホのデザインが未定ですが、PCと同じカード型のレイアウトで縦積みにする形（オートレイアウトのルール）で、一旦仮実装してもよろしいでしょうか？」
• 「このシャドウのエフェクトはCSSでの再現負荷が高いので、少し簡略化するか、画像として書き出す対応でも問題ないでしょうか？」

このように、「実装の都合」を押し付けるのではなく、「ユーザーの体験」や「デザインの意図」を尊重した上で、選択肢（オプション）を提示します。
Figmaのコメント機能を使って、該当箇所にピンを立てて具体的に質問するのも非常に有効です。デザイナーは、実装の制約を理解しているコーダーを心強いパートナーだと感じます。

【まとめ】Figmaを「見る」のではなく「対話」しよう

これからのコーダーの価値は、「書くこと（Writing）」から「設計すること（Architecting）」へと確実にシフトしています。

最後に、これからのアクションをまとめます。

1. Dev Modeで、デザイナーが意図した「構造（オートレイアウト）」を読み解く。

• それはFlexboxやGridの設計図そのものです。

1. 変数やスタイルを、変更に強いCSSの論理（変数管理）に変換する。

• 色やサイズに「名前」と「役割」を与え、セマンティックなコードを書きます。

1. レンダリングの差分を埋め、ブラウザ上で最高の体験を作る。

• フォントの太さ、画像の解像度など、実機での美しさにプロとして責任を持ちます。

1. 「実装視点」での提案を行い、デザインをブラッシュアップする。

• 受け身にならず、デザイナーと共にプロダクトを作るパートナーとして振る舞います。

「このデザイン、実装しやすそうですね！」とデザイナーに伝え、逆に「ここは実装だとこうなりますが、どう調整しましょうか？」と提案できる。そんな「デザインエンジニア」としての働き方が、あなたの市場価値を確実に高め、AIには代替できない信頼を築くことになります。