この記事はSafie Engineers' Blog! Advent Calendar 22日目の記事です。
こんにちは、セーフィー 企画本部 デザインセンターの木村です。デザインOpsグループのグループリーダーをしています。
デザインシステムを用いたSafie Viewer（セーフィー ビューアー）のUIリニューアルを行い、無事2025年8月にリリースすることができました！
この記事は、「デザイナーとエンジニアで作るデザインシステム 」シリーズ第2回目の記事です。 デザイナー3名がエンジニア・PdMと協力し、Safieのメインプロダクトである「Safie Viewer」にデザインシステムを導入したプロジェクトを振り返ります。
今までの記事
#2: 「どう進めるか」から考えた、0からの挑戦！1年4ヶ月でデザイナーとエンジニアが「共創」し、デザインシステムを導入した話 ←今回の記事はこちら
- 【はじめに】Safie Viewerとは
- 【導入編】デザインシステム反映の目的、そして0からのスタート
- 【決断編】エンジニアに「デザイン」を迷わせない 〜全画面作成の決断〜
- 【実践編】エンジニアとの接続 〜デザインを伝える〜
- 【確認編】作って終わりじゃない 〜デザイナーが実装まで責任を持つ〜
- 【完結編】「チーム力」が、プロダクトを強くする
- さいごに
【はじめに】Safie Viewerとは
プロジェクトを振り返る前に、Safie Viewerについて簡単にご紹介します。
Safie Viewerとは、「Safie」のカメラで撮影しクラウド上に録画された映像を、リアルタイムで視聴したり、過去の録画を確認したりするためのWebアプリケーションです。録画された映像を、ダッシュボードで自由自在にレイアウトやカスタマイズしたり、切り取りたい映像のスナップショットやタイムラプスを作成し、ダウンロードすることもできます。
【導入編】デザインシステム反映の目的、そして0からのスタート
私はSafie ViewerのUIリニューアルプロジェクトに、ディレクション兼デザイン担当で参画しました。任されたミッションは、「機能や開発要件を変えずにデザインシステムを適用し、UIを刷新すること」。これは以前から「デザイン」と「開発」の間にあった、以下の課題を解決するためです。
- 品質基準の揺れ
- デザインの再現性の低さ
- 個別実装による開発コストの増加
「既存のデザインをデザインシステムに置き換える。」
言葉にすると簡単そうに聞こえるかもしれませんが、いざプロジェクトに参画してみると、UIを刷新するために必要な検討事項や解決すべき様々な課題があることが分かりました。
- 仕様書がない（一部の詳細仕様は立ち上げメンバーの記憶の中に存在）
- 機能拡張により複雑化したUI/UXの見直しや再整理が必要な箇所がある
- どう進めるかの具体はこれから（ここは事業会社の醍醐味かもしれません）
- デザインプロセスで、明確に決まっていたのはほぼ「納期」のみ
デザインの置き換えといっても、単なる表層の変更ではありません。当時のデザインになった経緯、機能仕様、そしてUIの刷新によってUXが最適化されるかどうかも含め、多角的に考慮しながら進める必要があります。
それらの情報や、既存のデザインデータもほぼない状況からのスタートでしたが、私たちのミッションは単にUIを新しくするだけでなく、「どう進めるか」というプロセスを考えるところから始まりました。
しかし、進め方が決まっていない不安よりも、自由に検討できることへの期待の方が強かったです。仕様書がないならみんなで認識合わせすれば良い。進め方が決まっていないなら、自ら提案し、みんなで模索しながら最善策を検討していけば良い。
「どう進めるか」から考え、自分たちの手でプロセスを築き上げていくことが、私にとっても「ワクワクする仕事」でした。
【決断編】エンジニアに「デザイン」を迷わせない 〜全画面作成の決断〜
プロジェクトに参画した当時、私は入社5ヶ月目で会社には慣れてきた頃でしたが、Safie Viewerに関する知識はまだ乏しく、どんな機能があるのか、どのようなユーザーがどのように使っているのか、十分に把握できていない状態でした。
デザインシステムのオーナーとしての役割も引き継いだ後でしたが、すべての仕様や操作など完全に網羅できておらず、エンジニアチームのメンバーとも、ほとんどコミュニケーションを取ったことがない状態からのスタートでした。
「Safie Viewerの理解度を上げるためにも、仕様書もデザインデータもないので、実際に操作してみて、画面を起こすところからはじめよう。」
プロジェクトを進めるにあたって、私がまず着手したのは、既存画面の「洗い出し」と「可視化」による現状把握でした。Safie Viewerの全画面のスクリーンショットを撮り、Figmaにひたすら貼るという作業を行いました。その数なんと、ライトモードのみで約680枚。
当初は、主要画面のテンプレートとデザインパーツのコンポーネントをエンジニアに提供し、実装していただく方針で進んでいました。しかし、対象となる画面とパターンの膨大さを目の当たりにすると、テンプレートのみを渡して「似たようなページはよしなに実装してほしい」という進め方では、エンジニアの負荷が高まり、デザインの再現性も担保しづらく、プロジェクトが破綻すると思いました。
エンジニアとデザイナーでは、専門領域が違うため、注力するポイントや見る視点が異なります。
「ここの余白はどうしたら良いんだろう」「ここはこの色で合ってる？」と、エンジニアの手を止めさせてしまうことは、余計なストレスをかけてしまい、本来注力すべき開発作業の工数を圧迫しかねません。
何が正解か分からないまま進めるより、デザイナーが画面を作り視覚的に正解を示すことで、エンジニアがデザイン理解にかける負荷を減らし、同時に意図した形でUIの再現性を高めることができる。
「デザインに迷うエンジニアの工数」と、「デザイナーが手を動かす工数」を比較すると、デザイナーが工数をかける方が、圧倒的にメリットが大きいと感じ、できるだけエンジニアが実装に集中できる環境を作ろうと考えました。
そして私は、「スクリーンショットを撮った画面すべてをデザインデータとして起こす」という決断をしたのでした。
想定外の効果
この判断は、結果としてチーム間のコミュニケーションに良い影響をもたらします。
具体的に画面を作成し並べることで、「この画面にはこのパターンが抜けているから追加してほしい」「こういう実装方法なので、デザインデータをこのように変更してほしい」「このデザインだと、次の操作はどうなりますか？」など、エンジニア・PdM・デザイナー間で、実際の操作や他の画面パターンを想像しながら、積極的でかつ建設的な議論ができるようになりました。
さらに、「実はこんなレアケースの仕様があって⋯」「実は裏機能があって⋯」など、そんな使い方があったんだ！と、今まで一部の人の頭の中にしかなかった「隠れた仕様」の発見にもつながったのです。
画面全体の可視化は、チームメンバーそれぞれの頭の中にあった仕様や思考も可視化し、結果的に、デザインシステムの実現性とUIの最適化、また共通認識のすり合わせに大きく貢献しました。
【実践編】エンジニアとの接続 〜デザインを伝える〜
「全画面をデザインする」と決めた後、エンジニアへデザインを伝えるプロセスとして特に徹底したことが3つあります。
①デザインの意図や方針を、言葉で丁寧に説明し共有する
他のデザイナーが作成したデザインの意図を読み解くのは、デザイナー同士でも難しい場合があります。職能が異なればなおさら、デザインデータだけで意図を正確に伝えるのは、さらにハードルが高いことだと思います。
そこで、単に完成した画面を渡すのではなく、週3回の定例ミーティングで、担当デザイナーが1ページずつデザインの意図や方針を説明し、不明点を解消しながら進めることにしました。これにより、作成したデザインの意図を正しく伝えることができ、認識齟齬による手戻りを防ぐきっかけになったと思います。
また、PdMとエンジニア側の専門的な視点を交えることで、技術的な実現性やプロダクトの整合性、そしてユーザーニーズとの落とし所などを探りながら進行することができました。メンバーが意見を出し合いながら認識をあわせることで、チームの共通資産を協力して作る場にもなったと思います。
②デザインの意図や仕様を、デザインデータの横に記載する
デザインの意図、仕様、旧デザインとの変更点などをデザインのすぐ横に記載し、開発時にエンジニアが参照しやすい状態にしました。あわせて、定例の中で話した変更点や決定事項なども明記し、後から経緯を振り返れるようにしています。
「書くのを忘れていた！ここどういう仕様だったっけ？」となることもありましたが、細かく面倒なこの作業こそが、後々チームを助けることになりました。
③実装しやすいFigmaデータを作成する
FigmaのDevモードで、エンジニアが参照しやすく、実装しやすいデザインデータの作成を心がけました。オートレイアウトの活用や、コンポーネント・余白の共通化により、可能な限り実装に近い形でデータを作成しています。
細かい点では、Frameの名前も適切に変更しました。Devモードで確認する際、データ構造を素早く理解し、参照箇所に迷わずスムーズに実装できるよう配慮しています。
Figmaの構造上どうしてもFrameが多重になってしまうなど、完全に実装を考慮したデータ作成が難しいケースや、エンジニアチームと微調整を重ねた箇所もありましたが、ある定例で「デザインデータで困っていることはありますか？」と尋ねた際に、「特にありません」という回答をいただけたのは、こうした日々の努力があったからだと自負しています。
また、デザインデータをきれいに作成することは、デザイナー側へのメリットにもつながりました。デザインの更新や修正も容易になり、「この画面を作ってほしい」などの要望にも、スピード感を持って応えられるようになりました。
【確認編】作って終わりじゃない 〜デザイナーが実装まで責任を持つ〜
エンジニアとの連携において、私が最も大切にしていることの一つが、実装後の「デザインQA」です。
前述の通り、デザイナーとエンジニアでは専門領域が違うため、着眼点が異なります。いくらデザインデータが完璧であったとしても、実装後に細かいズレが生じてしまいます。
そのため、実装後に機能的な挙動を確認するQAチームとは別に、「意図したデザインになっているか」「想定通りの操作感になっているか」などデザイナー自身の目で細かく確認しました。
628件のチケットでデザインと開発の「隙間」を埋める
今回、デザイン修正依頼で作成したチケットは、合計「628件」に及びました。一見多く感じるかもしれませんが、この数は今回のエンジニアチームによる実装のデザイン再現性が非常に高く、デザイナーが「ここをもっと良くしたい」と細部までこだわることができた結果です。
チケットを起票する際は、単に文章だけで伝えるのではなく、該当ページのリンク、修正箇所の画像（必要に応じて目印をつける）、発生条件など、可能な限り詳細を記載するように心がけました。
作成には手間がかかりますが、その分修正内容が直感的に伝わりやすくなります。結果的に「どこを直せばいいか分からない」というストレスを軽減したり、デザイン意図の把握や該当箇所を探す手間が省けるため、修正対応が圧倒的にスムーズになると実感しているからです。
最初は「細かすぎる」と思われたかもしれません。しかし、チケットを通じたやりとりが、デザイン意図への理解を深めるきっかけとなり、そこで得た知見が別のページの実装にも活かされるといった好循環が生まれていれば嬉しいなと思います。
自分のデザインに最後まで責任を持つ
「デザインだけ渡してあとはお願いします」と開発側に依頼するのは、私個人としてはあまり好きではありません。世の中に出るプロダクトは、最終的にエンジニアの力があってこそ初めて「形」になると思っています。だからこそ、自分が作ったデザインに対して最後まで責任を持ちたいですし、意図を正確に伝え、対話を重ねることは、結果として「自分が作ったデザインのため」でもあり、「エンジニアへのリスペクト」でもあり、「プロダクトの品質担保」にもつながると考えています。
将来的にはAIの力でデザインの再現度が高くなり、この工程はもっと楽になるかもしれませんが、複雑な機能を持つ業務システムの場合、細部の調整にはまだまだデザイナーの目が必要だと感じています。
デザインQAは私の永遠の課題です。品質を担保しながら、スピード感を持ち、より効率的な進め方を、これからも模索していきたいと思います。
【完結編】「チーム力」が、プロダクトを強くする
私はもともと制作会社の出身です。以前の仕事は「クライアントの要望を形にすること」であり、向き合う先は常にクライアントでした。しかし、事業会社に所属する今は違います。エンドユーザーであることはもちろん、一緒に働くチームメンバーや社員もデザインを届けるべき重要な相手だと実感しています。
私には、「チームの良い空気感が、良いプロダクトを生み出す」というポリシーがあります。心理的安全性が担保されていれば、それだけ遠慮なく意見を言い合うことができ、結果としてプロダクトの質を高めることにつながると信じているからです。
正直に言えば、時には厳しい意見が飛び交ったり、私自身の言い方がきつくなってしまった場面もあったと思います。しかし、それをお互いに受け止めながら、建設的な議論ができたのは、風通しが良く、本音で向き合えるチームだったからだと思います。
お互いを尊重し、相互理解を深めることで目線を合わせ、納得のいく意思決定につなげていくプロセスこそが、セーフィーではとても重要だと感じています。
正解がないからこそ、自分たちで創る
セーフィーのプロジェクトには、「こう進めればうまくいく」という正解はありません。
「ここはまず仕様を整理してからUIに落とそう」「この機能は複雑だから、個別にMTGを設けよう」「ここの意思決定には、UXリサーチャーの視点を借りよう」
その都度、自分たちで最適な進め方を考え、会話しながら進めることは、セーフィーで働く醍醐味の一つです。
1年4ヶ月にも及ぶ「Safie Viewerのデザインシステム反映プロジェクト」は一旦完了しましたが、課題はまだまだ山積みです。Safie Viewer自体のUX改善はこれからも続きますし、デザインシステムの社内浸透もまだまだこれからです。
それでもここまで走り続けることができたのは、エンジニア・PdM・デザイナーといった職種の垣根を超えて、お互いの分からない部分を補完し合い、一緒に良いものを創ろうとするみんなの想いと協力があったからこそだと思います。
最後まで読んでいただき、ありがとうございました！
さいごに
デザインセンターでは、Safieのデザインシステムに関するその他の記事も公開しています。
ぜひ、あわせてご覧ください。
