エンジニアが「それ実装できません」と言う理由｜デザイナーとの認識ズレを埋める方法

こんにちは！

今日は「エンジニアが『それ実装できません』と言う理由」について、僕の実体験を交えながら解説します。

デザイナーの「できそう」とエンジニアの「実装難」のズレ

僕も昔は、デザイナーからの提案に対して「えっ、これできるの？」と驚くことが多かったんです。
いや、むしろ「これは実装できません」と断ることもありました。
ほんまに申し訳ない対応やったなあと思うんですが、その時の僕は「なぜできないのか」を上手く説明できていなかったんですよ。

現場でよく見るのは、こういうシチュエーションです。

• デザイナー: 「ホバーで要素が360度回転するアニメーション」
• エンジニア: 「そのアニメーションは理想的なのですが、パフォーマンスの問題で…」
• デザイナー: 「えっ、でもAfter Effectsでできてますけど…」

この会話、めっちゃ「ズレ」が起きてるんです。
デザイナーにとっては「見た目でできてる＝実装できる」って感覚になりやすいんですが、エンジニアの頭には「ブラウザ互換性」「読み込み速度」「ユーザーのデバイス性能」といった複数の制約が常に存在しているわけです。

エンジニアが最初に確認する3つのポイント

エンジニアが「実装できません」と言う時、実は背景に3つの確認事項があるんです。
これを理解するだけで、デザイナーとの会話がめっちゃ変わります。

1. ブラウザ対応範囲の制約

これが一番難しい部分です。
例えば、backdrop-filterというCSSプロパティがあるんですが、これはモダンブラウザ（Chrome、Safari、Edge）では素晴らしく動きます。
でも、もし古いスマートフォンやInternet Explorerに対応する必要があると、全く別の実装方法を考え直さないといけないんです。

デザイナーからすると「えっ、そんなの知らんわ」ってなりやすいんですが、これが現実です。
ディレクターや営業から「IE対応が必須です」って言われた時点で、デザインの実装方法は180度変わることもあります。

2. パフォーマンスと画面サイズ

美しいアニメーションや複雑なエフェクトって、確かに見栄えがいいんです。
でも、モバイル環境（特に低スペックの機種）で同じクオリティを出そうとすると、めっちゃ重くなることがあります。

僕が過去に経験した失敗ですが、デザイナーが提案した「複雑なパーティクルエフェクト」を実装したら、モバイルで30fpsまで落ちちゃったんです。
その結果、全部作り直しになりました。
初期段階で「このデバイスで想定される表示速度はどれくらい必要か」って相談しておけば、そんなことにはならなかったんですよ。

3. 実装にかかる時間的コスト

「技術的には可能だけど、実装に2週間かかります」ってエンジニアが言うことがあります。
これって、デザイナーからすると「単なる怠慢」に見えるかもしれません。
でも、実際には複雑なロジックやAPI連携、テストが必要だったりするんです。

その時間的コストが、プロジェクト全体のスケジュールに影響する場合、「実装できません」=「このスケジュール内では実装できません」という意味になるんですよ。

僕が失敗した「聞き方」と成功した「聞き方」

ここからは、僕が実際に経験した良い例と悪い例を話します。

失敗例: 一方的に「できません」と言うだけ

新人時代、僕はこんな返答をしていました。

デザイナー: 「この画像、マウスホバーで斜めに傾く動きで」
僕: 「それ、CSSのtransformで傾けると、内側の画像も一緒に傾いちゃうので、実装できません」

この返答、何が悪いかわかりますか？
デザイナーはめっちゃモヤモヤしますよね。
「なんで？できそうなのに」って思われる。
そしてそこから建設的な話し合いが生まれないんです。

成功例: 代替案を提示しながら説明する

今、僕はこう返答するようにしています。

デザイナー: 「この画像、マウスホバーで斜めに傾く動きで」
僕: 「素晴らしいアイデアですね！ただtransform: skew()を使うと内側の要素も傾いちゃんです。そこで2つの案があって、1つ目は親要素と子要素を分けて、親だけを傾ける方法。2つ目はclip-pathを使う方法です。どちらがデザイン的にしっくり来そうですか？」

同じ「できません」でも、こう言うことで相手の反応が180度変わります。
デザイナーも「あ、エンジニアなりの制約があるんだな」って理解してくれるし、一緒に解決策を考える雰囲気になるんですよ。

双方の視点を持つコミュニケーション術

最後に、実務レベルで役立つコミュニケーション術を3つ紹介します。

早期段階で「技術的な相談」をクセづける

デザインが完成した段階で「これ実装できます？」と聞くのではなく、デザインのコンセプト段階から「こういう見た目を想定してるんですが、技術的にはどんなことが考えられますか？」って相談するんです。

この「予防線」を引いておくだけで、後々のトラブルが大幅に減ります。

「できない理由」を聞き出す前に「制約条件」を共有する

プロジェクト開始時に、以下を明確にしておくといいですよ。

• 対応ブラウザは何か（IE対応の有無など）
• 想定ユーザーのデバイスは何か
• 読み込み速度の目標は何か（Lighthouse スコアなど）
• 実装期間にどの程度の余裕があるか

これがないと、デザイナーは「実装できる」ものだと勝手に想定してデザインしちゃいます。

デザイナーもエンジニアも「相手の言語」を学ぶ

これは僕からのお願いなんですが、