「DDDもスクラムも当たり前」な開発者組織に入って気付かされたDDDの価値を出すための条件
この記事は 株式会社ログラス Productチーム Advent Calendar 2023 の17日目の記事です
こんにちは。ログラスでエンジニアをしております、南部です。
ログラスでは、当アドベントカレンダーの5日目の記事で紹介されていますように、「DDDもスクラムも当たり前」な開発組織が形成されています。
私は、今年の9月からログラスに入社していますので、上記の記事で紹介されているログラスのDNAを受け継ぐ側に当たるかと思います。
そしてちょうど直近で、DDDの文脈においてこのDNAの価値を感じる機会がありました。
実は、前職でもDDDっぽいコードを取り入れたりはしていたのですが、それによって特にメリットは得られておらず悩んでいました。
結論、原因は私の不勉強でDDDの価値を出せる条件となっていなかったということなのですが、それに気づく過程でログラスのDNAの重要性を感じました。
みなさんはDDDの価値を出すための条件をご存知でしょうか？
多くの人には当然と感じる内容かもしれませんが、この条件を肌感をもって気付けた経験が私にとっては勉強になるものでしたので、紹介させていただきます。
DDDとは
ドメイン駆動設計(Domain-Driven Design)の略です。
DDDは、ビジネスの核となるドメインを中心にソフトウェアを設計するアプローチです。
本記事を目に留めていただいた方の多くは、DDDの概要をご存知の方だと思いますのでこれ以上の説明は省略させていただきます。
気になる方は弊社の現LLMチーム/エンジニアリングマネージャーでもある松岡が多くの情報を発信しておりますのでご覧いただければと思います。
入社前のDDDの印象
冒頭で記述した通り、前職でもDDDのコードを書こうと思い立ち、新規の小さなアプリケーションにおいて意識したディレクトリ構成にしたりしていました。
当時、チームリードをしていた私は、大目標としてプロダクトをユーザーの課題を解決できる価値あるものにしたいと考えていました。
その中で、足元では以下のようなことに課題を感じていました。
コードを書く人によって品質にばらつきがある
コードの保守性が低い
便利関数を詰め込んだファイルが肥大化していく
これらを解決するために、最近イケてると噂のDDDを試してみよう！という軽い気持ちでろくにDDDの概論について勉強せずコードだけ書き始めていました。
実際に書いてみて、自分で開発していてそのほとんどを把握しているアプリケーションにおいては、ただ単にファイル数が多く、追いづらいコードになっているなという感想を抱きました。
しかし、今になって思い返しても、コードとしてはそれっぽくできていたと思うのです。
どうやったら世間で言われているように品質や保守性が高く、価値あるプロダクトにできるのか？というモヤモヤを抱えていたのがログラス入社前の私でした。
入社後に感じたDDDのメリット
前職ではDDDのメリットを感じることができなかった私ですが、ログラスに入社してから明確にメリットを感じることができました。
「コードに関して」の側面と「コード以外に関して」の側面があるので、分けてお伝えします。
コードに関して
性格上とにかくコードを読みたいというのもあり、入社してすぐにコードリーディングを行っていましたが、やはり前職で自分が書いたコードに感じていたようにファイル数が多く読むのには結局苦労していました。
そんな中、ドメイン的な理解やアプリの使い方の知識についてオンボーディングに関しても進んでいきます。
すると、不思議なことにお客様がプロダクトをどう使うかが見えてくるごとにコードが読みやすくなりました。
それどころか、実際のDBスキーマを見ていなくてもコードを読んでいるだけでDBスキーマまでが透けて見えるようになりました。
これは、明確にコードが以下のようになっていることに起因しているかと思います。
ユースケースごとに分離して書かれている
データ集約ごとにリポジトリが分離している
1度コツを掴んでしまうと、他のコードに関しても基本的にはするすると読めるようになりました。
また、コードが読めるようになるということは書けるようにもなります。
どこに何を書くべきかがエンジニア間で認識共有できていれば明確になるので、考える時間が減り、コーディングにかける時間が圧縮されました。
コード以外に関して
こちらに関しては大きく2点メリットに感じたことがありました。
まず1つが、リファクタリングが当然となる点です。
私の入社前の勝手な勘違いでは、一度モデルを作ったら追加はあれど変更はしないような認識をしていたのですが、DDDでは運用の中での発見をモデルに落とし込んでいくことが良しとされています。
そのため、開発のたびにモデルを見直すということを行います。
これは、継続的なリファクタリングを強制するような役割も担い、機能追加にあたってもコードの品質を落とさない動きができるというのはエンジニアにとって嬉しいことだと感じました。
一定の強制力があるので、継続的なリファクタリングが文化として根付くというのは非常に良いことだと思います。
そしてもう1つが、エンジニア以外も巻き込んでモデリングを行うため、お客様への価値提供に自信が持てる点です。
具体的なエピソードでお話しします。
ログラスのモデリングでは、PdMやデザイナーもモデリングに参加することがあります。
実際に入社してから、既存の機能への機能追加に際してモデリングを行い直すということをしましたが、この際にはPdMとデザイナーも一緒に行いました。
既存のモデルから発展させようとモデリングをしている際に、デザイナーから「今のままのUIだとユースケースと齟齬があるよね」といった話が出たことがありました。
確かに現状のUIに立ち返ってみると、ユーザーのメンタルモデル的に行いたい順番としてUIが適切ではないよねという話になり、改善のタスクとして挙がりました。
こういったユーザーのメンタルモデルとUIの齟齬のような部分はエンジニアではなかなか気付きにくい部分ですが、一緒にユースケースを整理する機会が生まれることでこういった違和感に気づくことができるのはありがたいと感じました。
また、ログラスでは複雑な会計ドメインの機能を開発しているため、ユースケース図を作成している時に「本当にこれがお客様のユースケースなのか？」という疑問が上がってくることもあります。
こういった場合、PdMが答えを持っていることもありますし、ドメインエキスパートであるCSとさっと連携して整理してくれることもありました。
総じて、自分が開発しているプロダクトが確実にお客様に価値を届けられるという自信が持てるのが私にとっては大きなメリットに感じました。
DDDの価値を出すための条件
前のセクションで、私が感じたメリットを記述しました。
このメリットを理解した上で、私が前職でこういったメリットを享受できなかった理由を考えました。
まず私の認識が違った点ですが、1番に感じたのは
DDDってコードだけで語れる話じゃない
ということでした。
前職での私の取り組みでは、私の小手先だけでなんとかしようしている感が強かったですが、ログラスに入って
エンジニアが開発をするのではない
組織全体でプロダクトを開発していく
という文化を強く感じました。
この違いがとても大きいと思っていて、DDDのメリットを享受する条件としては、組織全体でプロダクトを開発していく意識を醸成することが重要だったのだと認識しました。
これが条件であるという結論までに飛躍があるように感じる方もいるかと思いますので、こうなるまでの思考の過程を置いておきます。
ドメインのユースケースに沿ったコードを書きたい(要はDDDしたい！)
↓
ユースケースを深掘りしないといけない
↓
モデリングをしたい(特にユースケース図)
↓
エンジニア以外の知見が必要不可欠
↓
エンジニアがドメインエキスパートと連携を取れないといけない
↓
それが可能な組織である必要がある
必要なものを深掘りしていったら組織だった、という形です。
まとめ
今になって思えばですが、入社前の私はDDDっぽいコードを書くことが目的となっていました。
どこかで、DDDのコードを書けば、魔法のように品質や保守性の高いコードが書けるのだと勘違いしていたのかもしれません。
この誤解は、DDDの定番書であるエヴァンス本を理解していれば初めから起き得なかったのかもしれません。
しかし、今回私は実体験を持って前述のDDDの価値を出すための条件を自分の血肉とできたことに価値があると思っています。
そして、裏を返せばDDDで価値を出すには組織文化の醸成から行わなければなりません。
これはかなりハードルの高いことだと思いますが、初期の段階からこの文化を醸成していたログラスのDNAというものはプロダクトの品質を向上していくためにも受け継いでいくべきものだなと感じています。
入社してまだ日が浅いですが、ログラスのDNAを引き継げるような人材になっていけるよう精進していこうと思います。
We Are Hiring!!
本記事を読んで
DDD導入したいけど組織から作るの辛い！
と感じていたそこのあなた！
ログラスにはすでにその組織があります！
そしてログラスはエンジニアを絶賛採用中ですのでご興味あれば求人をご覧いただければと思います。
カジュアル面談も大歓迎です。
それでは本記事は以上になります。
明日のアドベントカレンダーは、食へのこだわりがものすごい龍島さんによる記事です。お楽しみに！
この記事が気に入ったらサポートをしてみませんか？