エンジニアとデザイナーが幸せに協働するための6つの処方箋

※この記事は[モチベーションクラウドシリーズ Advent Calendar 2020](https://qiita.com/advent-calendar/2020/mcs "モチベーションクラウドシリーズ Advent Calendar 2020")の11日目の記事です。
今回は**エンジニアとデザイナーが協働するためのポイント**を、**デザイナーから見て有難かったエンジニアの言動**を交えてご紹介します。

モチベーションクラウドのデザイナーです。
デザイナーとエンジニア（特にフロントエンド）は、切っても切れない関係ですが、壁を感じることも少なくないと思います。例えば、こんなやり取りを見たことはないでしょうか？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/8dae1957-d2ca-d244-1843-9723d5d778e3.png)
なお、こちらは実際に私がやってしまった失敗です。笑　こうした「分かり合えない」壁を超える上で、エンジニアの方にたくさんサポートをいただいた経験から、協働のポイントをまとめてみました。

対象：
・エンジニアとの協働がうまくいかない**デザイナー**
・デザイナーとの協働をスムーズにしたい**エンジニア**


# 6つの処方箋
### 1. 背景・判断基準を伝える
ありがちな失敗：エンジニアから聞かれたことだけに答える
![1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/772ea86e-c44a-045d-874f-5ac802907564.png)
不明点に対して一問一答的に答えられても、判断基準が分からず毎度確認の手間がかかってしまいます。
「～（背景・判断基準）だから、～（対応方法）したい」と併せて伝えることで、場合に応じた最適な方法を一緒に考えられるようになりました。
◆ ちなみに私は、**エンジニアの方が「それって何でですか？」と背景まで確認してくれた**おかげで、不足に気づくことができました:pray:



### 2. そもそもの課題や実現したい価値と繋げる
ありがちな失敗：要求・要件の前提にある条件を伝えない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/97654e8d-b059-df14-e784-8720f9fe32b6.png)
もちろん要求・要件を伝えることは大事ですが、その前提を伝えないとエンジニアからは全体像が見えず、「デザイナーからの指示が全て」になってしまいます。
例えば「この機能が実装されると、誰のどんな課題が解決されるのか？」「それは、どんな指標で計測するのか？」など目的を共通化することでお互い提案がしやすくなり、アウトプットの質やスピードを高めることができます。
◆ **目的を理解した上で提案してくれるエンジニア**はデザイナーにとって、とても頼もしい存在です。



### 3. 迷ったら、相談してみる 
ありがちな失敗：デザインはデザイナーだけのものだと思い込んでいる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/4fa14284-0ae3-7cb6-ad0e-981139fe3be8.png)
デザインを決めるのは全部デザイナーの役割と思い、抱え込んでしまうと、（特に経験の浅いデザイナーの場合）判断のスピードが遅くなったり、実現可能性の低いデザインを空想してしまいがちです。
判断基準に迷ったとき、エンジニアの意見も聞きつつ一緒に考えると、実装を踏まえた最適な判断ができるかもしれません。
◆ 困っていたとき、**エンジニアの方が「一緒に考えますよ！」と言ってくれた**のは、とても有り難かったです。



### 4. 優先順位を判断する
ありがちな失敗：実現可能性の判断をエンジニアに丸投げする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/0b1917a9-a77c-727a-4f5d-36368d81c417.png)
デザイナーは「理想的なUX・UIを考える」、エンジニアは「実現可能性を踏まえて実装する」という分担ではありますが、「デザイナーなので理想しか考えられません」というのはあまりに自分勝手です。デザイナーが思う「ほんのちょっと」のデザインの差でも、実装の難易度が大きく変わることもあります。
譲ること全てを妥協と捉えず、全体の状況から「今ではない」という判断もできるようになるとデザイナーとしての幅が広がります。
◆ **エンジニアの方は、技術的に難しい/負債を残すリスクを感じたら、遠慮せず伝えてもらえる**と嬉しいです！



### 5. 実装の難易度やDB構造を理解しようとする
ありがちな失敗：デザイナーだから、技術のことは別に知らなくてよいと思う
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/7480e574-6254-ef20-f17b-d36f85a2cda8.png)
共通のコンポーネントなど影響範囲が大きいところや、DB構造上の違いなどについて知ることで、エンジニアとの齟齬を減らし、デザイン段階でも実装を考慮しながら効率的に進められます。
◆ 私の場合は、**エンジニア/デザイナーを問わず開発メンバー誰でも参加できる、技術についての共有会**が良いきっかけになりました。
　


### 6. 仲良くなる
ありがちな失敗：共通の話題がないと思って、相手を知ろうとしない
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/886860/a6e4ce05-7ea4-ade8-bd99-117335a1f566.png)
無理に馴れ合うことを勧めているわけではないですが、人として相手に興味を持ち、相手を知ると一緒に仕事をしていても楽しいなあと個人的に感じています。更に、こんな言葉もあります。
> 実際のところソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。
> ―トム・デマルコ/ティモシー・リスター「ピープルウェア」より引用

開発プロジェクトは、技術よりむしろ人間関係などの問題で失敗していることが多いそうです。開発組織の中でのコミュニケーション量を増やし、冗談も真面目な話も忌憚なくできるようになると、業務でのやり取りも円滑になるはずです。
◆ 開発組織に入ってすぐの頃、**エンジニアの方から気軽に声をかけていただいた**おかげで、とても安心できたことを覚えています。



# 変わったこと/効果
この6つの実践によって、コミュニケーションのすれ違いが減りました。また、これまで知らなかった領域について知る機会が増え、興味が湧き、エンジニアのみなさんと開発を進めるのがより楽しくなりました。

# 最後に
書いてはみたものの、私自身完璧ではありませんし、考慮した方が良いところがまだまだたくさんあると思います。それでも、デザイナーやエンジニアが、個人の役割や能力を超えて一緒に考えるチームであれば、最終的なプロダクトのアウトカムもより高められることを確信しています。願わくば、エンジニアとデザイナーが、より幸せな関係を築けますように。