※この記事は、2025年8月に開催されたイベントでの発表内容をレポートしたものです。
登壇者はこの方
安田 さくら（Sakura Yasuda）
パーソルキャリア株式会社
リードエンジニア
教育系Webシステムの開発経験を経て、2023年にパーソルキャリアへ入社。「dodaダイレクト」の機能改善や運用開発に携わった後、現在はアーキテクチャ再構築プロジェクトに従事。 仙台からフルリモートで参画し、DDDを学びながら設計の実践に奮闘中。
安田：中途採用支援をはじめ、新卒採用、副業・フリーランス支援など、働くに関する様々なサービスを展開している当社ですが、今回の取り組みの対象となったのは、中途支援領域にある「dodaダイレクト」というサービスです。
まず、なぜアーキテクチャー再構築に取り組むことになったのか、その背景と課題からご紹介します。
アーキテクチャーの再構築に至った背景と課題
「dodaダイレクト」は、企業が転職希望者様へ直接スカウトを送ることができる法人向けのサービスです。日本最大級のスカウト会員データベースを活用し、これまで成長を続けてまいりました。既存のデータベースを活用し、スピードを重視して開発が進められてきた結果、事業は拡大したものの、その代償として技術的負債が蓄積されていきました。
このような急成長の中で、いくつかの技術的な課題が顕在化してきました。
具体的には、保守性の低いコードや不明確な仕様、複数のサービスが複雑に絡み合った「分散モノリス構造」、そしてプロダクトをまたいで利用される「共有データベース」などが挙げられます。
その背景には、事業や機能追加を優先する開発体制、ドキュメントの陳腐化、人員の入れ替わりといった様々な要因がありました。その結果、品質を維持するための工数が増大し、開発のリードタイム長期化やパフォーマンスの低下といった影響が懸念されていました。皆さんの現場でも、事業を優先して開発を進めた結果、技術的な歪みが残ってしまったというご経験はないでしょうか。
そこで私たちは、これらの課題を根本から見直すため、ドメイン駆動設計（DDD）を軸としたアーキテクチャーの再構築に踏み出すことを決意しました。
ただドメイン駆動設計の導入は決まったものの、経験者は少なく、私自身も未経験ながらモデリングチームのリーダーを務めることになりました。正直なところ、当初は何から手をつけて良いかすら分からず、期待感と共に非常に大きな戸惑いもありました。
属人化した仕様、密結合なアーキテクチャー、共有データベースといった課題を前に、教科書通りには進められない状況でした。仕様も不明確な中でどのように取り組めばよいのか、また、組織としてどう導入していくべきかという点でも、悩みは尽きませんでした。
この発表では、そのような状況の中、現場の私たちがどのように第一歩を踏み出したのかを共有したいと思っております。同じような課題や悩みをお持ちの方々にとって、少しでも参考になれば幸いです。
具体的な進め方について
ここからは、私たちが具体的にどのように進めていったかをご紹介します。
進め方は、大きく3つのステップに分かれています。
最初のステップは、ヒアリングを基にした大まかなモデリングです。有識者へのヒアリングや過去の資料から、ドメインの全体像を描きました。
2つ目のステップは、コードを起点とした詳細なモデリングです。仕様が不明確な中、コードを手がかりにロバストネス図を用いて現在の仕様を可視化していきました。
そして3つ目のステップが、実装からのフィードバックを反映させるプロセスです。POCを通じて設計の妥当性を検証し、モデルをアップデートしていきました。
それでは、それぞれのステップについて、もう少し詳しくご紹介します。
ステップ1は「ヒアリングをもとに大まかなモデリング」です。
まず、これまでの資料や有識者へのヒアリングから、システム全体の像を描くモデリングを実施しました。スライド右側にあるような仮のドメインモデルを定義し、その後、ドメインを仮特定することで、議論を進めるための土台を築きました。
この段階で作成した暫定のコンテキストマップは、完成形を目指すものではなく、あくまで今後の探索を進めるための「地図」として活用しました。ここでドメイン分割を行ったことにより、プロジェクトを進める上での優先順位付けや、チーム内のタスク分担にも役立てることができました。
ステップ2は「コード起点での詳細モデリング」です。
このプロジェクトでは、仕様が不明確であることが大きな課題でした。ドキュメントは陳腐化しており、仕様がコードの奥深くやSQLの中にまで埋め込まれているなど、表からは見えない状況だったのです。
そこで私たちは、コードや画面操作を読み解きながら、ロバストネス図を用いて現在の仕様を可視化することにしました。この方法は、チームで取り組む上でも着手しやすく、業務を理解する上でも有効でした。
ロバストネス図とは、ユースケース駆動開発におけるアイコニックプロセスで用いられる図の1つで、「バウンダリ」「エンティティ」「コントロール」という3つの要素で構成されます。「バウンダリ」は画面などのインターフェース、「エンティティ」は概念モデル上のクラス、「コントロール」はバウンダリとエンティティをつなぐ存在で、処理やロジックを表します。これらの要素をつなぐことで、ユースケースに対してどのような流れで処理が行われ、どのようなオブジェクトが扱われているかを把握することができます。
この段階では、現在の仕様を読み解くことに焦点を当て、エンティティを現在のテーブルに対応させることで、そのテーブルの影響範囲や処理との紐付けを明らかにすることに努めました。また、この図はモデルを作成した後、モデルとテーブルのマッピングを考える際にも活用できる有効な情報となりました。ロバストネス図を用いることで、これまで見えていなかった処理の流れや要件の振る舞いを整理することができ、仕様に対する理解が大きく進みました。
ステップ2の後半では、コードから掘り起こした仕様をもとに、ドメインモデル図の精度を高めていきました。現状のコードやデータ構造には、実装上の都合が強く反映されており、ビジネス的な「意味」を理解する必要がある場面が多くありました。そこで、仕様を自然言語で記述し、それをモデルに変換するというプロセスを実施することで、「実装の形」ではなく「意味の形」で捉え直す工夫をしました。
また、現在のデータモデルとのギャップが大きい場合には、変換用のモデルを挟むなどして、その乖離を吸収する設計を取り入れました。しかし、それでも対応が難しい場合には、ドメインモデルを現在のデータモデルに寄せるという判断をすることもありました。こうした整理を通じて、ステップ1で作成したドメインモデル図の精度を高めていくことができました。
最後のステップ3は、「実装のフィードバックを反映」です。ここまで整理してきたモデルを、実際に一部実装してみることで、設計の妥当性を検証しました。
プロジェクトの特性上、当初はモデリングを完全に作り切ってから実装フェーズへ移行する想定でしたが、初めての取り組みということもあり、設計成果物に過不足がないかという不安がありました。そこで、いくつかのユースケースを用いてPOC実装を行い、そのフィードバックをもとにモデルへ反映させるというプロセスを繰り返しました。
このように小さく作ることで、失敗した場合のコストを抑えつつ、素早く学びを得ることができました。ただし、ここで試すユースケースの選定は重要です。複数のモデルや制約、ロジックが絡むものでなければ、有効な検証が行えないという事実がありました。また、実装を通じて設計が実際に動くものとして繋がったことで、モデリングチームのメンバーの納得感も非常に高まったと感じています。このように、小さく試しながらモデルを更新していくプロセスは、DDDをどう実践していくかというプロセス自体を考える上でも、大変良い気づきとなりました。
学びと組織でモデリングを進める難しさ
ここからは、この取り組みを通じて得られた学びや、組織的な難しさについてお話しいたします。
モデリングを進める中で特に難しかったのが、「どの粒度で、どのように伝えるか」という点でした。技術に詳しい人、現在の実装をよく知る人、外部のパートナーの方など、関わる人々の視点や背景は実に様々で、用いる表現の抽象度や説明の仕方にもばらつきが生じてしまいます。
そこで導入したのがロバストネス図です。これを「共通の型（フォーマット）」として用いることで、モデリングを前に進めるための助けとなりました。画面操作やデータの流れを1枚の図に落とし込めるため、仕様を明らかにしながら、誰もが理解しやすい形になったと考えています。
また、モデルを整理する中で、もう一つ難しかったのが「意味で捉える」ということでした。現在の実装やデータ構造に詳しければ詳しいほど、これまでの知識に引っ張られてしまい、業務の「意味」で捉え直すことが難しい場面が多々ありました。しかし、そうした方々は、これまでの施策の背景や歴史を深く理解している現場のドメインエキスパートであり、プロジェクトにとって非常に心強い存在でもありました。技術的な知識と業務的な知識、その両方を橋渡しすることで、「意味の形」としてモデルを描けるようになっていきました。
まとめとこれからの挑戦
最後に、まとめとこれからの挑戦についてお話しします。
この取り組みを通じて、私たちは不確実な状況下でも、具体的なアクションを起こすことの重要性を実感しました。
まずは仮説ベースでモデリングを始め、仕様が不明確な部分はコードを起点にロバストネス図で意味を整理し、小さく試してフィードバックを反映することでモデルを進化させていきました。プロジェクトの制約下では、こうした更新は一見「手戻り」に見えがちですが、これを「進化の前提」として捉える視点が重要でした。そのため、DDDを組織で実践していくには、こうした考え方をチームだけでなく、プロジェクト全体に広めていくことが不可欠です。
今後の展望として、モデリングを進める中で、複数のプロダクトにまたがる複雑な共有データベースの存在に悩まされることが多くありました。この共有データベースの課題を解決するため、プロダクトを横断した取り組みを本格的にスタートさせています。ちょうど先日、複数のプロダクトのメンバーでイベントストーミングのワークショップを行い、プロダクトを超えてビジネスの「意味」をつないでいくための対話を始めたばかりです。
また、今後はAIの活用も進めていきたいと考えています。組織やプロダクトとしての活用はもちろんですが、モデリングやコーディングといった開発の現場でもAIを味方につけていきたいです。現場で得た学びを武器に、このプロダクト横断の取り組みとAI活用の取り組みを加速させていこうと思います。
私の発表は以上です。
▼▼ ぜひ他登壇者の発表レポートもご覧ください
