“後から広げる”を、あえて選ばない。Day1からバックオフィス全体を設計したDress Codeの開発思想

人事、情報システム、総務、採用──。バックオフィスでは、一人の従業員にひも付く情報が、いくつものサービスに散らばっていることがあります。Dress Code株式会社は、これを「SaaSのガラパゴス化」と呼び、そこで生まれる業務の摩擦をなくすことを掲げています。

同社が開発する「DRESS CODE」は、人に関わる業務のすべてを一つのデータ基盤の上で扱う、バックオフィス部門横断の業務OSです。2024年設立の後発ながら、すでに5カ国・215社以上が導入し、従業員数万人規模のエンタープライズにも拡大しています。

一つの領域から始め、成功したら隣へ広げる。それが過去のSaaS開発の定石でしたが、同社は創業当初からバックオフィス全体を一つの基盤として設計し、プロダクト開発をスタートしました。加えて、開発組織の在り方も独特です。CxOを置かず、エンジニアは全員が「プロダクトエンジニア」。何を、なぜつくるのかを考えるところから、設計、実装までをメインの担当者が通しで担います。

なぜ、あえてこれまでの“当たり前”から外れた開発手法を取るのか。役職者を置かない開発現場は、どう回っているのか。創業期から在籍するエンジニアの渡邊雅弘さんと蒲生廣人さんに聞きました。

データ構造から逆算する。Dress Codeが最初からバックオフィス全体を設計する理由

―― まず、DRESS CODEがどんな課題を解こうとしているのかを教えてください

渡邊：ひとことで言うと、バックオフィス業務の“分断”と“摩擦”をなくすことです。

どの業務にも必ず関わるのが、従業員の情報です。一人の従業員には、使っているデバイス、アカウント、契約しているソフトウェアが紐づいています。DRESS CODEは、この従業員情報を起点に、情シス、人事労務、採用、総務といったバックオフィス全体へとプロダクトを広げていく構想で開発しています。業務のプロセスを一つの基盤の上でつなぐことで、部署ごとに分断された業務や、そこで生まれる摩擦をなくそうとしているんです。

―― 一つの領域でプロダクトを育て、その周囲の領域へ広げていくほうが、開発としては成功確率が高そうです。なぜ最初から、バックオフィス業務すべてを対象にするのでしょうか

渡邊：あとからつくり直すのは、極めて難しいからです。

おっしゃる通り、一般的には一つの大きなプロダクトが育ってから、他の領域へ広げていくマルチプロダクトの形が多いと思います。ただ、小さく始めて、あとから隣の業務を足そうとすると、そのたびにデータ構造が歪んでいく。それが技術的負債になって、最終的に、機能拡張やデータの連携の難易度を極めて高くしてしまいます。複数のプロダクトを一つの基盤の上で展開するコンパウンドプロダクトの開発の難しさは、ここにあります。

バックオフィス向けの先行プロダクトは市場に多数あり、もちろんリスペクトしていますが、後発だからこそ彼らの成功も失敗も学びにできます。簡単な道ではありませんが、最初から全体を見据えて設計するからこそ、本当の意味で業務全体を最適化できる。

実際、私も入社前にこの構想を聞いたとき、「ここまで大きな課題に真正面から挑もうとしている会社があるのか」と驚きました。難しい道だからこそ挑戦する、その姿勢に強く惹かれたのを覚えています。

蒲生：私も、入社前に開発の方向性を聞いて、とてもしっくりきました。前職でマネジメントを経験する中で、SaaSの管理をはじめ、バックオフィス業務が分断されている課題は身近に感じていたんです。「自分が使いたいプロダクトをつくれる」と感じたことに加え、当時から日本国内にとどまらず、グローバル展開まで見据えていた構想の大きさにも惹かれました。

―― とはいえ、すでに強いプロダクトが市場にいくつもある領域です。入社を検討していた時点では、「本当に後発で勝てるのか」とは思いませんでしたか

蒲生：正直にお話しすると、入社前はそう思うこともありました。

ただ、実際に入って開発を進めていくと、遅れるタスクやプロジェクトはあっても、当初のロードマップの中で実現できなかったことは一つもないんです。着々と開発を進め、お客さまに提供できるところまでたどり着けている。

実際、現在は30(2026年7月時点)を超えるプロダクトを展開し、5カ国語にも対応するなど、構想を着実に形にしてきました。だからこそ、「後発だから不利」という感覚は次第になくなっていきました。やればやるほど、バックオフィス全体を一つの基盤で支えるという構想は間違っていなかったと確信しています。

―― 一つのプロダクトから徐々に広げていくアプローチではなく、最初から全体を見据えて開発することで、ユーザー側はどんなメリットを実感できるのでしょうか

渡邊：一番分かりやすいのは、UIやUXがプロダクト全体で統一されていることです。同じ会社が提供しているサービスでも、プロダクトごとに画面の設計や操作方法が異なるケースは少なくありません。

DRESS CODEは最初から一つの基盤で設計しているので、データ構造だけでなく、画面や操作感にも一貫性があります。一つのプロダクトを使えば、別のプロダクトでも「この情報はここにある」「この操作はこうすればいい」と直感的に使えるんです。

例えば、ユーザーが別のバックオフィス部門へ異動して利用するプロダクトが変わっても、一から使い方を覚え直す必要はありません。データの考え方も操作感も共通なので、迷うことなく業務を進められるメリットがあります。

―― 人事も総務も情シスも採用も、業務の中身はまったく違います。深いドメインへの理解が必要ですが、そこはどのように補っていますか

蒲生：代表の江尻の存在が大きいです。さまざまな企業のバックオフィス業務を知り尽くしていて、「そんな業務があるのか」と驚くような実務や法制度まで理解しています。その知見を最初から設計に落とし込めるのは、大きな強みですね。

渡邊：業務の共通項を抜き出して抽象化するのも、とにかく上手で。

週1回のPMFミーティングでは、お客さまからさまざまな要望が挙がりますが、それを個別機能として実装するのではなく、複数の要望を満たせる形に抽象化して設計していきます。だからカスタマイズが増えず、一つの設計で幅広いニーズに応えられるんです。

これは海外展開でも同じでした。例えば住所一つ取っても国ごとに構造は異なりますが、最初からグローバル展開を見据えて設計していたので、大きくつくり直すことなく対応できました。

不確実性を減らしてからAIに任せる──AI時代に価値を発揮するデータ基盤

―― バックオフィス全体を同時に開発していくとなると、一人ひとりが担う範囲も広くなると思います。そうした開発スタイルを支える上で、AIはどのように活用しているのでしょうか

渡邊：そうですね。開発量はどうしても多くなるので、効率化できるところは徹底的に効率化しないといけません。そのため、AIによる効率化や自動化にはチーム全体で積極的に取り組んでいます。

好奇心旺盛なエンジニアが多いので、新しいモデルが出たらすぐ誰かが試して、「設計はこっちがいい」「実装はこっちがいい」とナレッジを共有してくれる。「じゃあ、みんなでも試してみよう」という流れが自然にできていますね。

蒲生：開発だけでなく、プロダクトそのものにもAIを組み込んでいます。ただ、バックオフィス業務は深い文脈を理解する必要があるので、AIに正しいコンテキストを渡さなければ、期待する答えは返ってきません。設計が甘いままAIを載せると、かえってユーザーの負担が増えてしまいます。

だから、私たちはまずデータや業務フローを構造化し、AIが正しく理解できる土台をつくることを重視しています。不確実性に頼るのではなく、不確実性を減らしてからAIに任せるという考え方です。

また、自動化する以上、権限管理や機密情報の扱いなど、AIに越えさせてはいけない線もあります。そのため、組織構造や権限も含めて基盤を整備してきました。AIが本格的に普及する前からこの土台をつくっていたので、新しいAI技術もスムーズに取り入れられています。

――「SaaS is dead」とも言われるように、AIがインターフェースになる時代が来ています。そうした中で、SaaSの価値はどこにあると考えていますか

渡邊：最初からコンパウンドプロダクトであることの強みは、AI時代になっても生きると思っています。インターフェースはAIに置き換わるかもしれませんが、バックオフィス全体を横断しているからこそ、業務に関するデータを一つの基盤に集約できます。

Dress CodeはSSoT（Single Source of Truth）を掲げ、データを一元管理しています。全部のデータが集まっているからこそ、AIによる業務の効率化や全体最適を実現できる。その価値はなくならないと思っています。

―― 最初に基盤を固める設計思想だとしても、実際の開発では想定外の課題に直面することもありますか

蒲生：もちろんあります。3カ月前につくった構成を、次のプロダクト開発に合わせて見直すことも珍しくありません。例えば、従業員数5万人規模の企業に導入いただいた際は、管理対象となるファイルやフォルダが数千万件に及び、そこまでの規模は当初想定していませんでした。

ただ、データをどう構造化するか、どこまで網羅性を持たせるかといった基盤の設計は、後から変えるのが非常に難しい。だからこそ、そこは最初にしっかり固めます。一方で、その上のアプリケーション層は、利用規模や要件に応じて柔軟につくり直していきます。

ドメインの捉え方を外すと後から取り返すのは難しいですが、スケーリングはエンジニアの技術で解決できます。必要に応じてスクラップアンドビルドを繰り返していく。そこは腕の見せどころですね。

―― 自分がつくったものを3カ月で捨てるのに、抵抗はないんでしょうか

蒲生：あまりありませんね。チーム全体でも、自分がつくったものを守るというより、「もっと良い構成があるなら試してみよう」と考えるエンジニアが多いんです。

AIの進化で技術も開発スタイルもどんどん変わる時代です。これまでの構成を守り続けるよりも、変化を前提に柔軟にアップデートし続けるような思考のほうが、この先はエンジニアとして活躍しやすい気がしています。

「技術で線を引くと、落ちるボールが増える」──プロダクト起点で広い裁量を持つ開発組織

―― 開発組織は、どんな体制になっているのでしょうか

渡邊：社員約50名のうち、エンジニアは約15名。CxOは置かず、全員が「プロダクトエンジニア」です。

提供しているプロダクトの数が多いので、一人ひとりが担当する領域も自然と広くなります。もちろん専門性は持ちながらも、設計や実装だけでなく、デザインやプロダクトの意思決定にも関わることが多いです。今の体制は、プロダクトのつくり方にもかなり合っていると思います。

蒲生：AIが出てきたことで、技術的なレイヤーをまたぐハードルはかなり下がったと思います。だからこそ、レイヤーごとに役割を分けるよりも、プロダクトやドメインへの理解のほうが重要になってきました。

AIを活用すれば、大きな機能でも一人で進められる場面が増えています。一人で自走できるほうが開発のサイクルも速いので、結果的に今のような体制がすごく合っていると感じています。

―― 技術で役割を細かく分けるよりも、一人ひとりが広く見ることを重視しているんですね

渡邊：技術で線を引くと、落ちるボールが増えそうなんです。

DRESS CODEは、プロダクト同士が横につながっているシステムです。共通基盤もつくっている。そこで「自分はこの領域しかやらない」と線を引くと、「これはどっちがやるの？」というものが必ず出てくる。自分の担当プロダクトに関係するものは、ある程度広げて見ていくほうがやりやすいんです。

だから、やり方にこだわるよりも、何をつくるのか、なぜそれをつくるのかを先に考えられる人のほうが、Dress Codeには合っていると思います。

蒲生：自分が設計したものは、他のプロダクトやチームにも影響していきます。だからこそ、自分の担当だけでなく、全体を見ながら開発することを楽しめる人が、Dress Codeには合っていると思います。

―― 一人の裁量が大きいぶん、意思決定にばらつきは出ないのでしょうか

渡邊：そのために、ADRという仕組みがあります。本来は Architecture Decision Record の略ですが、社内では「Any Decision Record」と呼んでいます。技術的な判断だけでなく、プロダクトの価値判断も含めて、あらゆる意思決定をドキュメントに残す文化です。Notionに記録し、週2回、全員で読み合わせています。

その積み重ねがあるので、担当が別の領域に移ってもゼロからのスタートにはなりません。過去の意思決定をたどれば、「なぜその設計になったのか」まで理解できるようになっています。

―― では、何をどう決めるべきかの判断基準は、どこにあるのでしょうか

蒲生：社内には、エンジニアの行動原則があります。

例えば「引き算思考」です。まずPdMを中心に理想形を描き、そこから逆算して「今、何をつくるべきか」を決めていきます。目の前の要望に合わせて個別に機能を足すのではなく、業務のプロセスやデータ構造まで立ち返り、より本質的な解き方を考える。構造化や抽象化が好きな人には、とても面白い環境だと思います。

もう一つが「ダブルシンク」です。DRESS CODEはSMBからエンタープライズまで幅広い企業で使われることを想定していますが、先ほどお話ししたように、企業規模によって業務フローや要件は大きく異なります。そのどちらかに寄せるのではなく、相反する要件を一つのプロダクトでどう両立させるかを考え続ける。これは代表からも繰り返し伝えられている考え方です。

―― 裁量が大きいことで、挑戦することへの心理的なハードルはありませんか

渡邊：むしろ、挑戦しやすい環境だと思います。チャレンジに伴う失敗にはすごく寛容で、「まずはやってみよう」という雰囲気があります。

分からないことがあっても、つまずいても、とりあえず最後までやり切ってみる。やってみた結果、違ったのであれば、もう一度つくり直せばいい。そんな考え方がチーム全体に浸透しています。

「ゼロイチでやる面白さは、まだ味わえる」フェーズが変わっても残る余白

―― お二人が入社して約2年が経ちました。プロダクトや事業の変化を、どのように感じていますか

渡邊：入社した当時、機能としてしっかり提供できていたのは情報システム部門向けのプロダクト「IT Force」くらいでした。当時は、コンパウンドプロダクトの価値をまだ十分に届けられていたとは言えなかったと思います。

でも最近は他のプロダクトも充実してきて、入り口がHRでもITでも、一方で入れたデータをもう一方で生かせるようになりました。部門をまたいだ業務も連携できるようになり、ようやく「一つの基盤でつながっている価値」をお客さまにも感じていただけるようになってきた。そこに一番手応えを感じています。

プロダクトが増えるほど、一つひとつの価値ではなく、全体としての価値が積み上がっていく。まさに複利のような感覚ですね。そうした価値を発揮できるようになったことで、今では数万人規模のエンタープライズ企業にも導入いただけるようになり、目指せる市場も一段広がってきています。

蒲生：コンパウンドプロダクトとして価値を出せているのは、最初に土台をつくることを優先したからだと思います。権限やデータの基盤を先に整えたことで、その上に新しいプロダクトを自然につなげられるようになった。遠回りに見えても、最初に足場を固めたことが、今になって効いてきていると感じます。

―― 会社もプロダクトも成長してきました。エンジニアとして働く面白さは、入社当時と比べて変わってきましたか

蒲生：正直、入社した時とそんなに変わっていないような気がしています。プロダクトも増え続けているので、この人数になってもゼロイチでやる面白さはまだ味わえます。一つのプロダクトを最後までやりきる経験は、自分のキャリアにも自信にもつながります。そうした経験を積める環境が、Dress Codeの面白さだと思います。

組織がフラットなことも、その面白さを支えています。何百人規模になれば組織化も必要かもしれませんが、今はそれぞれが専門性を生かしながら、大きな裁量を持ってプロダクトづくりに関われるフェーズです。

―― 最後に、どんなエンジニアと一緒に働きたいか教えてください

渡邊：エンジニアという職自体が、AIの登場によって不透明になっている時代です。実装のハードルは大きく下がり、プロダクトをつくること自体は、これまでよりずっと身近になってきました。それでも、人間が決めなければいけないこと、人間が介在する余地はたくさんあると思うんです。

その余地を見つけて、自分なりの価値を生み出せる人が、この先も活躍していくんじゃないかと思っています。目指すべき世界観があって、やり方にはこだわらず突き進んでいける。そういう方と、たくさん話してみたいです。

蒲生：私たちは、目指している世界がはっきりしています。「競合となる新しいプロダクトが出ました」と言われても、焦ったことはありません。一つの部門のツールだけでは解決できない課題があると考え、最初からバックオフィス全体を見据えて開発してきたからです。

私たちが目指す世界観を実現するには、一人ひとりが目の前の実装だけでなく、プロダクト全体を見ながら設計を考えることが欠かせません。だからこそ、仲間になってくださる方にも、「アーキテクチャごとこうしたほうがいい」と提案できるような方と、一緒に働きたいですね。

専門性を掛け合わせながらプロダクトを発展させ、バックオフィス業務全体を支える世界を、一緒につくっていきたいと思っています。