Alp開発日誌 Day8 「ドメインモデル勉強会」

先月、アルプが開発している サブスクリプションビジネス効率化・収益最大化プラットフォーム「Scalebase」 の正式リリースが出て、ありがたいことにたくさんお問い合わせが来ている状況です。開発も年末に向けて更に勢いがついているところで、チーム全体である動きが出てきました。アルプのドメインモデリングが大変という話を以前書きましたが、最近いよいよ 「ドメインの詳しいことはわからないけど、とりあえず目の前の仕事進める」 状態になり始めてきたのです。

blog.kaelae.la

ここで多少時間を使ってでもみんなのドメイン理解の足並みを揃えて進めようと決めました。そうして先日行った「ドメインモデル勉強会」が非常に良かったという話を書いていきます。最近は松岡さんが主催するドメイン駆動開発(以下、DDD)のコミュニティもでき、DDDを実践する土壌が整ってきてるので、積極的に現場のリアルを公開していきます。読んだ感想やアドバイス、体験談の共有お待ちしております！

※既に出ていますが、ここで使っている「ドメイン」という言葉はドメイン駆動開発のドメインと同義です

きっかけ

会社の成長とともに社員が増えていき、上記のブログでモデリングをしていたメンバーはどうしても あとから入るメンバーとドメイン知識の差 が生まれます。普段の業務では特定の問題の具体的なユースケースを考えればよく、ドメインモデルの一部情報だけを理解すれば進められることが多いため、ふとしたときに「なぜこうなっているのか？」「今話している問題を共通の認識で考えられているのか？」がわからない状況が目立つようになってきました。

例えば、アルプでは一部ドメインモデルの中に頻繁に現れる「周期」という概念があり、かつ周期の種類は数種類あって、コンテキストやモデルの状態ごとにそれぞれを使い分けています。身近なもので言えば「契約周期」で、携帯電話の料金プランでは プランの契約周期が24ヶ月 で契約更新やアップセル、ダウンセルなどが発生するといった用途で使います。

auの料金プランに登場する周期

参考: auデータMAXプラン Netflixパック| au

他にもいくつか周期があり、今は一体どの周期の話をしているの？みたいな会話がよく出てきました。こうしたドメイン知識の差が生まれた背景には、チームメンバーがそれぞれが固有の問題領域へ特化し始めたことも挙げられます。Aさんは契約関連の実装を担当する、Bさんは外部サービスとの連携部分を実装するといった具合です。これまでは一緒にモデリングをしていたメンバーであっても、実際のユースケースを解決するときに気付きドメインモデルの更新やブラッシュアップが行われるのが普通なので、 自分は知らない仕様 が少しずつ生まれていきます。そう、みなさんがよく知っている「顧客が本当に必要だったもの」の状況へと突き進んでいるのです。

顧客が本当に必要だったものの風刺画

参考: 顧客が本当に必要だったもの｜ニコニコ大百科

このような状況が少しずつ積み重なって、ある日 「XXXについては〜さんに聞いてね」 という状況になり、それ自身は仕方ないとわかっていながら、ドメイン知識が暗黙知化、仕事の分業化、属人化が進んでいきました。チームもコードと同じく、定期的なリファクタリングをすることで健全な状態を保ち、後々の自分たちへ大きな負債を残さないようにしようと考え、今回の勉強会を開催することに至りました。

勉強会の流れ

まずはNotionにアジェンダを書いて共有しました。平日に行ったので、通常業務との兼ね合いから二日に分けて行いました。

ざっくり分けると以下のような内容です。

• DDDについて
• アルプで行っているDDDの現状共有
• ドメインモデルの紹介
• 質疑応答

参加者は基本的に全社員、業務委託として関わってくださるメンバーにも公開で可能なら参加をお願いしていきました。

あとは発表者がスライドや自分が用意した資料を展開しながらアジェンダ通りの流れで進めました。Zoomなどのビデオチャットも繋げた状態で、ROM専のメンバーなどもいました。お菓子や飲み物を用意して、怖くない雰囲気にするのが大事そうです。

よかったこと

一通り発表が終わったあと、質疑応答のタイミングで早速勉強会の効果が現れました。普通の会話で正確なユビキタス言語が使われはじめたのです。DDDとはどういうものだという認識が全員の頭に共通認識として存在し、入社したばかりのメンバーからモデリングに関する質問や提案が出てきました。

既存のモデルのXXXはなぜここにあるんですか？実際のケースでは〜〜〜ということがあって、今の状態だと対応できないかもしれないです。

この瞬間、僕は感動しました。上に載せたドメインモデリングの記事でも紹介していた、 ドメインモデルの局所解に至っている問題 へのアプローチであるモデルの揺さぶりが目の前で行われたのです。

yukis.biz

エンジニア同士では実装について悩んでCRCを行うことでモデルの揺さぶりが可能ですが、あくまで実装の目線なので、他の視点や経験から得られる揺さぶりはこれまで体験してませんでした。

また、初期のモデリングメンバーもチームへの説明をすることで理解をより正確にできたり、リファクタリングのヒントを得られたりしました。実際に図にしたり、言語にすることで、システムのややこしい部分を目視できたり、ドメインモデル貧血症が起きてそうな部分があぶり出せたりしました。

今後もっとよくするべきこと

今回の取り組みで、前回のブログで問題として上げていた以下のことを解決できそうになってきました。

• 他のメンバーへの共有
• ビジネスロジックがほぼエンジニアリング(実装)な部分がある
• 専門知識によるモデルのブラッシュアップ
• ドメインモデルの局所解にとどまる
• 外部向けドキュメント

これらは勉強会を通じて作成された資料やノウハウがベースとなって、今後も開催していくことで解決できそうに思います。一方でまだ解決できない問題はあります。

• 資料のまとめかた、フォーマットの統一
• 実装と資料の乖離を埋める仕組みづくり
• ドキュメント管理コスト問題

これらはまだ解決策が明確にはなっていません。まだ本格的に開発をして一年も経っていないですが、メンテナンスできなくなったドキュメントや誰も見なくなったコンテンツが山程あります。ある程度は人力で解決できますが、ここの痛みを根本的に解決しないと、持続可能なものにはならないでしょう。この辺は各社どのような工夫をされているのか興味があります。

tips

本筋ではないにせよ、今回やってみて良かったtipsも紹介しておきます。

実況スレ

Slackで実況用のthreadを作成して、そこにワイワイ雑にメモしていくのが楽しかったです。Twitterでイベントに参加できない人がタグを眺めるような感じに近いです。流速は早いので、コンテンツに集中したい人はROM専がよいでしょう。

UMLを用いたライブモデリング

どのタイプの図を使っても良いのですが、クラス図、シーケンス図、ユースケース図みたいなものは簡単に書け、視覚的に情報の整理がしやすいのでライブモデリングがおすすめです。参加メンバーから「モデル間の関係理解がしやすい」といった意見が上がったので、やっておいて損はないと思います。ツールは何でも良さそうです。ホワイトボードの人もいればastahを使った人もいました。チーム全員でUMLを見ることに慣れると普段の議論も進めやすいです。

頻繁に参照したい概念はSlack botに仕込む

すごく地味なのですがめちゃくちゃ強力です。人に聞かなくてもいつでも参照できます。Slack以外のツールでも何かしら似たようなことはできると思うのでまずはユビキタス言語から始めてみてください。

余談ですが、Googleでは「良いレビューや良いコードの記述とはどんなものか」というコードの健全性について書かれたドキュメントがトイレに貼ってあるそうです。重要なことは何度でも見てしまう、目についてしまう環境作りが大事です。

動画撮影

対外向けではないので、ある程度準備不足でも挑める雰囲気にしておくのが良いと思います。準備に時間を費やしすぎると参加者が負担と感じてしまい、会そのものにネガティブな印象を与えてしまいかねません。ですが、アウトプットの資料が残らないとなると忘れてしまうので、せめて動画を撮っておいてアクセスできると嬉しいと思います。何度も見返せますし、非同期での参加、振り返りなど様々な用途で使えます。

ブログにする

これは僕が見たいからです。笑 というのは冗談で、社内の活動を公開することで興味を持ってもらえたりしますし、動画と同じくアーカイブとして様々な用途に使えます。

システムの複雑さを科学する

ここからは僕の雑談なので、読み飛ばしてもらって構いません。

僕らはよく「複雑なシステムです」と話しますが、「システムが複雑である」とは何なのかを考えていく上で、今回の勉強会は発見が多かったです。例えば、ビジネスロジックが複雑になっている部分を共有することで、 わかっている人が増えると複雑とは感じなくなったりします。 誰かの頭にしか無い（またはプログラム上にしかない）ことを共有するという行為は、自分たちの感じているシステムの複雑さを緩和するようです。

また、システム上に複数のコンテキストが存在し、ある概念または、 モデルが持つ情報や役割がコンテキストに応じて変わるときに複雑だと感じる ことが多いようです。今回の勉強会でも、似た情報を持ったモデルがこの場合は別なモデルとして振る舞うといった実装を説明するシーンで「難しい」みたいな声が上がるようになりました。特定のユースケースを解決するビジネスロジックに多数の前提条件が必要なときに複雑に感じやすいようです。

複雑さが判定できるようになってくると、因数分解をしてシンプルにするアプローチを考えやすくなりそうです。

---

以上です。年末に向けて開発も架橋ですが、気を抜かずにやっていきます！勉強会についてブログを書いてみて、この取組みの良さが他のチームでも再現できるのか気になったので、読者のみなさんの環境でやってみたブログや他のモデリング方法とかもぜひ知りたいです。

終わったら顧客が本当に必要だったものゲームで遊ぼう

顧客が本当に必要だったものゲーム - 反社会人サークル - BOOTH

アルプタグで開発日誌公開中

アルプの開発現場のリアルを綴っています。どんなチームが何をしているのか、ぜひ御覧ください。

ALP カテゴリーの記事一覧 - 道産子エンジニア

アルプで一緒にやっていきたいというメンバーを募集しています。興味のある方はぜひご連絡ください。

thealp.co.jp