【開発生産性カンファレンス 2025】高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ

事業・プロダクト紹介

河村：多くの企業が事業やプロダクトの理想を定義している一方で、「アーキテクチャの理想」を言語化・可視化している企業は少ないのが現状です。理想を明確にすることで目指す方向が見え、現状とのギャップが明確になります。

本日お伝えしたいのは、理想が見えることで足し算ではなく引き算で物事を思考できるということです。

Dress Codeは2024年9月設立、2025年4月正式創業の企業です。現在メンバー数は約20名、シードラウンドで14億円の資金調達を実施し、導入企業は150社以上となっています。事業展開は日本、インドネシア、ベトナム、タイの4か国で行っています。

私たちはグローバル市場、特にアジア領域でワークフォースマネジメント領域に挑戦しています。この領域は、従業員や業務委託者の入社から退職まで、採用・労務・育成・プロジェクト管理など、すべての業務プロセスを包括します。

現在多くの企業で発生している課題が「摩擦問題」です。SaaS/ツールの乱立により、部門間のシステム分断・業務サイロ化が進行しています。採用、契約、労務、勤怠、SaaS、デバイス関連データがそれぞれ分断され、ツール間のアナログ連携による非効率、部門間摩擦の増大、最適なSaaS選定の困難、データ散在による活用阻害といった問題が発生しています。



この課題解決のため、私たちは包括的なアプローチを採用しています。IT Force、HR Force、RCT Forceなどの複数シリーズで約50個のプロダクトを展開。この大規模な開発を可能にするのが「Platform Capability」と呼ぶ共通基盤です。

2025年4月の正式創業時点で導入企業130社超、3シリーズ8プロダクトの同時リリースを約7か月の開発期間で達成しました。開発体制は2024年9月の4名から始まり、2025年1月に7名、正式創業時には9名（PdM2名、デザイナー2名、エンジニア5名）という少数精鋭の体制でした。

この少数精鋭の体制で高速開発を実現した背景には、戦略的なアーキテクチャ設計があります。これらを支える基盤アーキテクチャの構築が、今日の本題となります。

高速なプロダクト開発の実現

この速度でプロダクト開発が可能になっている要因は5つあります。



ドメイン知識の経験、永続的PMFサイクルの構築、柔軟で強力なプロダクトチームの構築、Platform Capabilityの投資と構築、AIエージェントの活用です。今回はPlatform Capabilityについて詳しく説明します。

Platform Capabilityでは、プロダクトにおけるデータベース、ミドルウェア、デザインシステム、国際化（ローカライゼーション）における共通基盤を構築しています。これをコンパウンドプロダクトにおける価値を提供するエンジンと位置付けています。

私たちのアプローチは一般的な常識とは異なります。通常であれば個別プロダクトを順次開発しますが、私たちは先に共通基盤を構築します。例えば、Aプロダクト、Bプロダクト、Cプロダクトがある場合、各プロダクトを順番に作るのではなく、共通基盤を作って、その上に各プロダクトを展開する方式を採用しています。

この戦略を採用する理由は、私たちが後発のBtoB SaaSだからです。既存のBtoB SaaSや業務システムの課題が明確に見えている状況で戦うため、共通基盤への先行投資が有効と判断しています。経験上、後から共通部分を抽出する作業は時間とコストがかかるため、最初から共通基盤を構築する方が効率的です。

この共通基盤により実現したいことは2つあります。1つ目は部門間の摩擦解消です。ワークフォースマネジメント領域における業務の抽象化を行い、個別の業務やシステム、データを統合して、共通のデータ基盤やプロセスで管理します。

2つ目は、採用から退職までの従業員ライフサイクルの構造的管理です。HR ForceやIT Forceなどのプロダクト群を、Platform Capabilityという共通基盤上で動作させることで実現できると考えています。

具体的な構造を説明すると、各部門で発生している部門の摩擦問題に対して、部門ごとの個別業務を抽象化・統合し、個別の業務システムを統合して一元管理するPlatform Capabilityを構築しています。

この共通基盤の上にHR Force、IT Force、RCT Forceといったプロダクトを展開することで、統合的なソリューションを実現しています。なお、これは技術的なアーキテクチャとは異なる概念です。



ここからが本題で、これらを支えるアーキテクチャが必要という話になります。

アーキテクチャは高速な開発を可能にする土台だと考えています。柔軟性、拡張性、効率性を備えたアーキテクチャが必要で、ドメイン知識やAI活用を最大限に引き出すためにもアーキテクチャが重要です。開発速度やプロダクトの持続可能性につながるものだと思っています。

アーキテクチャは地図の役割を果たすものだとも考えています。地図の役割とは、全体の方向性や目的を示し、複雑な地形をナビゲートし、共同作業を調整する共通の地図になることです。これはまさに、プロダクト開発のゴールとそこへ向けた道筋を示し、システムの構造や制約を整理して、効率的に作業できる環境を提供するものです。

さらにAIエージェントの活用においては、プロジェクト全体の目的と構造が不明確だと、生成されるものが不安定になります。だからこそ、アーキテクチャはAIの力を最大限に引き出し、プロダクト開発を成功に導く羅針盤だと考えています。

エンタープライズアーキテクチャの推進

エンタープライズアーキテクチャは、組織のビジネスプロセス、情報技術、データ、アプリケーションを体系的に整理・設計する枠組みです。

私たちが重要だと考えているのは、「現状（As-Is）と目標（To-Be）の視点で整理」という部分です。ここで冒頭の話に戻りますが、足し算ではなく引き算で考えることが重要です。



従来のアプローチでは、その場で必要なアーキテクチャを継ぎ足しで増やしていくことで、システムがより複雑になり、本質が見えにくくなるという問題がありました。そうではなく、理想形や目標を定めて本当に必要なものだけを見極め、不要なものは削除してシンプルな状態を目指すべきです。つまり理想のゴールを見据えて、必要なものだけを選び抜く。そうしなければ目指す方向がぶれて、複雑さが増すだけになってしまいます。

この考え方は、ドメイン駆動設計（DDD）と親和性が高いと考えています。システムのコアとなるドメインを中心に設計を進め、不要な複雑さを排除するアプローチは、まさにどこを目指すかを見極めることに他なりません。結果的にDDDを実践する必要があると考えています。

戦略的DDDは、プロダクトの目的を明確にして、その構造を整理するプロセスです。その中でもプロダクト特性から、プロダクトにとって最も重要な差別化ポイントとなる部分を見極めることを重視しています。

Dress Codeのプロダクト特性を整理すると、2つの重要な要素があります。



1つ目はドメインの広さと深さです。ワークフォースマネジメントという領域は非常に幅広く、採用、人事、労務、総務など、あらゆる業務を網羅するコンパウンドプロダクトを構築する必要があります。必要なドメイン知識の広さと深さは相当なものです。

さらにグローバル展開の複雑性も関わってきます。グローバル展開では多言語対応だけでなく、タイムゾーン、通貨、日付や数値フォーマット、そして各国の法的要件への対応が必要です。例えば、インドネシアの入社手続きでは宗教情報の収集が法的に義務付けられています。このような国固有の要件に対応する必要があります。

2つ目はコンパウンドプロダクトによる価値提供です。部門間の摩擦問題の解決が私たちの最重要課題です。これをコンパウンドプロダクトならではの統合的アプローチで解決し、そのためのPlatform Capabilityという共通基盤を構築しています。

これらをまとめると、統合性、グローバル対応・スケーラビリティ、業務のシームレスな連携、プラットフォームの拡張性とエコシステム化といった特性が重要になります。

Dress Codeでは50個以上のプロダクト開発を予定しており、最速でPMFを達成するため、年間10個以上のプロダクトを継続的に開発することを目標としています。

プロダクト特性を踏まえ、次にアーキテクチャ特性を検討します。

アーキテクチャ特性とは、『ソフトウェアアーキテクチャの基礎』で紹介されているもので、運用特性、構造特性、横断的特性に分類し、品質や成功を決定する機能要件を検討するためのものです。重要なのは、ビジネス目標に適合したアーキテクチャを設計することです。

特性を明確に定義し、トレードオフを考慮してシステム設計を行う必要があります。

Dress Codeでは、プロダクト特性から導出したアーキテクチャ特性が約15個ありますが、これらすべてに対応することは不可能です。アーキテクチャ特性は基本的に全部入りできません。設計や構造が複雑になりすぎるため、基本的には実現困難です。また、特性同士が互いに干渉し合うトレードオフの関係にあります。

セキュリティ向上の取り組みは、基本的にパフォーマンスに影響を与えるといった例があります。したがって、優先すべきアーキテクチャ特性とその程度を決定する必要があります。私たちは、その中でも特に重要な特性を選択して優先順位を決めています。



優先度の高いアーキテクチャ特性が決まれば、領域ごとのアーキテクチャを定義できます。技術スタックも含めて、フロントエンド、バックエンドのアーキテクチャを、アーキテクチャ特性を軸に定義していきます。

重要なポイントとして、開発プロセスとプロダクト組織も、1つのアーキテクチャとして考えています。

例えば、アーキテクチャ特性でセキュリティを重要視すると決めても、プロダクト組織に対して単純に「セキュリティを頑張って」と指示するだけでは実現できません。基本的には、専門的なスペシャリストをイネーブリングチームとして配置する必要があります。そうなると組織構成を見直し、採用も強化する必要が出てきます。アーキテクチャ特性の優先度は、様々な領域に影響を与えます。

私たちは設計判断をすべてADRに記録しています。AI時代においてドキュメントを残す文化は極めて重要です。私たちはあえてArchitecture Decision Recordではなく、Any Decision Recordと呼んでいます。アーキテクチャに関するすべての意思決定を記録する取り組みを実践しています。



この取り組みにより、その時点における理想のアーキテクチャを定義できました。

この定義により得られる効果は複数あります。まず意思決定がスムーズになります。明確なガイドラインを提供し、技術選定や設計の選択肢を評価する際の基準となります。トレードオフの可視化とステークホルダー間の合意形成にも活用できます。私たちが統合性を優先しているということを、ステークホルダーに説明しやすくなります。

さらに中長期的に取り組むべき課題も明確になります。創業期では短期的な課題が多くなりがちですが、アーキテクチャ特性で妥協している部分は技術的負債につながる可能性があります。そうした課題を管理しやすくなり、プロダクト成長に対する柔軟性の向上にもつながります。

エンタープライズアーキテクチャの一例

ここからは、具体的なエンタープライズアーキテクチャの実装例について説明します。

前述したDress Codeで必要なアーキテクチャ特性のうち、7つを重要度の高い特性として選定しました。さらに設計を進めるため、これらの優先順位を明確化しました。

最優先はアジリティです。最速でのPMF達成と、年間10個以上のプロダクト開発という目標において、アジリティは何よりも重要です。

その次に重要なのが、モジュール性、統合性、国際化、セキュリティです。これらを軸として、バックエンドアーキテクチャの設計を進めています。

アジリティを優先するため、特定のトレードオフを受け入れています。



現在はモノリスアーキテクチャを採用しています。単一コードベース、単一デプロイにより、初期開発速度の向上と開発の認知負荷軽減を実現しています。トランザクション管理が簡素化され、AIにコンテキストを提供する際も分散アーキテクチャより効率的です。現在12個程度のプロダクトを運用していますが、継続してモノリス構造を採用しています。

DBもシングル構成を採用しています。当初は分散データベースも検討しましたが、開発速度を重視してシングルDBを選択しました。分散トランザクションが不要となり、統合テストも容易になるため、開発の高速化に大きく寄与しています。

イベントソーシングも導入していますが、CQRSのライト・リード分離は行わず、単一データベースで実装しています。これもシングルDB戦略の一環として、開発しやすい方式を選択した結果です。

個人的な見解として、シングルDBで開発を進め、適切なタイミングでNewSQLに移行する戦略が有効だと考えています。

しかし、これらの選択にはトレードオフが存在します。モノリスは大規模化に伴いボトルネックとなり、単一デプロイによる遅延や障害の影響が拡大します。シングルDBも高負荷時の拡張性に限界があり、シャーディングやレプリケーションが必要になります。

結果として、アジリティを向上させている一方で、中長期のスケーラビリティを犠牲にしているという課題があります。

アジリティを維持しながらモジュール性を実現するため、モジュラーモノリスを採用しています。



マイクロサービスのような独立性を部分的に実現しつつ、単一デプロイのシンプルさを維持しています。各モジュールは特定のドメインの責任を持ち、内部実装をカプセル化しています。

モジュール間連携では、DBからの直接アクセスを禁止し、アダプターを経由する仕組みを構築しています。プロダクト間やモジュール間の連携を抽象化することで、内部実装の変更による影響を最小限に抑えています。

ただし、この実装にもトレードオフがあります。依然として中央集権的なモノリス構造であり、単一デプロイによる制約は残ります。プロダクト数の増加に伴い、デプロイ時間や障害の影響範囲が拡大します。

また、アダプターの実装とメンテナンスにはコストがかかります。中長期のスケーラビリティ課題を残しつつ、プロダクト間のアダプター実装によってアジリティが低下する可能性もあります。

アジリティを維持するため、補償トランザクションのような複雑な仕組みは採用せず、トランザクション共有という妥協点を設けています。

最後に、国際化・セキュリティ・統合性について説明します。



国際化対応では、グローバル展開を優先してローカライゼーション基盤を構築しています。UIテキストとエラーメッセージの一元管理により、対応言語の追加への迅速な対応とAIの効果的活用を実現しています。

日付・時刻や通貨・数値のフォーマットも一元管理し、インドネシアの法的要件のような国固有の要求に対応できるよう、特定国に依存しない設計を採用しています。

セキュリティ面では、創業から1か月後にSOC2とISMS認証を取得し、これらを最低ラインとしてセキュリティ強化を進めています。業務において重要な監査ログのため、テンポラルデータモデルを採用し、クリティカルな変更にはイベントソーシングによる記録を実装しています。

統合性を実現するため、Platform Capabilityの構築が不可欠です。データベースや共通基盤の整備に加え、データガバナンスによるアクセス制御の統合的管理を進めています。

これらの取り組みには、それぞれトレードオフが存在します。基盤構築により実装速度は低下し、セキュリティ強化には制約と限界があります。テンポラルデータモデルは大規模化に伴いストレージコストとパフォーマンスの課題を生みます。

しかし、セキュリティについては一定レベル以下に下げることはできないため、適切なコストをかけてツールを導入し対応しています。

統合性においては、ドメイン知識の獲得と設計難易度が大幅に向上します。複数の業務プロセスの統合により、広範なドメイン知識が必要となります。個別業務では利用できない設計は基本的に採用せず、これはDress Codeの最重要価値であるため優先度を下げることはできません。

この制約の中で、知識習得と設計速度向上のための施策を最優先で実施し、トレードオフに対処しています。

基本的に、すべてを実現することは不可能です。現在最も必要なアーキテクチャ特性を選択し、理想形を見据えて必要なものだけを選び抜くことが重要です。これがDress Codeで実践している引き算思考です。

これらの詳細については、テックブログで継続的に発信しています。創業月にアドベントカレンダーを実施し、多数の技術記事を公開していますので、ご興味があればご覧ください。

まとめ

Dress Codeは約7か月の開発期間で、3シリーズ8プロダクトの同時リリースを達成しました。この成果を支えた要因は5つあります。圧倒的なドメイン知識と経験、永続的PMFサイクルの構築、強力なプロダクトチームの構築、Platform Capabilityへの投資と構築、そしてAIエージェントの活用です。

この高速開発を実現するために、エンタープライズアーキテクチャの定義が重要な役割を果たしました。現状と目標の視点で整理し、プロダクト特性からアーキテクチャ特性を特定し、トレードオフが生じる部分については重要度を決めて対応しています。

最も重要な教訓は、理想形を見据えて必要なものだけを選び抜くことです。現在最も必要なアーキテクチャ特性を選択し、プロダクトもアーキテクチャも足し算ではなく引き算で考えることが成功の鍵となります。

私たちは現在、グローバル市場で共に戦う仲間を積極的に募集しています。新オフィスへの移転など、創業期ならではの変化を経験しながら一緒に成長してみませんか？

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です