こんにちは！アイスタイルで＠cosmeアプリのiOSエンジニアをしているaboyです。
先日、こちらのイベントにブログ枠として参加しました。
なかなかエモいタイトルですが、＠cosmeアプリにはたくさんのエンジニアとデザイナーが関わっていて、両者がもっと「いい関係」を築けたらいいなーと思っていたので、すごく興味がありました。弊社からはぼく含め4名が参加することに。
それでは発表の概要と感想を書いていきます。
発表一覧
そのUI、実は簡単じゃないんです @akatsuki174
音響機材が不調で、声がハウリングする斬新な世界観の中、堂々のトップバッターは主催者のakatsuki174さん。
概要
iOS開発における、ありがちだけどじつは実装が面倒なデザインの要望のお話。
感想
紹介されていた3つの要望全てがiOSエンジニアとしては「あるある！」な要望で、みんな苦労してるんだなーというのが実感できました。
いわゆるアコーディオンUIについては、弊社の＠cosmeアプリでもいくつかの画面で実装されています。
ぼくがアコーディオンUIの実装で難しいと感じる部分は、大元の画面(UIViewController)のつくりや、アコーディオンUIにするViewのつくりによって実装方法や遭遇する問題が変わり、ベストプラクティスが見つからないところですね・・・。
ちなみにこちらの発表、コードが載せてあるので、デザイナーがなんとなくでも「うわぁ大変そう…」と感じられる最高の発表だと思いました。
たとえば2番目の要望『ハイパーリンクを付けたい』では、コードの中身はわからないにしても、行数が多くごちゃごちゃやっていて大変そうな雰囲気がコードから読み取れるので、デザイナーでも感覚的にわかりやすかったのではないでしょうか！
Atomic Designはデザイナーとエンジニアの架け橋 @testkatsuobushi
この発表をした方、テクノのDJを20年ぐらいやっているらしく、それに掛けてネット上に転がっている良記事をディグって組み合わせて発表するスタイルでした。
※ディグる: dig（＝掘）る。音楽を探すという意
概要
Atomic Designの紹介や、良記事の内容をかいつまんだお話。
紹介されていた記事はこちらだったと思います。
また、デザインデータのバージョン管理ができるAbstractというプラットフォームも紹介されていました。
感想
まずAtomic Designを知らなかったので、タメになりました！最高の発表です。
Atomic Design、かなり便利だと思います。
パーツ化されて定義されていないと、例えばチームに新しいデザイナーが入ってきたときに、同じ見ためなのに違う名前でUIを作ったり、本当は同じパーツなのに少し色味や角丸ぐあいが違うパーツを作ったりしちゃう問題が起きたりするのかなーと。
また、Atomic Designにおける原子や分子が定義されていれば、エンジニアでもそれらを組み合わせて生体を作れたりしてプロダクト作りの幅が広がりそうだなーと思いました。
※Atomic Designではパーツの最小単位から順に「原子」「分子」「生体」「テンプレート」「ページ」と定義されています。
約2ヶ月デザイナーとペアプログラミングを行なった話と僕が伝えたいこと @bannzai
概要
デザイナーと約2ヶ月間ペアプログラミングによるiOSアプリ開発をしたら、お互い理解できてコミュニケーションが円滑になったお話。
ちなみにデザイナーの方が書いた記事はこちらです。
感想
ペアプロそのものについては、ぼくも2日間業務時間中がっつりペアプロをしたことがあるのですが、たしかに相互理解やコミュニケーション促進の効果を実感しました。
また、デザイナーがアプリ開発の知識を持つと、1つ目のLT『そのUI、実は簡単じゃないんです』で紹介されていたようなUIの難易度がデザイナー自身である程度わかるようになって、エンジニアとのコミュニケーションも円滑になりそうですね。
お互いが歩み寄ることで、チームとして最高の結果を得られたという、最高の発表でした。
デザイナーとエンジニアを両方経験したわたしが思うこと @nanammeon
概要
元SE現デザイナーだからこそわかるツラさ…を解決するために、コミュニケーションや尊敬の念、感謝が大事というお話。
感想
話すこと全てに「うんうんそうだよねそうだよね」となるような最高のお話でした。
仕事をするうえで、よりよいプロダクトを作るうえで、よりよいチームを作るうえで、このスライドに書いてあることは本当に大事だと思います。
弊社が組織として大切にしている価値観『共創の精神』のなかの『相互理解とリスペクト』という概念がまさにこれで、その価値を再認識できました。
また、スライド中に出てくる「すぐすぐの楽よりのちのちの楽」という言葉。
エンジニアが行う『単純作業の自動化』がいい例ですが、作業だけでなく、コミュニケーションについてものちのちの楽を求めるようにしたいですね。
今日からはじめるデザインレビュー @noa_design51
概要
デザイナーとエンジニア、それぞれがデザインレビューで心がけるべきことのお話。
感想
スライド中に、いらない機能を「処す(意訳:削除する)」という話が出てきます。いらない機能を処すというのは、ぼくは意外と難しいなーと思っています。
エンジニア側は絶対にいらない機能/仕様だと思っていても処せるだけの根拠が提示できなかったりして、そのままリリースされたり…というのはよくある(?)話なのではないかと思います。
もちろんリリースしてユーザーの反応を見てから不要だと判断して処す、というやり方もありますね。
また、デザインレビューでは、デザイナーが混乱してしまうような意見はしないように気をつけないとなーと思いました。
弊社もそうなんですが、デザイナーがエンジニアに持ってくるデザインは、たいてい他の大勢のデザイナーからのレビューや様々な事情を考慮して、練って練って練られたものである、というのを忘れてはいけないですね。
個人的にやさしく処せる人になりたい！と思ったので最高の発表でした。
デザインに込められたエモを知りたい @mogaming
概要
ディレクターが企画を練る -> デザイナーがデザインを作る -> エンジニアが実装する というような開発において、デザインに込められた願い・狙い・想い = エモをエンジニアが知ることによるメリットや、知るための施策のお話。
感想
デザインのエモ(意図や想い)がわかっていれば、エンジニア側から、その意図を満たしてかつ工数がより少なくなるようなUIを提案できたり、的外れな指摘も無くなったりする、というのはぼくも日々の業務で実感しています。
デザインのエモを知るというのは、よりよいプロダクト作りには欠かせないことだと思っています。
また、エモを理解することによって、相手の意図や想いを理解したうえでのコミュニケーションができるようになるため、よりよいチーム作りの手助けにもなりそうですね。
この方は、エモを知る手段として、デザイナーに熱く語ってもらう会『エモ会』を開催し、「いいね！」と言い合うようなポジティブな会にしたとのこと。
ポジティブな会にすることによってデザイナー側の心理的な負担も減るでしょうし、良い関係性も構築できますね。最高の会だと思いました！
Android, iOS両方を考慮したアプリデザイン管理 @bird_tummy
概要
1画面1アートボードとすることで、ごちゃごちゃしすぎず、iOS/Android共通のコンポーネントを共有しやすい。また、画像はsvgでもpngでもどちらでもいいけど、iOSは取り扱いが若干面倒なので、エンジニアと相談して決めるが吉、というお話。
感想
紹介されていたZeplinやSketchですが、弊社でも使われています。実装するエンジニア視点でもこれらはとても便利で助かっています！
また、画像の管理(pngかsvgか)についてですが、アプリ内のリソースに含める場合であればまだいいのですが、サーバーに画像を置く場合だと、svgはなかなか取り扱いが難しいです…。
つい先日も、「アプリに画像が表示されない！」といった現象が起こり、調べてみたらその画像がsvgだった！ということが起こりました。
最終的には、デザイナー側のより綺麗なベクター画像を使いたい気持ちも聞きつつ、エンジニア側の実装の事情なども話し、相談の結果pngに置き換えてもらうことになりました。
結局なにか問題が起こるときはコミュニケーション不足で、それを解決するのもまたコミュニケーションなのかもしれません。
そのことに気づかせてくれた最高の発表でした。
エンジニアだけでがんばってみた @Yuriさん
※スライドが公開され次第更新します
飛び込みLT。かなりのスポーツウーマンで、「腕相撲なら会場にいる男性の2/3に勝てる自信あるぜ！」的なことを言ったため、このあとの懇親会で腕相撲が行われることに！
（腕相撲の様子も以下のDXEL.1のtoggeterで確認できます）
なおぼくも社内の腕相撲大会で優勝した経験があるため、「腕相撲」と聞いたとき一瞬ピクッとなりましたが、怪我が怖いため自粛しました。
概要
デザイナーがいない状態でアプリ開発を頑張ってたけど、デザイナーがjoinしたら、バラバラだったアプリのUIに一貫性を与えてくれたし、多様なユーザーの期待に答えられるようにUX設計したりで、デザイナー最高！！！ というお話。
感想
エンジニアだけで作業していたら、画面や機能に集中しすぎて、全体を俯瞰できていなかった、とのこと。
ぼくも社内用Webアプリケーションを1人で作ってる際に、UI/UX的になかなかヒドイものを作った経験があります…。
一個一個の機能は動くけど、「最初何したらいいかわからない」「使いづらい」といったフィードバックをもらいました。そのときの自分は全体を俯瞰できていなかったなと、この発表を聞いて思いました。
ただ実装に関してはエンジニアも、アプリが巨大になっても設計や実装に一貫性を持たせるように工夫したりしていますよね。
つまりデザイナーも最高だしエンジニアも最高だし、もうみんな最高だということですね！
おわりに
DXEL.1に参加して、たくさんのLTを聞いたり人と話したりTLを見て、エンジニアもデザイナーも、みんな共通の意見(課題意識)を持っているなーと感じました。それは、エンジニアとデザイナーは
- もっと相手を理解したい！
- もっと相手に伝えたい！
- もっとコミュニケーションとりたい！
ということ。大事ですね、これ。
じつはコミュニケーションや理解、について課題を以前から感じていたため、解決する施策のひとつとしてぼくも先日社内で『iOS Human Interface Guidelinesをみんなで読む会』という会を実施しました。
この会がどんなもので、実施してどうだったかについては、別途ブログなどでまとめたり、次回のDXELに発表者として申し込むなどしてアウトプットしたいと思います。
また、イベント開始前の自己紹介タイムや、懇親会が盛り上がっていたのも印象的でした(腕相撲だけじゃなく、会話も！)。エンジニアは緑色の名札、デザイナーは赤色の名札、というふうに色分けされていたので、話しかけやすかったです。
こうした運営側の工夫もありつつ、あの盛り上がりを見ると、エンジニアとデザイナーがお互いに悩みを相談したり、コミュニケーションをとりたいと普段から思っているんだなーと感じました。
第2回目も開催予定とのことなので、ぜひ次回は発表者側で参加したいと思います！
運営、発表者、参加者のみなさん、最高の会をありがとうございました！
