はじめに
こんにちは、コミューンの中でSuccessHubというプロダクトの開発者をしている中野です。
SuccessHubは正式にローンチされてから1年半弱経過しており、開発初期からドメイン駆動設計を基に開発を進めています。この経験を通じて、コードベースのアプローチ以外の部分でも、開発者としての取り組みに関する課題や成功体験が浮かび上がってきました。今回はその一部を振り返りつつお話しできればと思います。（少し抽象的な話になります）
モデル同士の関係性がうまく表現できない
SuccessHubローンチ直後、新規プロダクト開発記 〜どうしたら業務知識をコードに落とし込めるのか〜という題のブログで、開発初期に苦労したモデリングについて触れました。当時はチームで共通言語を見つけ、正確なモデリングに努め、なるべく歪みのないモデルを構築しました。しかし、開発が進むにつれて、このモデルでは周辺のドメインとの関係性をうまく表現できなくなってきました。これには以下のような要因があるように思えます。
モデルが変化している
モデルは常に変化し、プロダクトの変化とともに周辺との関係性が変化したり、俯瞰して見た時の重要度が高まったりしていきます。特にアーリーフェーズのプロダクトでは、プロダクトの中心となるモデルが入れ替わったりモデルそのものの構成要素が大きく変わったりしやすいです。開発初期から携わっていて2年間で驚くほど変わりましたが、これはドメインがまだ成熟していなかったとも言えます。
これには、継続的でミニマムなリファクタリングが効果があり、継続してリファクタリングすることでモデルのそういった変化に気がつくことができるという実感があります。コードベースでは、ある意味継続的にリファクタリングを繰り返しながら開発できているからこそ早期に歪みに気がつけたのでその点は良かったのではないかと感じます。
ただし開発者がコードだけを注視して解決できる範囲には限界があると感じています。それがもう一つの要因に関連します。
共通言語が貧しくなってきた
新規機能を開発する際には、初めは意気揚々として概念や振る舞いについて名前を整理します。開発者単独では捉えきれない概念があれば、それに関しては詳しいエキスパートに質問を投げかけます。このようなアプローチで、以前のブログで取り上げたドメインも当時としてはベストな形でモデリングされたはずです。
前述したSuccessHubローンチ直後のブログでは、「カスタムフィールド」という概念に対して以下のようにしてモデルを捉えていました。
最初に中心となるモデルを考えます。
Q: カスタムフィールドとは何か？
A: カスタマイズ可能なテーブル UI 全体を指している。
しかしSuccessHubに機能が増えるにつれ、この「カスタムフィールド」の情報が他のあらゆる画面や機能から参照され始めます。具体的な部分についてはあまり触れませんが、例えば「どのようにカスタムされているか」が変数として他の画面や機能から参照されるようなことが起こり得るわけです。
こうなってくると、もう「カスタムフィールド」は「カスタマイズ可能なテーブル UI 全体」だけを指す言葉としては大きく膨らみすぎており、アプリケーション全体の中で見たときには、より大きな存在へと変化しています。その影響は開発者の会話やソースコード上などで表れ、次第に機能の追加や変更時に影響をもたらし始めます。
先ほど述べたように「モデルが変化している」ため、共通言語の探求も変化に追従する必要があります。もちろんこの機能自体の名前が変わるわけではないので、「カスタムフィールド」は残り続けるかもしれませんが、他の新しい言語を探す必要が出てくるはずです。
ただ、機能が完成してからは徐々にこのモデルについて、エキスパートと会話を行うことが少なくなっていました。これ自体は自然なことかもしれませんが、今振り返ると少しづつ開発者内だけで解決してしまうようなケースが増えてきてしまっていたような気もします。それにより、最初に作り出した共通言語はいつの間にか開発者専用の用語に寄っていってしまい、これがモデル同士の関係性を悪化させる要因の一部になったのではないかと考えています。
開発者としての姿勢
上記の課題に対処する前に、開発者としての振る舞い方についての見直しが必要だと感じました。「エリック・エヴァンスのドメイン駆動設計」 （以下、エヴァンス本）を読み直した折に、もう一度取り組みについて考えてみました。その際に注目すべき改善点がいくつか見つかったのでそれを以下に示します。
コミュニケーション
共通言語への取り組みを振り返ってみて思うことは、前述したとおり継続的な取り組みが欠けていたことと、もう一つあります。それはSuccessHubに関わるメンバー全員で使える共通言語を無理に作ろうとしたことです。
とりわけドメイン駆動がまだ浸透していない初期においては「みんなでこう呼ぶようにしましょう」といった強制的な形を取ることがありました。当然ながら、ビジネスサイドには顧客とやり取りする上で使う用語があり、デザイナーにはデザイナーの用語があります。その中でも共通の言語があるはずだからそれを探そう、という姿勢自体は間違っていないかもしれません。しかし、このようなコミュニケーションは理由を含めて理解が得られない限りはかえって意味のないやり方になっていた可能性があります。実際にこのやり方が良い効果をもたらすことは多くありませんでした。
ただし逆に言えば、なぜやるかを伝えた上で適切なスコープ内のメンバー間で普段の会話の言葉を統一してくことに意味はあると感じています。無理に多くの人を巻き込まずに、まずは開発者とプロダクトスペシャリスト。それから必要に応じてドメイン知識が豊富なメンバーとコミュニケーションを行っていく方が効率的なように思えます。
また、「開発者が言葉を整理するための活動に協力してもらう」という形ではなく、こちらがドメインを理解するために教えてもらうという姿勢を持つこと。かつ開発者が主導して行うことも重要な点だと感じました。エヴァンス本で挙げられているコミュニケーション例の多くも開発者側から質問を投げかける形式になっています。
技術だけで解決しようとしない
モデルの設計がうまくいかないときや、依存関係が不明瞭になっているときにコーディングの力だけで解決しようとしがちです。熟練されたモデラーであればそうではないかもしれませんが、私自身はまだまだ開発の作業に集中していると定量化可能な技術を好んで使いたくなってしまいます。 ただ、そこで立ち止まって「もう一度ドメインを捉えなおそう」「エキスパートにあたる人物と言葉の整理をしよう」という発想になれるかがより高いレベルのモデリングにおいて重要だと感じます。
ドキュメントに起こして満足しない
ドメインを整理するための会話は、目にみえる成果物がなくあまり生産的に感じないため、ドキュメントに起こして満足したり綺麗なドキュメントを作ることを目標にしてしまいがちです。
エヴァンス本でも書かれているように、図に起こして理解しやすくすることは大切ではありますが、開発者とドメインエキスパートの理解のためになるものであればどのような図でも構わないはずです。綺麗に整理された図に時間を割くよりも、コミュニケーションを増やしてその場の理解を深める方が重要なはずです。その過程での議論や洞察が、ドメインの理解をより深める手助けとなります。特にアーリープロダクトでは、モデルが成熟するまでは変化が激しいので、綺麗に整理されても気がついた頃には全く違うモデルになってしまっていることが多いです。
まとめ
エヴァンス本の中でも「ドメインエキスパートと開発者のコミュニケーション」について繰り返し説かれている箇所があります。 開発者主導でありながら、技術的な用語を中心に据えないようにするコミュニケーションやモデルを引き出すやりとりがまだまだ足りないなと感じています。
今後はコミュニケーション自体の理解度を大切にしていけるような継続的な取り組みを今後考えていきたいです。またその取り組みに進展があればブログにしようと思います。発展的な取り組みを行なっている開発者様やプロダクトスペシャリストの方がいらっしゃれば是非ご教授願いたいです。
最後に
コミューン株式会社では、Engineer、EngineeringManagerを絶賛募集中です! 記事を読んで、少しでもコミューンの開発にご興味を持っていただけたのであれば、是非カジュアルにお話できると嬉しいです!
