本記事は Figma Advent Calendar 2022 17日目の投稿です。
自分は今年の３月にBrooklynにあるRobotics Startupに入社して、Robotを操作するためのDesktopアプリの開発を担当しています。アプリ自体がオープンソースのため、デザイン自体もPublicな状態になっていますｗ
Advent Calendarのお題「コラボレーションUPの方法」に沿って、現在の会社での使い方と紹介しつつ、エンジニアとして、どのような恩恵を受けているかを書きたいと思います。
Roboticsの会社なので、Hardware teamもあるのですが、今回はわかりやすく自分の所属しているSoftwareチームの一つであるDesktopアプリを開発しているApp＆UIチームをメインに書いていきたいと思います。
ちなみに、Software teamは（Embed, Robot service(BE), App&UI(FE)という3つのチームから構成されています。各チーム代替メンバーは5－8人です。）
各チームの使い方⚒️
最初に各チームの使い方について簡単に紹介しておきたいと思います。
Designer team
Designer teamはDesktopアプリ・Webアプリのデザインをメインとして、プレゼンテーション資料の作成とビジュアルに関するすべての作業をFigmaで行っています。デスクトップアプリのデザインに関するアクセス権限はデザインを担当した各デザイナーとDesign teamのマネージャーに管理されています。基本的にDesign teamに属していないメンバーに与えられるアクセス権はコメント権限のみになっています。
PM team(software)
Product management teamのメンバーはどちらかというとテキスト系のドキュメントをAtlassianのConfluence/Jiraを使う機会の方が多いのですが、実装する機能のScopeを決める場合やアプリのSitemapのたたき台を作る場合にFigmaを利用しています。PMチームがFigmaで利用して作ったドキュメント類も上記のデザイナーチームと同じで、他チームに許可しているアクセス権限はコメント権限のみです。
App&UI team
エンジニアのみのApp＆UI teamは基本的にDesign team/PM teamがFigmaで作成したドキュメントに関して、質問に回答したり、Designや機能のスコープに関して質問したりという使い方がメインになります。ただ、圧倒的にPM teamメンバーよりはDesign teamメンバーとのやりとりが多いです。
Designer Review
エンジニアが実装した機能を他のエンジニアがReviewして、それをメインのdevlopブランチに取り込み、全体の改修作業が終わったころに、デザイナーがアプリを立ち上げて、各ページを細かくチェックしていくDesign Feedbackというフェーズを設けています。以下のリンクはDesignerによるReviewの結果です。
口頭やテキストを利用した指摘ではなくFigmaを利用したこのReviewには、エンジニアとして2つ大きな利点があります。
以下のリンクを見ていただくと分かると思うのですが、修正すべき場所が明確にわかります。そのため、どのコンポーネント(Desktopアプリ: Electron + reactjs)を修正する必要があるか簡単に判断できます。
2つ目は修正が必要に対して、そのような変更が必要かがわかるので、作業時間の見積もりがかなり容易にできるという点です。
Design System management
Desktopアプリのデザイン刷新に伴い、Design Systemも刷新されました。
ただ、自分が入ったときはcolor constantsの定義が完全ではない上に、Designerがつけたcolor nameとcodeでの変数に相違があり、Reviewの際にFigmaのデザインを見て、当該のコンポーネントのコードを見て、色の名称が一致していない場合、color constantsのファイルを確認してと結構手間がかかっていた上に、時々Code Reviewをパスして、他のエンジニアが気づいて直すみたいな事が発生していました。
まずコード側を一度Figmaで利用している名称に一致させることをエンジニアに通達したうえで、一部の色(白#fff、 黒#000 etc)をコーディング時に迷うことがないように一般的な表記に変更してもらうようにデザイナーと交渉して、下記の状態にアップデートしてもらいました。
現状は色に関して、上記に書いたようなコーディング上の問題もなく、スムーズに言っています。
また、デザイナーが新しく色を追加する場合もエンジニアが識別しやすいネームを追加してくるようになりました。
サイドエフェクト的なものとしては、エンジニアとデザイナーの間を取り持ったことで、デザイナーからの信用は上がりました。
Avoid out of sync
既存のDesktopアプリやWebアプリのUI改善、機能追加というのはある程度、どのチームのメンバーもアプリを触っているので、多少の認識のズレがあっても、最終的にSoftware team主導ででハンドリングができるんですが、現在、全社でクロスオーバーチームでやっているような新規ハードウェアの開発の場合はPM team主導でのsyncが必要になってきます。
Design team <--> Product team <--> Software team
最初に書いた通り、Product teamは仕様等や今後の機能追加に際して、ドキュメントを作成する場合、テキストベースのためConfluenceを利用しています。量が数ページとかなら、問題はないんですが、実際新規ハードウェアの場合はその量がその3，4倍になるので、読むだけで結構時間が掛かるので、大まかな内容をカバーするためにPM teamがFigmaを使って、必要な機能及びスケジュールなどをVisualizeすることが暗黙の了解になっています。
上記の情報がFigmaのページ１枚にまとめられているおかげで、Google WorkspaceでDocs、Sheets,Slidesの該当ページに行ってコメントを入れるみたいな面倒作業が省けます。
このため、エンジニアオンリーの会議を除けば、ほぼすべての会議でFigmaが使われます。
これは自分のような英語長文読むの面倒とか思っている非ネイティブには大変ありがたいですｗ
現在までの所感
使い方の問題もあるのだと思いますが、割とデザイナーがいろいろとページレイアウト変えたりしていて、最初は迷子になりがちでしたが、最近検索が使えるようになったので、迷子になることがなくなりかなり快適です。
今後
現状チームではほとんどFigmaのPluginsを使っていない状態なので、年末年始にでも少し見てみて、来年に向けてチームの用途に合っていそうなものをリストアップしようかなぁと思っています。
あとは、必要であれば自分で勉強もかねて、pluginを作ってみるのも良いなぁと思っています。