こんにちは、TECH Street編集部です！
この記事では、2025年7月4日（金）に開催した「デザインシステム勉強会～各社の取り組みや課題から学ぶ会～」の登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。
登壇者はこちらの方々！
T氏
パーソルキャリア株式会社
リードエンジニア（フロントエンドエンジニア）
Webデザイナー、Webディレクター、HTMLコーダー、Flasherなどを経験しフロントエンドメインのエンジニアに。目に見えるとこ作るのが好き。 2024年2月パーソルキャリア入社。前職は10年ほどファッションテック系ベンチャー企業でWebフロントエンドやスマホアプリの開発を行う。現在はdodaダイレクトのリアーキ（根本の仕組みから作りかえる）プロジェクトに従事。
becolomochi
株式会社ROUTE06
プロフェッショナルサービス事業本部Acsim事業部
デザインエンジニア
ROUTE06へ2021年5月入社。プロダクトデザイン〜フロントエンド実装を担当。デザインとエンジニアリングを行き来する中で、デザインシステムやDesign Tokensの整備の設計に興味を持ち、DesignOpsを推進し始めました。
Tomoki
株式会社スタディスト
UIUXデザイナー
2016年新卒で半導体製造装置メーカーに入社し、海外営業に従事。手に職をつけたい思いからデザインを学び、2022年UIUXデザイナーに本業をチェンジ。大阪のスタートアップで1人目の正社員デザイナーとして社内全般のデザイン業務を担当。2023年より現職。BtoB向けSaaSプロダクトのUIUXデザイン・新規事業開発を担う。
古川陽介
株式会社ニジボックス
デベロップメント室室長
JSConf.jp 開催主催者
2019年よりニジボックスに参画、株式会社リクルートではグループマネージャ、Japan Node.js Association では代表理事を務める。 JSConf.jp 開催主催者。
プロダクトリニューアルと同時に進める 初めてのデザインシステム
「デザインシステム」と呼べる日は来るのか？Acsimでの取り組みから考える
身の丈に合うところから始めるデザインシステム
デザインシステムがもはや必須の時代に
Q&Aコーナー
（Q）大企業ですし、横展開って苦労はありませんでしたか？
T氏：はい。現時点では、意志統一がまだ十分とは言えず、課題は残っていると感じています。プロダクトごとに使用されている技術が異なるため、すべてを一気に統一するのは現実的ではありません。そこで現在は、段階的に進めるアプローチをとっています。
（Q）一貫化やりがいがありますね。その場合はどういった役割というか部署がPMを担当するのでしょうか。メインプロダクトが中心となりますか？
T氏：メインプロダクト自体もいくつか存在しています。現時点では一部参加していないプロダクトもあり、まだ曖昧な部分もあります。他のプロダクトのメンバーも巻き込みながら、進めていきたいと考えています。
（Q）パーソルさんの体制面も気になります（大部隊？）。エンジニア部隊との連携の仕組みとかも。
T氏：デザインシステム共通化プロセスの中では、おおよそですが、デザイナーが約５名、エンジニアが約４名という割合です。
（Q）ROUTE06って名前がかっこいいです
becolomochi：ありがとうございます！私もかっこよくて好きです。
（Q）何のツール使うかはエンジニアの自由度高いのですね？うらやましい。取り纏め（取り仕切り）の体制ってどんな感じなのですか？
becolomochi：取締役レベルでもAIツールの活用に積極的で、現場のエンジニアからツールの提案が上がってきます。そのうえで、「利用してよいかどうか」を判断する専任のチームが存在しており、そのチームの承認を得られれば、実際に導入・活用することができます。
（Q）全員に開発知識があると意思疎通がしやすそうですね。全くコード書いたことがない人も学びながら対応しながら覚えていけていますか？
becolomochi：まず背景として、全社でGitHubを使ってドキュメント管理をしているため、GitHubの操作については全員がだいたい理解しています。開発については、開発経験の浅いメンバーも、AIの力を借りつつ各自が学びつつ経験のあるメンバーからサポートを受けつつで取り組んでいます。
（Q）ベースガイドラインってどのようなものでしょうか？
becolomochi：「ボタンは押せる要素であること」といった基本的なルールから始まり、ローディングの表示方法や、ラジオボタン・セレクトボックスの使い方など、どのプロジェクトでも共通で活用できるシンプルで汎用的なルールをまとめています。
（Q）エンジニア以外の人がAIで書いたコードも、モックとまりではなくプロダクトに反映されていますか！？AI化すごすぎます
becolomochi：ケースバイケースですが、レビューでApproveにさえなればプロダクトに反映されることはあります。もちろんモックとして作成され、そのあとエンジニアがモックをもとに作り直してリリースされることもあります。
（Q）共通で使っているトークンの粒度はどれくらいでしょうか？atomやmolecureくらい？
becolomochi：社内で統一されたトークン設計はなく、カラー、スペーシング、タイポグラフィ、幅（width）といった基本的な要素に絞ってシンプルに運用しています。
（Q）まだ歴が浅く、はずかしながらAcsimはじめて聞き、先程調べました。Acsimのお話が聞きたい…！今回のデザインシステムに関連させてAcsimならではのお話ってありますか？
becolomochi：ローディング中に表示されるアニメーションをデザイナーが手がけてくれて、ロゴをモチーフとした図形がくるくると回る動きを実装してくれました。それを見て「テンション上がる！嬉しい！」っていうことがありました。Acsimらしさが言語化されていたためにできたことだと思います。
（Q）AIにはどこまで読み込ませていますか？
becolomochi：基本的にドキュメントはリポジトリ内のdocsディレクトリ内に入っていますが、必須で読み込ませるファイルはデフォルトの指示に設定されており、必要に応じて随時指示を出して読み込ませています。
（Q）デザイントークンのレビューって職種的にどなたがやれていますか？Sassでデザインシステムを導入してみたのですが、ブラウザには値で表示されているため、デザイントークンのレビューをデザイナーができないという課題がありまして。
Tomoki：弊社は、整備の取り組みを始めてから日が浅いので、まだレビューらしいレビューはないです。決める際は、デザイナーとエンジニアが会話しながら、命名ルール、書き方のルールを決めています。
（Q）最近のニュースみたいなお話嬉しいですね。これみなさんからも、最近気になった話とか時間あれば聞いてみたいです
Tomoki：最近 Figmaのアップデートがあって「Figma Make」が使えるようになりました。社内でも「AIをどう使うか」は話題です
（Q）リサーチ＆デザイン室、いいですね。開発本部ってことは、その下部組織ですか？体制とか気になるのと、社内での横串体制とかあるのか気になります
Tomoki：リサーチ室は開発本部に位置する組織です。社内は職能ごとに部が分かれており、エンジニアもテーマごとにチームを編成しています。プロジェクト推進にあたっては、いわゆる横串体制で連携を取りながら開発を進めています。
（Q）ともきさんがリーダーとしてプロジェクトを進行したのでしょうか
Tomoki：特にリーダーという明確な役割を設けていたわけではありません。自分自身が作業を進める中で、「こういうものがあったら便利だな」と感じたものを、自発的に整理しはじめたのがきっかけです。その取り組みに対して、エンジニアの方から声をかけていただき、そこからさらにプロジェクトが前に進んでいきました。
（Q）ジョイン前から職種は変わらず、ジョインして学び・情報収集時間なく即ゴリゴリやって行った感じですか？
Tomoki：その時々で必要に応じて調べながら、「自分のチームにはどんなアプローチが合うだろう？」と考えて取り入れてきました。事前にしっかり準備してから、というよりは、必要に迫られて情報収集しながら、実践を通じて学んでいくことが多かったです。
（Q）楽になるように！だいじですね。これはエンジニアもそうですか？そしてTeachme AI気になります。
Tomoki：デザイナー・エンジニアどちらもです。Teachme AIで作成や編集が楽になってきているので、使える環境でしたらぜひお試しください。
（Q）元々未経験とのことですが、どこでUIUXの知識を付けたのですか？また、デザイナーでエンジニアさんとの意思疎通で苦労する部分はどこですか？
Tomoki：営業職から転職した直後に入社した会社では、正社員が自分ひとりという状況でした。そのため、すべてを自分で対応する必要があり、オライリーの書籍やnoteの記事などを読みながら独学で学びました。実務を通して実践し、改善を重ねる中で少しずつ知識を身につけていった形です。現在は、エンジニアの皆さんがとても優秀で、ざっくばらんにコミュニケーションが取れているため、大きな意思疎通の壁は感じていません。ただ、データ構造について質問する際には、どう聞けば的確に伝わるか悩むことはあります。
（Q）お話しめちゃくちゃ共感しました。ありがとうございます。エンジニアとの連携などどのようなコミュニケーションをとってトークン名など揃えたのかなど気になります。実装上この命名は使えないなどなかったのでしょうか。
Tomoki：週1で設定したミーティングで会話して、一緒に他社の資料とか眺めながら、トークンの命名の仕方は決めていきました。命名規則を一緒に決めているので、実装上使えないと言われたことは今のところないです。
（Q）デザイナーです。デザインシステムを進めていて、タブ、アンカーリンク、ボタンなど、いろんなパーツの共通化を進めています。サイトがECサイトでして、特集のページを作るのですが、ページごとにデザインを少し変えたいということで、パーツを定義しても、定義したもの以外のパターンを作ってほしいという要望があったりで、なかなか共通化が難しいと感じています。何かアイデアというか、、アドバイスなどあれば、、、嬉しいです！
Tomoki：パーツの要素を分解して考えて、共通化できるところからしていくのはどうでしょうか？形状・色・状態変化、など分けて、例えばホバーする時はシステムからのFBがわかるように背景色を変えること、みたいにここだけは統一する、という部分から整理するのは1つアイディアとしてあるかと思います。パーツ内の余白の取り方は、左右でXXpx, 上下XXpxとすること、みたいなのもアリかもしれません。
（Q）デザインルールの決定にあたり最終的に決めの問題になる時、決め手や基準などありますか？
Tomoki：決めて自分たちが楽になるか、です。ルールを決めすぎて逆に身動き取りにくい、メンテナンスしにくいもあると思うので、今決める必要ないなら、決めないでおこうとした時もありました。
（Q）組織の皆さんのデザインシステムに対する理解度ってどんな感じでしょうか？私たちのところでは、デザインシステムやデザインガイドラインといった言葉が一人歩きしていて、デザインシステムを作る前にまず言葉の共通認識を揃えるところが大事だなあと。
Tomoki：弊社も人によって、デザインシステムという言葉が何を意味するか、ここの認識は人によって差があると思います。共通認識を揃えるのは大事だが、関わる人が少ないので、まだそこまできっちりしなくてもいいかという状況に甘えてはいます。
（Q）デザインシステム公開を検討しているのですが、公開する際の注意点やメリットを上司とかけあうために調べています。公開についてみなさんの意見を聞いてみたいです
Tomoki：デザインシステムの公開は、一種の企業ブランディングかなと個人的には捉えています。きっちり整備して公開できる力がある、しっかりしたデザイン組織として対外的に発信できるもの、というイメージがあります。
（Q）ニジボックスさんのデザインシステムの体制、変遷、課題などの話があれば聞いてみたいです。
古川：デザインシステムに関する依頼があった際、最初に動き出すのはデザイナーチームです。まずはFigmaなどを使って、見た目の部分だけでも形にしてみることが多いです。たとえば、色味やトーン＆マナーなど、ビジュアル面に関する基本的なルールを明文化するところからスタートします。その次にエンジニアが加わり、実際のデザインカタログとして実装に落とし込んでいくという流れです。ただ、それを一度作って終わりにするのではなく、形骸化させずに継続して活用できるようにすることが今後の課題です。ニジボックスとしても、引き続きその運用を支援し続けられる体制を整えていきたいと考えています。
（Q）費用対効果で悩んでいます…とツール継続・乗換等の指標、見るべき箇所、重要な意識すべき箇所あればぜひアドバイスお願いします
古川：私自身も同じように悩んでいますし、完璧な試算は出来ないと思っています。よくあるのはまずはスモールスタートで、一つのプロダクトで進めてみて、効果を見てみるのが良いのかなと思います。まずは小さなプロダクトで試算してみてください！
▼▼ ぜひ他登壇者の発表レポートもご覧ください
