Designer x Engineer Lovers #01〜デザイナーとエンジニアが「いい関係」を築くために〜 にブログ枠で参加してきました。エモかったです。

懇親会で結構お酒飲んだので帰宅後はさっさと寝て後日にブログ書こうと思っていたのですが、妻に「フランス・ベルギー戦（W杯準決勝）の後半だけ見たいから4時に起こして」とオーダーされたため明け方まで暇なんで、深夜に記事を書き始めた次第です。W杯面白いよね。（奴隷並感）

■■■

Designer x Engineer Lovers #01 、とても良いイベントでした。
会場の様子はと言うと...

ある運営メンバー（エンジニア女子）の要望で日本酒の一升瓶が用意されるも、あっという間に空になる。

拳で語る系の登壇者（エンジニア女子）が来場者に片っ端から腕相撲を挑み、敗者に『ウチの求人に応募しろよ！』と脅しをかける。

というカオスぶりでした... というのは、懇親会の話です。（@fromkkさん、@yuri_httさん、@niwatakoさん、写真使用許可ありがとうございます。）

本編はと申しますと、代わる代わる8名の登壇者が「デザイナーとエンジニアの好ましい関係を語る」という、大変エモいイベントでした。

それぞれのLTに関して感想書いてたらえらい長くなってしまったので、まずはまとめから述べさせてください。

（いきなりですが）LTまとめ

複数のLTで共通して出てきたキーフレーズがありました。

【感謝と敬意】
複数の登壇者さんが、「感謝を忘れない」「尊敬し合うの大事」と繰り返し述べていました。

【共通言語で円滑なコミュニケーション】
デザイナーが「Autolayout」を知る、エンジニアがデザインレビューに適した言い回しを知る... と言う風に、「使う言葉を擦り合わせるとスムーズだよ！」という話がチラホラありました。

【もう一方の作業を経験する】
デザイナーがXcode使ってエンジニアとペアプロミングする、デザイナー不在の環境でエンジニアがデザインも頑張る、エンジニアとして就職したのちにデザイナーになった... といった経験が語られていました。

この3つのキーフレーズ、上手く噛み合えば一つのサイクルを構成できるように思います。
図にすると以下のような感じ。

共通の体験を経て共通知識を増やすことで共感が増し、それによって知識・体験への意欲がさらに増すという好循環... ってこれ人間関係全般に言えそうですね。

で、デザイナーとエンジニアという関係性において、このサイクルをうまく回す取っ掛かりは何だろう、と考えると、「作業を経験」のところかなと思っています。

デザイナーもエンジニアもいろんなタイプの人がいますが、多数に共通するのは「黙々と作業するの好き」な点だと思います。ので、取っ掛かりとしては「とりあえずツールとか触ってみる、なんか作ってみる」が良いのではないかと。

そして「どんなツールが良い？」「こんなん作ってみたんだけど、見て？」とアドバイスやフィードバックを求めるところから繋がりを深めていって、サイクルを回していく。

組織として勉強会やレビュー会をやるのももちろん有効ですね。

だた、ここで障壁になるのが「業務忙しくてそんな暇ないよ」という状況。
これはむしろ、感謝・敬意をブーストする要素と考えると良いのかもしれないです。
「こんな忙しいのに頑張ってトライしてんのか、すげえ」「こんな忙しいのに丁寧にアドバイス下さる、有難い」というような。
感謝、敬意の醸成という観点では、忙しい時ほど頑張る意義があると言えるかも。

（でも体力的にしんどいのは嫌だな...。結局は「興味、関心に従ってトライできるような、余裕ある状況を作ること」が大事なのだろうか。そのへんがまだまだ多くの組織にとっての課題ですね。）

それと、マウント取りたがる人が組織内にいるとアドバイスとかフィードバックもらうのが億劫になって、上記のサイクルを阻害しそうですね。
マウント取る人なんか全部消滅すればいいのに。

ああ、文章がツラツラしてきた。これにてまとめ終わります。
以下、各LTの感想書かせてもらいますね。

■■■

まず1人め、@akatsuki174さん

なぜかマイクにばっちりエコーがかかるという状況で、エンジニアの想いを熱く語りあげていただきました。エモい。

「そのデザインの良さ、すげーわかるけどすげー実装大変なんだよ」という事例を3つ挙げて、どう大変なのか、代替案はどんなか、というあたりをご説明されていました。（題材はiOSアプリです。）

事例1「戻る」ボタンタップ時にアラートを表示したい。

テキスト編集中に「戻る」ボタンを押した際に、「編集中のテキスト消えちゃうよ」とアラートを出すような仕様の話。

標準コンポーネントでは実装困難。カスタムでコンポーネント作っても書くコード量が多い。
そもそも本当にアラートは必要なのか。編集中の情報が失われることをアラートするより、自動保存機能を備えてアラートを不要にするのが正しい。

他、事例2「テキストの一部をハイパーリンク化」、事例3「アコーディオンメニューの実装」など、Webだと当たり前のように実装されてるけどiOSでは困難なのだ、という事例が挙げられていました。

アコーディオンメニューをUITableView（iOS標準のテーブルコンポーネント）でゴリゴリ組むとか想像するだけで涙でますね...。

そしてこのような状況を避けるための施策は...

こういった事態を避ける手段は「早めに議題に挙げること」。

これって、「早期のデザインレビューにエンジニアが参加していること」が重要であることも暗に示唆されていますね。

2人め、@testkatsuobushiさん

アトミックデザインはデザイナーとエンジニアの架け橋 というテーマ。
DJスタイルでのLTというちょっと面白い試みでありました。エモい。
いろいろと素敵な記事や書籍を紹介しながら想いを語る、という内容。（実情は、忙しくてスライド作れず、前日も寝落ち... とのこと）

紹介されていたのは以下のリンク。

アトミックデザインの説明として、

デザインカンプから作ると部品化し漏れが出てくるから、あらかじめ作っとこう、という思想のもの

とざっくり言い切ってくれたのが共感しやすくて良かったです。

3人め、@bannzaiさん

デザイナーとエンジニアで、ペアプログラミングしてiOSアプリを作った、という話。

デザイナーがxCode使って画面レイアウト構築を行ってエンジニアがレビューすることで、素晴らしい効果を得た。
デザイナーが「Autolayout」といった用語を知り（使用言語の共有）、それらが何をできるのか知れた（可能性と不可能性の共有）。

最終的にエンジニアとデザイナーが双方から提案しやすくなり、そして双方の提案を受け入れやすくなった、という下りが印象的でした。

4人め、@nanammeonさん

まだまだそこかしこに存在する、「デザイナーの発言力が弱い組織」でのお話し。

頑張って良いデザインを作ってもエンジニアに否定され実装されず、結果エンドユーザから「使いづらい、わからない」との問い合わせが多数寄せられるという、とても泣ける展開に。
そして「作ったもの拒絶されたくないために、開発サイドとのコミュニケーションを拒否する」という悪循環に陥った。

上記の失敗を踏まえ、今では自分の思っていることを（Figma等のツールを使って可視化しつつ）とにかく伝えるようにしている、とのこと。

お互いの感謝と尊敬を忘れず、何かしてくれたら「申し訳ない」でなく「ありがとう」で返す。

たしかに、負い目よりも感謝、ですね。

5人め、@noa_design51さん

非デザイナーがデザインレビューに参加する際の観点について。

「なんかキモい」「これだとコードが汚くなるから無理」といったレビューコメントは良くない。自分の感覚や都合でコメントしてはダメ。ではどうするか。

①HIGやMaterialDesignといった、（ユーザビリティと開発しやすさを突き詰めた）既存のガイドラインを引き合いに出してコメントする。

「自分の意見」でなく、客観的なルールを引き合いに出せば、デザイナーも「そこは〇〇な事情で、あえてルールから外してます」とか説明しやすい。

②ユーザ目線で（一旦頭からっぽにして）レビューする。

作った経緯とか実装しやすさとか一旦忘れて、完全に思考をフラットにすることで「このパーツ要らないんじゃ？」とか「このレイアウト意味なくない？」と処すことができる。それによってプロダクトはよりシンプルに洗練される。ただし、優しく処さないとデザイナーが死ぬから注意。

そして大事な点は、最終判断はデザイナーの手にあるということ。
レビューでいろいろコメントをされても、HIGやMaterialDesign、その他デザイン原則から外れるならば切り捨てる。ぶれない芯を持たないとレビューに振り回されてしまいますからね。

6人め、@_mogamingさん

デザインデータを受け取って実装していたエンジニアが、デザインにこめられたエモ（想い）を知りたいと思ってエモ会（デザイナーが想いを語る会）を執り行った、という話。

エモさがピークに達したLTでした。
そして炸裂する名言↓

エンジニアは足枷ではなくて翼であるべきだ。

デザイナーがどう語ったとかエンジニアがどう受け止めたかという点が非常に面白かったのですが、何よりも「エンジニアが自らデザイナーの想いを知りたい！と歩み寄った（というか、突撃した）」ことが肝なのだと思います。やりたいなエモ会。

7人め、@tummyさん

「アートボードの管理」と「画像の管理」の2点について述べられていました。

■（SketchとかPhotoShopとかの）アートボードの管理
１機能で１アートボードにすると、情報過多になり過ぎる傾向にある。
コンポーネントをアートボード外に括り出す機能を駆使しつつ、1画面で1アートボードとして管理するのが吉。これならAndroid, iOS間でのコンポーネント共有もしやすい。

■画像の管理（pngかSVGか）
Sketchで作れば、zeplinでもpngにもSVGにもエクスポートできるので、どちらかに決めきらずに適材適所で、エンジニアと相談しつつ選ぶべし。
iOSはAndroidよりSVG使う手間が大きい、といった特徴もあり。

ツールの駆使と有効活用がやはり重要だなあ、と思わせるLTでした。

8人め、＠yuri_httさん

ラストは飛び入りLT枠です。

「飛び入り枠、yuriさんいけますか？」
「はい、いけます」
「スライドあります？」
「呼ばれる気がしてたので今朝作っときました」
「強い...」

と、会場をどよめかせながら始まったLTのタイトルは「エンジニアだけでがんばってみた」。その内容はタイトルに反して、デザイナーへの感謝と敬意に溢れたものでした。

デザイナー不在の組織でアプリを制作。JUST INSPIRE（悪く言えば、パクリ）の精神のもと、エンジニアたちで作りきる。
その後外部デザイナーに委託したところ、画面ビジュアルの統一が劇的に向上した。

エンジニアだけで作業してしまうと、各画面、各機能にフォーカスしすぎて、俯瞰できない。デザイナーの介入によって、プロダクト全体の世界観統一、UXの一貫性を実現できた。

なお、登壇者自己紹介の下りで「アタシ腕相撲強ぇから。男にも勝つから」的な煽りが入ったせいで、その後の懇親会がカオスと化しました。
巨漢のアメフト経験者まで煽るのはどうなの。

そしてアンケートタイム（5分）

ちょっと斬新で、かつ非常に有効だったと思ったのが5分間のアンケート記入タイム。

アンケート書く気満々だったのに書き忘れることよくあるので、時間を設けてくれてありがたかったです。

懇親会についてつけたし

冒頭で触れた通りなかなかにカオスな懇親会でしたが、普段イマイチ懇親会で人と喋れない自分が結構いろいろな方とお話できました。運営サイドの施策（最初のアイスブレイクとかネームプレートとか）が上手く効いてたのだと思います。

で、個人的な興味から、数名のエンジニアさんに「デザイナーに転向したいエンジニア、またはデザイン業務を経験してみたいエンジニアってどのくらい居る？」と聞いてみたりしました。

転向とまでいかなくても学習意欲は高いようで、概ねみなさん「時間があれば勉強したい」「取っ掛かりがあれば経験したい」と思ってらっしゃるようです。

激烈なデザイナー不足が起きている昨今、非デザイナーがデザイン領域へスムーズに踏み込める仕組みが大事だよなー、と強く思う今日この頃です。