はじめに
こんにちは。DMM.com の高井 実です。
私は2000年頃より debiru (@debiru_R) という名前で HTML, CSS の設計手法やリソースの在り方、URL の考え方について研究してきました。近年では Web アクセシビリティ、セキュアな Web アプリケーション開発手法、パスワードポリシーの在り方、DNS の仕組みについて考察・啓発しています。
DMM.com では、プラットフォーム開発本部 第3開発部 Developer Productivity グループのフロントエンドチームで、社内プロダクト向けのデザインシステム Turtle を開発しています。Turtle は現在 React アプリケーション専用のコンポーネントライブラリを提供しています。
2024年2月に DMM.com に入社し、この12月で入社11ヶ月目になります。私が入社する前から Turtle は開発されており、私は途中から開発に参加したという立場であるため、過去に行われた設計や実装については私が知らない部分もあります。
この記事では、私が入社してからこの10ヶ月間で DMM.com で取り組んできたこと、特に Turtle 開発の周辺情報についてお伝えできればと思います。
私のチーム
私の所属しているフロントエンドチーム（本部、部、課などでいう課に相当）は2024年12月現在で8名いますが、その中で2つのチームに分かれています。App チームと Turtle チームです。私は Turtle チームに所属しています。
App チーム（エンジニア4名）では、DMM のプロダクト関連サイトの開発リソースに関する Monorepo 管理や決済に関わるプロダクトのサイト開発など、フロントエンド領域のインフラ管理を担当しています。
Turtle チーム（デザイナー2名、エンジニア2名）では、DMM のプロダクト関連サイトを開発する際に効率的な開発ができるようにするためのデザインシステム Turtle を開発・運用・提供しています。
私の Turtle チームではスクラム開発を採用しており、1週間のスプリントで開発作業を行っています。1週間ごとに成果物を出しフィードバックを得ているので、まるで Web ブラウザ等のラピッドリリースのような、高速な新機能のリリースと軌道修正ができるようになっています。
また、モブ作業（複数人で群がって1つの作業をすること）を積極的に実施することで、デザイナーとエンジニアという垣根を超えて、それぞれの職種の視点を共有しながら日々の作業を行えています。チームにスクラム開発のベストプラクティスを馴染ませるのには少し時間がかかりましたが、慣れてからは効率的な開発が実現できるようになり、1週間という短いスプリント期間の中でも価値（成果物）を計画通り出せるようになりました。
10ヶ月間での私の取り組みタイムライン
- 2024年2月
- 入社し、React を初めて触りました
- 3月〜5月（第1四半期）
- React と Turtle に慣れる目的も含め、Turtle コンポーネントライブラリを使った「デモサイト（リファレンスアプリ）の作成」をしました
- 社内横断型の LT 大会で「DNS 浸透いうな」というテーマで講演しました
- 6月〜8月（第2四半期）
- Turtle デザインシステムの改善施策として、「デザイン原則」の見直し、「デザイントークンの一元管理」を行いました
- 9月〜11月（第3四半期）
- 引き続き Turtle の改善施策として、「Figma Code Connect の設定」と「ドキュメントの一元管理」を行いました
- 社内横断型の LT 大会で「DNS 浸透いうな（改）」というテーマで講演しました
さらっと書いていますが、Turtle の改善施策では技術的な仕組みづくりや工夫を凝らしたシステム設計術を多分に含んでいるため、この記事ではその工夫されたポイントについて紹介します。余談ですが DNS といった Turtle 以外の活動についても最後に少しだけ触れたいと思います。
Turtle とは
まず始めに、Turtle の概要と構成について触れておきます。
Turtle とは、DMM.com プラットフォーム開発本部 フロントエンドチーム（Turtle チーム）にて開発しているデザインシステムの名称です。プラットフォーム開発本部は、認証・決済など DMM のプラットフォーム機能を担当しています。
DMM.com 社内では様々な部署があり、各部署ではプロダクトを開発しています。そのプロダクトの Web サイトを開発する際にデザインシステムを用いられることがありますが、そのデザインシステムはいくつかの部署によって独自に開発されたりもしています。
我々のフロントエンドチームは組織横断型のチームとして、社内で統一的に、全プロダクトで使われるような DMM.com 唯一のデザインシステムを目指して Turtle を開発しています。現状では Turtle はプラットフォーム機能全体への適用はできていませんが、いくつかのプロダクトでは採用してもらっています。また一方でプラットフォーム外でも一部のプロダクトで採用されており、そのシェアを少しずつ伸ばしています。将来的には DMM で全社的に使われるデザインシステムとして、社外公開もできたらと考えています。
Turtle について過去に公開された記事があるので、ここで紹介しておきます。
- （2022年8月）DMM プラットフォームのフロントエンド開発を支えるエコシステム
- （2022年10月）デザインシステムにおけるタイポグラフィーの試行錯誤
- （2023年3月）サービスを支える基盤であり共通言語。DMMのデザインシステム「Turtle」が目指すもの
Turtle の構成要素
デザインシステムとして、次のような要素を持っています。
- デザイン原則
- ガイドライン
- スタイルガイドライン
- アクセシビリティガイドライン
- コミュニケーションガイドライン
- Turtle ライブラリ
- デザイントークン
- コンポーネントデザイン（Figma）
- コンポーネント実装（React）
- ドキュメント
- Turtle マニュアル（デザイントークンやコンポーネントの説明書）
- コンポーネントショーケース（Storybook）
デザイン原則
Turtle デザインシステムは、次の5つの価値を大切にします。
- Achieve Goals - 効率的に目的を達成できる
- Bring out Abilities - クリエイターの能力を最大限に引き出す
- Consistency - 一貫性を担保する
- Design Intent - 設計の意図を明確にする
- Evolve - 変化を恐れず進化する
それぞれの項目を英語にして頭文字を取ると ABCDE となるようにしてみました。デザイン原則を忘れたときにも ABCDE をきっかけにして思い出すことができます。
この項目それぞれについても、より詳細な意図や思いがありますが、ここでは割愛します。いつになるかはまだ分かりませんが、将来、Turtle がパブリックに公開できるようになった暁にお披露目できればと思います。
ガイドライン
Turtle を使ったりカスタマイズしたりするときにはどのようなことを意識して守らなければならないかについて規定したガイドラインです。
スタイルガイドラインでは、主にデザイントークン（色や余白など）の使い方に関する取り決めを定めています。
アクセシビリティガイドラインでは、最終的に出力される HTML がどのようになっているべきなのかについて Web アクセシビリティの観点から取り決めを定めています。
コミュニケーションガイドラインでは、主にクリエイター（デザイナーとエンジニア）が効率よく開発を進めるための取り決めを定めています。
Turtle ライブラリ
デザイントークンでは、次の5つの要素をトークンとして用意しています。
- border-radius
- color
- spacing
- typography (font-family, font-size, font-weight, line-height)
- z-index
コンポーネントデザインでは、Figma でデザインデータを管理しており、Turtle 利用者は Figma 上で Turtle のコンポーネントを利用して Web ページをデザインできます。
コンポーネント実装では、React のコンポーネントライブラリを提供しており、React ベースのアプリケーション（Web サイト）を開発するプロダクトであれば React コンポーネントを利用して実装できます。将来的には React に限定されない形で Turtle コンポーネントの提供を目指しています。
ドキュメント
Turtle マニュアルでは、デザイントークンやコンポーネントの種類や使い方、設計意図について、Turtle 利用者が知りたい情報をまとめています。
コンポーネントショーケースでは、Storybook を用いて、実装コードの実際の表示結果やバリエーションを Web ブラウザ上で確認できるようにしています。
Turtle 開発で取り組んだこと
前置きが長くなりましたが、ここからが本題です。
- 3月〜5月（第1四半期）
- React と Turtle に慣れる目的も含め、Turtle コンポーネントライブラリを使った「デモサイト（リファレンスアプリ）の作成」をしました
- 6月〜8月（第2四半期）
- Turtle デザインシステムの改善施策として、「デザイン原則」の見直し、「デザイントークンの一元管理」を行いました
- 9月〜11月（第3四半期）
- 引き続き Turtle の改善施策として、「Figma Code Connect の設定」と「ドキュメントの一元管理」を行いました
デザイン原則については前述しましたが、見直した結果、現在の ABCDE 原則を制定しました。
ここからは、デモサイト（リファレンスアプリ）の作成、デザイントークンの一元管理、Figma Code Connect の設定、ドキュメントの一元管理について詳細に解説していきます。
デモサイト（リファレンスアプリ）の作成
Turtle を使った参考サイトとして、リファレンスアプリと呼んでいるデモサイトを作成しました。Turtle の改善をするにあたってユーザー（Turtle 利用者）が何を求めているかをヒアリングしたところ、Turtle の使い方を理解できる実装例があると助かるという意見がでました。
そこでフォーム周りのコンポーネントの実装例を紹介するための、会員登録ページ（フォーム入力ページ、確認ページ、完了ページ）を作ることにしました。Turtle を使って Figma でデザインを行い、そのデザインに沿って React で実装をしています。デザインの再現だけでなく、住所入力フォームでは郵便番号から住所を導出するといったインタラクティブな機能も参考実装として行いました。
これまで Turtle デザインシステムを開発してきましたが、Turtle を実際に使って Web サイトを作るといった機会を設けていなかったため、実際に自分たちで Turtle を使ってみると不便な点や改善点がいくつか見つかりました。改善点についてはリファレンスアプリの開発と並行して修正作業を行い、改善したコンポーネントをリファレンスアプリで使える状態にできました。
デザイントークンの一元管理
Turtle ライブラリとして「コンポーネントデザイン」と「コンポーネント実装」があり、またドキュメントとして「Turtle マニュアル」があると述べました。
例えば、Color のデザイントークンである Blue100 について、このグローバルトークンに対応するカラーコードの値は何でしょうか。その値を我々は決めてはいるのですが、その値 #EBF3FF をどこに保持しているかというと、「コンポーネントデザイン」と「コンポーネント実装」と「Turtle マニュアル」にそれぞれ記述していました。
これでは、値が変わったりトークンが増減したときに3箇所を変えなければなりません。また、変更を忘れたり、書き間違えたりしたときにデザイントークンの整合性が失われてしまいます。
この問題を解決するための取り組みが「デザイントークンの一元管理」でした。これを第2四半期である6月〜8月に取り組みました。
デザイントークンの一元管理：改善案
この図では次のような構成であることを述べています。マスターデータとしてスプレッドシートを用意し、スプレッドシートから GAS（Google Apps Script）を経由して JSON を出力します。その JSON を GitHub でバージョン管理しつつ GitHub Pages で取得できるようにします。JSON には2種類あり、単にスプレッドシートの記述内容を二次元データとして出力した Simple JSON 形式と、Figma でデータをインポートできるように加工した JSON for Figma 形式があります。これらを「Turtle マニュアル」「コンポーネント実装」「コンポーネントデザイン」に渡してインポートして使うようにします。
スプレッドシートと GAS
スプレッドシートにはデザイントークンとその具体値をプログラムから利用可能な形式で記述しておきます。一部のセルは計算式を利用して自動的に出力しています。
GAS（Google Apps Script）では、スプレッドシートに記述した内容を Web API として JSON で参照可能なように公開する機能があります。JSON として参照できるようにするためには、Web API のデプロイ操作の他に、GAS に doGet という関数を定義する必要があります。
以下は単純化した実装ですが、これでスプレッドシートの内容を JSON として参照できます。
const SID = 'スプレッドシートのID'; function doGet(e) { const data = getRecords('globalColor'); return jsonResponse(e, data); } function getRecords(sheetName) { const sheet = SpreadsheetApp.openById(SID).getSheetByName(sheetName); const values = sheet.getDataRange().getValues(); const keys = values.shift(); const records = values.map(row => row.reduce((acc, cell, i) => { acc[keys[i]] = cell; return acc; }, {})); return records; } function jsonResponse(e, data) { const json = JSON.stringify(data, null, 2); const response = { mime: ContentService.MimeType.JSON, content: json, }; return ContentService.createTextOutput(response.content).setMimeType(response.mime); }
[ { "colorName": "gray", "token": 50, "mode.Light": "#FFFFFF" }, { "colorName": "gray", "token": 75, "mode.Light": "#FAFAFA" }, { "colorName": "gray", "token": 100, "mode.Light": "#F5F5F5" }, ... ]
GAS を実装するにあたっては、コードのバージョン管理やテストコードの実装も含めて行うため、Clasp を用いてコマンドラインベースで GAS の管理ができる仕組みを整えています。
詳細は GAS を Clasp + esbuild + TypeScript + Jest + Git 環境で管理・開発するをご覧ください。
Figma への JSON インポート（Local Variables Manipulator プラグイン）
Figma には Local Variables という変数を管理する仕組みがあります。これを用いて Figma 上でデザイントークンを管理しています。しかし、Figma には Local Variables のインポートやエクスポートといった機能が標準では用意されていません。そのため、それを実現したい場合はプラグインを用いる必要があります。
この作業を進めていた2024年7月時点で、Local Variables のインポート・エクスポートを行うプラグインはいくつか存在していましたが、JSON の形式や使い勝手に多少問題があったため、プラグインを自作することにしました。
自作したのがこちらの Local Variables Manipulator プラグインです。略称は LVM です。LVM の内部実装について興味がある方は、Figma Plugin API を用いた Local Variables Export/Import プラグインの開発をご覧ください。
Export ボタンを押すと、現在の Figma ファイル上に設定されている Local Variables を JSON 形式で出力します。
Import ボタンは、Export される JSON と同じ形式で記述した JSON を基に Figma ファイルに Local Variables を設定（上書き）する処理を実行します。
JSON の形式は次の通りです。
{ "ColorExample": { "Alias Token/primary": { "$variableValues": { "Light": "$Global Token/blue/100", "Dark": "$Global Token/blue/100" }, "$description": "", "$codeSyntax": { "WEB": "color.aliasToken.primary" }, "$scopes": [ "ALL_SCOPES" ], "$hiddenFromPublishing": false }, "Global Token/blue/100": { "$variableValues": { "Light": "#0000FF", "Dark": "#0000FF" }, "$description": "", "$codeSyntax": { "WEB": "color.globalToken.blue['100']" }, "$scopes": [ "ALL_SCOPES" ], "$hiddenFromPublishing": false } } }
これで、Figma に関してはマスターデータであるスプレッドシートから、Figma の Local Variables へデザイントークンのデータを入れることができるようになりました。
Turtle マニュアルと React コード
Turtle マニュアルは、もともとは JavaScript が記述可能な社内 Wiki サイト（Confluence）に掲載していました。そのため、2024年7月時点ではそのマニュアルページから JSON でスプレッドシートのデータを取得してマニュアルに書き出すという手順を採ることで、マニュアルについてもデザイントークンの一元化が実現できました。
コンポーネント実装である React コードについては、もともと実装側にデザイントークンをベタ書きしていたわけですが、これを JSON から変換して実装コードとして利用可能になるようにしました。JSON と実装コードの変換処理を吸収するライブラリとして turtle-design-tokens というものを新たに作り、そこで Simple JSON を受け取って実装コードに変換するという手順を採りました。
一つポイントだったのが、もともとデザイントークンの実装コードには JSDoc を丁寧に書いていて、それによって VS Code 等の開発環境で JSDoc の内容がコードヒントとして出力されていました。そのため、単に JSON をプログラム的にインポートするだけだと JSDoc の情報が失われてしまうという問題がありました。これを防ぐため、JSON をインポートするだけではなく、メタプログラミングする形で JSDoc や型情報を含めてデザイントークンの JSON を実装コードに変換するという仕組みを考えました。
「デザイントークンの一元管理」については以上です。次は「Figma Code Connect の設定」について見ていきます。
Figma Code Connect の設定
Figma は高機能なデザインツールであり、デザインデータとしてコンポーネントやプロパティを設定できます。このため、Figma 側に各種コンポーネントが存在し利用可能になっているのですが、Turtle デザインデータでは、そのプロパティ設計などが実装コードと乖離しているという問題がありました。
実装コードと Figma データでは、そのプロパティの使い方などが若干異なるため、必然的に差異は多少生じてしまいます。しかしながら、同じ機能なのにプロパティ名が実装とデザインで異なっているなど、差異が生じなくてもよい場面で差異が生じているということがあったのでこれらを統一するために Figma データを修正することにしました。
また、Figma には Code Connect という機能があります。これはデザインデータ上で組んだコンポーネントやプロパティの設定に対して、それに対応する実装コードを Figma 上で出力するというものです。これを用いるとコーディング作業時に Figma からコードをコピーペーストするだけで実装ができてしまうという強力な機能になっています。この機能を活かすべく、Figma データを修正してから Code Connect を全コンポーネントに対して設定するという作業を2024年10月に行いました。
React による Code Connect
公式の React Code Connect ドキュメントは、2024年9月時点で情報がそれほど充実しておらず、試行錯誤しながら Code Connect を設定する手順や仕様について調査しながら作業を進めました。
Code Connect のテンプレートファイルを生成するには、サブコマンドなしで npx figma connect を実行する手順が紹介されています。これは「Figma 上のどのコンポーネントに、どの実装ファイルを関連付けるか」というのを対話型モードで操作するのですが、対話型モードは操作するのが少し面倒です。慣れてくれば以下のようにサブコマンドを付けてコマンド一発で *.figma.tsx ファイルを生成した方が効率良く作業できました。
npx figma connect create "Figma コンポーネントの URL" -o "./path/to/index.figma.tsx" --token "アクセストークン"
Code Connect は、設定用の実装コード（*.figma.tsx）を記述して、コマンドラインから publish コマンドを実行することで Figma ファイルへの設定をします。しかし、その設定用の実装コードは一般的なプログラムコードとは異なり、Code Connect 独自の構文上の制約が存在します。
Code Connect の docs/react.md より引用：
Note: Code Connect files are not executed. While they're written using real components from your codebase, the Figma CLI essentially treats code snippets as strings. This means you can use, for example, hooks without needing to mock data. However, this also means that logical operators such as ternaries or conditionals will be output verbatim in your example code rather than executed to show the result. You also won't be able to dynamically construct figma.connect calls in a for-loop, as an example. If something you're trying to do is not possible because of this restriction in the API, we'd love to hear your feedback.
（拙訳）Code Connect ファイルは実行されません。これらのファイルはコードベースの実際のコンポーネントを使用して書かれていますが、Figma CLI は本質的にコードスニペットを文字列として扱います。つまり、データをモックすることなく、例えばフックを使用できます。しかし、これは、条件演算子（三項演算子）のような論理演算子が、結果を表示するために実行されるのではなく、サンプルコードにそのまま出力されることを意味します。また、例えば figma.connect の呼び出しを for ループの中で動的に構成できません。API にこのような制限があるために、あなたがやろうとしていることができないのであれば、ぜひフィードバックをお寄せください。
というようなことが書かれています。冒頭の「Code Connect ファイルは実行されません」というのが制約として特殊であり、通常であればループ文や条件分岐を使って書けるコードを、コピーペーストする形で何個も書かなければならないということです。
Code Connect 設定用の実装コードの例を以下に示します。この3行目の URL 部分を変数にしたり、コード下部の example プロパティの関数の中にロジックを記述したりすることが一切できません。実行コードのようで、文字列として解析されて処理されるというわけです。
figma.connect( FormLabel, 'https://www.figma.com/design/...', { props: { labelText: figma.string('labelText'), badgeType: figma.enum('badge?', { required: 'required', optional: 'optional', none: 'none', }), }, example: (props) => { return ( <FormLabel label={props.labelText} badgeType={props.badgeType} /> ); }, }, );
2024年10月はこの Code Connect の設定を Turtle の全コンポーネントに対して行いましたが、その経験によって Code Connect に関する知見をたくさん得ることができました。また、10月16日にリリースされた Code Connect v1.2.0 では React の publish 実行時の不具合を発見し報告しましたが、これは10月24日にリリースされた Code Connect v1.2.1 で修正していただきました。
「Figma Code Connect の設定」については以上です。最後に「ドキュメントの一元管理」について見ていきます。
ドキュメントの一元管理
Turtle の利用者が Turtle の情報を確認したいとき、2024年10月時点では社内 Wiki サイトを確認したり、Storybook を確認したりと、リソースを行き来する必要がありました。将来的に Turtle の情報を一般公開することを考えたとき、社内 Wiki サイトは公開できないので困るということもあり、公開に向いている Storybook 上に Turtle マニュアル情報を集約することにしました。
また、ドキュメントの一元管理を進めるにあたってはユーザー（Turtle 利用者）へのアンケートを行い、よく参照している Turtle 関連文書は何か、Storybook は普段参照しているか、といった情報を収集しました。ユーザーにとって Storybook が馴染みのあるリソースであることを確認できたので、Storybook に情報を集約することがユーザーにとってもベストであるという判断をしています。
Storybook の CSS, JS カスタマイズ
Storybook は、サイドバーとメインエリアを伴う「マネージャーエリア」と、ストーリーやドキュメントを表示する「プレビューエリア」で構成されています。プレビューエリアは iframe 要素で表示されています。
このそれぞれのウィンドウに対して、任意の head 要素内容を設定できます。つまり、任意の CSS や JavaScript を挿入できるというわけです。その方法は次の通りです。
- マネージャーエリアに対しては
.storybook/manager-head.htmlファイルを記述する - プレビューエリアに対しては
.storybook/preview-head.htmlファイルを記述する
Storybook のアクセス解析による統計情報の取得
我々のチームでは Turtle の Storybook に Google Analytics を設定してアクセス解析を行っています。Turtle の利用者がどのコンポーネントを特に参照するのかを調査することで、優先的に改善すべきコンポーネントが何であるかの参考にしています。
なお Turtle 開発メンバーのアクセスを解析対象から除外するために、特定のフラグを localStorage にセットしています。フラグがあれば Google Analytics のコードを出力しないようなスクリプトを manager-head.html を介して設定しています。
サイドバーのメニュー項目の構造見直しと mdx 記述
Storybook のサイドバーの構造を見直し、より適切な構造でデザイントークンおよびコンポーネントライブラリを展開できるようにするという作業を2024年11月に行いました。
mdx は「JSX が含められる Markdown」を書くことができる仕組みで、Storybook では mdx が使えるようになっています。特に Storybook v8.x では mdx のバージョン v3 に対応し、その機能が強化されました。これらを活用し、Turtle に関する情報を Storybook に集約することで、Storybook 本来のストーリー（ショーケース）と密に相互参照しながら、コンポーネントのプロパティや使い方について説明を参照できるようにしました。
mdx 上で各コンポーネントの Props 情報を出力するにあたっては、Storybook で提供されている ArgTypes という API を用いています。これを用いると表形式でコンポーネント実装のコードに JSDoc として記述しているコメントの説明文を自動的に取得して表示できます。しかし、その Props の型が Union や Intersection になっていると Props 情報がうまく取得できないという問題がありました。この問題を解決するため、Storybook v8.x から使われるようになった react-docgen というパーサーの代わりに従来使われていた react-docgen-typescript というパーサーを使うように設定を変更して対応しました。
以上で Turtle 開発に関する2024年中の取り組みの紹介は終わります。
その他の活動
私は、フロントエンドチームで Turtle デザインシステムの開発に携わる傍ら、私の得意分野である HTML や URL の扱い方、Web アクセシビリティ、セキュアコーディング（セキュリティ）、DNS に関しても社内で発信したり啓発したりしています。
いくつかの事柄については関連する記事を書いているので、ここで紹介させてください。
- HTML について：(PDF) Web の誕生とブラウザの歴史
- 私の HTML に対する思いと Web ブラウザの歴史について解説しています
- URL について：クールな URL の心得 - Knowledge of Cool URLs
- URL の設計やドメイン名の登録に関する箴言を書いています
- サーバー構築について：Ubuntu サーバー構築手順書
- VPS サーバーに LAMP (Linux / Apache / MySQL / PHP) 環境を構築する手順書です
- DNS について：DNS浸透いうな - それは言葉狩りじゃなくて
- DNS の誤解を解くためのキーワード「浸透いうな」について啓発しています
おわりに
2024年現在、社内向けに開発されたデザインシステムを一般公開している企業がいくつか存在しています。DMM.com でもその流れに乗れるよう Turtle デザインシステムの開発に勤しんでいます。今後の展望ではありますが、2025年中に Turtle を一般公開できればいいなと思いつつ、一方でコンポーネントライブラリの充実にも力を入れていきたいと考えています。
我々のチームでは Figma を使って Code Connect などの機能を活用しながらデザインシステムの開発、改善に取り組んでいます。同じように Code Connect や関連技術を使いこなしたいと思われているチームの方にとってこの記事が少しでも参考になれば幸いです。
Figma プラグインや Code Connect については私自身もかなり詳しくなったので、もし質問などがあればお答えできるかもしれません。X (Twitter) 経由でよければ、本記事に関する内容は @debiru_R までお気軽にお問い合わせください。
最後に、求人情報のご紹介です。DMM.com ではフロントエンド職種として一緒に働いてくれる仲間を募集しています！ご興味のある方は、ぜひ下記の募集ページをご確認ください！
https://dmm-corp.com/recruit/search/?keyword=フロントエンドエンジニアdmm-corp.com
