こんにちは。dodaダイレクト エンジニアの 安田 です。
アドベントカレンダーも10日目に突入しました。🎄
ちなみに、この記事が公開された12/10は“ごめんねの日”だそうです。そして今、私たちはDDDワークショップ本番の真っ最中！この記事では、その舞台裏――準備編をお届けします。
本番うまくいってなかったら…ごめんね（？）🎅
はじめに｜なぜDDDを学ぶ場をつくったのか
私たちの法人プロダクト領域では、いま大きな変化の波の中にいます。
モノリスからの脱却、マイクロサービス化、そしてAI活用の加速。複数プロダクトが複雑に絡み合う中で、領域の見直しや責務の整理が必要になり、「どこをどう分けるのか」を共通言語で議論できる状態づくりが重要になってきました。
そこで、注目したのが ドメイン駆動設計（DDD）。
コンテキストを意識した整理や、業務の“意味”から考えるアプローチは、再構築の方向性ともぴったり。ただし、現状では「DDDという言葉は知っているが、実務経験は少ない」というメンバーが大半。まずは全体で基礎理解を揃える場が必要でした。
DDD知見向上を目的としたワーキングチームが立ち上がり、その第一歩として企画したのが、ITコンサルタント職・エンジニア職を対象にした約60人規模の2日間のDDDワークショップ。
今回はその【準備編】をお届けします。
「組織でDDDを広めたい」「多職種の学習機会づくりに興味あり」そんな方の参考になれば幸いです。
準備で工夫したこと｜大人数×多職種をどう設計したか
なぜ「体験型」にしたのか
DDDに関する本や記事はたくさんありますが、概念や用語をインプットするだけでは、実務でどのように業務を整理し意思決定するかの手触りが得づらいものです。そこで今回は、手を動かしながら考え方の流れを体験することを重視し、ワークショップ形式を採用しました。
題材は外部講師の方もよく使われている図書館ドメイン。
選定理由は以下のとおりです。
・なじみやすい：誰もが日常的にイメージしやすい
・用語の共通理解が取りやすい：専門用語の壁を低くできる
・実務の固有事情を持ち込まずに議論できる：純粋に「意味」で分ける練習に集中できる
・構造がちょうどよい：多職種×大人数でも議論が広がりやすい
2日間の全体構成
学びの律速を下げるため、「広げる → まとめる」という構成にしました。
- Day1 午前：イベントストーミング（業務の全体像を見える化）
イベント（業務で起こるできごと）を付箋でだし、業務の流れを俯瞰します。 - Day1 午後：コンテキスト分割（意味的なまとまりを整理）
関心や目的に応じた境界を引き、関係性を可視化します。 - Day2 ：集約設計（モデルの単位に落とす）
不変条件やルールを扱いながら、責務・情報・振る舞いを設計します。
DDDの深い部分に踏み込むというより、“業務を言葉にする → まとまりを見つける → 役割を考える”という一連のプロセスを体験してもらうことを目的にしています。ワーク後に「なんとな～く見えてきた」という感覚を持ち帰ってもらえたら理想です。
大人数でも迷わない工夫
対象はITコンサルタント職・エンジニア職が混在する約60人。DDDの経験値がまちまちな状況でも迷わず参加でき、会話が自然に発生する構造を最重視しました。
そのために準備したことは：
- 5～6人の小チーム編成
会話量が確保され、全員が発言しやすい規模。事前アンケートをもとに経験レベルの偏りも調整。 - 共通の題材（図書館）で前提を揃える
実務固有の前提差を排除して、意味ベースでの議論に集中。 - 手順をシンプルに、ステップを明確に＋ワークシートを用意
各パートで「何をするか」を明示して、迷いどころを減らす。論点の誘導を適度に設計し、チームごとのポイントを分かりやすく。 - 外部講師＋社内エキスパートの回遊
各チームの疑問や観点のズレをその場でフォローする。
「詳しい人がリードして初心者がついていく」構造ではなく、「全員が同じペース・同じ型で考える」構造となることを意識しました。
ワーク設計の裏側
ワークを成り立たせる設計ポイント
ワーク設計は社内で試行錯誤しながら進め、外部講師のレビューでブラッシュアップしました。ここでは、設計のポイントを紹介します。
- イベントストーミングを段階的に進める
「イベント要素を洗い出す→他要素を加えて結ぶ→ウォークスルーし、見直し→まとまり（集約候補）を見つける」のステップに分解。
大人数でもやることが明確になるよう、進行の“型”を用意しています。 - コンテキスト分割の“観点”を言語化
「どの視点で境界を引けばいいか迷う」というメンバーからのフィードバックを受け、意味的なまとまりを判断するための観点を整理して観点集を用意しました：
【観点の例】
・業務目的・関心｜どんな成果・目的をもつ業務か？
・用語の意味｜同じ言葉が同じ意味で使われているか？
・ライフサイクル｜どこで生まれ、どこで更新・廃棄されるか？
・外部との関係｜外部システム・他チームとの接点は？
など
例）「貸出」と「返却」はいずれも利用者へのサービス提供が目的なので、同じコンテキストの可能性が高い
例）「貸出」と「蔵書管理」は、前者はサービス提供、後者は在庫整備で目的が異なるため、別コンテキストっぽい - 集約設計は「問い」で責務を浮かび上がらせる
技術的な詳細に寄り過ぎず、責務をどう理解し、どう説明するかをチームで言葉にできるよう「問い」を用意しました：
【問いの例】
・この集約はどんな役割を持つべきか？
・どんな情報が必要か？
・常に守られるルールは何か？
など
問いに答える過程でチームの視点が揃い、集約としての“形”が立ち上がるよう意識しています。 - “議論→清書”の二段階で理解を整理
議論のあとには、テンプレートを使ってチームとしての結論を清書します。一度出した情報を整えることで理解が固まります。さらに、後から参照できる成果物として残すことができ、チーム間共有にも役立ちます。 - チーム間で成果を共有
各パート後に、10チームを2グループに分けて成果共有会を実施。外部講師・社内エキスパートのコメントも交え、他チームの視点からの気づきを得られるようにしています。
外部講師との連携｜講義と資料レビュー
外部講師の方に事前講義（1時間×2回）依頼しました。戦略的DDD・戦術的DDDの基本や用語の理解を揃えることが目的です。アンケートでは「理解が深まった」と約9割が回答。
ワークの前提を揃えるうえで非常に有効でした。
さらに、外部講師の方にはワーク資料のレビューもお願いしました。
・ワークの時間配分
・迷いやすいポイントの明示
・説明の粒度や順序の調整
などの具体的なアドバイスをいただき、資料と当日のテンポを整えるうえで大いに助けになりました。
生成AI（Copilot）の壁打ち活用
準備段階では、資料づくりやワークの組み立て時にCopilotを壁打ち相手として活用しました。
- この説明で伝わるか？迷いそうか？専門的すぎないか？を都度チェック
- 初心者の視点でシミュレーションしてもらい、言い回しや順序を微調整
- 題材が架空の図書館ドメインのため、複数の図書館の公開情報の横断確認に活用し、基本ルールや業務の一般的前提を土台として整備
「自分たちの前提」に引きずられがちな資料づくりに、第三の相棒として有効でした。
おわりに｜これはまだ準備編なのだ…
今回は、60人規模のDDDワークショップをどう準備したかを紹介しました。正直、うまくいくかはやってみないと分かりません（ﾄﾞｷﾄﾞｷ）。ただ、DDDを組織的に広げるためには、手探りでも一歩を踏み出す価値があると考えています。
資料づくりや構成設計には大変な面もありましたが、チームで工夫を重ねながら進めたことが大きな力になりましたし、ゼロから形にしていくプロセスは私自身にとっても学びと発見の連続でした。
実施後には【本番＆振り返り編】として、当日の様子や参加者の反応に加えて、今回書ききれなかった試行錯誤や学び、苦戦したポイントなどについても共有できたらと思っています。
準備編はひとまずここまで！本番どうなるかなぁ…ﾄﾞｷﾄﾞｷ
付録｜用語のショート解説
-
イベントストーミング：業務で起こるできごと（イベント）を付箋で並べ、流れや関係を俯瞰する探索手法。
-
コンテキスト（境界づけられたコンテキスト）：意味的なまとまり。業務の目的や用語の使い方が一貫する範囲。
-
集約（Aggregate）：一貫性を保つために一緒に扱うべきデータと振る舞いの単位。不変条件を内部で守る責務を持つ。
安田 さくら Sakura Yasuda
クライアントプロダクト本部 テクノロジー統括部 プロダクト開発２部 法人サービスモデリンググループ
新卒で印刷会社の開発部門に入り、教育関連のWebシステム開発を経験。
2023年にパーソルキャリアへ入社。現在は宮城・仙台からフルリモートで参画しながら、DDDを学びつつ設計の現場で奮闘中。
※2025年12月現在の情報です。
