🌾

勉強会「スタートアップでDDDを最大限使いこなすには？ ~事業と組織を連携するプロセスづくり~」の参加メモ

2023/06/16に公開

DDD

こちらの勉強会に参加したのでそのメモと所管まとめです。

参加した理由

現在、リーガルとファイナンスを掛け合わせたとあるドメインのスタートアップの創業メンバーとしてリリースに向けてサービスデザインから開発までやっています。

ドメイン的にも参画しているメンバー的にもDDDとの親和性は高いのですが、とはいえ文化圏に根付く慣習などあり複雑で規模もなかなかのサイズ故に軽量DDDと本格的なDDDの間くらいの雰囲気で進めていることもあり、スタートアップとDDDを他の皆さんはどうしているか知りたくて参加を決めました。

雑なまとめ

今回はcommmune株式会社さんと株式会社ログラスさんの二社の取り組みを座談会方式で話す会です。参加者は50人程度でDDDやってる2割、今後取り組みたい2割といった感じです。

話を聞きながらメモったものを見返しつつ、懇親会での話など踏まえて思い出しながら書いているのでもしかすると二社の情報がテレコになっているかもですがご容赦ください。

両社の状況

両社ともに規模感は近いようで、複数チームで開発を進めているそうです。会社のステージとしてはアーリー〜ミドルくらいですかね？

DDDの採用については、commmuneさんはここまで軽量DDDで取り組んできていたが会社全体で取り組んでいるというよりはエンジニアだけが取り組んでおり、故にドメイン知識などモデリングなど現在進行中でリファクタしながら進めているそうです。

ログラスさんはすでにDDDの導入は一通り済んでおり、現在はモデリングなど精度を高めるフェーズにあるように感じました。

DDDをなぜ採用したのか？

特に気になったのはcommmuneさんは主に開発におけるコミュニケーションの齟齬といったユビキタス言語がユビキタスになってない問題の様でした。その齟齬を減らすこと、ユーザに提供するサービスや機能の取捨選択する上での根拠をドメイン知識やそれらから得たモデルを駆使して行いたいというところの様でした。
また、ドメイン知識を得た上でこれまで提供していないサービスを提供できるのではないか？その可能性も模索しているとのことでした。

この辺についてはDDDを採用したもののうまくいかないあるあるの様に思います。いわゆるドメインエキスパートとのコミュニケーションがなく、ソフトウェアエキスパートが頑張ってモデリングしているのと、アーキテクチャに注力してモデリングが十分になされていない故に開発メンバーにドメイン知識が浸透していない問題かなと。

DDDの導入の道筋

ログラスさん曰く、導入はDDD勉強会をやるとか鶴の一声的にいきなり導入するのではなく、例えばサービスクラスを見直しつつドメイン知識を分析しながらユースケースからコードのリファクタを行い、コードの責務と見通しの良さを実践して見せて、その後にモデリングを行い集約などからリファクタしていくといった部分的に変更し、そうすることのメリットを周知する努力を繰り返したそうです。

commmuneさんは、事業成果に直結する部分から取り組んでいるそうです。今のフェーズとしてはコアドメインを明確にしてそれを中心に導入しているとのこと。

尚、DDDを導入するにあたっては、今のコードに何かしら困っている（変更容易性が低くく改善や機能追加に時間がかかるなど）といった様な課題感が一致していない状況、例えば人によっては見通しが悪く辛いコードでも、また別の人によっては良いコードと思っていたりするとDDDの導入は難しいそうで、成功体験を繰り返し見せていくことでメンバーの認識を揃えることが重要な様です。

DDDの効果

ログラスさんはボトムアップでの改善の様なカルチャーは元々社内にあったものの、それぞれのチームが縦割として機能していたので横串で進められる様になったそうです。また、事業ドメインの理解=具体から事業のビジョン=抽象が行き来により事業的な視野が広がったそうです。

あと、アプリケーションの画面やプロトタイピングを見てデータをどう扱うか見やすくなったとも言われていました。

また設計標準（いくつかの設計案からベストなものをブレストして全員で決めていく）を設けることができる様になったなどコミュニケーションや指針の策定などに効果を発揮しているみたいです。

これはcommmuneさんも同様の様で、提供しているサービスの抽象度が高いが組織でそれを把握できる様になってきたため、顧客へのサービスの提供の仕方・最適化・新しいサービスのエンドポイントの創出にも繋がっているそうです。

所感

所感の前に自分たちことも踏まえると…。

自分たちはシードでありながら運よくそこそこ酸いも甘いも経験のあるメンバーが集まっていたり、CEOは間違いなくドメインエキスパートだったりします。足りないものはありますが環境はいい方ではあると思います。

また、そのメンバーのドメイン知識の量を揃えるために、Notionにドメイン知識から抽出した概念の辞書みたいなのを作っています。概念同士の関連はNotionのPage Mentionを使っていたり、いわゆる値オブジェクトに相当するものをページでそれぞれまとめ、概念の属性という形でリンクを貼っていたりします。必要に応じてER図に起こしたりもします。

ただ、これだけやってもドメイン知識の量はメンバーによって差があるし、全員揃えるにはリモートメンバーとかも入れると常に一定にはなりません。そういった点でのコミュニケーションの齟齬は何度も発生しています。

ただ、そんな風に齟齬があってもドメイン知識量の差があっても、コミュニケーションのベースに概念の辞書を置いているので軌道修正や知識量の引き上げがしやすいのはメリットとして感じています。

また、うちのCEOが紛うことなきドメインエキスパートでありますが、ドメイン知識をもとに開発陣と協業して概念を整理していく中で新たなる気づきがあり、それをサービスデザインとして昇華するなんてことが何度か起こっていたりもします。

つまり最も重要なのは「ドメイン知識」であり、それをどうメンバーで会得していくのか、どうコミュニケーションや実装として使うのかであり、その方法論やきっかけとしてDDDがあるのだなと改めて思いました。