60名規模DDDワークショップ「準備編」から「実施・振り返り編」へ

背景｜「DDDをやることは決まったけれど…」からのスタート
打ち手の検討｜ブレストの中から「ワークショップ」が残った
ワークショップの骨格づくり｜どこに時間を使うかを決める
設計の要点①：事前の「基礎講義」で、当日ワークに集中できるようにする
設計の要点②：60人×多職種でも「何するんだっけ？」にならない“型”と“流れ”
実施結果の振り返り｜満足度は高水準、ただしNPSは職種ごとに揺れた
おわりに｜DDDを日常的に使われるようにしていくために

この記事は、法人プロダクト領域（法人向けサービス・システムの領域）で実施した約60名規模のDDD（ドメイン駆動設計）知見向上ワークショップの「準備〜振り返り」編です。

発起人（なぜ始めたのか）
企画推進者（どうワークショップを設計していったのか）

という2つの立場から、ワークショップの準備をどう進め、当日どんな場となり、そこからどんな示唆を得たのかを書いていきます。

DDD有識者によるコンテンツ準備の舞台裏や、技術的な狙いについては、こちらの「準備編」で詳しく紹介されています。

背景｜「DDDをやることは決まったけれど…」からのスタート

最初の前提として、「DDDを前提にプロダクトを考えていこう」という方針自体は、すでに見えつつある状態でした。

私が担当していたプロジェクトでもDDDを先行採用して検討に着手しており、「やるかやらないか」で言えば「やる」が決まっているフェーズです。一方で、足元を見渡すと、

DDDの実務経験者はごく一部
用語の理解も人によってばらつきがある
「なんかよさそうだけど、自分の仕事とどうつながるのかはまだ見えていない」

という状態でした。

発起人として特に気になっていたのは、

プロダクトや職能ごとに前提が違いすぎて、境界や責務の話をしようとしても“通訳コスト”ばかり増えてしまう

という点です。このままだと、せっかくDDDを用いて領域や責務の見直しを行っても「理想の絵だけ描いて終わり」になりかねない、と感じていました。

そこでまずは、DDDというものに対して基礎的な理解をある程度まとめてそろえるということを取り組んでいくことにしました。

打ち手の検討｜ブレストの中から「ワークショップ」が残った

ただ、最初から「60名規模のワークショップをやろう」と決めていたわけではありません。

発起人としての危機感をチームに共有したうえで、「組織に対してDDDの基礎的な理解を広めるためにどんな打ち手がよさそうか？」をブレストするところから始めました。

ブレストでは、たとえばこんな案が出ています。

少人数の読書会や勉強会
実案件を題材にしたハンズオン
DDD経験者による事例共有会
eラーニングや動画コンテンツの整備……など

これらをメンバーと一緒に眺めながら、

「職能やプロジェクトをまたいで、同じ体験を共有できること」
「境界や責務を“頭で理解する”だけでなく、“手を動かしてみて理解する”こと」
「短期間で、ある程度まとまった人数の土台をそろえられること」

という条件から絞り込んでいった結果、最初の一手としては大人数のワークショップを開催するという方法を採用することとなりました。

ワークショップの骨格づくり｜どこに時間を使うかを決める

ワークショップという打ち手に絞ったあと、上長と相談してオフラインで2日間開催するということになりました。オンラインではなく対面で、一気に同じ体験を共有することを重視しています。

次に決めたのが「お題」です。実際の業務や既存システムを題材にしてしまうと、どうしても前提知識の差や“今の事情”に引っ張られてしまいます。そこで、

特定のプロダクトや職場の知識がなくてもイメージしやすい
誰もがある程度、利用者の立場を想像できる

という条件で題材を探し、最終的に「図書館の業務」をお題として選びました。そのうえで、

このお題で、DDDのどの部分を体験してもらうか

を洗い出しながら構成案を作っていきました。

最初は「あれもこれも入れたい」と盛りだくさんな案になりましたが、実際に使える時間でシミュレーションしてみると、「全部を薄くなぞるだけになってしまう」懸念が見えてきました。そこで、

DDDを“全部体験する”のは不可能なので、2日間で扱うスコープをはっきり決める

と割り切り、

重点を置くところ
- イベントストーミング
- コンテキスト分割
- 集約設計
あえて割り切るところ
- 戦術DDDの細部（コードレベルのHow）
- 実案件固有の制約・組織事情への深い踏み込み

という取捨選択をし、「この2日間で何を持ち帰ってもらうか」を明確にしました。

設計の要点①：事前の「基礎講義」で、当日ワークに集中できるようにする

骨格が見えてきたところで、最初に設計したのが「事前の基礎講義」です。狙いは大きく2つでした。

参加者の基礎知識の最低ラインをそろえること
当日の座学の時間を減らして、体験するワークの時間を増やすこと

当日にいきなりワークを始めてしまうと、「DDDって何だっけ？」「その用語はどんな意味？」といったところで説明に時間が取られてしまいます。そこで、事前にインプット用の講義を2回に分けて行うことにしました。

1回目：DDDの基本概念・基本的な用語の解説
2回目：イベントストーミングやコンテキスト分割など、当日に扱うワークの流れとポイントの解説

講義の実施にあたっては

「本番までに、参加者がワークショップに必要最低限の内容を理解している状態にしたい」というゴールを設定
ゴールを講師の方と共有し、講義構成とスライドを作ってもらい、2回分の講義を実施
各講義のあとにアンケートを取り、2回目講義とワークショップ本番の改善に反映する

というプロセスを踏みました。

その結果、参加者は最低限の前提知識と用語のイメージをそろえた状態で当日に臨めるようになり、当日の説明は「復習＋具体化」にとどめつつ、2日間の多くを「体験するワーク」の時間に充てることができる状態をつくれました。

設計の要点②：60人×多職種でも「何するんだっけ？」にならない“型”と“流れ”

もう一つの設計上のポイントは、60人規模・多職種混在でも、実際のワークの場面で「今何をするんだっけ？」とならないようにすることでした。

当日の進行がわかりづらいと、参加者の頭は「やり方の理解」に持っていかれてしまいます。そこで、「スムーズに作業や議論に入っていける仕組み」を意識して設計しました。

具体的には、次のような“型”と“流れ”を用意しています。

当日の説明スライド
- 全体のタイムラインと、各ワークの「目的」「ゴール」「手順」「例」を明示
- いま自分たちが全体のどこにいるのかが一目でわかるようにする
- 有識者でも経験則で行っている思考を言語化することで議論の材料にする
チームごとのワークシート
- 各ワークにはチームごとにワークシートを用意し、「この時間は、どういう思考で何をアウトプットすればいいか」が分かるようにする
- 事前講義の内容と対応づけておくことで、「聞いた内容をこの場でこう使うのか」がつながる構成にする
チーム編成と当日のサポート役
- 事前講義のアンケート結果をもとに、DDDに対する理解度が高い人と議論を引っ張れる人がチーム内に必ず混ざるようにチーム編成を行う
- 講師と社内エキスパートが各テーブルを巡回し、詰まりそうなところで声をかける

これらの成果物や進め方は、

「当日どのようなメンバーで」
「どんな説明を受けて」
「どのボードや資料を見ながら作業するのか」

を具体的にイメージしながら作り込んでいきました。

そのうえで、講師や有識者と壁打ち・レビューを行い、運営メンバーでリハーサルも実施して、「ここで戸惑いそう」というポイントを事前に洗い出して潰していきました。

こうした“型”と“流れ”を用意したことで、当日は

「このボードに沿って手を動かせばいい」という状態から議論を始められ、
参加者の認知負荷を「進め方の理解」ではなく「内容の思考」に割いてもらえる場

に近づけられたと感じています。

実施結果の振り返り｜満足度は高水準、ただしNPSは職種ごとに揺れた

当日は、講師や社内有識者のフォローもありつつ、大きな詰まりなく想定どおりの流れで進行できました。
事前講義で前提をそろえ、当日の“型”も用意していたことで、参加者の多くがワークに集中できていた印象です。

ワークショップ実施後のアンケートでは、全体満足度や理解度はおおむね高い水準でした。

「DDDの必要性・背景が腹落ちした」
「考え方のイメージがつかめた」

といった声が多く、「導入の入り口」としては狙いに近い評価だったと感じています。

一方で、NPS（他の人に薦めたいかどうか）は職種ごとに傾向が分かれました。

マネジメント層・ITコンサルタント：比較的高いスコア
エンジニア（特にリード層）：相対的に控えめなスコア

という結果です。

企画側の意図として、今回は「全体像の理解」と「共通の考え方の導入」に振り切った設計にしていたこともあり、組織的な構造や将来像を考えることが多い層ほど価値を感じやすかった一方で、

「今のシステム」「今の案件」にどう効くのか
集約設計から具体的なコードにどう落とし込むのか

といった、より具体的な適用まで期待していた層には、ワークショップ単体では応えきれなかった部分があったと捉えています。

自由記述のコメントでも、

イベントストーミングやコンテキスト分割を通じて、「言葉と境界の重要性」を体感できた
「全体像の入り口」としてとても良い経験になった

といったポジティブな声と並んで、

集約の設計から具体的なコードへの落とし込み方を知りたい
ケーススタディなどでの反復練習をしてみたい

といった“次にやりたいこと”が具体的に挙がっていました。

これを受けて、集約設計からコードへの落とし込み方を扱うアフター講義を企画・実施し、今回のワークショップで扱いきれなかった「戦術寄りのHow」の一部をフォローする形につなげています。

おわりに｜DDDを日常的に使われるようにしていくために

当社の挑戦は、事業成長とともに肥大化してきたシステム・プロセスの再構築であり、ここまで本記事（あるいは関連の記事）をお読みいただいた皆さんの現場でも規模の大小はあれど何らか同じようなジレンマを抱えているのではないでしょうか？

私たちの組織がそうであったように、DDDはそれ自体が目的なのではなく、壮大な変革を現実的に前進させていくための私たちの選択したアプローチです。戦略の道筋・アプローチは無限の可能性がある中で、私たちのチームが選んだ一つの選択でしかなく、絶対の正解である確信はまだ持てていません。

一般的にソフトウェア開発の生産性を上げるためには少数精鋭が良しとされていますし、私たちも同じように考えています。しかし、こと当社のように数千人規模のメンバーが一丸となって運営している事業・プロセス・システムを再構築していく上では、現場有識者を広く巻き込んだ”あるべき姿”の見極めが必要です。この段階において、どんなアプローチの選択をするのであれ、関係する多数のメンバー個々人が変革に必要な知識・スキルを装着する必要、つまり組織としての装着が必要になります。

元々私たちのプロジェクトのチームはごく少数でした。少数で試行錯誤を経て、より広い範囲・より多数の協力者・同志の存在が必要不可欠であるという危機感の元に、組織に広くDDDを装着するための挑戦に踏み出しています。数名のチームから、数十名単位の大きな視点で見た目的を一つにする開発組織の中への定着を目指し、その後は丁寧なアラインメントを経ながら、当社が一丸となって変革に向けて歩んでいけるところまで見据えた挑戦が始まっています。

当初は数名のチームから、60名規模という少しチャレンジングなスケールでやってみた結果、組織内でDDDを活用して境界・責務・言葉をそろえる「入り口」は作れたと感じる一方、「案件への具体適用」や「戦術DDDの深堀り」は、さらなる打ち手が必要ということも見えてきました。

今回の取り組みの振り返りも踏まえて「次の打ち手の方向性」を言語化し、今後は組織としての取り組みに広げていきたいと考えています。

ここまで読んでくださった方の現場でも、「うちならどうやるだろう？」を考えるきっかけになっていればうれしいです。