BASE Product Design Divisionでデザイナーをしている渡邊です。
昨年5月にジョインしてから、約1年が経ちました (入社理由などはこちら)。
入社してから、改善施策など中心に、たくさん関わらせてもらいましたが、個人的に一番大きなトピックだったのが「全社Figmaへの移行」をリードしたことです。
もともと前職からFigmaを利用し、その便利さに魅了され熱烈なFigmaファンになった私が、「BASEというチーム全体で」Figmaを活用するまでにやったことなどをまとめてみたいと思います。
・熱烈なFigmaファンのみなさま
・チームで利用ツールを揃えていきたいデザイナーのみなさま
に向けて、Figma愛と試行錯誤を伝えていければと思っています。
きっかけはデザインガイドライン策定プロジェクト
昨年5月に入社してから、私はデザインガイドラインを新たに策定する「デザインガイドラインプロジェクト」に入っていました。
当時は、ボタンなどのコンポーネント自体はすでに定義されており、デザインデータはSketchでデザイナーが、実際に実装するためのコンポーネントは、以下のようにStorybookでエンジニアが管理をしていました。
しかし、「どの画面・機能で主に使われているのか」「似ているコンポーネントとの使い分けはどうなっているのか」など、詳しい仕様については特に明文化されていない状態でした。
そのため、入社してすぐのデザイナーやエンジニアが仕様をキャッチアップすることが難しかったり、コンポーネントの呼称がバラバラだったり、ベテランメンバーの間ですら認識が異なるものが出てきたため、デザインガイドラインを策定しようと始めたのがこのプロジェクトです。
Sketchを中心とした運用をしていたものの...
2020年ごろは、Sketchを基本的なUIデザインツールとして利用しながら、Abstractでバージョン管理、Overflowでプロトタイプやガイドラインの共有などを行っていました。
デザインガイドラインプロジェクトにアサインされた私は、他のメンバーと一緒にデザインデータと同様にガイドラインもSketchとAbstractを利用して作成することにしました。
Overflowは主にデザインツールで制作した画面を同期してフロー図やコメントをつけたものを、リンクを発行して共有するツールです。
権限がなくてもパスワードをかけてブラウザから閲覧できたり、簡単なページ遷移を実装できることから、これをデザインガイドラインの公開場所として利用できるんじゃないかと思い、利用することにしました。
しかしいざガイドラインの執筆を開始すると、通常のデザイン作成ではそこまで感じていなかった不便さが少しずつ見えてくるように...。
0から書き始めるデザインガイドラインの量は膨大で、当然ブラッシュアップや誤字脱字の修正が大量に発生します。当時は3人ぐらいで手分けして執筆していたため、結果軽微なものであっても文章の書き換えの度にAbstractでブランチを切ってはMasterにマージする大変な作業が必要になってしまいました。Sketch+Abstractはどう考えても複数人で共同ドキュメントを執筆するのには向いていませんでした。
またOverflowはあくまでデザインを共有するツールなので、他にも問題が浮かび上がり、ドキュメントの共有としてはベストとは言えない運用でした。
- 全てのページは画像化されてしまいテキストは抜き取れない
- Sketchデータとの同期は手動でやらなければいけない
- 複数人で同じファイルを同時期に編集したい
- ドキュメント内に目次やリンクを設置したい
- デザインツールがなくてもブラウザから閲覧できるようにしたい
これらの問題が浮上したとき、私の頭の中で「それ、Figmaにすれば全部解決できるよ！！」という熱い思いが爆誕しました。
Figma移行を後押ししたデザインデータ問題
デザインガイドラインを執筆しながら改めてデータを確認していく中で、デザイナーが管理するSketchデータとエンジニアが管理するコンポーネントや実装との差異が発生している箇所が多数見つかりました。特に当時のSketchはカラーの変数が定義できなかったり日本語の文字組みにかなり弱かったところもあり、実装との全体的な数値ズレが発生していました。
デザインガイドラインは単なる新人デザイナーのマニュアルではなく、エンジニアとよりスムーズなコミュニケーションを取るための架け橋としての役割もありました。
実装と合わせて正しく管理するため定義を見直したり、データを直してみたりするものの、ツール自体の限界もあり完全に揃えることは難しかったです。
ちゃんとデザインガイドラインを書いたとしても、このままSketchでデザインする限り、エンジニアは正しいデータを汲み取ることができないし、デザイナーは都度エンジニアに「ここは実は16pxで...」といったコミュニケーションを都度とらないといけない。このままでよいのだろうかと考えることが増えていきました。
その考えがよぎるたびに私は...
Figmaへの想いをこじらせていくことになりました。
マネージャーとの1on1を経て、個人プロジェクトとしてFigma移行に着手
デザインガイドラインプロジェクトを進めるにあたっても、これからのBASEのためにも、やはり今のままのデザインツール運用じゃだめだ！と勝手にヒートアップした私は、、思わずマネージャーの小山さんに「Figmaに乗り換えたいんですけど...」と相談していました。
(👆マネージャー陣に私がインタビューしているものです。マネージャー陣の雰囲気がわかるかもしれません。)
実は、私は前の職場で１度SketchからFigmaへのツール移行を提案し、実現したことがありました。その時はデザイナーが少人数でデザイン量もそこまで多くなかったこともあり、「これからはFigmaです、爆速です！」という私の熱意と勢いだけでありがたいことに移行を決断してもらうことができました。
今回もそのノリで「いいね！やっちゃおう！」なんて言ってもらえるかと思っていたのですが、BASEのデザインはそこまで甘くありませんでした。
10名以上いる大所帯のデザインチーム、膨大すぎるレイアウト数と差分、コンポーネントの多さ仕様の複雑さ....何もかも前の経験よりスケールが大きく難易度が高かったのです。
そんなことにも気づかないまま鼻息荒くFigma移行への熱意を語る当時の私を小山さんは優しくたしなめ、
「Figma移行については何度かチームで話題に出たことはあるから、まずは個人プロジェクトとしてリサーチから入ってみたらどう？」と最初の一歩として何をしたら良いかを丁寧に提案してくださいました。
というわけで、本当にFigmaに移行できるのか、冷静に判断するためリサーチを始めました。
他ツールを触ってみながら比較検討
チーム全体として導入することに納得してもらうためには、しっかりメリット/デメリットを整理する必要がありました。
そのため、同じデザインツールで人気のAdobeXDも含め他ツールを徹底的に触ってみながら比較をしました。
マネージャーの小山さんにも相談に乗っていただきながら
- Abstractでやっていたようなバージョン管理はどうするか
- 複数PJが並列で進行するブランチ運用をどうするか
- Figmaは自由度が高すぎるので、デザインデータの作り方がバラバラになって開発側がデザインを汲み取る上での負荷が高くならないか
- デザイナーのFigmaスキルにばらつきがあるので同じ水準まで上げられるか
などを中心にドキュメントに残していきました。
結局、
- XDは「チーム単位でファイル管理ができないこと」が大きな理由で断念
- FigmaでHistoryを遡れば、ブランチが切れなくても大きな事故は防げる
と判断してFigma移行を、改めてチームに提案。チームとしても進めていこうとなりました。
移行スケジュールを引き、徐々に移行
移行のために、スケジュールや、やることの洗い出しを行っていきます。
BASEの場合は、いきなり全てを移行するのではなく
- 基本的なコンポーネントやUI-kitなどは最初に移行
- 新規プロジェクトはFigmaでやり始める
- 過去にあるファイルなどは後半に移行
という形を取りました。
コンポーネントを移行しないことにはレイアウトを作ることもできないので、まずはUI-Kitと呼ばれるパーツ類の移行を最優先に進めることに。
移行したコンポーネントの一例
BASEのプロダクトの画面数はかなり膨大なので、一度に移行することは不可能でした...。現在進行形でSketch上でデザインを進めていたプロダクトもあったため、直近で触る予定のあるレイアウトや基本的な画面などの移行を優先しました。
移行当時のデザインファイルの様子 (Atomicデザインに沿ってまとめていました)
本格的にチームで移行を進めていくにあたり、よりBASEのデザインや開発フローに詳しいデザイナーにも入ってもらい、チームのプロジェクトとしてより実現可能なスケジュールや運用フローの設計などを手伝っていただきました (感謝...)。
後述するオンボーディング会までにはUI-Kitと基本的なレイアウトが必要だったので、主に私が積極的に移行を進めていきました。中盤からは1人先行してFigmaの使いかたをレクチャーし、合流して移行をお手伝いしてもらいました。
Sketchからのインポートでは、スタイルが崩れてしまったり、うまくいかないことが多かったので、結局コンポーネントはほぼゼロから組み直しました。Figmaの神機能Variantsのおかげで制作時間は量の割りに短く済んだと思います。
オンボーディング会開催
いくら便利なFigmaとはいえ、新しいツールに移行するのであればデザインチーム全員が使えるツールでないといけません。移行後もメンバーにスムーズに作業してもらうため、Figmaのオンボーディング会も担当しました。
デザイナーはレクチャーがなくても経験でツールを操作でき、なんとなくでデザインを組めてしまう故に、データの作り方がバラバラになることがしばしばあります。だからこそ初歩的なところから詳しく説明することで、ある程度データの作り方を統一することが大切だと考えました。
まずFigmaとSketchのデザインを組む上での考え方の違いから説明。 Figmaにはアートボードの概念がないので、ここで戸惑う人も多そうだなと予想して用意しました。
Figma学習にとって一番の鬼門であろう Group / Frame / Auto layout の使い方については特に重点的に説明しました。
AutolayoutとVariants機能については公式チュートリアルを拝借しみんなで進めていきました。(Auto layoutは日本語版が公開されていなかったので翻訳プラグインを使って変換しました。そんなプラグインまであるなんて神すぎる)
基礎が理解できたあとは実際にBASEのレイアウトデータを作るための実践編へ。
基礎までは理解できたメンバーも実践編では少し手こずっていた部分もあり、「数をこなさないと難しいね〜」などと話していたものの、優秀なので最終的にはみんなauto layoutにもレスポンシブにも対応したデザインデータを作ることができていました。
合計3時間ほどにも渡る大オンボーディングではありましたが、なんとか無事に終えることができました。
Be Hopefulの精神で前に進めてみることの大事さ
今も絶賛移行中ではあるのですが、移行は順調に進んでおり、すでに新規のプロジェクトはFigmaで制作しています。
前職でFigma移行を進めた時とは違い大規模だったので熱意だけでは厳しかったのですが、個人プロジェクトで小さくはじめてみることから一歩づつ実現に繋げられたことは大きな経験になりました。
後日Figmaへ移行した感想をメンバーから聞くと、「Figmaに移行したいって声は前々からあったんだけど、いざ行動するまでの熱量がなかった」といった声があり、私のFigma愛も無駄ではなかった...！と嬉しくなりました。
会社の行動指針でもある「Be Hopeful」(楽観的でいること) な精神で、「このFigma移行がBASE全体の良い未来にきっとつながる」と信じながら、仲間を巻き込み前に前に進めていくことが出来ることが弊社の良いところだと改めて感じました。
今後も、どんどん他のプロジェクトを進めているので、続編をお楽しみに。
