公開日 2025/11/19更新日 2025/11/18

スポットバイトル1年目の舞台裏~急成長で生まれた技術的負債とドメイン駆動設計による再構築~

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

こんにちは、ディップ株式会社でエンジニアをしております、奥野と申します！

弊社では「Labor force solution company」をビジョンに掲げて、人材サービスとDXサービスの提供を通して、労働市場における諸課題を解決し、誰もが働く喜びと幸せを感じられる社会の実現を目指しています。私たちが開発するスポットバイトサービス「スポットバイトル」は、2024年10月1日にリリースされ、おかげさまでちょうど1年を迎えることができました。

このようなマッチングサービスにおいて、市場の変化やユーザー（ワーカー様、クライアント様）のニーズに素早く応え、安定したサービスを提供し続けることは、事業の成長にとって非常に重要な要素です。「スポットバイトル」は、まさにこの価値を迅速に届けるため、約半年という急ピッチで開発・リリースされました。この立ち上げスピードによりサービスは順調に拡大しましたが、その裏側では、急ピッチな開発による「技術的負債」が徐々に顕在化し始めていました。この「負債を抱えながらサービスを拡大している状態」から脱却し、市場の変化に対応しながら長期間サービスを稼働させ続けるための土台を再構築すべく、私たちはリアーキテクチャへの挑戦を始めています。

本記事では、私たちが直面した具体的な課題から、それを乗り越えるためにどのようなアプローチで刷新を進めているのか、そして私たちが目指している今後の展望までを、順を追ってご紹介します。

スピードと引き換えに見えてきた課題

「スポットバイトル」は、スポットバイトで働くワーカー、求人を出すクライアント、弊社の社員であるCS(カスタマーサポート)といった使用者ごとの単位に分けられた複数のチームが、それぞれのシステムを開発しています。

現状のアーキテクチャでは、これらの複数システムが共通のDB、テーブル、レコードを参照・更新している状態でした。

既存アーキテクチャイメージ図

会員限定コンテンツ無料登録してアーキテクチャを見る

リリースから暫くすると、このアーキテクチャに起因する以下のような問題点が顕在化してきました。

高い結合度：一つのデータモデル（テーブル）に複数のシステムが強く依存している。
低い凝集度：本来まとまっているべきビジネスロジックが、各システムに分散してしまっている。

これらの理由から、ある機能の変更が他のシステムに意図しない影響を与えないように、常に全チームで足並みを揃えて開発を行うことが常態化していました。結果として開発スピードの低下や、意図しないバグの発生といった課題に直面していました。

「画面駆動」から「業務駆動」の設計へ

これらの課題から脱するため、私たちは従来の画面駆動の設計から、業務駆動の設計へと舵を切ることを決断しました。その中核的なアプローチとして、DDD（ドメイン駆動設計）を選択しました。さらに、開発速度を高めながらも品質を担保する狙いで、TDD（テスト駆動開発）を取り入れ、リアーキテクチャを開始しました。

最初に行ったのは、AWS様にもサポートいただきながら実施した「イベントストーミング」です。イベントストーミングには、各チームのエンジニアやPO（プロダクトオーナー）が一室に集まりました。これにより、以下のような非常に大きな成果が得られました。

実際の業務フローに基づいた「集約」の発見
システムの単位となる「境界づけられたコンテキスト」の特定
コンテキスト間の依存関係を示す「コンテキストマップ」の可視化
チーム間での業務仕様の認識合わせと「ユビキタス言語」の定義

特に、チーム間で業務ドメインの認識を合わせ、DDDの土台を構築する上で非常に有意義な時間となりました。

（※イベントストーミングやリアーキテクチャの詳細な取り組みに関しては、下記のブログで詳しく紹介していますので、ぜひ合わせてご覧ください。）
AWSさんにイベントストーミングワークショップを開催して頂きました
 【GoCon前夜祭登壇レポート】GoによるDDDとTDDを用いたリアーキテクチャの実践

ドメインの整理と目指すアーキテクチャ

イベントストーミングで発見したコンテキストマップを基に整理・議論を進め、私たちは「スポットバイトル」のドメインを以下のように分類しました。

コアサブドメイン
マッチングコンテキスト：隙間時間で働きたいワーカーと「今」人手が欲しいクライアントのマッチング最大化
就業コンテキスト：ワーカーが安全に働くことのできる土台の構築
支援サブドメイン群
上記コアサブドメインの業務をサポートするその他のドメイン

目指すアーキテクチャは、これらをドメイン単位で責務を分割した「マイクロサービス」の形です。

コンテキストマップイメージ図 会員限定コンテンツ無料登録してアーキテクチャを見る

「開発を止めない」ためのストラングラーフィグによる移行戦略

リアーキテクチャを進めるにあたり、最大の課題は「エンハンス開発（既存機能の追加・改善）とどう並行させるか」でした。サービスを止めずに移行を完了させるため、私たちはストラングラーフィグパターンを採用しました。

具体的には、まず既存のAPIをBFF（Backends For Frontends）として位置付け、フロントエンドからのリクエストは引き続きこれらがすべて受け止める形を取ります。これにより、フロントエンド側は既存のAPI（BFF）を呼び出し続けるだけでよく、リアーキテクチャによる変更の影響を受けることがありません。

その「裏側」で、既存のAPIが直接担当していたドメインロジックを、新しく構築したドメインごとのマイクロサービス（マッチングAPI、就業API、支援サブドメインAPI）側へ移譲します。既存のAPIは、該当する新しいAPIを呼び出すだけのシンプルな責務へと変わります。この「機能単位での段階的なロジック移譲」こそが、エンハンス開発と並行した安全な移行を可能にする鍵となります。

新規アーキテクチャイメージ図 会員限定コンテンツ無料登録してアーキテクチャを見る

この戦略のもと、私たちは移行が停滞することを避けるため、「理想（完璧さ）」よりも「速さ」を重視する現実的なアプローチ（フェーズ1）を立てました。

まず、フェーズ1における移行の割り切りとして、DBは当面、既存のものを共有することを許容しました。これにより、DB移行という大きな作業を後回しにし、価値の高いドメインロジックの置き換えを先行させることが可能になります。

このDB共有を技術的に可能にしているのが、DDDの戦術的設計であるリポジトリパターンです。このパターンは、既存DBへのアクセスや複雑なデータマッピングといった処理を、すべてリポジトリ層（インフラストラクチャ層）に集約しカプセル化するものです。このようにリポジトリ層がデータ構造の差異を吸収する役割を担うことで、ドメインロジック（ドメイン層）を、DBの物理的な構造から切り離しています。これにより、ドメインロジックはビジネスルールに集中したクリーンなモデルを維持したまま開発を進めることが可能になります。

会員限定コンテンツ無料登録してアーキテクチャを見る

この設計により、将来的にDBをドメイン単位で分割する際にもドメイン層への影響を最小限に抑えて移行することが可能になります。この「ドメインロジック先行」のアプローチの結果として、移行の優先順位も明確になりました。更新系の処理はドメインロジックとして独立させやすいため、移行を最優先としました。

一方で、複数のロジックが密結合しBFF（既存API）への影響も複雑な参照系の処理は、移行を後回しにする戦略を定めました。これは、単にリスクを最小限にしつつ価値あるドメインロジックを移行するだけでなく、後述する「理想の開発体制」の構築を最優先に据えた戦略となります。

今後の展望：AI-DLCの活用と「ドメイン単位のチーム」への進化

現状は、専任のリアーキテクチャチームが新しいAPIを開発し、他チームのエンハンス開発（機能追加・改善）と並行して移行を進めています。将来的には、リアーキテクチャチームが整えた開発基盤（DDD/TDD）上で、エンハンス開発チームも新しいAPIを使った開発に早期に合流できる体制を目指しています。

そのための新たな挑戦として、「AI-DLC（AI-Driven Development Lifecycle）」といった、ユーザーストーリーの作成など上流工程からAIを活用してPO(プロダクトオーナー)を含むチーム全体で開発を進めていく手法も試行しています。
（※この取り組みに関しては、弊社のCTOがアーキテクチャConference 2025で登壇予定ですので、ご興味があればご視聴ください。また具体的な実践内容については、『AI-DLCワークショップ体験記：3日間で学んだAI駆動開発の実践と課題』でも詳しく紹介していますので、ぜひ合わせてご覧ください。）

そして、私たちが最終的に目指す理想の姿は、望ましいシステムアーキテクチャを実現するために意図的に組織構造を変革する「逆コンウェイの法則」を実践することです。これは、リアーキテクチャを高速化し、エンハンス開発と並行して進められる「理想の開発体制」を構築するための、戦略的な一手です。この「体制」と、「ドメイン単位のマイクロサービス」というアーキテクチャの歩調を合わせるため、開発組織も現在の「プロダクト単位のチーム」から「ドメイン単位のチーム」へと再編成していきます。

これにより、システムと組織のアーキテクチャを意図的に一致させ、各チームが自身のドメインに対して高いオーナーシップを持ち、「エンハンス開発」と「フェーズ1で後回しにした既存処理の移行」とを、自律的かつ並行して進められる体制の構築を目指していきます。

終わりに

「スポットバイトル」のリアーキテクチャはまだ道半ばです。しかし、この取り組みを通して、当初の課題であった「高い結合度」と「低い凝集度」という問題に対し、ドメイン駆動設計（DDD）が強力な解決策であることを日々実感しています。DDDを実践することで、モデルの責務が単一になり、ビジネスロジックが自然と簡潔になっていく手応えから、この方向性で進めることで課題を解決できると確信しています。

また、「全チームで足並みを揃える」という開発体制の課題も、「AI-DLC」の活用によるリアーキテクチャの加速によって、「ドメイン単位のチーム」への移行を高速に実践し、その効果を素早く検証しながら組織自身も変化し続けることで、解決できると見込んでいます。本記事でご紹介した、サービスを高速に成長させる過程で生まれた課題に向き合い、持続可能なアーキテクチャへと進化させようとする私たちの挑戦が、同様の課題を抱える方々にとって少しでも参考になれば幸いです。

ディップは今、「第二創業期」を迎え、まさにこの記事で述べたように既存事業の良いところは残しつつ、市場の変化に合わせて大きく変わろうとしています。そんな変革の最前線で、一緒に社会課題の解決に挑戦できるエンジニアを募集しています！ぜひ、ご応募お待ちしています！

2027年卒新卒採用エントリーはこちら
 中途採用エントリーはこちら（Findy内のディップ株式会社/バックエンドエンジニア求人ページが開きます）

執筆者のご紹介