Visionalのビズリーチ事業部でデザイナーをしている福田です。「ビズリーチ」の求職者様（toC）向けプロダクトの機能開発や改善を担当しています。
2022年の8月から現在にかけて、「ビズリーチ」の開発チームにおけるデザイナーとフロントエンドエンジニアの連携フローの見直しを実施しました。
今回、フロントエンドエンジニアチームと協力しながら連携フローを見直すことで、それぞれの負担を減らしつつ、より早く、品質を落とさずリリースができる体制の下地ができました。
取り組んだことを振り返りながら、具体的な背景や工夫したポイントをまとめていきます。
「ビズリーチ」は2009年にリリースされて以降、ユーザー数も開発規模も大きくなっています。
今後もサービスを成長させ続けるために、リリースの速度・品質を保ちながらも、負債をできるだけ生まない柔軟な開発体制を目指しています。
今回、デザインと実装の連携のフローに改善点があると考えました。デザイナー(自分と新卒メンバーの2名)とフロンドエンドエンジニア3名でプロジェクトを結成し、開発体制について議論を進めていきました。
まずは、どのような部分に課題を感じているのかを把握するために、プロジェクトメンバーで課題感の整理を行いました。
特に以上の3点が課題として大きく、メンバーの負担や、デザインと実装のズレに繋がりやすくなってしまっていることが分かりました。
今までリリース前のデザインQA(品質チェック)は、エンジニアが実装を終えたらデモ環境にデプロイし、デモ環境を見ながらデザイナーがチェックを行い、修正点があればエンジニアに報告して修正してもらうというフローでした。
ただ、デモ環境を立ち上げたり、Figmaとデモ環境を行き来しながら差分を見比べたりするフローは個人への負担が大きく、実装ズレを見逃してしまうリスクもあります。また、修正点を伝えられたエンジニアも再度コードを更新してデモ環境を用意して…という手間がかかってしまう問題もありました。
デザインの作成と受け渡しを主にFigmaを用いて行っていましたが、Figmaに慣れないエンジニアも多く、カラーやテキストなどのデザイントークンを読み取ることが難しく、手戻りが生まれやすい状況にありました。特に目視では読み取りづらい詳細なカラーパレットなどは手戻りの発生源になっていました。
以前はデザイナーも基本的にHTMLやCSSを書くようにしていましたが、チームが大きくなるにつれ、コードは書けないがビジュアルや情報設計に強みがあるデザイナーや、新卒メンバーが加わるようになり、エンジニアがスタイリングの実装を担う割合が増えていたことも背景にありました。
また、デザイナーがFigma上で使用しているカラーパレットやその命名規則が、エンジニアが実装上で使用しているものと差分があり、デザイナーとエンジニア間での共通言語を作りきれておらず、コミュニケーションコストや手戻りが生まれやすい状況でした。
上記の背景を踏まえ、たとえ今後さらにチームや開発規模が大きくなっていったとしても、個人の力量に左右されず、リリースの早さ・品質を保てるよう、連携フローの改善を進めていきました。
具体的に取り組んだことは以下の3つです。
エンジニアとデザイナー双方からのデザインQAを円滑に
コードベースでデザインの調整を可能に
Figma上の命名規則をエンジニアと共に作成
まず取り組んだのは、デザインと実装のズレを減らすことを目的に、デザインQAのフローを整備することです。
大きな変更点は、実装完了後にエンジニアが1回、その後デザイナーがもう1回デザインを確認する体制にすること、そして、今までより負担が少なく円滑にQAが回るように、Chromaticというツールを導入することでした。
Chromaticを使い、実装後のデザインの差分を自動で検知して比較表示します。また、デモ環境を立ち上げずとも、効率的にデザインレビューができるようになっています。
この体制を取ることで、リリースに関わるデザイナーとエンジニアそれぞれが、デザインと実装のズレがないかなどの品質をより意識しやすく、抜け漏れも少なくなります。
デザイナーとエンジニアがそれぞれ確認する分、負担が増えたように見えますが、チームで使えそうなツールをリサーチしてChromaticを試してみたところ、今までよりぐっとスムーズにQAを回せるようになりました。
また、このタイミングで新卒のデザイナーが仲間に加わったこともあり、経験差によるQA品質の差分が生まれないこの仕組みはとても重宝しました。
次に取り組んだのは、デザインデータの受け渡し方の見直しです。
具体的には、FigmaからGitHubにプルリクエストを送れるようにすることで、特にカラーやテキストなど基本的なデザイン要素の変更をデザイナーがエディタを開かずともできるように、エンジニアはコードさえ見れば細かなスタイルの定義が分かるようにしました。
Figma Tokenというプラグインを使用し、Figma上でカラーなどの要素を変更したらそのままコード上での定義も更新されるようになりました。
また、プロジェクトメンバーからのアイデアで、SVGアイコンの管理も併せてシームレスにできるようにも対応しました。
「デザイナーはデザインツール」「エンジニアはコードエディタ」のようなツールによる境目をなくし、コードベースでデザインのやり取りができるようにすることで、連携を滑らかにし、手戻りの発生を減らすことが狙いです。
Figma上に登録しているカラースタイルやテキストの命名規則の整理をエンジニアと議論しながら策定しました。このことによりデザイナーとエンジニア間の共通言語を作ることができ、開発もスムーズに着手できるようになりました。
Figma Tokenと併せて活用することで、デザインの共有時の齟齬を減らせるようになったと感じています。
この運用を開始してからまだ日は浅いものの、既に実装時の齟齬や手戻りが減ったり、チームでリリースの品質担保に臨めるようになった手応えを感じています。
具体的には以下の点で効果を実感しています。
デザインを正確に実装してユーザーに届けるため、デザイナーがデザインQAに関わる体制づくりを実現できた。
Figma上でToken管理を行うことで、今までよりもデザインの手戻りが減った。
仕組み化したことで、以前と比べてエンジニアのFigmaへの苦手意識が払拭でき、今ではエンジニア向けにFigma勉強会を開催するようになった。
今回は、1つのプロジェクトでの実験という位置付けで進めていましたが、今後他のプロダクトやチームへも展開を予定しています。
今回の取り組みは、誰か一人が主導して決めていった訳ではなく、エンジニアチームとの協力があってこそ進められたものです。
「こんなフローが良いんじゃない？」「こんなツールを導入してみるとどう？」「海外ではこんな取り組みをしているみたいだよ」と、全員がワクワクしながら意見やアイデアを出し合ったことにより、連携フローを変えることができました。
Visionalが掲げているバリューに「変わり続けるために、学び続ける」というものがあります。
今までの体制に疑問を持ち、変わるために新しい技術を学び、取り入れた今回の取り組みは、振り返ってみるととてもVisionalらしいエピソードだなと思いました。
これからも自分達が利用する仕組みを、自分達で楽しみながらアップデートし、ユーザーの皆さんに喜んでもらえるプロダクトをより早く、高品質で届けられるよう、チームで改善を重ねたいと思います。