デザイナーとエンジニアで語った「バッドな事例」について #PERSOL CAREER Advent Calendar2025

はじめに：なぜ「グッド」ではなく「バッド」を語るのか
1. 実装とデザインの「見えない」溝
2. 運用とコミュニケーションの「落とし穴」
- ② ビジネス要件の「メテオフォール」
3. QCD（品質・コスト・納期）について
- QCD（品質・コスト・納期）の優先度
最後に：AI時代における「バッドな事例」と「経験」の価値
- AIの苦手な分野
- 人間の役割

今年のDeveloper＆Designer Advent Calendar 2025の20日目を担当する、エンジニアの金子広大です。

今年は「デザイナーとエンジニアで語った「バッドな事例」について」について、まとめました。

はじめに：なぜ「グッド」ではなく「バッド」を語るのか

世の中には多くの「ベストプラクティス」の情報が溢れています。
それは、デザインやエンジニアリングの世界だけに限らず、他の業界でも同じことが言えるのかもしれません。

もしくは「歴史は勝者によって書かれる」と言う言葉に表れている通り、人は成功したことだけを得てして語りたがるものなのかもしれません。

しかし、実際の現場で私たちが向き合わねばならないのは、「なぜこんなことが起きたのか？」と真剣に検討すべき「バッドな事例」についてです。

この記事では、エンジニアとデザイナーが実際に直面した「バッドな事例」をあえて言語化しました。

そしてこれらを単なる失敗談に終わらせるのでははなく、プロダクトを健全に保つための「転ばぬ先の杖」にするためのモノになります。

それでは、報告されたバッドな事例を見ていきましょう！

1. 実装とデザインの「見えない」溝

画面上では美しく見えても、コードの裏側で悲鳴が上がっているケースがあります。

① レイアウトの「マイナスマージン」と「浮遊する要素」

【報告されたバッドな事例】

「ここの余白、ちょっと詰めたいから」とマイナスマージンを多用したり、スライダーのナビゲーション（矢印）を微妙な位置にフローティング配置するケース。

【なぜバッドなのか】

これらは典型的な「実装の負債」となります。特にフローティングオブジェクトは、画面幅が変わった瞬間に崩れやすく、その「微妙な位置調整」のためにフレームワークの標準挙動を捻じ曲げる必要が出てきます。結果、保守コストが跳ね上がります。

【考えられる解決策】

デザインガイドライン（余白ルール）からはみ出る時は、その理由をエンジニアと相談する
「絶対配置」が必要なデザインは、実装難易度とトレードオフであることを認識する
（基本的には「position:absolute」が必要になるケースはほとんど無いと思います）

② SP/PCでの「別コンポーネント化」の罠

【報告されたバッドな事例】

「スマホとPCで体験を変えたい」という理由で、全く異なる情報構造やレイアウトを採用する。

【なぜバッドなのか】

画面サイズに合わせて見せ方を変えるのは重要ですが、度が過ぎると「一つの機能なのに、実装上は別々のコンポーネント」として管理することになります。修正が発生した際、作業量は2倍になります。

【考えられる解決策】

レスポンシブで対応可能な範囲のデザインに留める。
構造を変える場合は、その管理コスト（2倍）に見合うビジネス価値があるか検証する。

③ アニメーション関連

【報告されたバッドな事例】

「クルッと回ってシュッと出る」ような、感覚的で複雑なアニメーションを工程の後の方で要望する
苦労して導入したわりに、効果があったのかよくわからない

【なぜバッドなのか】

十分な理由でアニメーションを導入していない
明確な仕様について話せていない
効果を計測しようとしない

補足:
Reactなどのモダンなフレームワークは、DOM（画面の要素）を仮想的に管理・使い回すことで高速化しています。そこにアニメーションという「直接的な動き」を無理やり組み込むのは相性が悪く、実装難易度が高くなるケースがあります。
Lottieなどのライブラリなどで解決できる場合もありますが、事前に技術的なフィジビリティや検討をしてから見積もりをする方が良いかと考えられます。

【考えられる解決策】

「アニメーションの採用理由」を明確にする。演出に価値があるのか、実装コストを掛けてでもやるべきか検証する。「目立たせたいから」などではなく、サービスの世界観に合わせたものを検討し、妥当性の高いものを採用する。
エンジニアに対し、擬音（クルッと・シュッと）ではなく、参考サイトや具体的な動きのパラメーターで伝える。
可能であれば、アニメーションを入れた前後の効果測定を行う。

※ 最近はAIによるサポート（特にFigmaMake）などを適切に受ければ、実装の提案と一緒に具体的なパラメーターを提示してくれます。

2. 運用とコミュニケーションの「落とし穴」

後述しますが、事前に取り決めておくだけで防ぐことができるバッドな事例がたくさんあります。

実開発に取り組む側としては「安請け合いをしない」「安請け合いが出来ない」ことと、その理由を正確に伝えることが大事です。
また、チーム全体としては、そう言った耳の痛いことも話し合える「信頼」や「心理的安全性」の確保も肝心だと言えるでしょう。

① 「静的テキスト」だと思っていたら…（情報の出所について）

【報告されたバッドな事例】

デザイン上のただのテキストだと思って無邪気に追加したが、実装のコストしか見ていなかった。
（運用のコストを認識できてなかった）

【なぜバッドなのか】

情報の出所によって、運用コストが大きく変化するから。

静的テキスト： コストほぼゼロ。
DBからの情報： API開発が必要。場合によってはDBのカラムの追加などが必要。
管理画面が必要な情報： 管理画面UI作成＋ API開発＋運用フロー策定＝コスト特大

【考えられる解決策】

デザインに着手する前に、以下のようなフローで「情報の出所」を確認し、コストに見合うものであるかを確認しましょう。

② ビジネス要件の「メテオフォール」

【報告されたバッドな事例】

開発終盤になって突然、「関連サービスへの送客KPI」のような重たいビジネス要件が空から降ってくる（メテオフォール）。

【なぜバッドなのか】

文字通り、積み上げたUIや設計が壊滅します。「ビジネス要件が決まっていないなら、稼働しない」くらいの覚悟が必要です。

【考えられる解決策】

プロジェクトの最上位ゴールとKPIは最初に固める（先に話しておく）
「あと出しジャンケン」のリスクを可視化し、発生した場合は納期か品質を見直すことを合意しておく。

3. QCD（品質・コスト・納期）について

QCD（品質・コスト・納期）だけが指標ではないですが、これらはシステムがビジネスに関連する以上、とても大事な指標になります。
サービスオーナーなどの立場からだと「すべての項目を優先させたい」と言いたくなるでしょうが、それは「すべてを優先させない」ことと同義になると言えます。
チームのなかで明確な優先順位を、早い段階で先に決めることが理想です。

QCD（品質・コスト・納期）の優先度

【報告されたバッドな事例】

品質を犠牲にしてスピードを取る判断をした結果、どんどん技術負債が積み上がる
そもそもの優先度も決まっていないので、ここでも後出しじゃんけんで物事が決まってしまう

【なぜバッドなのか】

技術的な負債が積み上がり、品質・コスト・納期の全てが低下していくことになる。

【考えられる解決策1: トレードオフスライダー】

具体的には、早い段階でトレードオフスライダーなどを用いて、QCDの優先度を決めるのが理想です。

また、事業のフェーズによっては最適な優先度は変化します。
半期か、1年ごとに現場を踏まえて議論をするのが理想だと言えるでしょう。

【考えられる解決策2: ユリシーズ契約】

誘惑に負けて「品質を犠牲にしてスピードを取る」判断をした場合、その負債をいつ返すのか。
その取り決めを先に決めておくために「ユリシーズ契約」と言う考えがあります。

「今回は品質を落とすが、来月のスプリントで必ずリファクタリングの時間を取る」
「これ以上の仕様追加は、リリースの延期とセットでなければ受け入れない」

このように、理性が働いている正常な時に、あらかじめ「未来の行動」を契約などで拘束しておくことで返却するリソースをあらかじめ確保しておきます。

最後に：AI時代における「バッドな事例」と「経験」の価値

最後に、筆者が「バッドな事例」をまとめていくなかで、今のようなAIが興隆してきた時代における「バッドな事例」と人間ならではの「経験」に価値が有るのではないかと思い至ったので、それを記載して末筆とさせて頂きます。

AIの苦手な分野

昨今、AIがコーディングもデザインも他にもさまざまなことをサポートしてくれるようになりました。
しかし、AIは基本的に「究極のYESマン」であり、能力が高いですが出されたプロンプトに対して反論することはありません。

反論することが苦手なので、以下のようなケースに弱いと言えます。

1. 質問の意図と内容が食い違っている
例) 統計の質問で本来の意図としては[中央値] を求めるべきなのにプロンプト上の指示では[平均] を求めている
2. そもそもの道筋が悪い方向へ進もうとしている
例) システムのコーディングを依頼し、コード自体は綺麗に生成されたが、それをリリースすると仕様面での負債を溜め込む結果になる
3. 必要な情報が書かれていない 

「SCoRe」（Self-Correction via Reinforcement Learning）などによる自己修復、思考の連鎖（Chain of Thought）をして単一のAIの中で思考を深めたり、複数のAIを利用して監視させる（Multi-Agent）などの手段はあります。

しかし、最初の指示が良くないと、AIは「補正」や「確認」のために余計な計算（トークン）を消費し、回答までの時間が遅れることは明らかです。
また、修正が成功しなければハルシネーションの発生は抑えられないでしょう。

VibeCordingの弊害事例などもありますが、間違った方向により進捗させてしまうこともAIの力であると言えるのが現状だと考えています。