組織が拡大しても質の高いDDDを守れるか？ログラス松岡氏・村本氏に聞くDDD浸透の切り札

アジャイル開発の普及により、その関連手法であるドメイン駆動設計（Domain-Driven Design：以下、DDD）にも注目が集まり、実際に業務に取り入れられることも増えてきました。DDD普及の第一人者である松岡幸一郎さんは、独特な用語や考え方が多くとっつきづらいと思われがちなDDDについて、ブログやセミナー等で活発に情報発信を行い、啓発に勤しんでいます。

松岡さんは現在、企業の中に複数存在する経営データの収集・一元管理・分析を一気通貫で実現するSaaS「Loglass 経営管理」を提供する株式会社ログラスで、EMとして活躍しています。様々なバックグラウンドを持つエンジニアが集まる中、どのようにDDDを浸透させているのか？これからさらに組織が拡大していく中でもDDDでの開発を続けていくために、何をする予定なのだろうか？

松岡さんと、同じくログラスで働くエンジニアの村本雄太さんにお話を聞きました。

• keyboard_arrow_down エンジニアの数は3年で4倍。モデリングから実装までDDDを用いて開発
• keyboard_arrow_down DDDを広める切り札は「成功体験」
• keyboard_arrow_down ビジネスサイドとエンジニアが協力し合う文化を保ち拡大していく

——まず、ログラスの開発チームについて教えてください。

松岡：2023年7月現在（取材当時）はエンジニア22名で、3チーム体制で開発しています。私がログラスにジョインした2020年9月は、エンジニアはまだ5人くらいでしたから、だいぶ人数が増えましたね。

——DDDを用いて開発を進めているそうですが、具体的にどのように開発しているんですか？

村本：DDDというのは、ドメイン、つまりシステムの対象となる領域に基づいてプロダクトを開発する考え方で、設計のときに行う「ドメインモデリング（以下、モデリング）」と実装の2つに大別されています。モデリングの方が実装よりも抽象度が高く難しい部分がありますが、現状、チーム全体としてモデリングから実装までDDDを用いて開発しています。

普段の新機能開発は、最初にCS、PdM、デザイナー、エンジニアなど関係者が全員集まって、ユースケースやデータの具体例などを1時間くらいでざっとまとめながらモデリングをします。それをもとにエンジニアがドメインモデル図をつくり、実装に移ります。

DDDを意識してこうしているというよりは、開発プロセスのひとつとして、必要性を感じて自然とやっていると言った方が近いですね。

松岡：私はもともとDDDの講師として外部から関わっていて、入社後も開発組織にDDDを浸透させる役割を担っていました。ただ、昨年11月の時点で機能開発チームからは離れていて、それ以降DDDに関しては、たまに壁打ちや相談を受けるぐらいのスタンスです。それでも各チーム自然にDDDを実践していると思います。村本さんはその中でも新規メンバーへの手法の伝達を率先してしてくれています。

——どうやって、現在のようにモデリングから実装まで誰もがDDDを用いて進められるようになったんですか？

松岡：メンバー1人1人に「DDDでモデリングをしてみたらうまくいった」という成功体験を積んでもらいながら、じわじわと広めていきました。

DDDの実装に関しては、ある程度お手本となるパターンを定義すれば、比較的横展開していきやすいです。エンジニアは既存のパターンを踏まえた横展開が得意ですし、具体的なコードがあれば良し悪しを議論しやすいからです。私は入社直後、DDDの実装上の改善点を整理して、参照実装を作って展開しました。これは比較的すぐに広めることができたと思います。

一方、モデリングは実装に比べると工夫と根気が必要です。DDDのモデリングは抽象的ですし、いろんな書籍を見ても手法が1つに統一されていません。それゆえに「やらないといけない気はするし、必要性は感じるけれども、どうすればいいのかわからない」と戸惑いがちな領域だったりします。ログラスでは苦手意識を持たれてしまうのを避けるため、「DDDはモデリングしないと意味ないよ！」といった否定的なメッセージは発信しないようにしていました。

当たり前のようにモデリングを行う組織をつくりたいのであれば、「開発における合理的な選択」としてモデリングを選んでもらえるようになればよい。そのためには、モデリングのメリットを肌で感じてもらい、成功体験を1人1人に積み重ねていってもらおうと考えました。

—— モデリングの成功体験を積み重ねてもらうために、松岡さんはどのように動いたんでしょうか。

松岡：まずはエンジニアが設計などで困っている様子がないかを逐次観察し、自分から積極的に首を突っ込むようにしました。そして何に困っているのか聞いた上で、私がファシリテーターとしてモデリングをするんです。

その結果困っていたことを解決できれば「モデリングは便利だな、これはやった方がいいな」という成功体験になります。これを繰り返していくうちに「モデリングは開発の初期において必要なプロセスだ」と思ってもらえるようになっていきました。

村本：松岡さんは「こうするんだ」と教えるというより、自然と「一緒にやろう」と誘ってくれるんですよね。

チームで設計を考えているとき、議論がちょっと複雑になってきたなと思うと、松岡さんが「じゃあ、図を書いて整理してみよう」と、自然にドメインモデリングを始めるんです。そうやって、現段階でわかること、わからないことを整理して、わからないことがあれば「じゃあ、次はここを知ってる人を集めてやろう」と、知見を持ってる人を探して声を掛ける流れになる。

こうして進めると、必要な情報を集めたうえで開発に入れて手戻りもないので、すごくスムーズに動けるんです。松岡さんとは別のチームになった人も、同じやり方を自然と受け継いでいっていますね。

——現在のような「一緒にやりながら覚えてもらう」という方法は、開発組織の拡大につれて難しくなっていくような気もしますが…

松岡：そこがまさにチャレンジしているポイントですね。

私は2022年11月に機能開発チームを離れたので、一緒に開発してない人も増えてきています。でも、だからといってプロセスを制度化して強制力を持たせてしまったら、DDDが「合理的な選択」ではなく「やらないといけないこと」になり、場合によっては形骸化していってしまうおそれもあります。

そのため、今まで通り「一緒にやる」「相談しやすい関係性でいる」という属人的なつながりを連鎖的に広げて、納得感を持って進められるほうがいいだろうと思っています。今いるメンバーに広げてきた「DDDのプラクティスを活用したら、困っていることを解決できた」という成功体験を全てのメンバーに広げていければ、組織が拡大してもDDDを受け継いでいけるはずです。

——スクラムで言うスクラムコーチのように、チーム内にDDDを普及させるためのポジションをつくることは考えなかったんですか？

村本：ポジションはあえてつくっていないし、これからも必要じゃないと思っています。

今は、そういうポジションにあたる人がチームにいなくても、各チームが自然とDDDを実践しています。この先さらにチーム数が増え、DDDに馴染みのないメンバーがジョインしても、今のメンバーが新しいメンバーを巻き込みながらDDDを実践していけば、重要な部分を引き継いでいけるはずです。

松岡：DDDに詳しくて、わからないことを聞ける人は必要ですが、あくまで「キャラ」みたいなラベルで、明確な役割ではないほうがいい気がしています。「役割」にしてしまうと、「あの人がやってくれるから自分はいいかな」と遠慮してしまったり、関心が薄れてしまったりする恐れがあるからです。

ログラスはスクラムでチームとして開発をし、要件定義や設計もチームで行っているため、その中でドメインモデリングやDDDの実装ができる人と未経験の人が一緒にやっていくと、日々の体験の中でやり方が伝わっていっていきます。そうして学んだ人が別のチームに入ったら、またその手法を広げていける。こうして少しずつ着実に伝播していくことで、一定のラインまではスケールできそうだと思っています。

――モデリングについて、一緒にやって見せる他には、どうやって教えているのですか？

松岡：YouTubeでモデリングの動画を公開しているので、それを社内で使うこともありますね。もともとは個人的な活動で、自分がモデリングしているところを撮影して公開しているものですが、村本さんが社内に広めてくれました。

村本：これがすごくわかりやすいんです。動画を参考に、個人で開発しているサービスのモデリングをしてみたらうまくいったので、社内でもぜひ見てほしいと思ってシェアしました。

松岡：DDDについて、積極的に発信している人ってすごく少ないんです。特に、モデリングに関しては種類やプロセスが多すぎて、発信のハードルも高いし、見る方も大変です。そこで、たくさんあるモデリングの種類から4つに絞って使いやすくしたモデルを「SUDOモデリング」と名づけ、動画をつくって公開しました。すると、思ったより評判が良くて。社内はもちろん、ログラス外の企業でも活用の報告をいただいています。

——松岡さんは機能開発チームから離れたそうですが、これからログラスでどんなことをするんですか？

松岡：ドメインに合わせてシステムもチームも拡大していけるよう、DDDやチームトポロジーなどの理論を参考にシステムを分割し、それに基づいてチームを分けるという体制づくりをしていきます。

今「Loglass 経営管理」は、サービス提供領域をどんどん広げていくフェーズですので、開発するシステムとチームをどうやって切り分けていくのかが課題になります。この課題に向き合わないまま開発を進めると、「コンウェイの法則」の通り、チームの単位に合わせたシステムをつくりがちです。そうしてチームに合わせてつくったシステムが、ドメインに合わないことも、顧客体験を損なってしまうこともあるでしょう。

そうならないようにするために、ドメインに対して理想的なシステムの切り分け方を整理した上で、最適なチームの分け方や開発体制を整える必要があります。まずはシステムの構想をつくるために、DDDのコンテキスト分割といった概念を使ってモデリングしながら、どうすればよさそうか考えています。

——エンジニアとビジネス職が協力し、自然とDDDに則って開発が進んでいく文化は、なかなか実現できないと思います。なぜこうした文化ができたのでしょうか。

松岡：良くも悪くも、「Loglass 経営管理」が注力する経営管理という業務領域が複雑でエンジニアに馴染みがないということが要因の一つにあると思っています。

というのも、経営管理は、会社の中でも経営者や経営企画という一部の人しか経験しない業務です。その経験がないエンジニアや社員にとって、顧客はどんな業務をして、「Loglass 経営管理」がどう役に立つのかさっぱりわからないんです。創業当初はCEO以外経営管理の経験がなかったので、まずは全員でドメインを理解することからスタートし、その理解に基づいてシステムを設計し、開発を進めていきました。これはまさにDDDの考え方ですが、業務領域が難しすぎるからこそ、このやり方を選ぶしかなかったとも言えますね。

そうして開発初期から、エンジニアだけでなくCTO、CEO、ビジネスサイドも協力し合い、DDDに則ってプロダクトをつくり、それが顧客の役に立つ、という成功体験を積み重ねてきました。それが今の「ビジネスサイドと開発サイドが協力し、DDDに則って開発を進める」という文化にもつながっているんだと思います。これも、制度や強制ではなく、必要性が産んだ文化だと思っています。

村本：今のように、ユーザーの声を熟知しているビジネスサイドと、システムを熟知しているエンジニアが協力できれば、自然と「顧客にとって本当に必要な機能開発・改修」に取り組めますから、会社の規模が拡大してもこうした文化は保っていきたいですね。

取材・執筆：青山 祐輔
撮影：赤松 洋太