勉強会参加 / 【デザイナー×エンジニア】 プロダクトづくりのほんとのところ
自分が今まで関わってきたチームにはデザイナーという職種の方はいなかったので、どのように仕事で関わっていくのか知りたいと思い参加してきました。
当日の流れ
- C CHANNELの開発の現場
- Pairsの開発の現場
- パネルディスカッション 〜デザイナーとエンジニアの理性的な殴り合い〜
C CHANNELさん発表
eurekaさん発表
組織体制の詳しい話
パネルディスカッション
テーマは 〜デザイナーとエンジニアの理性的な殴り合い〜ということで、お互いに普段言えないことを言い合うことでより良い組織作りをして行こうという内容でした。
デザインをエンジニアに共有するときに思うこと
エンジニア
- 古いデザインのまま開発してしまった。
- どの部分がFixしていて、どの部分がNon-Fixなのか知りたい。
デザイナー
- Fix or Non-Fix問題は、早めに伝えるようにしていて、その結果発生している。
=>現実的な解はコミュニケーションを密にすること
開発中のアプリのチェックをどうしているか
デザイナー
- 常に検証用端末に配信されているので、いつでも見られる。(eureka)
- いつでも見られるので、「まだ完成してないと思ったらリリースされた。」ということはまれにある。
- C CHANNELも同様のことがあった。それ以降は開発中に随時チェックするようにしている。
エンジニア
- UIから先に作るようにしている。(C CHANNEL)
- アプリのチェックフローをオートマチックにしたいけれど、なかなかできない。(eureka)
デザインのガイドラインはどうやって定義しているか
eureka
- 作っているものと作っていないものがある。
- 色はがっつりある。
- ダイアログもある。ボタンが1つのものと2つのものの使い分けなど。
C CHANNEL
- 現在の課題である。
- デザイナーとしてはガイドラインはあるが、エンジニアへの共有はまだできていない。
定義されていない色をなぜ使ってしまうのか?
- どっちだ!?
- リニューアルすると綺麗になるが、、、
- グレーがなぜか4種類、、、
Google「Material Design Awards」の受賞理由は?
ぶっちゃけできあがったアプリがイケてない時
デザイナー
- エラーステータスなど、アプリの都合による画面や通知はたまにある。(eureka)
- その時は下手に出て直してもらう。
- GitでISSUEを切る。(C CHANNEL)
エンジニア
- デザインしたのはあなたですよね?
- 手を動かす前に認識を合わせることが大事
デザインがイケてない時
エンジニア
- 質問する。「ここってまだFixしてないですよね?」
- 「Fixですか。なるほど、、、」
- 決まった背景を聞くと納得することが多い。
- エンジニア視点で更に良い案が出せることも。
- 基本的に納得していない場合は作らない。
- iOSとAndroidでそれらしいデザインでない場合は質問する。
デザイナー
- マテリアルデザインを基準に相談するようにはしている。
- エンジニアと一緒に協力して作ることが多い場合は事前に直せるので上手くいく。
- リソースが足りないと、、、
- 日本人はガイドラインに厳しい。(eureka)
ここだけはこだわって欲しい!
エンジニア
- エラー、ローディング画面はアプリを作る時に決めた方が良いかも。
- デザイナーは実装のことを考えずに最高のUXを提案して欲しい。
- その方がエンジニアとして燃える。
デザイナー
- 実装コストを考慮しすぎて、ベストなUXを追求できていないかもしれない。(自戒)
- 「ライブラリ依存だからできません。」は言わないで欲しい。
アニメーションはどちらが主導で?
- Pairsグローバルはエンジニア主導でやる。
- PairsJPはデザイナーがやる。
- C CHANNELはリソースの都合上、エンジニアがやる。
- デザイナーが参考にしているアプリを実際に見る。(エンジニア)
- 参考にしたアプリの制作元が公開しているライブラリがめっちゃ参考になることも。(エンジニア)
意思決定をどうしているか
- C CHANNEL デザイナーがする
- 決定までにはエンジニアも関わる。
- Pairsグローバルは重要な機能はチームメンバー全員で意思決定している。
- 細かいものはデザイナーがする。
- PairsJPは最終決定は責任者がする。
- そこに至るまでは職種関係なくディスカッション
数値を取ったりデータを集めるのは誰が?
eureka
- BIチームが行う。
- 欲しい数値がある時はBIに聞くと教えてくれる。
C CHANNEL
- アプリ上の数字ではなく、リアルイベントの数字が開発に影響を与えることが多い。
- デザイナー、エンジニアとは言えない。
今後はどのように関わっていきたいか
エンジニア
- デザイナー、エンジニアの職種を分けず1つのチームで開発していきたい。
デザイナー
- エンジニア側の意見と同じ。(eureka)
- 「デザイナーは8割のユーザーのことを考える。エンジニアは異常系を考慮する。」サービスを良くするために見ている視点が異なるということを、お互いに認識して関わっていけるとよい。(eureka)
- 同じチームでやることのメリットはあるが、学習コストの問題もある。(C CHANNEL)
- お互いに相手の分野は学んでいく姿勢は必要。
感想
2社ともデザイナー、エンジニアの立場を尊重しつつ、より良い方法を模索して実践しているという印象でした。 ディスカッション中は諸所に「コミュニケーションが大事」という内容が出てきたので、忙しい時ほど、コミュニケーションを蔑ろにしないよう気を付けていきたいと思いました。
参加させていただきありがとうございました!!!
初めて聞いた言葉「デザインを当てる」
「ここデザイン当たってなくない?」という風に使うそうです。
How To 的な学び
デザインもバージョン管理した方がよい。 Sketchでデザインして、Abstractでバージョン管理する。