デザイナーが「実装不可」と言う理由を理解する｜エンジニアが知っておくべき視点

こんにちは！
今日は「デザイナーが『実装不可』と言う理由を理解する」というテーマで、現場で本当に起きてることをお話しします。

「実装不可」は拒否ではなく、大切な情報

僕も新人時代、デザイナーから「これ実装不可」と言われて、めっちゃムっときたことあります。
「なんで俺の技術を否定すんねん」って感じでね。
でも今になって思うと、あれは僕への否定やなくて、プロジェクトを守るための大切な警告だったんですよ。

デザイナーが「実装不可」と判断するのには、ほぼほぼ以下のような背景があります。

• ブラウザ互換性の問題（特に古いIEやSafariでの動作）
• パフォーマンスへの懸念（ページ速度低下のリスク）
• 保守性の問題（後で誰が修正できるのか）
• アクセシビリティの違反
• スケジュール内での実装が難しい

つまり、デザイナーは「できるかできないか」じゃなくて「このプロジェクトにとって本当に必要か、リスクはないか」を考えてるんです。
これに気付いたときに、僕の職人気質が少し丸くなりました。

デザイナーが見えてるものとエンジニアが見えてるものの違い

デザイナーが実装可能性を判断するとき、エンジニアとは違う視点を持ってます。
ほんまに大事なポイントなので、具体例を出しますね。

デザイナーが見てる世界：

• ユーザーの操作フロー全体（A→B→Cの流れで、どこで迷うか）
• 複数デバイスでの表現の統一性（スマホで同じ雰囲気が出てるか）
• アニメーション終了後の状態管理（派手なエフェクトが終わった後、どう見えるか）
• 時間経過による劣化（半年後、メンテなしで大丈夫か）

エンジニアが見てる世界：

• 技術的な実装の難易度（これをコード化できるか）
• 現在の環境での制約（使えるライブラリ、Node.jsのバージョン）
• バグが起きたときの原因特定（どこが壊れた？）
• パフォーマンス測定（実際のメトリクス）

この二つの視点ってめっちゃ大事で、両方がいないとプロダクトは質落ちするんですよ。
デザイナーの「実装不可」は、エンジニア視点では気付かなかったリスクを教えてくれてるわけです。

実装可能な提案に変える具体的な質問テクニック

では、デザイナーとの擦り合わせをスムーズにするために、僕が現場で実際に使ってるテクニックをお教えします。

1. 「なぜ実装不可か」を深掘りする

デザイナーが「これスマホで実装不可です」と言ったときに、本人に「具体的にはどこが難しいんですか？」って聞きます。
すると「横スクロール領域の中に position: fixed の要素が必要なんですけど、スマホだと横スクロールと競合しちゃう」とか、具体的な懸念が出てくるんです。
そしたら「じゃあ、スマホでは固定せずに吸着させる案はどう？」みたいな代案を一緒に考えられます。

2. 制約条件をはっきり伝える

逆に「実は今このプロジェクト、iOS 12以上限定でいいんですか？」って聞くことで、選択肢が増えることもあります。
「そっか、じゃあこの最新CSS機能使えますね」ってなったりするんです。

3. 段階的実装の提案

「1次リリースではこのシンプル版で行って、2次以降にグレードアップさせる」みたいな段階的なアプローチを提案するのも有効ですよ。
デザイナーとしても「じゃあそれなら納得できる」ってなる場合が多いです。

4. 実装例を見せる

言葉だけで説明するより、実装の試作品や参考事例を見せるほうがめっちゃ話が早いです。
「こういう表現なら技術的には可能です」って、実物を見ると、デザイナーも代案を出しやすくなります。

まとめ

デザイナーの「実装不可」は、プロジェクトの品質を守るための大切な判断です。
エンジニアからすると歯がゆく感じることもあるかもしれませんが、実は両職種が協力することで、もっといいプロダクトが生まれるんですよ。

大事なのは「できない理由」を一緒に探すんじゃなくて、「どうしたらいけるか」を一緒に考えることなんです。
そのためには相手の視点を理解することが、めっちゃ重要。
デザイナーが何を心配してるのか、その背景にある「ユーザー体験」や「プロダクト品質」を想像する癖をつけるといいですよ。