フロントエンドエンジニアのデザイナーとの向き合い方
記事の内容
本記事は、 @seya さんが立ち上げた エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア カレンダー2の4日目になります。
4日目は、株式会社iCARE フロントエンドエンジニアの@watsuyo_2 が担当します。
iCAREのUI周りは、主にデザイナー4人(12月から新たに1人Join)、フロントエンドエンジニア9人(内3人業務委託)、技術顧問1人で開発しています。
10月に、iCAREにおけるデザイナーとフロントエンドエンジニアのコラボレーション という内容でミートアップに登壇したのですが、それ以降の話を取り上げようと思います。
現状のデザイナー → フロントエンド開発のペインを探してみた
挙げようとすれば、いくらでも出てくるような気がするので、観測範囲内で5つ挙げました、
- 実装前のデザイン確認漏れが起きる
- ツール上のデザイン詳細度を信用しきれていないことから起こる不信感がある
- 両者がいったい "何を考えてプロダクトを作っているか？" を実は知らない
- 両者が、何らかの障壁で本質的な仕事に注力できていないのでは？
- 相互にとって最も効率が良いツールと方法を構築し、質の高いアウトプットが出せているか？
あたりが有力だと思っていて、早いうちに向き合うべきペインがあると考えました。
上記のようなペインがある時にすぐに思いつくのは、フロントエンド技術領域とデザイン領域に長けている人をブリッジとして配置する ことを考えると思います。
次に、それらを解決するために、2つの解決策を検討しました。
1. フロントエンドエンジニアとデザイナーをブリッジしてみた
まず、以下の3つのような、デザイナーとフロントエンドエンジニア間のコミュニケーションの齟齬が起因のペインについての解決策として両者間のブリッジが必要だと考えました。
- 実装前のデザイン確認漏れが起きる
- ツール上のデザイン詳細度を信用しきれていないことから起こる不信感がある
- 両者がいったい "何を考えてプロダクトを作っているか？" を実は知らない
ブリッジ的なアクションとして、デザイナーメンバーと1on1 を実施しました。
話したトピックは、大まかに以下のような感じですが、デザイナーが普段どんな仕事していて、どんなことが仕事の障壁になっているかを知ることを目的としました。
- 今何をしているか？
- それらの障壁は何か？
短期的には、両者のコミュニケーションが活発になって効果を発揮 しそうですが、中長期的には ブリッジ人材が属人化 することが考えられます。
そこで、属人化を防ぐ方法を2つ検討しました。
チームで "違和感に気づく力" を身につける
チームで "違和感に気づく力" を身につける というのは、上記の属人化を防ぐ意味合いを含んでいます。
フロントエンドエンジニアやデザイナー以外の職能や役職の方でも、リリースや実装前に他人が作成した、デザインを確認することがあるかと思います。
速く、質の高いデザインとフロントエンド開発のためには、まずはデザインを確認する当事者間で 違和感に気づく ことを目標にしました。
そこで以下のような、題材で勉強会を開催することにしました(記事投稿時ではまだ決まっていない)
上記の2つは、一般的なデザインの指針が日本語で分かりやすく説明されていると考えていて、どこに着眼すれば、違和感に気づけるかの実践につながると考えました。
両者の共通言語でコミュニケーションをスムーズにする
ここで言う、共通言語とは、両者が近い目線や共通認識の同じ用語を使うことでコミュニケーションコストの削減や、 きっと相手は分かってくれていない と言った感情を取り除くことができると考えます。
ただ、あまり取り組めていなくて、現状だとStorybookが共通言語として導入されているに留まります。
それ以外にも、上記の勉強会内でコミュニケーションを通じて、共通言語を確認できればと思います。
2. ツールがデザイン、実装の質とスピードを向上させる？
冒頭で挙げたペイン言うと、↓が該当すると思っています。
- 両者が、何らかの障壁で本質的な仕事に注力できていないのでは？
- 相互にとって最も効率が良いツールと方法を構築し、質の高いアウトプットが出せているか？
デザイナーとの1on1でも、XD管理方法のやアウトプットのバラツキ、現環境でのコンポーネント指向によるデザインのしづらさについての意見が上がりました。
このような、ペインをツールで解決しようとすることは、本質ではないと考えています。
しかし時流に合わせたツールが世間で使われる理由を知ることと、現場の声を聞くことで、実は長い間見過ごされてきたペインは、ツールと対人間 がネックだったことに気づきました。
一貫性のあるデザインをツール上で管理するには、個人の裁量でコンポーネントの再発明をその都度、することは望ましくなくて、 個人の裁量 に依存しそうなことは、ツールを頼るべきです。
エンジニアで言えば、個人裁量に依存する手動テストには限界があるため、自動テストを充実させるために自動化テストツールを導入したり、エンジニアをもっと採用したいと思ったらモダンなプログラミング言語やライブラリを導入するよう、努力をするはずです。
今回でいうと、現使用デザインツールであるAdobe XDを使用することのペインを解決するためにFigmaを試用しています。
新規でコンポーネントをデザイン、または既存コンポーネントをルールから再定義すること場合は、Figmaを試用し始めました。
新しいツールを導入することによる導入と移行コストを払ってでも、導入する価値はあると考えています。
Figmaは、デザイナーにとってはツールが変わることによる慣れるまでのロスは、ありつつも Master Component や Auto Layout、Constraints 機能等を使いこなすことで少なくとも、現状よりも優れた一貫性と、速く質の高いデザインがやりやすくなるはずです。
とはいえ実は、フロントエンドエンジニアの方がFigma導入メリットが大きいと考えていてて、デザイナーのメリットと重複しますが、
- XD時代よりも、デザイナー個人に属人化したデザインを見てデザインをしなくて良くなる
- 同じコンポーネントなのに微妙に違うデザインが少なくなるため、実装の迷いとデザイナーとのコミュニケーションコストが削減される
- スピード重視が故に、負債となっていたデザインが生まれにくくなり、機能追加時のデザインが常に最新のコンポーネントの状態になっている
といった恩恵が少なくとも受けられると考えるので、フロントエンドエンジニアも他人事と考えずにFigma導入を支援 していけると良いですね。
ちなみに、これらは人間が悪いのではなく、デザイン環境や開発環境が不十分なこと が原因と考えているので、デザイナーの領域だけのペインと考えるのではなく、フロントエンドエンジニアに限らないエンジニアが、質とスピードの高いプロダクトを作るために避けることができないペインとして認識しています。
まとめ
- 非デザイナーとデザイナーにある距離感を勉強会や1on1を通じて、デザインに対する 共通認識 と 共通言語 で縮めよう
- デザインの 違和感に気づく力 を身に着けてプロダクトをより良いものにしていこう
- デザイン → フロントエンド開発にペインがあるならば、新しい開発環境とツールを試してみよう
最後に
Figma導入に関しては、一時的にスピードを落とさなければ行けない可能性を含んでいる可能性が高いこともネックの1つでした。
それでも、フロントエンドエンジニアの自分が先陣で旗を振ることで、iCAREのデザインとフロントエンド開発の未来が開かれると信じて(?)進めていこうと思います。
10月の、登壇の頃と比べて、デザイン → フロントエンド開発にあるペインの解像度が上がりました。
たまたま最近、Devチーム全員と1on1しよう企画を個人的にやっていて、デザイナーと1on1する機会があったこともあって、ペインの詳細を知ることができました。
お忙しいところ、お時間を頂きデザイナーチームの皆さんありがとうございます！
そしてそして
実は、3日目、4日目、5日目がiCAREのフロントエンドエンジニアとデザイナーでジャックしているカレンダーになっているので、併せてそれらの記事も読んでみてください。
環境改善に向けて、様々な取り組みをしているiCAREの採用情報に興味がある人は、こちらをご確認ください。
Discussion