この記事はMICIN Advent Calendar 2023の16日目です。
前回は朱田さんの「MICINエンジニア合宿2023について」でした。
こんにちは。株式会社MICINで主にフロントエンドの開発をしている小泉です。昨今はフロントエンドの開発に加えデザインに関する業務を少しばかり行うようになりました。その中でエンジニアである私がFigmaの扱いを学びデザインプロセスに関与していくことのメリットや難しさを感じています。この記事では最近の業務で感じた課題やその解決策について私なりの考えを書いてみようと思います。
はじめに - Figmaとの関わり -
Figmaは言わずと知れたデザインツールです。私は主にフロントエンドの開発をしているのでFigmaに触れる機会は少なくありません。しかし、以前のFigmaとの関わり方はデザイナーの方が作成してくれたデータをもとにフロントエンドの実装をする程度のものでした。inspectしながらスタイルを確認したり、データを見ながら口頭で確認したりすることが主な使い方で、最低限感覚で使うことはできてもその機能をがっつり使いこなしながら業務を行っていくという状態ではありませんでした。
しかしながら、チームにおけるデザイン面の課題が小さくなかったこと、devモードやvariablesといったFigmaの新機能のリリースを知り適用してみたくなったこと、個人的なデザインへの興味が大きくなってきたこと、これらの背景から最近では積極的にデザインプロセスに関与させていただくようになりました。
直面した課題
まずは、私たちのチームが抱えるデザイン面の課題について整理しておこうと思います。
デザインに割けるリソースの少なさ
私たちのチームはフルタイムの専任デザイナーがおらず、業務委託の方に週3日程度稼働していただいています。デザイン業務を一手に担って頂いており負担も大きいです。
また、私たちのプロジェクトでは現時点でかなり活発に新規機能の開発を行っており、新たにデザインを定義する機会も多いです。しかしその結果として、日々の案件追加に追われデザインについてより深く検討する機会が限定されてしまっています。デザインが軽視されている訳ではありませんが、機能拡充が第一となっているため（この点に関しては必ずしも悪いことではなくむしろポジティブだと考えています[1]）、デザインの整備、改善についてはなかなか工数を割けていないのが現状です。
中途半端なデザインシステム
デザインに割けるリソースが少ないながらも、昨年末から今年にかけてデザインシステムの整備を進めました。整備した内容は一般的なもので、カラーパレット、タイポグラフィ、余白、ボタンやインプットなどの各種コンポーネントといったものです。これらを一通り定義し、これから作成または修正する画面については定義したルールに則って進めていくということになりました。
また、実装においてはChakraUIを導入することで効率化を図りました。ChakraUIはデフォルトでthemeや質の高いスタイルを保持しており拡張性もあるため、定義したデザインとChakraUIの定義を一致させることで短期間でデザインシステムの落とし込むことができました。デザインシステムの整理においても「ChakraUIでこんな感じのコンポーネント（spaceの定義、radiusの値etc…）が用意されているから新たに考えずこのままで良いのでは？」といったコミュニケーションを行い、ライブラリをそのまま活用することで上手くコストの削減ができたと思います。
ChakraUIを活かしたルール
これだとデザインシステム導入の成功談のようですが、実際に運用し始めると課題が出てきました。ルール整備をしたは良いものの、Figmaのコンポーネント化が徹底できていなかったり、余白の値は都度定義を参照しないといけなかったりと新たな画面デザインを作成する際にルールの適用がしづらいという問題がありました。結果としてルールに即さないその場限りのデザインが作成され始めるようになってしまいました。さらに、前述のように私たちは活発に新規機能開発を行なっています。そのため新たな表現が必要になることも少なくありません。本来であればそのような時は一度立ち止まって根本のルールレベルで見直したいところではありますが、中々そういったことはできず「Chakraの○○でいい感じにできそうです！」みたいな感じで実装に移ってしまうこともしばしばおこるようになりました。こうなるとデザインする上でも実装する上でもデザインシステムの恩恵を100%享受しきれない中途半端な状況になってしまいます。
デザインと実装の不一致
デザインと実装の不一致という場合、２つのパターンがあると考えられます。1つはFigmaなどのデザインツールで定義されているデザインと実際の画面に反映されているデザインが一致していない場合で、こちらはわかりやすいです。そしてもう１つはデザインデータの命名や構造がFigmaと実装で乖離しているといった場合です。
前者については、色々な原因があります。デザインデータが実装しやすい状態になっていない場合、実装者が誤って読み取っている場合、他にはルールを逸脱した例外的なデザインを実装に反映できていない場合などが考えられます。この例外を汲み取れていないというパターンは上述のその場限りのデザイン問題で発生しがちです。
後者については必ずしも大きな問題にはならないかもしれません。名前を変更するだけの場合など、修正しようと思えばさくっと修正できる場合も多いです。しかし、命名や構造の乖離が積み重なると変換コストやコミュニケーションコストが次第に増大します。
課題解決へのアプローチ
これらの課題をどのように解決していけばよいか。エンジニアの私がどのように関われば解決していくことができるのか。実際に取り組んでいるアプローチについて書いていこうと思います。
デザインの本質的な部分にフォーカスできる時間を増やす
1つめの課題としてデザインに割けるリソースの少なさを挙げました。リソース不足を補うために新たな採用ができれば良いかもしれませんが、簡単ではありません。エンジニアが関与することでいかに改善していけるか、という視点で考えてみようと思います。
当然ですが、エンジニアは実装を理解しています。単純な考えではありますがエンジニアがデザインに踏み込むことでデザインと実装を繋ぐ部分の効率を大きく向上させられる思います。例えば、実装しやすいデザインをエンジニアとデザイナーの方が一緒に考え作っていけばその結果として実装段階における手戻り、再修正、デザインの再検討といった作業を無くすことができると思います。このように業務を効率化できれば結果的にこれまでリソースを割いていた作業を無くし、リソースに余裕を生み出せます。
また、命名規則やコンポーネントの整理といった部分にも実装の都合を理解しているエンジニアが積極的に関与していくことで逐一検討するコストを取り除けます。こういった土台を整える作業に積極的に取り組む意義は大きいと思います。エンジニアが理解しやすい構成で作成されたデザインデータは実装に落とし組むのも容易であり、実際の画面がなんか違うといった状況も防ぐことができます。土台となる仕組みを整えることで新たにデザインする際の組み立てが容易になります。さらに、コンポーネントレベルでデザインを修正したい場合もFigmaを修正したらコンポーネントの実装に同様の変更を加えるだけ、という状態にできます。土台となる部分を整えることは本来考えたいことに使える時間を増やすことにもつながるはずです。
もちろん、何でもかんでも実装都合にしてまえば良いというわけではありません。デザイナーの方をはじめFigmaに触れる他のメンバーを含めてメリットを享受できる状態にすることが重要です。しかし、実装しやすい構造化された構成が生むメリットは実装するエンジニアだけが享受できるわけではないはずです。画面を作成する場合などもしっかり構造化された要素を組み合わせる方が一から組み立てていくより容易になるでしょう。上手く他のメンバーを巻き込みながらエンジニアが強みを発揮していくことで大きな成果を生み出せるはずです。
Auto Layout化を徹底する
実装しやすいデザインを作っていく、と言っても実際に何をすれば良いでしょうか。もちろん実装のしやすさにはあらゆる観点がありますが1つ挙げるとするならばAuto Layoutの活用だと思います。Auto LayoutはFigmaの名物機能で詳細は割愛しますが余白や配置をシステマチックに決定できます。Auto Layoutが指定されたframeを入れ子にして fill-container などを指定すれば子要素を柔軟に拡大、縮小できます。こうすることで幅の指定から絶対的な値(fixedで指定された値)を排除して柔軟性のあるオブジェクトにできます。こういった柔軟性はレスポンシブなデザインを組み立てる場合にも効果を発揮します。このようにAuto Layoutを使って作成されたFigmaデータはFigma上のメリットだけでなくデザインデータが実装とほとんど一致するという大きなメリットがあります。同じ見た目であったとしても絶対配置を利用して組み立てられたデータからは実装に必要な情報を正確に読み取ることが困難です。Auto Layoutを積極的に利用することでFigmaデータの段階でどう実装すれば良いかということが明確になるので実装に落とし込むことは極めて容易になります。
Auto Layoutだとルールに則って柔軟にレイアウトができる
エンジニアがデザインに全く関与しない場合、Auto Layout化を徹底することのモチベーションはそこまで高くならないかもしれません。Figmaを本格的に触るようになって実感しましたが、Auto Layoutが適用されたオブジェクトはデータの確認や繰り返し要素の追加をする場合には抜群に扱いやすい一方、構造に制限がかかることで新たなデザインを1から考えたりラフに構想を考えたりする場合にはかえって扱いにくくなます。何もかもAuto Layout化されている状態は実装する上では非常に良いですがデザインのプロセス全体を考えた場合には最適ではないかもしれません。まずは自由に考えてデザインの全体像を考えるステップ、そして検討したデザインをAuto Layout化して実装しやすいデータに変換するステップ、という二段構えのプロセスを設けることで全体の効率を最適化できると考えています。実際に私たちのチームでもそういった運用を定着させようとしています。この2つ目のプロセスについてはエンジニアが積極的に関与していくと良い部分だと思います。エンジニア以外のメンバーと協力しながらデザインと実装をうまく繋ぐ橋渡し的な役割を果たすことができるはずです。
Figmaの新機能でデザインと実装の垣根をなくす
ご存じの方も多いと思いますが、今年のFigma Config、「Figma Config 2023」では数多くの機能がリリースされました。アップデート内容にはよりデザインと開発をつなぎやすくする機能が多く含まれています。
Dev Modeやvariablesといった機能はすぐにでも使いたいと思わせられた魅力的な機能です。いずれも使いこなしていきたい機能ですが、私たちのチームではまずはvariablesの作成、適用を進めていくこととしました。このvariables、課題として挙げた「中途半端なデザインシステム」の改善に大きく貢献します。variablesを使ってデザインしていくことでルールに則った一貫性のある、そして実装への落とし込みが容易なFigmaデータの作成が可能になります。
variablesの機能については公式が出している以下の動画がイメージを掴みやすいです。
こちらの動画でも紹介されているように、カラー、余白、角丸（radii）などといった項目についてvariablesを定義しました。動画でも触れられていますがカラーについては従来よりあるstylesで定義する方法もあります。これまでカラーについてはstylesを使用して定義していましたが、semanticな値を定義する際に別のvariableの値を参照できること、今は対応していないが将来的にダークモード等modeの変更を使いたいケースもありうるという点を考慮してvariablesへの移行を進めることにしました。
primitiveな値のvariables
semanticなvariablesとしてprimitiveの値を参照する
このような指定の仕方は私たちが使用しているChakraUIのSemantic Tokensの仕組みとの相性も良いです。primitiveな値としてカラーパレットを定義しておきそれを参照するsemanticな値を定義しておくという方法をFigmaと実装の双方に適用できます。semanticな値で参照するpaletteを変更する場合は同様の変更をvariablesとコードに加えることで全てのデザインと実際の画面に適用されます。
// variablesの定義をSemantic Tokensに落とし込む
import { extendTheme } from "@chakra-ui/react";
const customTheme = extendTheme({
semanticTokens: {
colors: {
primary: "blue.500",
warning: "yellow.500",
success: "green.500",
danger: "red.500",
},
},
});
また、カラー以外の数値（余白、角丸など）のvariablesについては新たに導入して大きな恩恵を感じています。これまで余白や角丸に関するルールは定めていましたが、実際にデザインする際はルールを参照して同じ数値を指定する必要がありました。ここが一致していればまだ良いですが、場合によってはルールにない値を指定しまうこともありデザインの一貫性や実装の非効率を招くことにつながってしまいました。Auto Layoutの余白や角丸の値についてはvariablesの値を適用できるようになったので指定したルールに則った値のみを使用できます。
variablesを使ってデザインする
またvariableを使用したFigmaデータをDev Modeで見ると以下のようにvariablesの値を確認できます。
ChakraUIでは以下のように実装すれば良いので直感的に実装していくことができます。
<HStack p={6} spacing={8}>
<Box w="full" h="full" />
<Box w="full" h="full" />
</HStack>
このvariablesの定義はエンジニアである私が主導して行いました。誰がやっても良いのですが実装を理解しているエンジニアが実装と一致するように値を設定していくのが最も手っ取り早いと思います。デザインシステムをしっかりと運用していくにあたり大きな効果を発揮するのでvariablesの整備は非常におすすめです。
今後に向けて
まだできていない、今後に向けてやっていきたいことについてまとめてみようと思います。
もっとFigmaを使いこなす
私自身、Figmaやデザインのプロセスについてキャッチアップを続けている最中です。まだまだできていない事や知らないこと、わからないことも多いです。Dev Modeをもっと使いこなすといったこともやりたいですし、効率よくFigmaでデザインを作れてしまう技術も身につけていきたいです。良いデザインを考える、という点にてついてはデザイナーの方にお願いしなくてはなりませんが、良いFigmaを作っていくということに関してはもっとコミットしていけると思っています。Figmaを使った積極的な改善やエンハンスを通してデザインプロセス全体をさらにブラッシュアップしていきたいです。
自動化の強化
Figmaを整え、実装を一致しやすくする、といったことを進める効果は大きいです。しかし、これらのプロセスに人間が介在する限りズレが生じる可能性は拭えません。Figmaからコード生成をすることなどはすでに広く行われていることですし、可能なことは積極的に進めていきたいです。
ChakraUIのコードを生成してくれるツールなんかも出ているので早く導入してみたいです。
また、昨今の生成AIの隆盛を鑑みればprototypeの自動作成、ロジックを含んだコードの生成なんてこともできるようになる気がしてしまいます。これからも進化していくであろう技術、ツールを最大限活かしながら良いデザインづくりを推し進めていきたいです。
さいごに
いかがでしたか？デザインに潤沢なリソースを避けなかったり課題を感じているチームは決して少なくないと想像します。この記事の内容が少しでも参考になったり共感していただける点があったら幸いです。これからもより良いデザインのプロダクト作りを頑張っていこうと思います！
MICIN ではメンバーを大募集しています。
「とりあえず話を聞いてみたい」でも大歓迎ですので、お気軽にご応募ください！
-
業界としても前例がない中でMVP（Minimum Viable Product）を模索しながら高頻度でリリースし続けており、充実した開発体制の構築ができています ↩︎
Discussion