Web制作において避けて通れないのが、
「デザインカンプからのコーディング」。
一見、やること自体はシンプルです。
「このデザインを、そのままWebで再現してください」
そう言われて渡されたカンプに沿って、HTMLとCSSを書くだけ。
……のはずなのに。
- 「え？これ、どうやって再現すればいいの？」
- 「カンプと同じようにならない…」
- 「ていうか、レスポンシブは？ホバーは？情報が足りない！」
こんな風に、再現できない問題に直面しているコーダーは非常に多いと思います。
私自身、これまでにたくさん悩んできたし、今でも悩みます。
この記事では、「デザインカンプからコーディングするのがなぜ難しいのか？」という悩みに対して、よくある原因と現場での対処法をわかりやすくまとめています。
デザインカンプって何？
まず前提として、デザインカンプとは何かを簡単にまとめておきます。
- カンプとは「完成見本」のこと
- 主にFigma、XD、Photoshop、Illustratorなどで作成された静的なデザイン
- Webサイトやバナー、UIの「見た目」を決める設計図のような存在
デザインツールには様々なものがあって、デザイナーの得意不得意や好み、案件ベースによって変わります（ここだけの話、本当はどれかに統一してほしい…）。
そして、コーダーやフロントエンドエンジニアは、それをHTML/CSS/JavaScriptで、動くWebページに変換する役割を担います。
つまり、デザインカンプを使ったコーディングは、設計図を見て家を建てるようなものです。
なぜデザインカンプ通りにコーディングするのは難しいのか？
それでは、なぜデザインカンプ通りにコーディングするのが難しいかについて考えてみましょう。
理由①：情報が足りない（仕様抜け）
デザインカンプはあくまで「見た目の一時点」を表しているものであり、Web上の挙動や状態までは含まれていないことが多いです。
例）
- PCデザインしかなく、SP（スマホ）のレイアウトが用意されていない
- ホバーやクリック時の挙動が書かれていない
- エラーメッセージやローディング中の画面が存在しない
これらの情報がないと、コーダーは自分で想像して補うしかありません。
そしてその解釈が、「デザイン通りじゃない」と指摘される原因にもなるのです。
XDなどはプロトタイプを使って挙動なども一部再現できますが、IllustratorやPhotoshopについては、コーダー、フロントエンジニアお任せの場合が多いので、良かれと思ってやったことが逆効果になる場合もあります。
フォントサイズや余白などもバラバラで統一性がないこともあり、慣れていないと戸惑うポイントです。
理由②：デザインカンプは、あくまでも静止画
ここが非常に重要です。
デザインカンプは、ある特定の画面幅での「見た目」を切り取った静止画のようなものです。
しかし、Webサイトは画面幅に応じてレイアウトが変化する「レスポンシブ対応」が求められます。
コーディングの現場では、単にカンプ通りにHTMLとCSSを組むだけでなく、様々なデバイス環境を想定して構造そのものを設計しなければなりません。
特定のデバイス幅の時にデザインカンプ通りにできても、少し幅を縮めるとレイアウトが崩れることはよくあります。
デザイナーによっては、どの幅で見てもイメージ通りを求める無茶振りをしてくるケースもあります。
さらに、PCとスマホで構造が大きく異なるカンプが渡されるケースもあります。
たとえば：
- PCでは見出し→画像→本文だったものが、SPでは画像→見出し→本文の並びになる
- PCでは横並びのナビゲーションが、SPではハンバーガーメニュー＋アコーディオンに
こうした場合、CSSだけでは対応できないケースもあり、その場合、HTMLの構造自体を分岐・変更する必要があります。
つまり、カンプから読み取る情報だけでは不十分で、設計者としての視点が求められる場面が多くなります。
理由③：デザインと実装の物理的ギャップ
デザイナーは「こう見せたい」という意図で美しく仕上げますが、Webの実装には制限があります。
例：
- フォントの太さや間隔がWebフォントで再現しきれない
- 「ぴったり中央」に見えるが、CSS上では微妙なズレが生じる
- グリッドや余白がCSSで表現しづらい構成になっている
結果として、「見た目は正しいけど、実装的には成立しない」状態になることも。
実装についての知識がないデザイナーがデザインを担当する場合に、けっこう起きがちな問題です。
コーダーの仕事はデザインを忠実に再現することですが、とはいえ、無理なものは無理だと理解してもらうことは大事です。
理由④：ツールやスキルのギャップ
FigmaやXDを使うデザイナーと、HTML/CSSを書くコーダーでは、ツールの見え方・考え方が大きく異なります。
- デザイナーはAuto Layoutやコンポーネント設計を意識していても、コーダーには構造が伝わりにくい
- 一方で、デザイナーがHTMLやCSSの制約を理解していないこともある
この前提のズレが再現難易度を高めているというケースも、実はかなり多いです。
私が思うに、コーダーはみんな一度はデザインツールでデザインカンプを作ってみるべきだし、デザイナーは一度デザインカンプをもとにコーディングしてみるべきです。
そうすれば、デザイナーが余白やサイズ感にこだわる理由がわかるし、コーダーがPCとSPで大きく構造が異なるデザインを嫌がる理由がわかります。
「再現できない」と感じたときの対処法
では、「どう頑張ってもカンプ通りに再現できない」と感じたとき、どうすればいいのでしょうか？
「完コピ信仰」を手放す
まず大事なのは、「ピクセル単位で完璧に再現しなければならない」という思い込みを捨てることです。
大切なのは、「見た目がまったく同じ」にすることよりも、
ユーザーにとって快適で、使いやすいWebページを作ることです。
- フォントサイズが1px違っても、実用上は問題なし
- marginが2pxずれていても、誰も気づかない
- その代わり、可読性や操作性が損なわれるなら要修正
ハッキリ言って、marginの数pxのズレを気にしているのは、デザインを作ったデザイナーだけで、クライアントやユーザーは気にしません。
だからそこまで数値に神経質になる必要はないです。
細かいデザイナーと組むことになって、万が一指摘されたら指摘箇所をなおすくらいのスタンスで大丈夫です。
再現性より「目的に合っているか」を優先することが、結果的に良い仕事につながります。
不明点はすぐに確認する
「聞いたら迷惑かも…」と遠慮しがちですが、仕様が曖昧なまま進めてしまうほうが、結果的に大きな手戻りが発生する可能性を高めます。
- スマホ版がない？ → 作ってもらう or 仮案を提案する
- ホバーの指定がない？ → どういう意図かを確認する
- UIアニメーションが必要？ → ユーザー導線とあわせて調整提案
など、迷ったらまず確認しましょう。
私自身、良かれと思ってやったことが本来不要な修正につながった経験が何度もあります。
確認して怒るデザイナーはいないと思うので、不明点はまず確認しましょう。
例）
- 「この仕様、デザインの意図を確認させていただいてもいいですか？」
- 「スマホ版の表示を仮で作ってみたので、一度見ていただけますか？」
- 「この構造、レスポンシブ対応を考えると分けた方が良いと思うのですが…」
レスポンシブを前提にHTMLを設計する
特に「PC版とSP版でレイアウトが大きく違う」場合は、最初からレスポンシブ前提でHTMLを組む意識が重要です。
- スマホ表示を意識して、汎用性のある構造にする
- モバイルファーストで設計しておけば、PC側での崩れが少なくなる
- どうしても構造が合わない場合は、CSSのみでなくHTML自体を条件分岐して別の構成にすることも視野に入れる
私は、ページ単位ではなく、ブロックごとにレスポンシブ設計を考えていて、
- デザインカンプで構成を確認する
- PC、SP両方に対応できるようにHTMLを組む
- SPのCSSを用意する
- PCのCSSを用意する
- 次のブロックに移る
という流れでコーディングしています。
実案件のコーディングの流れについては、下記記事でも詳細を書いているので、もしよければお読みください。
カンプ通りにすれば正解とは限らない
デザインカンプを再現するのがコーダーの仕事ですが、「カンプどおりに作ったのにNGが出る」ということもあります。
- h1タグが2つある → SEO的にNG
- 色のコントラストが弱い → アクセシビリティ的にNG
- ボタンが画像になっている → UX的にNG
など、「見た目通りに作ること」が目的になってしまうと、ユーザーや検索エンジンの評価を落とすこともあります。
つまり、見た目を重視しすぎるあまり、考えることを放棄してはいけないということです。
まとめ
- デザインカンプは「静止画」であり、情報の抜けや仕様の未定部分も多い
- 特にレスポンシブやスマホ設計では、構造設計のスキルが問われる
- 完コピを目指すのではなく、「目的に合う再現」を心がける
- 不明点は早めに相談・提案して、手戻りを防ぐ
慣れないうちは、デザインカンプを見て「こんなの無理でしょ」と思うこともあるかもしれません。
私自身、何度も思ってきました。
でも経験値が増えると、デザインカンプを見ただけで、頭の中で実装のイメージがわくようになってきます。
だから慣れるまではとにかく数をこなしましょう。
そして少しずつ改善していきましょう。
そうすれば、必ずコーディングスキルは伸びていくはずです。