AlphaDrive、NewsPicks兼務でエンジニアしている大場です。 フロントをメインで開発していますが、AWS CDKやServerless Frameworkを使って環境、リソース、CI/CD構築もしています。 また、最近ではGraphQLの導入のためAppSyncの検証と導入の推進もしています。
今回は、5月19日に行われた Qiita×Uzabase Tech Meetup #2 で話してきたことを紹介させていただこうと思います。
このMeetupでは、「デザイナー×フロントエンジニアで追求する最高の開発者体験」 というタイトルで話をしてきました。
なぜこの話をしたのか
今までいくつかフロント開発をしてきて感じたこと。 それは、デザイナーとフロントエンジニア間のやりとりでもっと効率的にできそうな問題が多くありそうだなということ。
例えば、デザインのpaddingやmarginを意図して設定しているのに開発に落とし込む時に正しく反映されてなかったことがありました。 エンジニアが過去のプロジェクトで、デザインはPdMがざっくり作ってざっくり実装するようなプロジェクトを経験してるとありがちな印象です。 初期の開発ではこの手順で開発することはよくありますが、製品が成長してデザインを整備していくフェーズになると問題になってしまいます。
他にも、画面幅を変更したり、文字を大量に入力した時のデザインはどうなるか？などの確認を都度行うこともありました。 コミュニケーションが多くなり、お互い時間を使ってしまいます。
こんな経験を経て、最近始めた取り組みについて紹介をし、同じような悩みを持ってる人に少しでも役に立てばと思ったのと、逆に自分にない視点の情報をもらえるかもしれないと思い講演の題材に選びました。
以下、講演の内容を紹介させていただきます。
デザイン×フロント開発でよく起こる問題
フロント開発をしていると、以下のような問題にぶつかることがあります。
- デザイナー、エンジニア間で確認作業などのやりとりが多くなる
- デザイン設計通りに実装されないことがある
- 開発物のデザインバグをなくすためデザインチェックを行うことがある
- フロントは修正されるけどデザインが更新されないで陳腐化することがある
これが起きる原因としては、コストのかかるコミュニケーションをしていたり、共通認識がなかったり、デザインとフロントをどうしていくかの決まり事がなかったりすると起きがちです。
誰が悪いというわけではなく、仕組みの問題で起こります。
目指していきたいこと
この問題を解決するため以下を目指していこうと思いました。
- コミュニケーションコストを下げる
- 2度手間をなるべく発生させない
- チーム内で共通認識・言語を持つようにする
- 共通認識が必要なものは設計によせる
- デザインが更新されないで陳腐化されることを防ぐ
やってること
最初にデザイナーとエンジニアの距離を縮めるために、お互いの作業内容の共有を進めました。
エンジニアはデザイナーにデザインからコードに落とし込む手順を共有し、デザイナーからはデザインはどのような思想でデザインされ、デザインツールをどのように使うかを共有してもらいました。
これにより、お互いがどうしたら効率のよい作業ができるかの議論が進むようになり、以下を進めることができるようになりました。
- デザインガイドラインの整備
- Figmaでもフロント開発でもAtomicデザインを採用
- デザインの段階でコンポーネント名称も設計しておく
- フロントエンジニアもデザイン修正できるようにツールの編集権限を持っておく
デザイン設計で定義できるものは定義をしていった方が共通認識ができてよいです。コンポーネントの構成、名称、カラー名称などがデザインと開発で別れてると会話に齟齬が発生しやすい状況になります。
また、フロントエンジニアも編集権限を持つことにより一緒に修正ができる体勢になるのでコミュニケーションコストを下げられます。
これらを行うことにより徐々にコミュニケーションコスト、認識齟齬が減っていき、当初感じていた課題は改善されて快適な開発者体験を得られるようになっていきました。
こうなるといいなという未来
前述の改善でだいぶ快適になりましたが、ここまでできるようになるともっとデザインとフロント開発をシームレスにしていきたいという欲が出てきました。その欲について少しだけ紹介します。
1. デザインとフロントコードの連携
フロントエンジニアならデザインがそのまま動けばいいのに、、、という夢を何度か見たことがあるのではないでしょうか。
そのまま動くとはいかなくても、デザインという設計書からコードが作れれば一番楽ですよね。 設計書がきちんと整理されているのであれば、理想的にはReactやVueなど技術に関係なく、デザイン上で定義できないイベント処理や業務ロジック以外は連携できてもいいと感じます。
最近は以下のようなツールが出てきていて、これらはデザインツール上で作成したコンポーネントからコードの出力が可能な素晴らしいツールです。
まだ発展途上ではありますがよくできていると感じます。欲をいうと、ここで生成されたコードは直接GitHubに連携できるようになると嬉しいとも思ったり。今後の機能改善にとても期待しています。
フロント開発はコンポーネントのコードやカラーコードの定義など気にしなくてよく、デザインから連携されるようになり、ロジック部分を書くだけになればとても楽になる予感がします。
2. デザイン設計を元とした開発成果物のデザインチェック
デザインという設計書があるんだから、これがそのままデザイン・画面差異チェックのテストで使えればいいのでは、という欲。 デザイナーが差異のチェックするのは流石に無駄が多い。できれば自動化したいという思いがあります。
もっと欲をいえばデザインツール上でイベント処理や業務ロジックまで一緒に開発し、デザインの履歴ごとGitHubで管理してこれをそのままデプロイ・リリースまでできればいいのに、、と思うこともあります。 最近、これに近い思想のツールも出始めているようなので、ここも今後の発展に期待です。
最後に
このブログで書いたことは当たり前のことなのかもしれませんが、意外とできなかったり頭では理解していてもなかなか動けなかったりすることがあると思います。そんな時は、このブログを思い出してもらえると幸いです。
デザイン、フロント周辺の技術はまだまだ改善点も多く、進化のスピードも著しい領域です。デザイナー、フロントエンジニアで協力しながら今後も積極的に快適な開発者体験を目指し、プロセスやツールの改善を継続していきます。また面白い改善や情報がありましたら共有いこうと思います。
