グローバルなコンパウンド戦略を支えるモジュラーモノリスとドメイン駆動設計

# 概要
DRESS CODEは、情シス・人事労務・採用・総務の課題を解決するコンパウンドプロダクトです。2025年4月の創業から3シリーズ12プロダクトをリリースし、アジアを中心にグローバル展開を実現。モジュラーモノリスとドメイン駆動設計を採用したアーキテクチャで、柔軟なプロダクト開発を実現しています。AI Agentによる自動化で開発速度を加速し、複雑な業務要件に応えるプロダクト群を開発しています。このセッションでは、DRESS CODEを支えるアーキテクチャの工夫を事例と共に紹介します。

#DDD #AIとアーキテクチャ

# プロフィール
Dress Code株式会社 Product & Technology テックリード 河村 勇樹(https://x.com/_syoryu89)

2019年に新卒で大手事業会社に入社し、航空気象サービスの開発に携わる。2021年にレバレジーズ株式会社に中途入社。レバテックCTO室のテックリードとして「レバテック」の開発・組織を牽引。レバテックのリアーキテクトやTiDBの導入を推進。2024年11月にDress Code株式会社に中途入社。アーキテクチャを中心にフルスタックに開発。ドメイン駆動設計やCQRS、Event Sourcingに挑戦中。採用や技術広報・組織設計にも携わる。趣味はお酒とゴルフとカワウソ鑑賞。

Transcript

1. グローバルなコンパウンド戦略を 支えるモジュラーモノリスと ドメイン駆動設計 Dress Code 株式会社 / Product & Technology かわうそ（河村　勇樹） 1
2. © Dress Code Inc . • 業務 ◦ プロダクト開発 ◦ アーキテクト ◦ 組織設計 ◦ 採用・技術広報 • 開発 ◦ アーキテクチャ全般が好き ▪ 最近は「集約」と「Event Sourcing」 • 趣味 ◦ お酒 / ゴルフ / 競馬 / カワウソ鑑賞 自己紹介 かわうそ(@_syoryu89) 2
3. © Dress Code Inc . 3 アジェンダ 1. 事業・プロダクト紹介 2. 今日、お話しすること 3. モジュラーモノリスの活用と工夫 4. DDD（ドメイン駆動設計）における集約の活用 5. まとめ
4. © Dress Code Inc . 1. 事業・プロダクト紹介 4
5. © Dress Code Inc . 14.1億円　 資金調達を実施 Pre Seed&Seed Round 180+社 が利用中　 Number of companies Number of countries 5カ国 で事業を展開　 Dress Code　会社概要 Company Name / 会社名 Dress Code 株式会社 2024年9月（正式創業：2025年4月） 23名 東京都中央区築地2-1-4 銀座PREX East 8F CEO / 代表取締役 Date of establishment / 設立年月 Location / 所在地 江尻 祐樹 Member / メンバー数 5
6. © Dress Code Inc . 挑戦する事業ドメイン/マーケット Dress Code が初めに挑戦するのは、グローバル（まずアジア）のWorkforce Management 領域全体 Asia to Global Workforce Management領域 労務 管理 育成/ 定着 人事/ 配置 採用 管理 拠点/ 環境 プロ ジェ クト 福利 厚生 ITツール /備品 外部 人材 活用 セキュ リティ /ガバナ ンス 【Entry】 入社/入場 【Retire】 退職/退場 ライフサイクル × 6
7. © Dress Code Inc . デジタル化に伴う社会課題 -「摩擦問題」 - SaaS/ツール乱立に伴い、システムの分断・業務のサイロ化が進む 採用 部門 法務 部門 労務 部門 人事 部門 情報 システム 部門 総務 部門 採用管理 システム 契約管理 システム 労務管理 システム 勤怠管理 システム SaaS管理 システム デバイス 管理台帳 採用関連データ 契約関連データ 労務関連データ 勤怠関連データ SaaS関連データ デバイス関連データ ツールの乱立で、使いこなせない/慣れるのまでに時間がかかる ツール/部門間のアナログ連携が大変 担当間/部門間の摩擦が増大している 各業務担当者 経営/管理部全体 最適なSaaSを選定することが困難 データが散在していて利用/活用できない 連携/メンテのためのコスト(時間・お金)が膨大 ❌
 分断
 ❌
 分断
 ❌
 分断
 ❌
 分断
 ❌
 分断
 7
8. © Dress Code Inc . 8
9. © Dress Code Inc . 9
10. © Dress Code Inc . 10 プロダクトにおけるデータベース・ミドルウェア含めた”共通基盤” コンパウンドプロダクトにおける価値を提供するための”エンジン” 初期段階から共通基盤に投資をしてプロダクトの横展開を実現
11. © Dress Code Inc . 11 ”約1年”の開発期間で ”15個以上”のプロダクトをリリース
12. © Dress Code Inc . 12 2. 今日、お話しすること
13. © Dress Code Inc . 13 高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
14. © Dress Code Inc . 14 高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
15. © Dress Code Inc . 15 高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
16. © Dress Code Inc . 16 DRESS CODE のアーキテクチャ • モジュラーモノリス ◦ 現在はモノリスでコンパウンドプロダクトに挑戦 ◦ UI（BFF）的な設計思想とドメイン的な設計思想の分離 • DDD（ドメイン駆動設計） ◦ 戦略・戦術ともに活用 ◦ ドメインの整合性を守るために”集約”を活用
17. © Dress Code Inc . 17 3. モジュラーモノリスの活用と工夫
18. © Dress Code Inc . 18 DRESS CODEにおける モジュラーモノリスの概要
19. © Dress Code Inc . 19 なぜ、モジュラーモノリスなのか？ • モノリスとしてのシンプルさを維持 ◦ 単一のコードとデプロイ単位を持つため、初期開発が高速 ◦ データスキーマやトランザクションの一貫性の管理コストも低い • 各プロダクト（ドメイン）の独立性を担保 ◦ ドメイン（データ）の責任範囲を明確化 ◦ 各モジュールが特定のドメインに責任を持ち、内部実装をカプセル化 • 組織としてのスケーラビリティも獲得 ◦ モジュールを分割して認知負荷を分散 ◦ それぞれの各プロダクト（ドメイン）ごとに組織をスケール
20. © Dress Code Inc . 20
21. © Dress Code Inc . 21 モジュラーモノリスの実現 • シリーズごとにモジュールを分割 • モジュールごとにチームを構成 • 共通部分は”全員”で管理 • （それぞれの領域に担当者を設ける）
22. © Dress Code Inc . 22 モジュールの中身 • レイヤードアーキテクチャ • 戦術的DDD
23. © Dress Code Inc . 23 モジュラーモノリスで困ったこと 1) モノリスにおけるUI設計とドメイン設計をどうやって分けるべきか 2) DB（スキーマ）をモジュールごとに分けるべきか 3) モジュールを跨いだ連携をどのように実現すべきか
24. © Dress Code Inc . 24 モノリスにおけるUI設計と ドメイン設計の切り分け
25. © Dress Code Inc . 25 BFF的な設計思想とドメイン的な設計思想の分離にモノリスなアーキテクチャで挑む
26. © Dress Code Inc . 26 API設計をUIに寄せるか、ドメインに寄せるか どっちに寄せるべきなのか？
27. © Dress Code Inc . 27 API設計をUIに寄せるか、ドメインに寄せるか UIに寄せると Application層が DBへのCRUDを行うだけの層になりやすい
28. © Dress Code Inc . 28 API設計をUIに寄せるか、ドメインに寄せるか ドメインに寄せると 「欲しいデータが一度に揃わない」 「呼び出し回数が増える」
29. © Dress Code Inc . 29 UIに寄せたAPI設計 UIに寄せた（BFF的な）設計 ↓ Application層がDBへのCRUDを行うだけ の層になりやすい ↓ ドメインを表現する層や ビジネスロジックを表現する層を 見失いがち ↓ UI（BFF的な）設計思想と ドメインの設計思想を分離 ↓ ReadとWriteを分離
30. © Dress Code Inc . 30 ReadはQuery Service経由、WriteはDomain経由
31. © Dress Code Inc . 31 ReadはQuery Service経由、WriteはDomain経由 Read（Query） Write（Command） 厳密なCQRSではない 👉 軽量CQRSを想定
32. © Dress Code Inc . 32 WriteはCommandを経由（ESパターンを考慮）
33. © Dress Code Inc . 33 WriteはCommandを経由（ESパターンを考慮） 副作用のある処理は ドメイン（Command）側へ 通常 / ESのパターンでも Commad を経由
34. © Dress Code Inc . 34 DB（スキーマ）を モジュールごとに分けるべきか
35. © Dress Code Inc . 35 モジュラーモノリスの特徴 • マイクロサービスのようなモジュール性 • モノリスのシンプルさを両立
36. © Dress Code Inc . 36 モジュラーモノリスの特徴 • マイクロサービスのようなモジュール性 • モノリスのシンプルさを両立 分けるべきなのか？
37. © Dress Code Inc . すべてのモジュールが1つのデータベースを共有して 各モジュールに専用のスキーマ（論理的な名前空間）を割り当てる 推奨理由 • 分離のバランス ◦ 名前空間を分けることで、モジュール間のデータアクセスを制限しやすい • 運用効率 ◦ 1つのDBで済むため、バックアップ、監視、スケーリングが容易 • 柔軟性 ◦ 将来的にマイクロサービス化する際、スキーマをDBに切り出すのが比較的スムーズ 37 同じDB内でスキーマを分離するのが推奨（のはず）
38. © Dress Code Inc . 38 モジュラーモノリスだけどDBは分割していない DRESS CODEはDBもスキーマも分割していない なぜ分割しないのか？（スキーマも含めて） • 現段階におけるモジュール分割が適切である自信がない... ◦ モジュールの構成を変えたいときに分割されていると変更のコストが高くなる • 分けない方が管理コストが低い ◦ マスタデータのような共通データの管理や共有などの管理コスト • 不整合なデータを作らないため ◦ 外部キー制約を利用して、不正な書き込みによる想定外のデータを作成させない ◦ （異なるスキーマ間でも外部キー制約を貼ることはできるが、分離性が低下してしまう）
39. © Dress Code Inc . 39 モジュラーモノリスだけどDBは分割していない DRESS CODEはDBもスキーマも分割していない なぜ分割しないのか？（スキーマも含めて） • 現段階におけるモジュール分割が適切である自信がない ◦ モジュールの構成を変えたいときに分割されていると変更のコストが高くなる • 分けない方が管理コストが低い ◦ マスタデータのような共有データをどのように管理・共有すべきかなど • 不整合なデータを作らないため ◦ 外部キー制約を利用して不正な書き込みによって想定外のデータが作成させないため ◦ （異なるスキーマ間の外部キー制約を貼ることはできるが、分離性が低下してしまう） 全てのデータに 自由にRead/Writeされてしまう可能性がある🤔
40. © Dress Code Inc . 40 分割しない代わりにデータのオーナーは定義 オーナーであるモジュールからのRead・Writeを基本とする 👉 すべてのデータを自由に直接Read/Writeをさせない仕組み • 不整合なデータを作らないことを優先 ◦ 他モジュールが抱えているデータに直接 Write をした場合に、必要なビジネスロジック を通過せずにデータが生成されるのを防ぐ • 分離性を落とさないことも考慮 ◦ 複数モジュールからRead/Writeしてしまうと、コード自体も分散
41. © Dress Code Inc . 41 モジュールを跨いだ連携を どのように実現すべきか
42. © Dress Code Inc . 42 全てのデータに自由にRead/Writeされる可能性
43. © Dress Code Inc . 43 ReadはAdapterを経由させる
44. © Dress Code Inc . 44 WriteはCommandを経由
45. © Dress Code Inc . 45 自由にデータをRead/Writeさせない • 良いこと ◦ コードレベルでデータ（ドメイン）を守ることができる ◦ モジュール間のインピーダンスミスマッチと向き合いやすくなる • 悩ましいこと ◦ Adapter経由でデータを取得すると非効率なデータ取得になる ▪ ページネーションなどを考慮すると複雑になりやすい ▪ どうしても複雑度・効率（パフォーマンス）的にも直接取得したくなるケースもある
46. © Dress Code Inc . 46 ReadにおいてQuery Service経由なら参照を許可
47. © Dress Code Inc . 47 ReadにおいてQuery Service経由なら参照を許可 オーナー外の参照がある状態にはなってしまう...
48. © Dress Code Inc . 48 Read Modelを構築して分離するパターンも検討 他モジュールに 必要なデータがある場合 👇 自モジュールにそのデータを Read Modelとして定義 👇 変更イベントを受け取り データを更新 Read Model 変更のEvent
49. © Dress Code Inc . 49 モジュラーモノリスで困ったこと - まとめ - • モノリスにおけるUI設計とドメイン設計の切り分け ◦ UIに寄せたAPI設計を実現した上で、Read / Write 自体を分離 • DB（スキーマ）をモジュールごとに分けるべきか ◦ 同じDB内でスキーマを分離するのが推奨ではあるが... ◦ DRESS CODEはDBもスキーマも分割していない • モジュールを跨いだ連携をどのように実現すべきか ◦ Adapter / Command を経由して自由にRead/Writeさせない仕組み ◦ 複雑性・パフォーマンスに応じて Read Model を構築を検討中
50. © Dress Code Inc . 50 4. DDD（ドメイン駆動設計）における ”集約”の活用
51. © Dress Code Inc . 51 今さら聞けないDDDとEvent Sourcingにおける集約
52. © Dress Code Inc . 52 WriteはCommandを経由（ESパターンを考慮）※ 再掲 集約を利用
53. © Dress Code Inc . 53 集約とはなにか
54. © Dress Code Inc . 54 集約とはなにか ”集約とは、データ変更の目的において単一のユニットとして扱われる、関連する ドメインオブジェクト（エンティティと値オブジェクト）の集合体です 。トランザ クションの一貫性を定義し、強制するための基本単位となります 。” ”集約の主要な目的は、その境界内に存在するオブジェクト群に対して常に真でな ければならない一連のビジネスルール、すなわち「不変条件」を保護することにあ ります 。例えば、「注文（Order）」集約においては、「注文合計金額は、常に 個々の注文品目（OrderItem）の金額の合計と等しい」というルールが不変条件に 該当します。” ”ここで重要なのは、集約が単なる関連オブジェクトのグラフではないという点で す。集約の境界は、データベースのリレーションシップによってではなく、ビジネ スルールに基づいて慎重にモデリングされます 。それは、ドメインの観点から見 て、概念的な「全体」を表現するものなのです。”
55. © Dress Code Inc . 55 集約とはなにか ”集約とは、データ変更の目的において単一のユニットとして扱われる、関連する ドメインオブジェクト（エンティティと値オブジェクト）の集合体です 。トランザ クションの一貫性を定義し、強制するための基本単位となります 。” ”集約の主要な目的は、その境界内に存在するオブジェクト群に対して常に真でな ければならない一連のビジネスルール、すなわち「不変条件」を保護することにあ ります 。例えば、「注文（Order）」集約においては、「注文合計金額は、常に 個々の注文品目（OrderItem）の金額の合計と等しい」というルールが不変条件に 該当します。” ”ここで重要なのは、集約が単なる関連オブジェクトのグラフではないという点で す。集約の境界は、データベースのリレーションシップによってではなく、ビジネ スルールに基づいて慎重にモデリングされます 。それは、ドメインの観点から見 て、概念的な「全体」を表現するものなのです。” 関連するデータとビジネスルールを ひとまとめにした「単位」のこと この単位の中でデータの整合性が 常に保たれるように設計
56. © Dress Code Inc . 56 集約は「一貫性の境界」
57. © Dress Code Inc . 57 集約を適切に分割するには ”業務理解”が必要
58. © Dress Code Inc . 58 集約を適切に分割するための業務理解の必要性 • 一貫性の境界を正しく定義するため ◦ 業務理解が不足すると、一貫性が失われる分割になり、データ競合や不整合が発生 ◦ 業務の因果関係やルールを知らないと、境界が曖昧になり、システムの信頼性が低下 • 複雑さを最小限に抑えるため ◦ 分割が多すぎるとクエリや更新が煩雑になる ◦ 一方、大きすぎるとパフォーマンスやメンテナンスが悪化 • 変更容易性を高めるため ◦ 理解不足で分割すると、変更が局所的に収まらなくなる ◦ ドメインエキスパートとの対話を通じて、業務の「不変のルール」と「変動する部分」 を区別する必要がある
59. © Dress Code Inc . 59 集約を適切に分割するための業務理解の必要性 • 一貫性の境界を正しく定義するため ◦ 業務理解が不足すると、一貫性が失われる分割になり、データ競合や不整合が発生 ◦ 業務の因果関係やルールを知らないと、境界が曖昧になり、システムの信頼性が低下 • 複雑さを最小限に抑えるため ◦ 分割が多すぎるとクエリや更新が煩雑になる ◦ 一方、大きすぎるとパフォーマンスやメンテナンスが悪化 • 変更容易性を高めるため ◦ 理解不足で分割すると、変更が局所的に収まらなくなる ◦ ドメインエキスパートとの対話を通じて、業務の「不変のルール」と「変動する部分」 を区別する必要がある 集約は「技術的なデータのまとまり」ではなく、 「業務ルール上一貫性を保つべき情報のまとまり」
60. © Dress Code Inc . 60 DRESS CODE ではどうしているか？
61. © Dress Code Inc . 61 DRESS CODE には Graph と呼ぶ概念が存在 全てのビジネスアプリケーションから共通して利用されるデータ。 「信頼できる唯一の情報源」として、組織内のすべてのデータが1つの場 所で管理・更新されるように設計されたシステムの根幹。 Peopleの例
62. © Dress Code Inc . 62 DRESS CODE では Graph が”集約”となる 業務シナリオ、業務プロセスが反映されたオブジェクト＝Graph 例：People、Organization、Device、Contract、etc…
63. © Dress Code Inc . 63 なぜ、集約が必要なのか？
64. © Dress Code Inc . 64 ドメイン（データ）の整合性を守る ために重要
65. © Dress Code Inc . 65 集約を適用することで整合性を守る 🏗 整合性を守る 🏗 • 集約ルートは集約のエントリポイントとなる Entity で、外部からはこ のルート経由でしか内部のオブジェクトにアクセスできないようにする 📍 大事なこと 📍 • 部分的な更新を許容しない ◦ 許容してしまうと集約ルートのビジネスルールを適用せずに内部の Entity を永続化で きてしまうため、容易にデータの不整合を生むことができてしまう
66. © Dress Code Inc . 66 必ず集約ルートを経由させる 集約ルートに定義された制約条件 を通過させる 内部のオブジェクトに 直接アクセスさせない ＝ 公開しない
67. © Dress Code Inc . 67 なぜ、データ不整合を回避できるのか？ 「原子的な変更単位」として扱うことでデータ不整合を回避 • 必ず集約を生成するというプロセスを強制させる（制約） ◦ 集約ルートに適切な Validation（ビジネスロジック）が実装されていれば、不整合のあ る集約が生成されることはなくなるはず • 部分的な更新を許容してしまうと... ◦ 集約を経由せずとも、データの永続化が可能になってしまう ▪ 集約ルートにあるビジネスロジックやルールは通過することができなくなる ▪ 集約ルートと Entity との関係性の間にある制約も守ることが難しくなる
68. © Dress Code Inc . 68 永続化のために Repository を定義 必ず集約ルートから永続化を行う 部分的な更新を許容してしまう 集約ルートのビジネスルールを 適用せずに Entity を 永続化できてしまう 良い例 悪い例
69. © Dress Code Inc . 69 AI時代における”制約を課す”ということの重要性 制約を課すことで”AI”によるコード生成の精度も上げる • DDDにおける集約による”制約を課す”ことの重要性 ◦ 「原子的な変更単位」として扱い、部分的な変更を許容しないという制約 • 制約により”AI”が想定外の実装をしないように防ぐ ◦ 自由な状態で”AI”に実装を指示するよりも、制約を課した状態で指示する ◦ 不整合なデータができる実装や今まで見たことのない実装が発生するのを防ぐ
70. © Dress Code Inc . 70 集約のサイズを 小さく保つことは難しい...
71. © Dress Code Inc . 71 集約は大きすぎても小さすぎても問題になる
72. © Dress Code Inc . 72 集約は大きすぎても小さすぎても問題になる 適切な境界を見つける 👉 DRESS CODE では Graph（集約）の定義から進める 👉 一貫性を保つべき情報のまとまり
73. © Dress Code Inc . 73 集約の大小問題は常に向き合う必要がある • 業務上、どうしても同一集約（トランザクション）で取り扱いたいこと は当たり前のようにある ◦ 業務想定やユースケースを変更して境界を分けることはできるが... • 大きい集約を安易に分割してはならない ◦ 安易に集約を分けてしまうと、思わぬデータ不整合に繋がったり、想定していないとこ ろでプロダクトに影響 ▪ 特に同一集約（トランザクション）であるべきはずだった集約など... ▪ ロールバック的なことを考えると同一集約（トランザクション）にまとめてしまった 方が、断然楽ではある
74. © Dress Code Inc . 74 集約が大きいことをあまりネガティブに考えない • データ（ドメイン）を守ることが最優先 ◦ 小さくしてパフォーマンスが良くなっても不整合なデータができてしまうなら... • ロック競合含めたパフォーマンス課題は技術でなんとかする ◦ DBのWriteがボトルネックになるなら... ◦ Read/WriteをDB含めて完全に分離してしまう（CQRS） ◦ （業務系アプリで同期的にデータを保証する必要性はほぼない）
75. © Dress Code Inc . 75 （人間含め）AIにとっても大きい集約は悪ではない • 集約が大きいということは... ◦ 必要なビジネスロジックが1つの実装（ソースコード）に集約されているということ • 人間や”AI”が読むコンテキストを分散させずに済む ◦ むしろ”AI”に実装してもらうときは効率よく開発できる（のではないかと考えている）
76. © Dress Code Inc . 76 （人間含め）AIにとっても大きい集約は悪ではない • 集約が大きいということ ◦ 必要なビジネスロジックが1つの実装（ソースコード）に集約されているということ • 人間や”AI”が読むコンテキストを分散させずに済む ◦ むしろ”AI”に実装してもらうときは効率よく開発できる（のではないかと考えている） 無理して集約を小さく保つよりは、 ”集約を適切に実装することを優先”して、 集約の大きさ・スケーラビリティ・AIの実装具合を 見ながら集約の境界を定義
77. © Dress Code Inc . 77 （人間含め）AIにとっても大きい集約は悪ではない • 集約が大きいということ ◦ 必要なビジネスロジックが1つの実装（ソースコード）に集約されているということ • 人間や”AI”が読むコンテキストを分散させずに済む ◦ むしろ”AI”に実装してもらうときは効率よく開発できる（のではないかと考えている） 集約も”要はバランス”
78. © Dress Code Inc . 78 5. まとめ
79. © Dress Code Inc . 79 まとめ • アーキテクチャは地図の役割である ◦ 理想系を定義しながら、今必要なアーキテクチャを定義 ◦ その結果として、「モジュラーモノリス」と「DDD」を活用 • モジュラーモノリスを活用、モジュール内部はRead/Writeを分離 ◦ モノリスとしてのシンプルさを維持しつつ各プロダクト（ドメイン）の独立性を担保 ◦ UI（BFF）的な設計思想とドメイン的な設計思想の分離 ◦ DB分割とモジュール間の連携は最適解を探索中
80. © Dress Code Inc . 80 まとめ • DDD（ドメイン駆動設計）における集約という”制約”で整合性を守る ◦ 集約は「業務ルール上一貫性を保つべき情報のまとまり」 ◦ DRESS CODE では Graph という概念が存在しており、集約として扱う • 集約が大きいことをネガティブに考えない ◦ データ（ドメイン）を守ることが最優先 ◦ （人間含め）AIにとっても大きい集約は悪ではない ◦ 集約の大きさ・スケーラビリティ・AIの実装具合をみながら見定める
81. © Dress Code Inc . 81 さいごに • ドメイン（データ）を守るという文脈でも、アーキテクチャは重要 ◦ 変更容易性ももちろん重要 ◦ データ整合性を維持し、破壊・改ざんのリスクを防ぐ「守りの仕組み」も重要 • 業務プロセスにおいて“履歴”も重要な資産（監査も含め） ◦ ”履歴”も含めて守りたいなら「Event Sourcing」は良い手段 ▪ ドメインの「現在の状態」だけでなく「変化の文脈（履歴）」を不変イベントとして 保護し、再構築可能にする
82. © Dress Code Inc . 82 アーキテクチャは 変更容易性だけでなく データを「守る」目的においても重要
83. © Dress Code Inc . 83 🎉 宣伝 🎉
84. © Dress Code Inc . 技術広報 カンファレンス・コミュニティ・テックブログにも力を入れています！ 84
85. © Dress Code Inc . 85 ”グローバル”に挑戦する仲間を募集しています！ • PdM（プロダクトマネージャー） • コミュニケーションデザイナー • デジタルプロダクトデザイナー • デザインエンジニア • プロダクトエンジニア • SRE・QA • etc… Dress Code イベント登壇情報まとめ
86. © Dress Code Inc . 86 ご清聴ありがとうございました！！！ ブースや懇親会等でもお話ししましょう！