DMMデザインシステムチームが語る、経験主義に陥らないコラボレーションパターン。 – UI+FE合流点レポート

8月6日、DMM.com さんと Gaji-Labo との共催で開催した『UI＋FE合流点』のレポートです。
（UI＋FE合流点は、プロダクトをとりまくさまざまな職能の人たちが、より良い仕事をする合流点を探るイベントです。「UI＋FE ジャンクション」と読みます）

今回は、DMMのデザインシステム「Turtle（タートル）」チームのみなさんに、デザインシステムの浸透や事業プロダクトチームとのコラボレーションについてお話をお聞きしました。

60以上の多岐にわたる事業を持つ会社のデザインシステム運用という、他の会社ではなかなか聞くことができない生々しい話ばかりで、とても学びのある時間でした。

DMMデザインシステム「Turtle（タートル）」チームのみなさん

ふるじゅんさん（@design_oldriver）デザイナー/プロダクトオーナー

ひらたさん（@04300815）デザイナー/スクラムマスター

debiruさん（@debiru_R）エンジニア

60以上の事業がある会社のデザインシステム！？

「Turtle」は、2021年頃にボトムアップでスタートしたそうです。

決済やポイントといった「共通機能」を開発するチームに焦点を絞り、そこにデザインシステムを導入することで、効果的に普及を進めています。

現在は、共通機能を使うデジタルプロダクトの約半数に導入されているとのこと。

サービスが複数あるので、あるサービスに入って出て、また別のサービスに入っていくようなユーザージャーニー

（ひらたさん）

ひらたさんのこの言葉は、複数の大規模サービスを使うユーザーがいるDMMさんならではのものです。この観点でデザインシステムを運用している話は、とても刺激的でした。

さらに、ひらたさんからはこんな発言も。

DMMはやっているサービスが多いから、ひとつの色にするということだとDMMのサービスを否定することにもなるので、それでは事業部門の開発チームにデザインシステムが使われなくなってしまう。

（ひらたさん）

60以上の事業がある会社のデザインシステム運用という、他ではなかなか聞くことができない生々しいお話をたくさんお聞きできました。

社内での利用率を KPI にしない。

Turtleチームの面白いところは、デザインシステムを作るチームでありながら、社内に押し付けて使ってもらうようなことをしていない点です。

ふるじゅんさんのこの言葉には痺れました。

デザインシステムを作るチームとしては、社内でどれだけ導入されたかをKPIにしたくなるけれど、私たちは導入率を上げることを目的にしないようにしている。

どれだけ使ってもらうかではなく、デザインシステムでどんな効果をもたらしたいかで考えるようにしています。

（ふるじゅんさん）

いまはデザインシステムによって開発効率が上がったチームがあったり、新規事業が始まる際に「この事業では Turtle を使いたい」と言ってもらえる存在になってきてはいるものの、

デザインシステムを（価値があるからではなく）作りたいからやってるんでしょと思われていた時期もあって、人によっては「全社に強制する気か」と思っている人もいたかもしれない。

（ひらたさん）

という時期もあったそうです。

debiruさんによると「いまでも『Turtleってなんのために使うものなの』っていうチームもあるので発展途上。コミュニケーションを模索している」とのことです。

デザインシステムの「ユーザー」に寄り添う、マーケットイン的なアプローチ。

デザインシステムを社内に浸透させる上で、ふるじゅんさんは「我々はマーケットインをやっている」という独自の視点を持っていました。これは、自分たちが作ったものを一方的に押し付けるのではなく、DMMの各事業やプロダクト開発チームを「マーケット」と捉え、利用者のニーズや課題に寄り添う姿勢を示しています。

Turtleチームは（デザインシステムの）プロダクトビジョンやコミュニケーションパターンを策定したそうで、ひらたさんは「これを作ってから上手くいくようになった」と語っていました。

ユーザー中心設計というわけではないけれど、できるだけ現場のデザイナーやエンジニアという利用者側とのコミュニケーションを設計した。

(ふるじゅんさん)

そんな話の中で出てきた「癒やしを提供する」という言葉。

「癒やしを提供する」っていうコミュニケーションにしたい。 「あなたたちのやりたいことができます」でなくてはいけない。

(ひらたさん)

社内にいる「ユーザー」のためにもデザインシステムは「意識高い人が考えたものを押し付けられている」と思われてはいけないということを強調されていたのが印象的です。

現場から求められるものにする。

(debiruさん)

こんな姿勢を徹底しているからこそだと思うのですが、「リプレイスが早く進められるので Turtle を使いたい」と言ってもらえることがあるとのこと。

使ってもらうための社内営業のようなことはせず、ユーザーにとって良いものづくりをするためのコミュニケーションをしているという話は、プロダクトづくりをしている参加者にも刺さったのではないでしょうか。

「経験主義に頼らない」コミュニケーションパターン

今回のサブタイトルは『経験主義に頼らないコラボレーションパターン』。

普通にデザインシステムのイベントをやるのではなく、わかる人にだけ伝わるようなイベントにしてしまおうということでこのテーマにしたのですが、会場に来てくださった参加者のみなさんはベテランのデザイナーやPdM、エンジニアの方々が多かったように思います。
（サブタイトルの意図が伝わって良かったです）

デザインシステム自体が、個人の知識や経験に依存せずに誰もが再現性をもって高品質な開発・デザインができる状態を目指すものであることは誰もがわかることですが、

個々人が経験したことが会社の資産になっていかない。

デザインシステムはその経験した知を共有資産化できる。

(ふるじゅんさん)

個々の経験を「会社の資産にする」という視座で見て、デザインシステムに取り組まれていることに衝撃を受けました。

その資産のひとつが、「設計ログ文化」の確立と透明性です。

デザインは「ここがよくない」ってみんなが言いやすいから、どうしてそうなっているのかの過程と透明性を残すことが大事。

(ふるじゅんさん)

Turtleチームは、数年後でもどうしてこれに決めたのかがわかるようなログを残すことにしているそうです。

たとえば、チェックボックスコンポーネントとラジオボタンコンポーネントで props の名前が違うということがあったとき、それが理由がある意図的なものなのか、考慮漏れなのか。
見ただけでは設計意図や経緯が分からない。

私たちは、そういったことをしたくないから設計ログ文化でやるようにしていて、GitHub の Issue や PR に設計の経緯を書いて、明日自分が消えてもいいようにあのメッセージを残す。

(debiruさん)

経験主義的に作られていると、「どうしてこれに決めたのか」を上手く説明できない場合があるけれど、それだと透明じゃない。

(ひらたさん)

ふるじゅんさん、ひらたさんがイベント中に何度も何度も「透明」という言葉を使っていたのも印象に残りました。

私たちは「明日トラックに轢かれてもいいように」設計ログ・途中経過を残しています。トラックナンバー3くらいにはしておきたい（笑）

(ふるじゅんさん)

トラックナンバーとは「誰かがトラックに轢かれたらプロジェクトが立ちゆかなくなったり、活動が困難になる人数」のことです（笑）

Turtleチームでは、このトラックナンバーを意識した設計ログ管理を徹底しています。
これもまた設計の意図や背景を詳細に記録し、明日だれかが関われなくなっても理解できる状態を保っている「透明にしておく」の実践です。

それにしても、まさかデザインシステムの話で「トラックナンバー」が出てくるとは思わず、会場もどよめいていました。

Figmaからコードを出力する 独自MCPサーバー を開発。これもコラボレーションパターンのひとつ。

TurtleチームではAI活用も進んでいます。
debiruさんが開発しているのが、デザインシステムから品質の良いコードを出力させるプロジェクト「AI Turtle」です。

FigmaのデザインデータからAIに直接コードを生成させると、品質が低かったり、コンポーネントが正しく使われないといった問題が発生するため、独自に「Turtle MCP」サーバーを開発。 Figma MCPをクローンして開発したそうです。

CursorとかAIにMCPのレスポンスを基に設計を考えさせるとコードの品質に揺らぎが出るので、Turtle MCPサーバー側で設計したコードをレスポンスしてしまうアプローチを採用しました。

(debiruさん)

CursorやClaudeが品質の高いコンポーネントソースをそのまま受け取ることができているとのこと(すでに社内で活用がはじまっているとのこと)。

他にも、デザインシステムのドキュメントを整備もしているそうで、徹底して社内にいるユーザーのことを考えて動かれていることが伝わってきました。

「Figmaから良い感じのコードを出力する」ことを目的にやっているのではなく、これもまたデザインのハンドオフというコミュニケーションパターンのひとつだというところがTurtleチームの凄いところだと思います。

合流を実践するための『UI＋FE合流点』

今回の『UI＋FE合流点』はどうでしたか？

本イベントは、UIデザインとフロントエンド開発という隣接した職種の「合流点」を発見するためのイベントとしてスタートしましたが、今回は5,000人以上が関わる60事業を抱える組織でのコミュニケーションパターンの話にまでテーマが広がりました。

イベントの中で、ふるじゅんさんが言った印象的な言葉がありました。

ある意味、私たちはぬくぬく自分たちの理想的なものを作っているので、会社や事業の課題の外、プロダクト開発の外で作っている。

プロダクト開発現場の人たちの課題に適合したソリューションに成長させていくことだったり、適したコミュニケーションをし続けるマインドをチームに根付かせることが必要。

(ふるじゅんさん)

これをデザインシステム推進側が言っているのはすごいことだと驚きました。 たくさんの事業のさまざまな人たちとコミュニケーションをとり、「合流点」を探している人ならではの言葉だと思います。

今後も、プロダクト開発にまつわるさまざまな合流点を探し、『UI＋FE合流点』を続けていきたいと思っています。「参加したかったけど知らなかった」や「次は参加するぞ！」という方は、Gaji-LaboのX(Twitter)アカウントをフォローするか、connpassのメンバーになると次回のイベント情報もキャッチできると思います。

それでは、また次の会場でお会いしましょう！