JIRAIZUKAN

デザインOKの後に始まる実装不能の地獄

「このデザイン、どうやって動かすんですか？」

実装メンバーのその一言で、打ち合わせ室の空気が一変。
誰もが目をそらし、沈黙する──なぜならそのデザインは、すでにクライアントへ提出済み＆OK済みだったから

クライアントのリアクションは最高。「めちゃくちゃいい感じです！これでお願いします！」
こちらも「よし、決まった！」と胸をなでおろした直後に、プロジェクトの致命傷が見つかる

「これ、技術的に対応できないかもですね……」
「そもそもCMS構造に合ってないです」
「このアニメーション、フロントだけじゃ無理です

この瞬間から、もう戻れない“詰み案件”が始まってしまうのです。

ケーススタディ

ケース1：まさかの“実装相談ゼロ”でデザイン確定

「実装できるか一応コーダーに聞こうと思ってたんですよね」
そうつぶやいたのは、すでにデザインが全確定した後。相談されていなかったコーダーは実装段階で詰まり、対応不能に。動かない、整わない、仕組みにすべて“事前のひと声”があれば避けられたミス。設計と実装が分断されたまま進むとこうなる。

ケース2：ビジュアルOK＝プロジェクトOKではない

営業やディレクターが「デザイナーがOKなら大丈夫」と判断して進行してしまうケース。
しかしその裏で、コーディング目線のチェックは一切されていないことも珍しくありません。このまま制作が進むと、後から「実装できません」「仕様を変えるしかない」という“地獄ルート”に直行。誰が何を確認したのか、そのプロセスを意識せずに進むと、手戻りの代償は大きくなります。

ケース3：「クライアントに“夢”を見せすぎた結果」

Figmaでマイクロアニメーションも完璧に再現し、デザインに“夢”を乗せすぎた。
クライアントも「うわ〜ステキ！」と大満足で即決OK。
でも、その夢を現実にするには実装時間も工数も倍。現場は悲鳴、スケジュールは炎上。

解説

このトラブルが起きる背景には、「見た目のOK＝プロジェクトのGO」という誤解があります。

特に以下のようなケースが危険信号：

• ・デザインが良かったからとそのまま提出
• ・クライアントもその提案に惚れ込んで即決
• ・実装側への相談は、提出“後”に初めて行われる

この段階で「ちょっと無理があるかも…」と発覚しても、もう誰も止められない。
なぜなら、クライアントの“OK”は絶対だから。

変更をお願いするには理由が要る。
でもその理由が「技術的に難しい」だけだと、「なぜ事前に確認してくれなかったのか？」という信頼の問題にすり替わる。
つまりこのトラブルは、ただの実装リスクではなく、関係性リスクでもあるのです。

解決策

クライアント提出前の「実装者レビュー」をマストに

どんなに小さなパーツでも、「動く前提で見せるなら、動くかどうかの確認を」。
デザイン提出直前の5分でも、コーダー・フロント・エンジニアに目を通してもらうことで、詰みの未来は大体防げます。

「デザイン＝仕様確定」ではないことを共有

特に表現にこだわった動き・アニメーションは、「視覚上の提案であり、仕様は後日確定」など、あえて曖昧にしておくテクニックも有効。

「OK出したからもう戻れない」文化をなくす

チームやクライアントとの関係性にもよりますが、“確認”ではなく“仮了承”という言葉を使うのも手。
万が一の変更を見越した“余白”を、あらかじめ作っておくとリカバリが効きやすくなります。

責任の所在をあいまいにしない

「提出の最終責任は誰が持つのか」「そのOKは“見た目”だけのOKか」プロジェクトのフローに合わせて、その線引きを明確にしておくことで、責任のグレーゾーンをなくせます。

まとめ

クライアントがOKを出したあとに、実装できないと判明した。このパターンの破壊力は、本当に大きい。

プロジェクトの初動がうまくいっていても、一瞬で空気が変わる。誰も悪くないはずなのに、全員が責任を感じて、全員が疲れる。

そして何より、クライアントに「なんで今さら？」と思わせてしまうことが、プロとして一番ダメージが大きい。

だからこそ、

• ・デザインを提出する前に、必ず技術面の実現性チェックを入れる
• ・提案の段階では「これはまだ検討中」というスタンスを残す
• ・チーム全員が「これは大丈夫か？」と声をかけ合う文化をつくる

プロジェクトが前に進んでいるときこそ、慎重さが必要です。
“そのOK、本当に動かせるの？”と、ひと呼吸おく勇気を

未来の自分たちを地獄から救えるのは、“今の自分たち”しかいません。