デザインとエンジニアリングを「繋ぐ」部分と「切り分ける」部分
これは Qiita Advent Calendar 2021 「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア」の2日目の記事です。
---
株式会社スペースマーケット所属のデザイナーの中原です。
スペースマーケットというWebサービスの開発に携わっています。
お鍋には必ずウインナーを入れます。
どんな内容？
デジタルプロダクトの開発において、デザインとエンジニアリングは密に連携して協業する（シームレス）のが良いとは言うものの、目指すものの違いがあることは認識しておくと良さそうだね、というお話。
分業で起きていた悩み
成果物や担当者がはっきり分かれがちだったデザインとエンジニアリングの間では、次のような問題がよく見られます。
デザイナーとエンジニアで認識が揃っていない、情報がうまく伝わらない
同じプロダクトを扱っているのに成果物・情報がデザインとエンジニアリングで分かれる（2重管理になる）
チームが分かれているので、お互いの作業待ちが大きくなりやすい・イテレーティブな開発がやりにくい
エンジニアとデザイナーの協業、みたいな話題がなくならないのも、こういった課題感がまだまだ世の中に残っていることの現れだと思います。
エンジニアリングとデザインのつなぎ目がなめらかになりつつある
当然同じプロダクトを開発するチームなので、同じ情報を共有し、同じアウトプットを触りながら開発をすすめるほうが齟齬も発生しづらく開発効率も上がるわけです。
どうやってデザインとエンジニアリングをスムーズに行うか、という部分ではいろんな知見が溜まってきているようで、最近は特に「UIデザインをコードにスムーズに落とし込めるか」をという部分においてのソリューションをよく見かけるような気がします。
例）
実装される時のコンポーネント構造やパターンがFigma上で既に表現されている（AutoLayoutやVariantなどをうまく組み合わせて）
Figmaやデザインシステムで定義されたDesign Token（カラーやタイポグラフィの定義など）がGitHubと同期している
いわゆる“デザインデータ”を管理せず、UIデザインを行う場合はコードで表現されたページをFigmaに落とし込んで修正する（デザインデータとコードの2重管理をやめる）
こういったソリューションを用いることは、デザイナーとエンジニアが同じものを見ることで共通理解を深めたり、一つのソースを共有・管理することで開発効率を上げることに繋がります。
デザインツール自体がそういった狙いを持っているものも増えてきましたよね。
「実現方法の検討」はデザインを妨げるか？
前述したような「デザインとエンジニアリングがシームレスになっていく」流れは大歓迎なのですが（このアドベントカレンダーに参加している皆さんは特にそうでしょう）、この境界が曖昧になっていく中で気になっているのが「価値の最大化（拡張）と価値の確立（収束）といった工程ごとの目的も曖昧になってしまうのでは？」という点です。
めっちゃ雑ですが、デザインは「ユーザーにより良いものを提供するためにこだわる」といった価値の最大化（拡張）を目指すものだと言えます。
逆に、エンジニアリングは「目的を達成するために具体的な方法を提供する」といった実現に向けての価値の確立（収束）を目指すものとだと言えます。
※あくまで一般的にはそういう傾向が強いんじゃないかという話です〜
今までデザイナーはある意味自然とエンジニアリング（コード）と切り離されたところでデザインを行なうことが多かったと思います。ノートやデザインツールを開いて、ユーザーにとっての価値を最大化するにはどうすればいいかにこだわる。もちろん実装可能かどうかなど考慮はしますが、価値の「最大化」と「確立」という2つが工程や役割として分かれていたためデザインの目的が明確でした。
しかし今後デザインとエンジニアリングの工程が曖昧になっていくにつれ、意識しないと自分が「最大化」と「確立」のどちらのデザイン（設計）を行なっているのか曖昧なまま進めてしまう危険性があるなと。
無意識のうちに実現方法を考慮しすぎて価値の最大化を十分に検討できなかった、ということは特に発生しやすいかなと思っています。
なんでこんなことを書こうかと思ったかというと、自分の中でもう上記のようなことが起きてしまっていたからです。
私はもともとエンジニアからデザイナーになったこともあり、どうしても「実現可能な範囲の中でどう具現化しようか」という考えが先に来てしまい、価値を最大化するというプロセスがおざなりになってしまうことが多々ありました。
価値を確立する・具体化するという取り組みは人に評価されやすいこともありつい急いでしまうのですが、それがプロダクト（ユーザー）にとってベストかどうかはまた別の話であり、価値の最大化はデザイナーが一番責任を持って取り組むべきものだと思っています。
最大化のために「揺さぶり」をかける
プロダクトの可能性を狭めないためには、やはりデザインに「揺さぶりをかける」ことが重要になってくるかなと思っています。
開発としてのつなぎ込みはシームレスを目指す、でもデザインの目指すべき価値の最大化につながる可能性を探り続ける。
例えば、似たような事例を探す、そもそものニーズについて再考してみる、違う提供方法を検討する、ユーザーから情報を得る…
当たり前のことなんですが、UIデザイン（特に実装方法）に強く関心を持つデザイナーはより意識的にそういう時間やステップを設けると両輪のバランスがとれたデザインプロセスが構築できるのではないでしょうか。
余談：実装方法から生まれるアイディアももちろんある
なんか「実装方法を意識しすぎるといいデザインできないよ〜」みたいな感じの文書に見えちゃうんですが、「実装方法を知っているからこそ思いついた価値」みたいなものももちろんあるので。
あくまで実装や具体的な表現手法に縛られないようにしたいよね、ということです。
「最大化」に制約をかけるのはそれだけじゃない
少し話はずれますが、この「価値の最大化」を妨げうる要因はいっぱいあります。
工数、ビジネスKPI、リソース、意見の不一致、などなど…
デザインの現場では、そういったものを認識しながらいかに「最大化」に注力できるか、という努力が絶えず行われてきたように思います。
例えば、UXデザインという昔からデザイン文脈で当たり前に存在したものがなぜ改めて名付けられ切り出されたのか。
この「最大化」のプロセスの存在を強調したいということもあったのかなーとも思ったりしたのでした。
いかにこの最大化プロセスに重点を置きつつ、効率の良い開発、シームレスをめざすのか。デザインとエンジニアリングのいい関係を作っていくために、今まで以上に「ねらいを確認しながら進む」ことが求められるように思います。
ありがたいことに、現在ではいろいろな人がUI設計のような詳細を考えるものと要件・ビジネス・サービス構造設計といったような抽象度の高いものとを行き来しながらデザインしていく方法を公開してくれているので、それらを参考にしながら開発に取り組むのはいいかもしれませんね。
参考：
この記事が気に入ったらサポートをしてみませんか？