FASTCODING BLOG

株式会社ファストコーディングで営業を担当しています長谷川と申します。お客様とお話ししていて気づいたことや、フロントエンド開発・コーディング制作界隈で最近流行っていることを書いていこうと思っております。どうぞ宜しくお願いします。

今回のテーマは「デザインの再現性」です。営業として20年以上この業界にいますが、お客様やデザイナーさんから一番多くいただく質問は、間違いなくこれです。

「このデザイン、そのまま再現できますか？」

この質問自体は何も悪くありません。むしろ、品質を大切にしているからこそ出てくる言葉です。ただ、この質問の裏には「デザインデータ通りにピクセル単位で再現される」という期待が隠れていることが多いものです。実際にはそう単純ではないケースがほとんどです。

今回は、営業の立場からこの「デザイン再現性」について正直にお話しさせてください。デザイナーの方にもディレクターの方にも、知っておいていただきたい内容です。

「再現できますか？」に対する営業の本音

正直に言いますと、この質問を受けたとき、私は即答を避けるようにしています。

「できます」と即答するのは簡単です。しかし、それは不誠実な対応だと思っています。なぜなら「再現できるかどうか」は、デザインの内容と実装条件によってまったく変わるからです。

あるアパレルブランドのサイトリニューアル案件で、こんなことがありました。デザイナーさんが作った美しいビジュアルコンプが届いて、お客様は大変気に入っていらっしゃいました。

「このデザイン、完璧に再現してくださいね。ブランドイメージに関わりますから」

お客様のお気持ちはよくわかります。ただ、そのデザインにはいくつか気になる点がありました。テキスト部分にWebフォントとして提供されていない書体が使われていました。さらに、背景の複雑なグラデーションがPC・タブレット・スマートフォンで同じ比率のまま表示される前提で作られていました。

私はお客様にこうお伝えしました。

「デザインの方向性は100%再現いたします。ただ、ブラウザやデバイスの仕様上、調整が必要な箇所がいくつかございます。事前にお伝えしておいたほうが、あとで『思っていたのと違う』となるリスクを防げます」

結果として、事前にすり合わせたことで公開後のトラブルはゼロでした。

デザインが「そのまま」再現されない3つの理由

デザイナーさんやディレクターさんから「なぜ再現できないんですか？」と聞かれることがあります。これは責めているわけではなく、純粋な疑問です。ここで、コーディングの現場で何が起きているのかをお伝えします。

理由1：ブラウザごとの表示差異がある

デザインツールはPhotoshopでもFigmaでも、1つの固定された環境で表示されます。しかしWebサイトは、Chrome、Safari、Firefox、Edgeなど複数のブラウザで表示されます。ブラウザごとにCSSの解釈が微妙に異なるため、同じCSSを書いてもフォントのレンダリングやline-heightの計算結果が少し異なります。

あるコーポレートサイトの案件で、こんなことがありました。

「Chromeでは完璧なのに、Safariで見たらボタンの角丸が微妙に違うんですけど」

デザイナーさんが検証中に気づいて連絡をくれました。これはSafariのborder-radiusのレンダリング方式が異なることが原因でした。エンジニアが調整して解決しましたが、こうした差異はブラウザのアップデートでも変わります。完全な「ピクセルパーフェクト」は、Webの仕組み上、実現が難しいのです。

理由2：レスポンシブ対応で可変する

Figmaのカンプは固定幅でデザインされます。しかしWebサイトの閲覧環境は、320pxのスマートフォンから2560pxの4Kモニターまでさまざまです。デザインカンプが1280px幅で作られていても、実際の表示幅は無段階に変化します。

ここで大きな問題になるのが「デザインカンプにない画面幅」の扱いです。たとえばPC版が1280px、スマートフォン版が375pxでデザインされていたとします。では769pxのときはどう見えるのか。これは誰も指示していないケースが多いのです。

私の経験上、この「中間の画面幅」でトラブルになるケースが非常に多いです。エンジニアが自分の判断で処理するか、デザイナーに確認するかで、工数もスケジュールも変わってきます。

理由3：テキストは「画像」ではない

デザインツール上のテキストは、フォントサイズ・行間・字間がピクセル単位で固定されています。しかしブラウザ上のテキストは、ユーザーの環境によって変わる可能性があります。

具体的には、以下のような要因で表示が変わります。

ユーザーがブラウザの文字サイズ設定を変更している
OSのフォントレンダリング方式が異なる（WindowsとmacOSではフォントの太さが違って見える）
指定したWebフォントが読み込めなかったときにフォールバックフォントで表示される
テキストの内容が更新されて、想定していた行数に収まらなくなる

特に多いのが、WindowsとmacOSでの見え方の違いです。デザイナーさんの多くはmacOSで作業されますが、エンドユーザーの多くはWindowsを使っています。macOSではきれいに見えたフォントが、Windowsでは少し太く、あるいは少しかすれて見えることがあります。

「Macで確認したときは良かったのに、Windowsで見たら全然印象が違うんですが……」

お客様からこういったご連絡をいただくことは、少なくありません。

営業が果たす「クッション役」の仕事

ここからは、少し営業の裏側をお話しさせてください。デザイナーとエンジニアの間に立つ営業の仕事についてです。

デザイナーを守るための「翻訳」

デザイナーさんがこだわって作ったデザインに対して、エンジニアから「これは実装が難しい」というフィードバックが返ってくることがあります。このとき、営業がどう伝えるかが重要です。

エンジニアの言葉をそのままデザイナーに伝えると、「自分のデザインを否定された」と受け取られかねません。逆に、デザイナーの意図を無視してエンジニアの都合だけで変更すると、デザインの品質が下がります。

私がやっているのは「翻訳」です。エンジニアの技術的な制約を、デザイナーの言葉に変換してお伝えします。

たとえばエンジニアが「このアニメーションはGPUレンダリングの負荷が高くて、低スペックのスマホではカクつく」と言ったとします。これをそのまま伝えても、デザイナーさんには判断材料になりません。

こう伝えます。

「このアニメーションはPCではきれいに動きます。ただ、古いスマートフォンでは動きがぎこちなくなる可能性があります。滑らかさを保ちつつ、少しシンプルな動きに調整する案をエンジニアに作ってもらいました。AとBの2パターンありますので、ご確認いただけますか」

こうすると、デザイナーさんは「代替案から選べる」ので、デザインの主導権を維持したまま技術的な制約に対応できます。

お客様を守るための「事前説明」

もう一つ大事なのが、お客様に対する事前説明です。

コーディングが完成してから「デザインと違う」と指摘されると、修正工数が発生します。場合によってはスケジュールの遅延にもつながります。しかし事前に「ここは調整が入ります」と伝えておけば、お客様も心構えができます。

私が過去に対応した金融系のサイトリニューアルでは、コーディング着手前にこんな資料を作りました。

デザインカンプから変更が入る可能性のある箇所の一覧
変更理由（ブラウザ対応、レスポンシブ、アクセシビリティ）
代替案と推奨案

この資料を事前にお客様に共有したところ、コーディング完了後の修正依頼がほぼゼロでした。お客様からはこう言っていただけました。

「先に説明してもらえたから、安心して任せられました。他の制作会社では、こういう説明は一切なかったです」

事前説明は手間がかかります。しかしその手間が、お客様の信頼と、制作チームの精神的な負担軽減につながります。

デザイナーがトラブルを避けるための3つの確認ポイント

ここからは、デザイナーさんに向けたお話です。私が現場で何百件もの案件を見てきた中で、「これを事前に確認してくれていたらトラブルにならなかった」というポイントを3つにまとめました。

確認ポイント1：使用フォントがWeb上で利用可能か

デザインツール上で美しく見えるフォントが、Webフォントとして使えるとは限りません。ライセンスの問題もありますし、日本語フォントはファイルサイズが大きいため、表示速度に影響するケースもあります。

確認すべき項目は以下の通りです。

そのフォントはGoogle FontsやAdobe Fontsで提供されているか
日本語フォントの場合、サブセット化（必要な文字だけを抽出）は可能か
フォントが読み込めなかった場合のフォールバック指定はどうするか
フォントのライセンスがWeb利用を許可しているか

これらを事前にエンジニアと確認しておくだけで、コーディング段階での手戻りが大幅に減ります。私の経験上、フォント関連のトラブルは制作トラブル全体の約2〜3割を占めています。

確認ポイント2：レスポンシブの「中間状態」を定義しているか

先ほども触れましたが、PCとスマートフォンの2サイズだけでデザインが作られているケースが多いです。しかし実際のユーザーは、タブレットや横向きのスマートフォン、小さめのノートPCなど、さまざまなサイズでサイトを閲覧します。

特に確認が必要なのは以下の点です。

タブレット（768px〜1024px）でのレイアウト方針
テキスト量が増減した場合のレイアウトの伸縮ルール
画像のアスペクト比が変わる場合の処理（トリミングか余白か）

すべての画面幅のデザインカンプを作る必要はありません。ただ「この部分はPCの3カラムをタブレットでは2カラムにする」「このセクションはスマートフォンでは非表示にする」といった方針だけでも、エンジニアの判断がスムーズになります。

ある教育系のサイト案件では、デザイナーさんがFigmaのコメント機能で「769px以下はカード型に切り替え」「画像はobject-fit: coverでトリミング」といったメモを残してくれていました。そのおかげで、エンジニアからの質問がほとんど出ず、コーディング工程が予定より早く終わりました。

確認ポイント3：アニメーションや動きの仕様を明記しているか

最近のWebサイトでは、スクロールアニメーションやホバーエフェクトを取り入れることが増えています。ただ、デザインカンプは静止画なので、「動き」の情報が抜け落ちることがよくあります。

確認すべき項目は以下の通りです。

ホバー時の変化（色の変化、拡大、影の追加など）の具体的な内容
アニメーションの速度とイージング（ゆっくり始まるのか、一定速度なのか）
スクロール連動の演出がある場合、トリガーとなるスクロール位置
アニメーションを無効にする条件（prefers-reduced-motionへの対応方針）

最後のアクセシビリティへの配慮は特に重要です。前庭障害をお持ちの方にとって、過度なアニメーションは身体的な不調を引き起こす可能性があります。OSの「視差効果を減らす」設定を有効にしているユーザーに対して、CSSのprefers-reduced-motionメディアクエリで動きを抑制する実装は、現在では標準的な対応です。

こうした仕様をプロトタイプツールや動画で共有するか、テキストで明記してもらえると、実装側の解釈違いがなくなります。