デザイナーがエンジニアの「できない」を理解する｜職種間コミュニケーションの実践テクニック

こんにちは！

今日は「デザイナーがエンジニアの『できない』を理解する」ということについて、僕の実体験をもとに解説していきます。

デザイナーの「いけるやろ」とエンジニアの「難しいんです」のズレ

Web制作会社に入りたての頃、僕も何度も経験してるんですが、デザイナーとエンジニアの認識の差ってほんまにあるんですよ。
特に多いのが「Figmaでこんな動きをしてるけど、実装できます？」って聞かれるパターンなんですけど、その時の返答の仕方で後のトラブルが決まるんです。

僕も昔は、「いや、それはブラウザの制約があってですね」って技術的な話ばっかりしてたんです。
でもよく考えてみたら、デザイナーは「Figmaで作れる＝Webでも作れるはずや」って感覚なんですよね。
そりゃそうや。デザイナーからしたら、デジタルキャンバスの上で動いてるんだから。

大事なのは「なぜできないのか」を、デザイナーの視点で説明してあげることなんです。
「技術的な制約」じゃなくて、「ユーザー体験」や「パフォーマンス」「ブラウザの仕様」みたいな、デザイナーが理解しやすい言葉で。

技術的な制約を「デザイン言語」で説明されたとき、僕がしていたこと

現場でよく見るのは、こういう場面です。
デザイナーが複雑なアニメーション効果をいっぱい詰め込んだデザインカンプを持ってきて、「ページスクロール時に、画像が回転しながらフェードインして、同時にテキストも動く」みたいな要件があるとします。

実装側としては、「めっちゃ重くなるし、スマホだと確実にカクつく」って思うわけです。
でも、デザイナーに「パフォーマンスの問題があります」って言っても、なかなかピンとこないことが多いんですよね。

そこで有効だったのが、実際に「重い状態」をデザイナーに見せてあげることなんです。
デザイン案通りに実装したページを、スマートフォンで見てもらう。
「ほら、こうやってカクカクになってますよね。ユーザーはこれをストレスに感じるんです」って、ビジュアルで理解してもらう。
そうすると、「あ、やっぱり調整しましょう」って自然に歩み寄ってくるんですよ。

もう一つ大事なのは「代替案を用意する」ってことです。
「これはできません」だけじゃなくて、「こういう代替えならどうですか？」って複数案を提示するんです。
例えば「全ての画像で回転させるのは難しいですが、メイン画像だけなら大丈夫です」とか、「スクロール時の複数同時アニメーションは重いので、段階的に動かすのはいかがですか」みたいな感じで。

実装可能性を早期に相談する仕組みづくり

根本的な解決は、デザイン段階での早期相談だと気づきました。
納品直前に「これ実装できません」って言うから揉めるんです。

今の僕たちのチームでやってるのは、デザインの初期段階（ラフスケッチとか、大まかなレイアウトの段階）で、「このアニメーション効果、実装的にはこういう制約があります」って情報を渡しておくことなんです。

具体的には、こんなドキュメントを作ってます。

• 「スクロール連動アニメーション：重いので、主要ページだけに限定する」
• 「複数の3Dトランスフォーム：CPU負荷が高い。iOSで特に注意」
• 「大量の影エフェクト：box-shadowを重ねると描画パフォーマンスに影響」
• 「フォント可変域：ブラウザ対応が限定的。フォールバック必須」

デザイナーはこれを見ながらデザインを進めるんです。
そしたら、「あ、このエフェクトはちょっと避けておこう」とか、「ここなら大丈夫そう」って判断できるようになるんですよ。

もう一つ効果的だったのが「実装サンプル」を共有することです。
「このくらいの複雑さなら大丈夫」っていう実例を、実際に動くコードで見せるんです。
そうするとデザイナーも「なるほど、この程度の動きなら実装できるんだ」って感覚がつかめるようになります。

まとめ

デザイナーとエンジニアの理解を深めるために一番大事なのは、相手の制約を「敵」として捉えるんじゃなくて、「ユーザー体験を守るための条件」として説明することなんです。

「できません」じゃなくて「この方法なら実現できます」って前向きに伝える。
技術用語じゃなくて、相手が理解しやすい言葉で説明する。
そして何より、早期段階でコミュニケーションを取ることで、後工程での大きなトラブルを防ぐことができるんですよ。

現場での小さなズレが、納品直前の大きなトラブルになることって、ほんまによくあります。
だからこそ、「なぜできないのか」を丁寧に伝える習慣をつけるといいですよ。