Variableをチームやプロジェクトで活用するために必要な3つのこと
FigmaにVariable機能が登場して1ヶ月強が経過しました。すでにポツポツとVariableを使った成果やナレッジが市場に表れ始めています。しかし、Variableに対応することはある種のチームやプロジェクトにとっては困難が立ちはだかり、多くの時間を要するかもしれません。そこで、Variableを今からチームやプロジェクトで活用するためには何をしなければならないのかを整理します。
Introduction
Figmaの2013年のアップデートから1ヶ月が経過しました。VariableやDev Modeといった大きなアップデートを、いよいよ現場で活用し成果に結びつき始めた方々も増えてくる時期でしょう。
私はというと、今のところ機能開発に追われ、Dev ModeはともかくVariableを仕事のレベルで活用することがまだ出来ていません。
この我慢には大変欲求不満を感じるところで、結局我慢出来ずに、Variableに対応したコンポーネントを個人で作成し公開してしまいました。
ボタンコンポーネントだけですが、私と同じようにまだうまく業務で使うことが出来ていない, あるいはまだvariableを使ったことが無いという方がいらっしゃいましたら、軽く触ってみてください。
そして勉強がてらこれを使ってちょっとしたものを作ってみてください。願わくば、ぜひ私にも「こういうものを作ったよ」と教えてください!それがFigmaコミュニティに公開したものであれば、さらに最高ですね。
Variableと現実
上記のファイルなどを使って他のデザイナーやエンジニアとVariableについて話してみました。その結果、改めてVariableの登場はデザイナーとフロントエンドエンジニアにとって福音と言えると感じています。
と同時に、直近においては多少の地獄を見るであろうとも。
というのも、Variableは使いこなせばフロントエンドレベルの生産性を大きく向上できると確信する一方、そもそもVariableを整えるのがチームによっては面倒なのです。
Variableに対応するには、3つのことを少なくとも行う必要があります。少し具体的に見ていきましょう。
StyleをVariableへ変換する
Figmaを使っている多くのプロジェクトでは、既存のStyleがファイル内もしくはライブラリ内に存在します。この内多くの部分をVariableに乗り換えることで、より合理的で効率的な設計を実現できます。
それは裏を返せば、Styleを今からVariableに変換しなければならないということです。
便利?なプラグイン
といっても、StyleをVariableにすること自体は難しくありません。既にいくつかのコンバート用のプラグインが出ています。下記2つはその例です。
また、Figma公式からもコンバートのためのサンプルが公開されており、これを使って自分でプラグインを作ることも容易です。この場合、Qiita社のエンジニア, デザイナーでありFigmaのAdvocateでもある綿貫さんの投稿も参考になるでしょう。
ただ実際にコンバートしたところ、当然ながらプリミティブ・トークンをセマンティック・トークンに紐付ける作業は手で行う必要がありました。その面倒さに割と絶望しています。
上記プラグインStyle to variableの開発者・Yann-Edern Gillet氏も、Styleからの移行の大変さについて同プラグインのドキュメントで次のように共感的に触れています。
I also know the huge amount of time that can represent a transition from Styles to Variables, so here you go design friends, have fun:
(前略)また、StyleからVariableへの移行には膨大な時間がかかることを理解しています。デザインフレンドの皆さん、(このプラグインを)楽しんで!
そして彼自身認めるこの大変さは、プラグインを使って緩和はできるものの、回避することは今のところ出来ません。
Variableをコンポーネントに適用する
Variableを作成しただけでは対応完了ではありません。既存のコンポーネントに適用してやっとFigma上の作業は完了となります。
これ自体は多少時間と集中力を要しますが、難易度は高くありません。問題は、それをいつMasterや本番環境に適用するかです。
ほとんどの会社では、何らかの機能開発やカイゼンのプロジェクトが常に走っていますから、既存のコンポーネントは既に様々な開発フローの中に存在し活用されています。
すると、Variableを適用したコンポーネントをMasterにマージしてよいタイミングがなかなかありません。不本意にインスタンスや画面、プロトタイプを破壊する危険性があるためです。しかも広範囲に。
これを防ぐための漸進的な取り組みを通常の開発やカイゼンをこなしながら遂行することは、通常難しいことです。
この面倒は特に、既に多くのStyleやコンポーネントが存在する既存のチームほど大きくなります。Styleやコンポーネントの規模はすなわち、Variableへ移管, 更新しなければならない規模と同義だからです。
ただ、そういったチームにおいてもゼロから作り直すよりはマシであることだけは確かでしょう(だからこそ悩ましい)。
Variableをチームにインストールする
さらに、Variableを揃えてコンポーネント全てに適用するのみならず、Variableについてチームの全員がキャッチアップしなければなりません。
1人のデザイナーがVariableを使えるようになることと、チームとしてVariableを使えるようになることは別のことです。
チームで活用するには、個々のリスキリングに加えてVariableに対応した新しいワークフローやルールの規定, 更新も必要になります。
例えばVariableはStyleを完全にリプレイスするものではありませんが、ではどういう時にエンジニアはStyleを参照すればいいのでしょうか?あるいはデザイナーはどういうときにStyleを利用すべきなのでしょうか? その答えはチームで取り決めておく必要があります。
しかもVariableは単なるハンドオフ以上にフロントエンドへの影響も大きく、デザインチームというよりは(デザイナーを含む)フロントエンドチームの全員が理解しておくことが望ましいものです。1
よってチームとして早急にVariableに対応するならば、機能開発などに使っていた時間の一部を数日間に渡ってVariableのために割くか、1〜2日間の合宿などを必要とするでしょう。
例外は、専属のDesignOpsチームがある場合と、全員がFigmaのことを大好きなフロントエンドエンジニアで構成されているチームくらいでしょうか。
おわりに
Variableに対応することでフロントエンド部門の生産性は上がると思われます。
しかし既存の完成されたコンポーネントやデザインシステムを持つチームでは対応までに時間を要すでしょう。
特にDesignOpsチームなどが無い環境では、通常の開発項目の間を縫って漸進的に対応を進めていくことになり、それ用の時間を意識して取らなければいつまでもVariableを活用できないかもしれません。デザイナーだけでなくエンジニアの理解と意欲も必要になります。
まとめると、Variableへの対応でやらなければならないことは次の3点です。
StyleをVariableにコンバートすること
Variableを既存の各コンポーネントに適用すること
Variableとその運用についてフロントエンドチーム全員で理解し、Variableを取り込んだワークフロー, ルールを作ること
また、既にデザイントークンが存在しているチームでは、上記に加えてVariableにそれを対応させる必要もあるでしょう。もしくは、トークンを構築している既存のシステムからVariableに移行するという選択肢もあります。
デザイナーの憂鬱
私たちプロダクトデザイナーは事業やプロダクトを通して大なり小なり世界を変えていくことに熱意を燃やすべきですが、最近は変化した世界に着いていくのがやっとです。
今回のFigmaアップデートだけでなく、昨今のAIブームについても同じことが言えるでしょう。デザイナー自身がまず小手先とは言えない大きなレベルで変化(進化)を求められています。
特にシニアになるほどツールや1つの技術よりも事業目線やマネジメントの目線が求められるので、こういった小さな──しかし大きな──変化に着いていくのは並大抵のことではありません。
そういったケースでは、休日や祝日、あるいは昼の休憩時間に友人や同僚, あるいは部下のデザイナーなどに実際に見せてもらって初めて「そういう機能があるんだ」「そういう使い方が出来るんだ」と学んだりすることもあります。
こういった友人が居るかどうかは偶然に依るわけですが、そんなラッキーに恵まれていなくとも、このニュースレターがその代わりとなりましょう。
ということで、次回は冒頭に載せたボタンコンポーネントを使ってVariableの解説をします。
次回予告
同ボタンコンポーネントにはいくつかの工夫を施し、かつ製作の過程やエンジニアにレビューしてもらった際の発見がありました。
ぜひ皆さんに知っておいてほしい発見でしたので、これをシェアする予定です。Varibaleで何が変わったのか、私の理解している全てをお見せします。
さて本稿から、ニュースレターの品質を向上するため毎号ごとにアンケートを行います。あなたの時間を少しでも良いものにするため、ご協力くださいますと幸いです🙏
また、現在100人の購読を目標に頑張っています。友人や同僚の方々にシェアをぜひお願いします!@yoshinaga
を付けてTwitterにシェアすると反応します。
【デザインチームというよりはフロントエンドチームの全員が理解しておくことが望ましい】
これは本来的には、デザイントークンが登場するより以前から当てはまることではあった。2015年頃には既にこの潮流, 流行は存在した。流行の分かりやすい節目は、国内ではサイバーエージェントにテクニカルクリエイター という役職が登場した時期だろう。
以降、UIデザインとフロントエンドは急速に融け合ってきた。それでもデザイントークンや完成度の高いデザインシステムといった一種のインフラ開発・運用は、実質的には技術的・組織的に優れたチームだけの特権だった。
それがVariableの登場によって強烈に顕在化・陳腐化し、そういったチームだけの特権ではなくなった。今や(Figmaを使う限り)ハードルは高くない。あえて言うならば、障害となるのは意欲とチームの理解だけだろう。