こんにちは、TECH Street編集部です！
この記事では、2025年8月26日（火）に開催した「システムアーキテクチャ勉強会～各社の取り組みや課題から学ぶ会～」の登壇者の発表内容の紹介と、イベント中に回答しきれなかったQ&Aを記載しています。
登壇者はこちらの方々！
安田 さくら（Sakura Yasuda）
パーソルキャリア株式会社
リードエンジニア
教育系Webシステムの開発経験を経て、2023年にパーソルキャリアへ入社。「dodaダイレクト」の機能改善や運用開発に携わった後、現在はアーキテクチャ再構築プロジェクトに従事。 仙台からフルリモートで参画し、DDDを学びながら設計の実践に奮闘中。
山縣 寿樹（Yamagata Kazuki）
エキサイト株式会社
2021年にエキサイト株式会社へ新卒入社し、現在5年目。バックエンドを主軸に、フロントエンドやインフラ領域も担当しています。エキサイトブログの開発に加え、最近は他サービスにも関わり、複数プロジェクトを横断して開発・運用をしています。
ドメイン駆動設計によるアーキテクチャ再構築 ～ 仕様を掘り起こし、意味の形へ ～
エキサイトブログのトップページを段階的にリプレイスする
Q&Aコーナー
（Q）dodaさんの場合、リアーキの体制や期間はどのくらいかかったのでしょうか。
安田：現在は20名の体制で進めており、着手からおよそ1年が経過したところです。まだ道半ばです
（Q）DDDのモデリングで特に苦労した点はありましたか？難易度の高い設計などあれば教えてください
安田：モデリングで最も苦労したのは、業務を「意味」で捉え直すことでした。現行のコードやデータ構造には過去の実装都合が強く反映されていて、業務の本質を抽出するには一度それらを“忘れる”必要がありました。今回はデータベースを変更しないという制約もあったため、ドメインモデルとのギャップをどう吸収するかにについても悩みました。
また、設計を進める中では、DDDの知識だけでなく、アーキテクチャや周辺のデザインパターンの理解も求められ、集約の境界や責務の分離などの判断にも苦労しました。
（Q）チーム内でDDDを浸透させる施策や工夫はなにか実施されたのでしょうか。
安田：最初の取り組みとしては、チーム内でDDDの理解を促進するためにTipsをまとめました。どんな場面でDDDが有効か、どう活用すべきかを整理し、共通認識を持てるようにしました。
また、現在はプロダクト横断での取り組みにも広げています。有識者の協力を得ながら、複数プロダクトのメンバーを集めたイベントストーミングのワークショップを企画・実施し、DDDの考え方を組織全体に浸透させる動きも進めています。
（Q）最善のアーキテクチャかどうかの判断、判定、評価はどのようにされていますか？定期的な棚卸というか、見直しをする専用チームなんかもありますか？
安田：私は社歴が浅いため詳細はお答えしづらいのですが、各メンバーがそれぞれ課題感を持ち、必要に応じて見直しを実施していると認識しています。
山縣：専任のチームがあるわけではありませんが、サーバーコストの削減はビジネスメンバーにも分かりやすく説明できるため、評価の観点として重視しています。そのため、サーバーコストを中心にアーキテクチャの見直しを進めることが多いです。
（Q）リプレース（リニューアル）という選択肢はなかったのでしょうか？今振り返ってリアーキテクトとリニューアルだとどちらの方が効率、工数、将来の保守性等の観点で良いと思いますか？
安田：当時の状況では、リニューアルという選択肢は現実的ではありませんでした。稼働中のシステムを止めることなく、外側から少しずつ変えていくリアーキテクトの方が、事業への影響を最小限に抑えられると判断しました。
振り返ると、効率や工数の面ではリアーキテクトの方が段階的に進められるメリットがありましたが、仕様や機能の整理にはもっと力を入れてもよかったと感じています。
しかし、既存資産を活かしながら将来のマイクロサービス化や保守性向上につなげる道筋を描けた点は、長期的には良い選択だったと思います。
（Q）進めるにあたり、一番の苦悩とか、社内とか体制の壁とか、で、どう乗り越えたかみたいな話もぜひ。
安田：チームとしての壁は、関わるメンバーの知識や視点がバラバラで、抽象度や粒度の違いから議論が噛み合わないことがあったことでした。共通フォーマットの導入や定例会の実施など、同じ土俵で話せるようにすることで、少しずつ前に進められるようになりました。
一方で、組織的な壁については、今まさに試行錯誤中です。DDDを単なる技術としてではなく、組織にどう“装着”していくか――つまり、プロジェクトの進め方や意思決定の仕方にどう組み込むかという観点で、まだ模索している段階です。
山縣：トップページのリニューアルは売上や利益に直結するものではないため、その必要性を説明することに苦労しました。しかし、リプレースの意義やメリットを言語化し、しっかりと伝えられたことが、社内の理解を得て前に進められた要因だと考えています。
（Q）プロジェクト前後で開発スピードやメンテナンスにどんな変化がありましたか？
リアーキって事業部門にとっては目に見える変化がなかったりするので感覚掴みにくいし成果としてどう共有とか説得したのか気になりますーー！
安田：プロジェクトはまだ進行中ですが、現時点でもPoCなどを通じて、開発効率や保守性の改善には手応えを感じています。とくに、これまで影響調査やテストに多くの時間がかかっていた部分に対して、構造を整理することで変更の影響範囲が明確になり、今後はその負荷を大きく減らせる見込みです。
こうした改善は、開発チームだけでなく、顧客にとっても「安定した品質で、より早く価値を届けられる」ことにつながると考えています。そのため、目に見える機能追加ではなく、「変更に強い構造」や「将来の柔軟性」といった観点で、設計の質や意思決定の変化として伝えていきたいです。
（Q）こういった設計をすすめるにあたり、生成AIってどれくらい活用していますか？
安田：設計の観点では、生成AIの活用はまだ限定的です。社内専用のChatGPTを使って、壁打ちやアイデア整理には活用していますが、設計判断を任せるというよりは、思考の補助として使っているイメージです。
ただ、設計成果物（たとえばクラス図やシーケンス図など）からコードへの実装という観点では、生成AIは十分に活用できるポテンシャルがあると感じています。現時点ではプロジェクトのフェーズや制約もあり、まだ本格的には取り入れていませんが、将来的には設計と実装の橋渡しとして、より積極的に活用していきたいと思っています。
山縣：現在の開発には、Claude codeを使っていたりします。
ただし、古いシステムに関してはAIを使うのは難しいかなと感じています。
（Q）モノリスからマイクロサービスへの転換についてはどのくらいの規模でどのくらいの期間を想定されていますか？
安田：どの単位で語るかによって規模は変わってきますが、数か月単位では考えておらず、長期的なスパンで進めることを想定しています。
（Q）20人のうち、何人くらいがdddビギナーでしたか？
安田：エンジニアだけでなく、ITコンサルタントもチームに含まれています。その中でDDDのエキスパートは1名、経験者も1名程度であり、残りの約18名はビギナーという構成でした。
（Q）20年システムならではの「苦悩」は沢山あるかと思うので、逆に「良かった点」を聞いてみちゃおうかな
山縣：アプリケーションが複雑でしたが、改善が必要な部分を直すことから取り組んだことで、今後新しく開発を行う際に避けるべきアンチパターンの実践を通じて学ぶことができました。結果的に大きな学びを得られた点は良かったと思います。
（Q）リプレイスの実行判断はエキサイトさんの場合、どこの部門が決断するのでしょうか。
山縣：エンジニア主導で進めていました。サーバーコストの削減にもつながり、コスト面でも大きな貢献ができています。
（Q）旧アプリ、ページの調査とか移行判断ってどんなツール活用しましたか？
山縣：活用はしませんでした
ページを実際に目視で確認し、コードを直接読みながら調査を進めました。
（Q）ページを消す消さないは中々双方の意見が食い違ったまま解決しない時ありますよねw
消しても問題ない（ようにみえる）のに、残してほしいという要望が強かったり
山縣：そのようなケースは特にありませんでした。ビジネスメンバーの理解や了承も得やすく、判断は比較的スムーズに進みました。例えば、過去のキャンペーンページを削除するといった分かりやすい対応が多かったです。
（Q）設計フェーズではどのくらいの期間をかけましたか？また共有が可能であれば、実装、テストの期間についてもどのくらいの期間をかけたのか教えて下さい。
山縣：全体の期間としてはおよそ半年を想定しており、そのうち設計フェーズには約2か月をかけました
（Q）Typescriptを導入は検討されなかったのでしょうか？
山縣：必要性がなかったため、検討しませんでした
（Q）設計フェーズではどのくらいの項目、観点に振り分けて対応を行なったのでしょうか？
山縣：設計フェーズはエンジニア2名が中心となり、それぞれの得意分野に応じて役割を分担しながら進めました。また、デザイナーにもフロント部分を担当してもらうなど、協力体制をしっかりと整えて対応しました。
（Q）エキサイトさんの体制・人数とか、プロダクト毎なのか、専門チームなのかあたりをお聞きしたいです
山縣：少数のメンバーで１つのサービスをみている状況です。多くても２～３人くらいのチームで行っています
（Q）単体テスト、機能テスト、結合テストに関してはどのようなバランスで検証を進めましたか？またその比率に関してどうしてそのような比率にしたのか教えて下さい。
山縣：特に複雑な実装は行っていないため、Webフロントエンドはあまりテストの比重を置いていないです。バックエンドについてはしっかりテストを実施しています
（Q）お話を聞く限りアジャイル的な開発を行なっていたかと考えるのですが、1つのスプリントはどのくらいの期間で行いましたか？またその期間にした理由を教えて下さい。
山縣：一週間を目途に設定して進めていました。2名体制だったので、攻めの姿勢でテンポよく開発を進めていました。
（Q）脆弱性などのセキュリティー面ではどのような取り組みをおこなっていますか？
安田：組織的に取り組んでいます。
山縣：インフラチームがいますので、そのチームが中心となって脆弱性対応やセキュリティ管理を徹底しています。
▼▼ ぜひ他登壇者の発表レポートもご覧ください
