UIデザインガイドラインをAdobeXDからFigmaに移行した私の奮闘記録 ④運用編

こんにちは、デザイナーの松尾です。
Figma移行奮闘記もいよいよ最終章です。
※当初は「Figma運用の引き継ぎ」にフォーカスする予定でしたが、今回デザイン業務全体にも関わる内容となったため、「運用編」としてお届けしていきます。

前回の勉強会を経てFigmaを使えるメンバーは私1人から4人に増え、チームでデザイン業務に取り組むための「土台」がようやく整いました。

しかし、本当の挑戦はここからでした。

ツールを「触れる」から「使いこなす」への移行は想像以上に難しく、「非デザイナーが実務で迷わず作業するには？」という課題に直面します。
本記事では、この1年で浮き彫りになったリアルな課題とその解決策をお話しします。チームでのFigma運用やデザイン業務の運用で悩む方へ、この奮闘が参考になれば幸いです。

Figma移行から1年、見えてきたのは「3つの大きな壁」

以前の記事「移行作業編」で、私がXDからFigmaへ移行するにあたってどんな状態がゴールなのかを定義しました。
その中では以下を掲げていました。

当時の私にとって、WANTである運用ルールの整備は、"あれば良いな"ぐらいの認識で優先度を下げていました。
まずはツールを移行し、使える状態にすることが最優先だと考えていたからです 。
この1年間チームでFigmaを運用していく中で痛感したのは、その「WANT」こそが、チームの生産性や品質を左右する喫緊の課題「MUST」だったということです。
まずは、この1年間のリアルな業務フローを振り返るところからお話しします。そこには、私たちの前に立ちはだかる、3つの大きな壁が潜んでいました。

一見、順調に進んでいたUI作成業務フロー

私たちのチームでは、Figmaを使ったデザイン業務を以下のような流れで進めています。

1. 仕様書をもとにUI設計
まず、仕様書やワイヤーフレームで要件が固まったら、Figmaでの画面作成に入ります。
「移行作業編」で地道に整備してきたUIコンポーネントや、「よく使うパーツ集」といったデザイン資産をフル活用し、画面を組み立てていくフェーズです。このおかげで、ゼロから画面を作る手間が大幅に削減され、まさに移行の成果を最も実感する瞬間でもあります。

2. チーム内レビュー
作成したデザインは、必ずチーム内でレビューします。ここでは、単なる間違い探しではなく、「このデザイン方針でユーザーが抱える課題解決に効果的か」「もっとユーザーにとって分かりやすいデザインパターンがないか」といった議論を交わし、フィードバックからさらにより良いものへとデザインを磨き上げていきます。

3. 開発チームへの共有 
チーム内で合意が取れたデザインは、いよいよ開発チームに共有し、実装にすすんでいきます。
ここでは開発からの細かいデザインや挙動の確認でやりとりすることがしばしばあります。

4. テスト環境での最終レビュー
そして最後は、STG環境（本番そっくりのテスト環境）で、実装された画面がFigmaで設計したデザイン通りになっているかを最終確認します。余白の取り方は適切か、ボタンやテキストのスタイルはルールに沿っているかなど、UIの一貫性を担保するための重要な品質チェックを行います。
ここで問題なければ、無事にユーザーのもとへリリースされます。

…と、こうして書き出してみると、一見ごく普通で、順調に進んでいるように見えますよね。
しかし、この一連のフローを1年間繰り返す中で、水面下では無視できない問題が少しずつ、しかし確実に広がっていることに気づきました。

チームを蝕む、3つの「見えない壁」

【壁その1】ルールが追いつかない。
「知る人ぞ知る」運用で引き起こす静かな崩壊

最初の壁は、細かい運用ルールが未整備のまま、個人の裁量やその場の判断で「よしなに」対応してしまっているという問題です。

例えば、Figmaのファイル名の付け方や、デザインを更新した際のバージョン管理方法といった基本的なルールが、明文化されていませんでした。
というのも、Figmaでの作成案件の8割以上を私が担当していたため、「自分さえ分かっていれば大丈夫」の状態で、ルール整備の優先度を無意識に下げてしまっていたのです。

しかし、チーム内でFigmaを扱えるメンバーが増えてくると、この「知る人ぞ知る」状態が深刻な問題を引き起こし始めます。
まず、無駄なコミュニケーションと認知コストの増大です。

「このコンポーネントのルールって、どこかに書いてありましたっけ？」
「この作業ファイル、どういう名前で保存すればいいですか？」
こういった確認が、都度デザイナーのもとに飛んでくるようになります。

一つひとつは小さな確認ですが、これが積み重なると、質問する側もされる側も作業が中断され、チーム全体の生産性を確実に低下させていくことになります。

さらに深刻なのが、UIの一貫性の低下です。
頼るべき唯一のルールブックがXDにはあるものの、Figmaには存在しないため、作業するメンバーによって、古い情報や自己流の解釈でUIが作られてしまう危険性がありました。
その小さなズレが積み重なると、ユーザー体験に「揺らぎ」が生じ、プロダクト全体の品質低下を招くことになります。

プロダクトの品質を長期的に担保するためには、デザインガイドラインのメンテナンスを行うだけではなく、誰もが同じ情報にたどり着ける「単一の情報ソース」として確立することが不可欠なのだと身をもって痛感しました。

【壁その2】参照しづらいデザインガイドライン。
情報源の分散が招く「信頼の喪失」

2つ目の壁は、より根が深い問題でした。
それは、デザインの拠り所であるはずのガイドラインそのものの信頼性が揺らいでいたことです。
Figmaへの移行作業に追われ、細かいデザインルールの情報が、実は中途半端な状態でしか移行できていませんでした。
その結果、「このUIの細かい仕様って、どうでしたっけ？」という疑問が出た時、Figmaのデザインガイドラインには答えがなく、古いXDのファイルを開かないと確認できない、といった事がしばしば起きていたのです。

この状態が引き起こす問題は、1つ目の壁よりも深刻でした。

まず、デザイナーである私への「問い合わせコスト」がさらに増大します。
運用ルールだけでなく、デザインの「正解」を知っているのも私だけ、という状況です。
どの情報が最新で、どのルールを適用すべきかの判断が、すべて私という個人に依存してしまい、チームのデザイン業務のボトルネックになり始めていました。

そしてその先にある最も恐ろしいのが、ガイドラインの「形骸化」と「信頼性の喪失」です。
本当に知りたい答えが載っていないガイドラインは、徐々に信頼を失っていきます。
そうなると、メンバーは「どうせ載ってないだろう」と、最初からガイドラインを開くことすらしなくなるかもしれません。

一度「使えない」という烙印を押されてしまったガイドラインは、もはや誰も参照しない飾り物（形骸化）になってしまいます。これは、いわばチームのデザイン品質を支える土台そのものが崩れ始めている、という危機的状況と考えています。

【壁その3】最後の砦「デザインレビュー」。
属人化が開発速度とチームの成長を止める

そして3つ目の壁は、ユーザーに届ける前の最後の砦、「デザインレビュー」の工程に潜んでいました。
実装された画面がFigmaのデザイン通りになっているかをチェックするこの作業が、専門的なタスクになっていました。
例えばピクセル単位のズレを見つけたり、意図した通りのインタラクションになっているかを確認するには、ある程度のデザイン経験と「勘所」が必要でした。

このレビューの属人化は、2つの大きな問題を引き起こしました。

1つ目は、プロダクトの品質を守るための最後の砦である「デザインレビュー」が、結果的にボトルネックになってしまったことです。
現在の運用では、UIの一貫性を担保するために、チームメンバーが手がけた画面も含め、リリース前の最終確認は基本的にそのプロジェクトを担当したメンバーに加え、私も担当するというフローになっていました。もちろん、これは品質を守る上で重要な工程です。

しかし、チームで開発を進める中で、最終確認だけが特定の人に集中しかねないこの「属人化したチェック体制」が、個人の稼働に全体の進行が左右されかねない、という新たなリスクを生み出していました。

そしてもう1つの、より根深い問題は、チームメンバーの成長機会を奪ってしまうことでした。 私が「ここ、Figmaと違いますね」と“正解”を教えるだけでは、なぜそのデザインが適切なのか、その背景にある“判断軸”をチームが学ぶことができません。これでは、いつまで経っても属人化が解消されることはありません。

３つの壁まとめ

こうして、移行計画当時は「あると望ましい（WANT）」程度に考えていた運用ルール整備の問題は、

1. チームの生産性を低下させ、

2. プロダクトの品質を揺るがし、

3. そしてメンバーの成長をも阻む、

という、紛れもない「今すぐ取り組むべき（MUST）」課題として立ちはだかりました。
ではこの3つの大きな壁を、どう乗り越えようと考えたのかについてお話しします。

3つの壁を乗り越えるための「デザイン業務の運用設計図」

今回はFigmaだけの話ではなく、デザイン業務全般に関わるため、現状の運用を全体的に見直すことにしました。
見直す際の根幹にある思想は、「デザイナーが担うべき専門的な役割」と、「チーム（非デザイナー）で協力していく役割」で、現実的に線引きしていくというシンプルなものです。
まずは運用がどう変われば理想なのかを整理してみました。

整理して図に起こしていくと、以下のようになりました。

この運用設計図をもとに、先ほど紹介した3つの壁の対策を具体的に見ていきます。

【壁1, 2への対策】ガイドラインを「みんなで育てる」仕組みづくり

まず【壁1：ルールが追いつかない】と【壁2：ガイドラインの信頼性喪失】。 この2つの問題の根っこは、「ガイドラインの更新がデザイナー個人に依存してしまい、情報が古く、分散している」という点にありました。
この壁への対策には「信頼できる唯一の情報源（=Figma上のガイドライン）を整備し、その鮮度をチームで保ち続ける仕組みを作ること」が必要だと考えました。

しかし、これを再びデザイナー一人で担おうとすると、同じ壁にぶつかることは目に見えています。
そこで、この対策を実行するため、ガイドライン整備の役割を以下のような分担を考えました。

• デザイナーの主な役割：

  • デザインの「法律」を作る：UIの一貫性を保つための根幹となるルール（コンポー-ネントの仕様や使い方）を定義し、その品質に責任を持つ。情報の信頼性を担保する最後の砦。

• チームメンバーの主な役割：

  • デザインの「判例集」を育てる：日々の業務でよく使うパーツや画面パターンを「よく使うパーツ集」として、チーム自身の手で追加・更新してもらう。

デザイナーはまず揺るぎない土台を作り、チームがその上で自分たちの業務に合わせて使いやすいように家を増築していくようなイメージです。
自分たちが使うものを自分たちで整備し、ガイドラインが「自分ごと」になることで形骸化を防げると考えています。

なんにせよ、私の役割である「デザインルールの整備」は急いで取り組んでいく必要があります。

【壁3への対策】レビューの「分業」で、属人化からの脱却を目指す

次に【壁3：デザインレビューの属人化】。
これは、「品質担保の要であるレビューがデザイナーに集中し、チーム全体のボトルネックになりかねない」という問題でした。
この問題に対しては、「レビュープロセスを分業し、デザイナーはより専門的な最終確認に集中できる体制を作ること」が必要だと考えました。

もちろん、この役割をチームメンバーで担えるようにするために、まずはデザインガイドラインへの正しい理解が必要です。今後の勉強会などを通じて、その共通認識をチーム全体で育てていきたいと考えています。

その上で、将来的にはレビューを2段階に分けることを計画しています。

• デザイナーの主な役割：

  • 専門的な観点でのレビューに集中する：下記チームメンバーのレビューに加えて、より専門的な観点（例：「このUIで本当にユーザーの課題は解決されるか」など）でデザインチェックを行う。

• チームメンバーの主な役割：

  • 一次レビューを担当する：Figmaのデザインと、開発された実際の画面を見比べ、「Figmaのデザインが正しく画面に再現されているか」という観点で基本的なチェックを行います。例えば、「指定のコンポーネントが使われているか」「テキストの抜け漏れはないか」といった、明らかな差異がないかを確認します。

この仕組みが実現すれば、将来的にはデザイン品質を上げるための検討に時間を割くことができると考えています。
また、Figmaと実装画面を見比べる中で自然とデザインへの理解が深まり、チーム内でスキルアップに繋がると考えています。

以上から、私の今後の動きをまとめると、「デザインルールの整備＞ガイドラインについての勉強会＞チーム全体のデザイン業務の運用見直し」の順番で取り組んでいくことになります。

大事なのは「より良いUXの実現に属人的な壁を作らないこと」

これまで紹介してきた運用設計図ですが、役割分担の線引きに固執するつもりはありません。
最終的に目指すべきなのは、「より良いUX（ユーザー体験）の実現が、特定の個人のスキルに依存しない状態」を作ることだと考えているからです。
きっとこれからも、チームの成長に合わせて改善していくことになると思います。
また、今回の役割分担を円滑に進めるため、定期的なデザイン勉強会を行っていきますが、単なる技術的なスキルの話ではなく、すべては「ユーザーがより快適に製品を扱える」ということを軸をブラさずに伝え続けることが大事だと考えています。
この共通認識を育てていくことで、私たちのチームはさらに強くなると信じています。

あとがき：私たちの奮闘は、まだ始まったばかり

Adobe XDからの移行という一つの決断から始まったこの奮闘記も、本記事をもって一区切りとさせていただきます。

準備編から始まり、手探りでの移行作業、UXチームやエンジニアを巻き込んだ勉強会、そして日々の運用の中で見えてきた新たな壁。長い道のりでしたが、その一つひとつの過程がデザイナーとして大きく成長することができたと感じています。

さらに、現在運用しているデザインガイドラインも、開発チームとの連携をより深める中で、コードと連携した『デザインシステム』へと進化させていく構想も生まれ始めています。 私の奮闘は、これからも続いていきそうです。

これまで全4章にわたり、私たちの試行錯誤の記録にお付き合いいただき、本当にありがとうございました。この奮闘記が、同じようにデザインツールの移行やチーム運用で悩む、誰か一人の道しるべとなれたなら、これほど嬉しいことはありません。

今後もUI/UXに関する新たな発見や学びを、個別の記事として発信していければと考えています。 

またどこかの記事でお会いできる日を楽しみにしております。