1. はじめに：なぜ“デザイン通り”にならないのか？
Webディレクターとして、こんな経験はありませんか？
「Figmaでは完璧だったのに、コーディング後に見たら何か違う…」
「ボタンの位置、ズレてない？」
「このフォント、ちょっと太く見えない？」
Webディレクターの方から、これまでに何度もいただいてきた言葉です。
一見すると「コーダーのミスでは？」と思われがちですが、フロントエンドのコーディング代行を専門にしている私の立場から言うと、“技術的な限界”や“前提の違い”が原因であるケースがほとんどです。
そして、それは決して「ミス」や「再現不足」ではなく、再現“できない”もしくは“すべきでない”ことさえあるというのが、現場での実感です。
本記事では、実際の案件で私が直面してきた“ズレ”の事例を交えながら、「なぜ完全再現が難しいのか？」「どこまで再現するのが現実的か？」「実装者はどんな工夫をしているのか？」を現場視点で解説しながら、ディレクターが知っておくとプロジェクトがスムーズに進む視点や考え方をお伝えしていきます。
2. デザインとコーディング、それぞれの“前提”の違い
私がコーディング代行を担当している案件のほとんどで、Webディレクターやデザイナーと共有することになるのが、「そもそもデザインと実装は前提が違う」という話です。
「デザインと同じ見た目にしてください」
──この指示、一見シンプルに聞こえますが、実装現場ではとても難しい課題です。
見た目だけを見ると「同じにできるはず」と思われがちですが、実はそれぞれが成立している環境も、求められる役割も根本から違っています。その理由は、デザインと実装では“成立している世界”がそもそも違うからです。
デザインは「理想環境の静的な完成形」
FigmaやXDで作られたデザインは、基本的に静的な一枚絵です。
表示環境もほぼ「Mac＋Retinaディスプレイ＋100%ズーム」で、フォントもレンダリングも最適な状態で見ることが前提になっています。
たとえば、ボタンの角丸がピクセル単位で揃っていたり、フォントの太さや余白が“きれいに見える”ようにチューニングされていたりします。これは当然で、デザインの役割は「理想的な完成形を示すこと」ですから、美しさを最大化するのが目的です。
コーディングは「不確実な環境への対応力」
一方、私たちフロントエンドエンジニアが担うのは、「現実世界で、どんな環境でも破綻しないUIを作ること」です。
その現実とは──
- OSの違い（Mac / Windows / iOS / Android）
- ブラウザの違い（Chrome / Safari / Edge / Firefox）
- フォントの有無、描画エンジンの違い
- 解像度や画面倍率の違い
- ユーザーが変更した文字サイズ設定や言語設定
など、想像以上に“条件がバラバラ”な世界です。
実装とは、このカオスの中でも、見た目の一貫性や使いやすさを担保する作業なのです。
実務でも起きる、前提のすれ違い
実際の案件でも、デザインと実装の前提の違いによってすれ違いがよく発生します。例えば──
- 「余白が狭く見える」→低解像度ディスプレイ＋ブラウザズーム設定の影響だった
- 「フォントが太い」→Windowsのレンダリング特性による見え方の違い
- 「改行位置が違う」→Figmaでは短いダミーテキスト、実装では実データが入ったことで発生
つまり、「ズレている」というより、そもそも同じに見えない前提で設計されているのです。
「同じに見えない」は、誰のせいでもない
このように、デザインと実装は、そもそも違うルールのもとで動いているものです。
だからこそ、デザインの理想をどこまで現実に落とし込むか、その「橋渡し」が実装者の仕事であり、ディレクターとすり合わせていくべきポイントでもあります。
3. よくある“ズレ”の具体例とその原因
私がコーディング代行の現場で実際に経験してきた中から、Webディレクターとの間でよく話題になる“見た目のズレ”をいくつかご紹介します。どれもフロントエンドエンジニアが頻繁に対応しているテーマであり、ディレクターが理解しておくと確認や指示が的確になります。
フォントが太く見える
原因：OSごとのフォント描画の違い（特にMacとWindows）
MacとWindowsでは、同じ font-weight: 400 を指定しても見え方が大きく異なります。特にWindowsでは、文字がくっきり・太めに描画される傾向があるため、「Figmaよりも文字が太い」と感じられることが多いです。
行間が詰まって（または広がって）見える
原因：FigmaとCSSのline-heightの仕様差
Figmaで「150%」と指定された行間は、CSSでの line-height: 1.5 と完全には一致しません。
さらに、フォントの種類や文字サイズによっても微妙にバランスが変わるため、「詰まって見える」「間延びして見える」といった違和感が生まれます。
テキストがはみ出す・想定外に改行される
原因：実データとダミーテキストの違い
デザインでは「仮テキスト（例：ああああ）」が使われていたのに、実装時に本番用の文章を入れた結果、改行や折り返しが変わって見えるというケースも非常に多いです。とくにモバイルでは顕著で、「ボタンの2行目が変な位置で改行されている」といった問題になりがちです。
シャドウが目立たない・弱く感じる
原因：FigmaとCSSのシャドウ表現の差
Figmaのシャドウは、見た目のインパクトを重視して強めに描かれていることが多いですが、CSSの box-shadow はブラウザや解像度の影響を受けやすく、思ったよりも薄く見えることがあります。実装側では見た目を近づける調整が必要になるパーツのひとつです。
実装現場のリアルな感覚
これらの“ズレ”は、ミスではなく仕様差によって起きるもので、すべてをピクセル単位で合わせることは現実的に不可能です。だからこそ、実装者は「近づけるための最適解」を探りながら調整していきます。
ディレクターとして知っておくことで、「どこが本質的な問題なのか」「どこは許容範囲なのか」の判断がしやすくなります。
では、そうした“ズレ”に対して実装側がどのような努力や工夫をしているのか、紹介しましょう。
4. 実装側が行っている“見た目調整”の努力
「デザイン通りに見えない」と言われたとき、私たちフロントエンドエンジニアは「仕方ない」で済ませているわけではありません。
むしろ、見た目をできる限り近づけるために、かなり細かい調整作業を行っています。
ここでは、私が日々のコーディング代行業務で行っている具体的な調整の一部をご紹介します。
ピクセル単位でのスクリーンショット比較
まず、Figma上のスクリーンショットと、実装後のブラウザ画面を重ねて比較し、1px単位で余白や文字位置をチェックしています。
ツールを使って差分を視覚化したり、目視で細かく確認したりしながら、「印象レベル」での違和感をなくす作業です。
マージン・パディングの手動微調整
デザイン通りの数値をそのままCSSに落とし込んでも、ブラウザのレンダリング特性やフォント差でズレが出ることが多いため、
必要に応じて上下左右のマージン・パディングを微調整します。1px動かすだけで印象がガラッと変わることもあるので、かなり神経を使う作業です。
表示環境を変えて再確認
私は納品前に、以下の環境（Mac / Windows / スマホ）で見た目を確認しています。
- Windows：Microsoft Edge、Google Chrome 最新版、Firefox 最新版
- Mac：Safari 最新版
- スマートフォン：iOS Safari、Android OS Chrome
特にWindowsのフォントレンダリングはズレが出やすいため、Macでうまくいっていても油断できません。
必要に応じて、OSごとにフォントを指定したり、ブラウザ固有のCSSハックを使って見た目を整えることもあります。
完全再現よりも「違和感をなくす」ことを重視
最終的なゴールは、“Figmaの完コピ”ではなく、ユーザーが見たときに「自然に感じられるUI」を実現することです。
私たちは、限られた再現性の中でベストを尽くし、環境差による見た目のズレを「感じさせないレベル」に落とし込むことを目指して作業しています。
このように、実装者は見えないところで細かな調整を行い、現実世界で使えるUIを作るために多くの努力をしています。
次章では、こうした前提を踏まえた上で、Webディレクターの皆さんに知っておいていただきたい「3つの視点」をご紹介します。
5. ディレクターに知っておいてほしい3つの視点
実装現場では「限界がある中で、違和感をなくす調整」が日常です。
そのうえで、Webディレクターの方とやりとりする中で、「ここを理解してもらえると圧倒的にスムーズになる」と感じる視点がいくつかあります。
1. 「ピクセル一致」が目的ではない
Figmaと1px違うと指摘されることもありますが、Webは動的なメディアであり、常に再現率に揺らぎがあります。
私たち実装者は“ズレても不自然に見えないかどうか”を重視しています。
100％の一致よりも、「ユーザーが自然に見られる状態」かを評価軸にしていただけると、フィードバックの精度が上がります。
2. UIの品質は「見た目＋動作」で判断する
表示のズレばかりが注目されがちですが、本来UIの品質は「見た目と動きが一体となってユーザー体験を形づくる」ものです。
たとえば、ボタンが数pxズレていても、ホバー時のアニメーションやクリック時の反応が直感的なら、体験としては成立します。
見た目だけではなく、動作や使いやすさも合わせて評価していただくのが理想です。
3. デザインレビュー時は「質問の仕方」で変わる
実装確認の際、「ここ、Figmaと違ってませんか？」と指摘するより、
「この表示は意図どおり？」という質問に変えるだけで、確認が前向きになります。
実装者としては、「Figmaと違う」こと自体は自覚していて、そのうえで調整した結果であることが多いです。
意図を軸に確認してもらえると、お互いの判断軸が一致しやすく、やりとりの質がグッと上がります。
こうした視点を持ってやり取りができると、単なる指摘や修正依頼ではなく、「良いWebを一緒に作る」チームとしての関係性が築きやすくなります。
6. まとめ：見えない技術的背景を理解すれば、やりとりはもっとスムーズに
デザインと実装の間に“ズレ”が生まれるのは、誰かのミスではなく、構造的な前提の違いによって当然のように起こる現象です。
私たちフロントエンドエンジニアは、そのズレをできる限り吸収し、違和感のない見た目に近づけるために、細かい調整を積み重ねています。
「再現性の限界」を理解してもらえると、現場は大きく変わる
実装者として本当にありがたいのは、Webディレクターの方が“完全再現が難しい”という現実を理解し、共に最適解を探ろうとする姿勢を持ってくださることです。
その視点があるだけで、
- フィードバックが的確になり、
- 対応の優先度が整理され、
- 修正のやりとりが減り、
- スケジュールも守りやすくなる
という好循環が生まれます。
より良い成果物は、対話から生まれる
「ズレてるかどうか」だけでなく、「意図どおりかどうか」「ユーザーが自然に使えるかどうか」**という視点を共有できれば、デザインと実装はもっと有機的につながります。
私たちフロントエンド実装者も、“ただ作る人”ではなく、UIの完成度を高めるためのパートナーでありたいと思っています。
これからも、Webディレクターとフロントエンドエンジニアが“同じ目線”で仕事ができるように、実装現場からリアルな視点をお届けしていきます。
次回のVol.2も、どうぞお楽しみに！
