開発者とデザイナーのワークフローを変えるFigma Dev Mode(開発モード)を語る『UI＋FE合流点』を開催しました。

『UI＋FE合流点』は、UIデザイナーとフロントエンド開発者がより良い仕事をする合流点を探るイベント。

今回のテーマは、正式機能としてリリースされたばかりの Figma の Dev Mode(開発モード)。

Dev Mode をチームで活用されている株式会社サイバーエージェントさんとの共催で『UI＋FE合流点 feat. CyberAgent』として Abema Towers で開催しました。

デザイナーとエンジニアの協力体制を Dev Mode がどのように変えるのか、これからのワークフローにどのように影響するのかを

• Figma Japan　谷 拓樹さん
• サイバーエージェント　原 一成さん
• Qiita　出口 裕貴さん

三人のゲストと Gaji-Labo 代表の原田 @neotag がお話させていただきました。

Dev Mode(開発モード)とは

まず、イベント前半戦。

Figma Japan 谷さんから Dev Mode とは何であるかご説明いただきました。

Dev Modeは、Figma を使ってUIデザインと実装者の連携を強化する機能群です。より簡単に説明すると、Figma で作られたUIデザインを実装者が見るためのモードとも言えます。

より良いプロダクト開発の効率化や開発体験の向上を目指し、ワークフローに変化が起きる転換点となる機能群といえます。

ハンドオフの現実に合わせて Dev Mode は、デザイナーと開発者間の絶え間ないコラボレーションの現実に最適化されています。

現実的なハンドオフ(デザイナーから実装者への引き渡し)は、デザイナーの仕事が終わったらフロントエンドエンジニア……と一方通行で進んでいくのではなく、行き来をしながら進んでいきます。

デザイナーと開発者を行き来する「現実に最適化されている」という言葉にグッときた参加者も多かったようです。

Dev Mode で人気の推し機能は、アノテーション(Annotation)

Dev Mode の「推し機能」をゲストのみなさんに話していただくトークテーマでは、アノテーション機能がダントツの推しでした。

下の画像では英語のテキストになっていますが、デザインの中の好きな箇所にアノテーションという説明テキストやプロパティを書くことができます。

プロパティ名の定義やコンポーネントごとの説明、ドキュメントへのリンクをつけることも簡単にできます。デザイナーがアノテーションを書くことで Dev Mode で見ている実装者に必要な情報を渡すことができます。

フォームのバリデーションを書く、代替テキストの指定ができるといった具体的な利用方法についても話が挙がりました。

実装に渡したら、想定とちょっと違うマークアップになったってことがある。
デザイナーからエンジニアにアノテーションを使ってマークアップの指定ができる。
従来のコメントは議論や対話に使って、アノテーションは仕様を書くという形で使い分けできるようになったのが推しポイント。

――― Qiita 出口さん

また、アノテーションでマークダウン記法が使えるという点は会場の参加者もかなり盛り上がっていました。

まだまだ使い方を試行錯誤しているところだけれど、アノテーションはデザイン上に直接テキストを書くのとは違うレイヤーで構造化されたデータとして扱える。

――― サイバーエージェント 原さん

これは便利ですね。

マージンやサイズの測定値を追加できる(Measurement)

アノテーションとセットで便利なのが、下の画像のようにレイヤーのサイズやマージンを測定して表示する機能です。デザインが変更されても常に最新の測定値に保たれるとのことなので、デザイナーから実装者に情報を渡すためのツールとしてとても便利そうです。

デザインの変更内容を比較できる(Compare Changes)

変更比較の機能は、デザインの何が変わったのか変更差分が簡単にわかる機能です。

フレーム履歴モーダルが開き、現在のバージョンと以前のバージョンのデザインをレイヤーとコードの変化で比較できます。

並べて比較するだけではなく、オーバーレイして重ねた比較もできます。

デザインのレビューで Compare Changes めちゃめちゃ使える。
フォントサイズが少し変わったとか、気づきにくかった差分を探すのはこれまで大変だったけど簡単にわかるようになった。

――― Qiita 出口さん

たしかに Figma 上のデザイン差分を確認するのはこれまで大変だったと思います。

すごく便利になりますね。谷さんの言葉からも便利さが伝わってきます(笑)

Compare Changes は自分が現場にいたときにあれば嬉しかったなと思う機能。

――― Figma Japan 谷さん

開発準備完了(Ready for dev)のフラグを立てられる

Dev Mode ではデザイナーが「開発準備完了」のフラグを立てることで、実装者がどのセクションやフレームが開発準備完了かを把握できるようになります。

会場からの「ステータスがつけられるのは便利だけど、開発準備完了(Ready for dev)の1種類しかないの？」という質問に Figma の谷さんからはそういったフィードバックをもらえるのは嬉しいとのコメント。

多くの要望はきている。例えばどういうものが欲しいかなどのフィードバックをもらえると嬉しい。

――― Figma Japan 谷さん

コンポーネントのバリエーションを試せるプレイグラウンド(Playground)

Dev Mode でプレイグラウンド機能を使うと、モーダルが開いてコンポーネントの可変プロパティを変更して試してみることができます。

実際のデザインを変更せずに実装者はコンポーネントのプロパティをいじることができるわけです。

各社の Dev Mode 活用状況は？

Dev Mode をすでに使っているサイバーエージェント、Qiita、Gaji-Labo の3社の活用状況についてのトークテーマ。

Qiita 出口さんによると、まだ Dev Mode はエンジニアに渡せていないとのこと。

Qiita では、デザイナーがアノテーションを残したり、レビューで Compare Changes を使っている。

――― Qiita 出口さん

「Dev Mode をバリバリ使っているチームと言っていいのでは？」という言葉に対して、出口さんは「エンジニアに使ってもらって協力体制を作れてこその Dev Mode なので、まだまだこれから」とのこと。

本気でデザイナーとエンジニアの合流点を考えている人でないと出てこない返しですね。

ちなみに Figma の話と直接関係はありませんが、Qiita ではアクセシビリティ周りはエンジニアではなくデザイナーがコードを書いているそうで、会場からは「流石 Qiita だ」という反応が出ていました。

サイバーエージェントでは、逆にエンジニアが盛り上がって Dev Mode 活用が進んでいるとのこと。

当初はデザイナーだけだったが、β版から正式機能になってからはエンジニアも Dev Mode を使っていこうと盛り上がった。エンジニア、デザイナー合わせて10名くらいは使っていてコラボレーションの感触は良い。

アノテーションを上手く使うことでコードを読みに行かなくても Figma のみで完結することができる。

また、外部の実装者に依頼するときにアノテーションを使った作業指示を入れたときは、かなり上手くいった。実装の注意点をエンジニアが記載するのもありだなと思った。

――― サイバーエージェント 原さん

Gaji-Labo からは、デザイナーががんばって Dev Mode を活用してくれたが、エンジニアが上手くキャッチアップできなかった話。

β版の時点でUIデザイナーがもりもり頑張って Figma を整えてくれていたのに開発者が Figma や Dev Mode をしっかり学習していなかったので、それを活かせず同じような作業で二度手間が発生してしまった。

こういったワークフローの問題は現場ではなくマネジメントの問題なので、Dev Mode を活用したワークフロー整備を進めていきたい。

――― Gaji-Labo 原田 (Neotag)

これに対して、Qiita 出口さんからも「Figma にしっかり書いてもエンジニアが見てくれない問題がある」という似た話が挙がりました

これから Dev Mode をチームに取り入れていく場合は、サイバーエージェントのようにエンジニアが「 Dev Mode をワークフローに組み込みたい」と盛り上がるよう進めると上手くいくんでしょうね。

Dev Mode に期待すること

また今後の Dev Mode に期待することというトークテーマでは Qiita 出口さんが

Compare Changes の中でコメントできるようになったら、レビューワークフローが良くなると思う。

――― Qiita 出口さん

と、実務で使っている人らしいコメントをされていたり、

いまはドキュメンテーションとレビューは GitHub でしているが、これから Figma をより中心地にしていく可能性はある。まだ考えている段階だけど。

――― サイバーエージェント 原さん

というサイバーエージェント 原さんが考えている今後の展開なども気になる話だと感じました。

また、 Figma Japan 谷さんが「X/Twitterで寄せられる要望は読んで参考にしている」と仰っていましたので、要望をポストすれば実現する可能性があるかもしれませんね。

どうやったら「プロダクトチーム全員」で Figma を使えるようになるか

『どうやったら「プロダクトチーム全員」で Figma を使えるようになるか』といったトークテーマも盛り上がりました。

そこで出てきたのが、Figma 公式ブログの 開発モードについて知っておくべきすべてのこと という記事の一節。

またハンドオフを一時的な瞬間と捉えるのではなく、デザイナーと開発者間の継続的な協力の一環として考える助けになることを願っています。なぜなら、一緒に構築しているのであれば、それは引き継ぎ(ハンドオフ)ではありません。

開発モードについて知っておくべきすべてのことより引用

Dev Mode は、引き継ぎを減らしてプロダクトチームが一緒にUIデザインを作り込んでいくワークフローへの変化であるという話。

引き継ぎっていう考え方が古くなって、みんなでプロダクト開発をしていくワークフローが当たり前になっていく。

コードを書いてから状態の話をするとかだと遅いし、上流ですべて設計できているべきとかいう責務の話ではなく、みんなで扱うとか。

――― Gaji-Labo 原田 (Neotag)

機能ではなくワークフローや協業に踏み込んだ『UI＋FE合流点』らしい内容だったと思います。

プロダクトチームの『合流点』をより強固に。

隣接する職種の「合流点」を発見するためのイベントである『UI＋FE合流点』。
今回は Dev Mode (開発モード)がプロダクト開発の合流点としてどのような役割を果たすか、という前回までとは少し違った切り口になっていて、面白いイベントだったのではないかと思います。

懇親会もとても盛り上がりました(ある意味、懇親会が合流のための本番というイベントです)。 

フロントエンド開発者と UI デザイナーが (もちろん他の職種も) 合流点を話し合う機会、他社の同業種と話し合う機会として今後も開催していきたいと思います。

「参加したかったけど知らなかった」や「次も参加するぞ！」という方は、Gaji-Labo の X(Twitter) アカウントをフォローするか、 connpass のメンバーになると次回のイベント情報もキャッチできます。

ぜひよろしくお願いします！

余談ですが、Figma Japan 谷さんが「Variants と Variables は、Figma 社内でも間違える人がいて、それが社内ミームにもなっている」と話されていたのを懇親会で更に別の方が話題にしてまた盛り上がっていたのが個人的な面白ポイントでした！

今回のゲスト登壇者のみなさま

谷 拓樹 さん（@hiloki）
Figma Japan株式会社 Designer Advocate

中小企業向けのSaaS、フリーランスでの受託、起業やスタートアップでの開発チーム立ち上げを経験。Webのフロントエンド開発や、UI・UX設計をおこなう。現在はFigmaのマーケティングやリソースの設計・開発に取り組んでいる。またデザインシステムに関連する情報のキュレーションや、その他講演・執筆活動などもおこなっている。

原 一成 さん（@herablog）
株式会社サイバーエージェント　Ameba Spindle テクニカルリード

開発組織のマネージメントやサイバーエージェントのDeveloper Expertsとしてアクセシビリティ、パフォーマンス、デザインシステムなどを活用したプロダクトの品質向上に従事しています。

出口 裕貴 さん（@degudegu2510）
Qiita株式会社　プロダクト開発部 デザインG マネージャー

Qiita株式会社 プロダクト開発部 デザインG マネージャー。法政大学 デザイン工学部 システムデザイン学科卒。
2020年4月に新卒でQiitaに入社。現在はQiitaが展開するサービス全般のデザイン・Qiitaのプロダクトマネジメントに関わっている。UI, フロントエンド周りのことを発信しているデザイナー自認！