sumirenです。
経営管理（事業計画作成、財務Modeling）SaaS「Zaimo.ai」を開発するZaimo株式会社で、技術顧問としてドメインモデリングや組織設計のアドバイザリを行っています。
Zaimo.aiでは、スケール後もドメインモデリングを事業全体で活用できるよう、創業間もないフェーズからドメインモデリングを組織的に活用するカルチャーづくりに励んでいます。
ドメインモデリングというと、DDDのような重厚なプロセスを想像される方が多いかと思います。同時に、技術が目的と化している熱狂的DDDファンも少なくないことから、ドメインモデルというワード自体に拒否反応を覚える方もいると思います。
しかし、ドメインモデリングはもっと手軽に使えるものであり、エンジニアリングのみならず、事業全体にインパクトをもたらしうるものと筆者は考えています。この記事では、そうしたドメインモデリングに関する筆者の考えを紹介します。この記事では技術の話は登場しません。むしろ、エンジニア以外のロールにこそ、この記事が届いてほしいと思っています。
この記事の内容はあくまで筆者の見解であり、特定の既存手法について解説するものではありません。ぜひ、共感してもらえる部分だけでも取り入れてもらえれば幸いです。
要約
- 事業組織全体でのコミュニケーションやキャッチアップのオーバーヘッドは、プロダクトやサービスのメンタルモデルが事業組織内で統一されていないことで発生している
- ドメインモデリングをビジネスプロセスの手法として事業組織全体で活用することで、より生産的に、より質の高いサービスを提供できる
- ドメインモデリングにおいて重要なのは、営業、CS、ドメインエキスパート、エンジニアなど、異なる立場の人々が対話し共創すること、そのカルチャーを維持することにある
- 事業組織内の一人ひとりがドメインモデリングを身近に感じた状態を作ることを最優先で目指し、ハードルを下げて始めよう
1. ドメインモデリングが解決する課題
1-1. よくある状況
昨今の自社サービス企業であれば、プロダクトを創り、運用する中で、様々なステークホルダが関わることかと思います。プロダクトマネージャ、デザイナー、ドメインエキスパート、営業、CS、エンジニアなどです。事業特性次第で、追加のロールや存在しないロールもあったりするでしょう。
例えば自分がドメインエキスパートだとして、担当しているプロダクトのある機能について、どういう改修がしやすいか想像がつくでしょうか。機能を追加したらどこに影響かでそうか想像がつくでしょうか。
また、プロダクトの仕様に関するコミュニケーションについて、自分が考えた仕様をエンジニアが言い換えたり、営業などの他のビジネス職と用語が合わなかったりしないでしょうか。グロースとともに次々入ってくる新規メンバは、プロダクトの仕様にすぐキャッチアップできているでしょうか。
このセクションを読んでピンとこない方は、この記事を読む必要はないかもしれません。こうした課題が発生しづらい事業ドメインなどもあるでしょう。もし、このセクションを「たしかに、機能追加の影響もいつも分からないし、コミュニケーションにも齟齬が起きがちだな」と心当たりがあるようでしたら、読み進めてもらえると嬉しいです。
1-2. 事業組織内でメンタルモデルが統一されていないという課題
なぜ、こうした状況が発生するのでしょうか。筆者は、チーム内でプロダクトや機能のメンタルモデルが統一されていないからだと思っています。ここでいうメンタルモデルとは、細かな仕様ではなく、1つ1つの概念の意味定義や概念のつながりであり、プロダクトや機能の骨格を成します。
例えば、ECサイトでお客様個人に紐づく「クーポン」の機能の開発コストを判断したいとします。関連しそうな機能として、既存サービスには「プロモーション」の概念があり、「セール」は既にこの一種として扱われているとします。このとき、開発の期間や影響範囲を決めるのは、おそらく「クーポン」がこの「プロモーション」の概念とスムーズに馴染むかどうかでしょう。
これが、メンタルモデルがプロダクトの骨格を成すということの意味であり、メンタルモデルの統一が重要である理由です。細かな仕様まで押さえていなくても、こうした重要な概念間のつながりが事業組織内で共通認識となっていれば、誰でも開発インパクトの仮説をある程度立てられるようになります。「あなたが言うプロモーションにはセールは含まれていますか」といった生産性の低いコミュニケーションも不要になります。新規メンバも、骨格を要領よく押さえることができれば、立ち上がりを高速化できます。
都合の悪いことに、メンタルモデルは放っておくとすぐバラバラになってしまいます。例えば、非エンジニアは、エンジニアリングに踏み込むことを遠慮しがちです。エンジニアは、技術を指向する気持ちや視野の狭さから、独自のモデルを作り上げてしまいがちです。組織がスケールすれば、チームをまたいだコラボレーションも相対的に少なくなっていきます。下記図解のように事業組織内のメンタルモデルがまちまちな状態から脱却するには、特別な努力が必要です。
【ステークホルダ間でメンタルモデルが整合していない図】
1-3. ドメインモデリングというソリューション
前セクションで議論の対象としたソフトウェアのメンタルモデルのことを、この記事ではドメインモデルと言います。あえて言葉の意味を定義するなら、「事業の問題領域への見方をモデル化したもの」と言えます。ドメインモデルは、技術指向のモデルではなく、概念のモデルです。そのため、ドメインモデルにはエンジニアだけでなく事業組織内の全メンバが関わることができます。
前セクションで述べた通り、ドメインモデルは放っておけばバラバラになっていきます。エンジニアは好き勝手なモデルを思いつき、非エンジニアはサービスの輪郭をメリハリをもって捉えられず行き当たりばったりといった、ドメインモデル不在の組織になるでしょう。実際、多くの企業がそのような状態に陥っていることでしょう。
もし、異なる立場の人たちが協働し、このドメインモデルを事業組織全体で創り育てられたとしたらどうでしょうか。
例えばECサイトを作るとします。「お客様」「商品」「購入」といった素朴な概念は誰でも洗い出せるかもしれませんが、ドメインエキスパートや経営企画などが参加していれば、それぞれ自分の専門性を発揮し、「自社のビジネスモデルでは利用規約同意は注文単位で取るべきかか」「近い将来他社とコラボする際に大きな手戻りはないか」といった論点を投じられるでしょう。こうした協働を経て、ドメインモデルはより豊かになりますし、事業組織内でのドメインモデルの同期も可能になります。
また、そうした場にソフトウェアの専門家であるエンジニアがいることで、そのモデルにソフトウェア的な実現性があるかを検証できます。ドメインモデルはビジネス価値とソフトウェア的な実現性のバランスを取ることができるようになります。その結果、事業組織全体で共有可能なドメインモデルに仕上がります。
このように、ドメインモデルを異なる立場の人たちが協働して作ることで、事業組織内のドメインモデル統一はもちろん、その過程でバリューチェーン全体の生産性と質の向上、対話による組織のクリエティビティ向上まで得られます。筆者は、こうした取り組みにより、圧倒的にサービスエンジニアリングに強い事業組織を創ることができると考えています。
この記事では、こうした事業組織全体を巻き込んだドメインモデル創造のプロセスを、ドメインモデリングを呼びたいと思います。
【ドメインモデルが事業組織内に浸透している図】
ドメインモデリングを事業組織全体に浸透させられた理想的な状態では、仕事のやり方が以下のように変わると想像できます。
- プロダクトマネージャやドメインエキスパートは、ドメインモデルに登場する概念や言葉遣いで要求を定義するようになる
- エンジニアは開発中にモデルの矛盾に気づいたら、勝手に独自の実装モデルを生み出すのではなく、ドメインエキスパートに声をかけてドメインモデルを見直すようになる
- CSや営業なども含む、あらゆる社内のステークホルダ間のコミュニケーションの中で、ローコンテキストなドメインモデル上の言葉遣いが飛び交う
- 誰もがアウトプットの一形式としてFigmaやGoogle Slidesに保存されたものを参照する
- 新しくジョインしたメンバは、些末な仕様に煩わされることなく、ドメインモデルからプロダクトや機能の全体像・骨格を掴み、既存メンバの頭の中にあるものと同じモデルを素早く得ることができる
ドメインモデリングで最も難しいことは、モデリングテクニックの習得ではありません。ドメインモデリングを通じて対話に取り組み続けること、それ自体です。エンジニアが技術的な正しさにばかり固執したり、非エンジニアがビジネス上のフォースを押し付けたりすれば、対話は途絶えてしまうでしょう。
究極的には、1つ1つのドメインモデル上の意思決定など、大抵の場合はどちらでも良いのです。異なる立場の人たちがドメインモデルを積極的に共創し続け、意見が割れても対話を通じて納得に至るカルチャーを根付かせることが重要です。
2. 事業組織全体で取り組むドメインモデリングのすすめ
ここまでで、事業組織全体をエンジニアリングに強く生産的な組織にするために、ドメインモデリングが必要であることを説明しました。
このセクションでは、ドメインモデリングの始め方について筆者の考えを説明します。各ステークホルダがどのような心構えで、どのような事業活動上のイベントにおいてドメインモデリングに臨むべきでしょうか。各モデリングの場はどのように進行し、どのようなアウトプットを出すべきでしょうか。そうした導入方法を具体的に議論します。
実のところ、事業全体で体系的にドメインモデリングに取り組める状態にするまでの道のりは、筆者にも見えていません。デザインとドメインモデルではどちらが上位概念でしょうか。事業組織のいたるところで育てられたドメインモデルを、どう統合してナレッジ化すればよいでしょうか。そうしたレベルにまでドメインモデリングを昇華した経験は、筆者にもありません。
しかし、それは問題ではないと思っています。前のセクションでも述べた通り、最も価値があるのは、異なる立場の人たち一人ひとりがドメインモデルを積極的に共創し対話するカルチャーそのものだと筆者は考えているからです。そのカルチャーがボトムアップでエンジニアリングに強い事業組織を育て、全ての活動の生産性と質を底上げします。
したがって、基本方針は、手法などの技術的なハードルは極力下げ、事業組織内の対話に注力することです。事業組織内の一人ひとりがドメインモデリングを身近に感じている状態を作れれば勝ちだと筆者は考えます。そうした方針を念頭に置きながら読んでいただけると幸いです。
2-1. ドメインモデルの図解
ドメインモデリングの経験がない方からすれば、ドメインモデリングの具体的なアウトプットが知れたほうが、イメージが湧くと思います。そのため、順番が前後しますが、まずはこの論点から始められればと思います。
最初に伝えたいのは、ドメインモデルは図解ではないということです。ドメインモデルとはメンタルモデルそのものであり、無形のものです。図解はあくまで表現方法です。例えば、「ユーザーが休会していたらイベントを申し込めない」といった関係性を図解で表現するのは難しいですし、そもそも「イベント」という概念の意味すら、図上では簡単には伝えられません。
それでも図解は、概念間の大まかな関係や、概念の名前といった全体像を一目で伝えることができます。図解はドメインモデルの射影であるということさえ忘れなければ、便利に図解を使うことができます。
Zaimoでは、エンジニアやPdMが集まってゼロベースで議論をし、最終的なアウトプットとして図解にまとめています。既存機能の拡張であれば、既存の図解をガチャガチャといじりながら、新しいモデルの形を模索します。
以下に、例として実際にZaimo.aiで利用しているドメインモデルの一部の図解を添付します。残念ながら本物は公開できないため、概念の名前や文言は適当に置き換えていますが、図の形や付箋の使い方などはそのままです。中身を読み解くというより、アウトプットのイメージと捉えていただければと思います。
一般には、UMLクラス図という記法をベースに、独自にカスタマイズして図解されることが多いかと思います。エンジニアリングをかじったことがある非エンジニアの方には、ER図に近いといえば馴染み深く感じられるでしょうか。
ふきだしや色づけで開発の状況や論点を表現しているのは、Zaimo.aiで筆者がカスタマイズしているポイントです。この図上にも負債であったりうまくモデリングできていない部分もありますが、それで良いと考えています。記法や完成度にこだわらず、便利に普段使いするのが筆者の好みです。
ここではUMLクラス図の読み方については割愛します。クラス図について詳しく知りたい方のために、参考になるリンクを載せておきます。なお、この参考資料ではソフトウェア設計にも利用できるようクラス図の仕様全体を詳細に説明しています。ドメインモデリングの図解におけるクラス図はあくまで記法のベースなので、例示したように簡潔に使って構いません。
参考：Lucidachart 5分でわかる、UMLクラス図とは？ 書き方もご紹介
最後に、UMLクラス図をドメインモデルの図解に使う上で、筆者が大事にしているTipsを簡単にまとめておきます。
- 概念間をつなぐ線に、関係を書き込むこと。できるだけドメインの言葉で書く
- 些末なことは書き込まず、重要なことだけに保つこと。些末な概念や。1対Nといった関連の数字も、自明なら削る。あくまで図解はモデルの射影なので、完全である必要はない
- 重要な制約をどんどん付箋で書き込むこと。例えば先程の「イベントを申し込めるユーザーは休会していない」など
図解は目に止まりやすいかもしれませんが、重要ではありません。あくまで、一番の成果は図解ではなく、議論を通して一人ひとりの脳内にインストールされた共通のドメインモデルであり、異なる立場の人たちが協働でドメインモデルを議論するカルチャー自体が重要です。この議題から始めたのは、目に見えるアウトプット例が最初にあったほうが親切だと考えたからです。
2-2. ドメインモデリングに臨む心構え
ドメインモデルは、ビジネス価値とソフトウェアにおける実現性の両方を満たすものでなければなりません。ソフトウェアを軽視したドメインモデルではエンジニアは実装時にソフトウェアのための独自のモデルを生み出してしまいますし、ビジネス価値を軽視したモデルでは当然ながらプロダクトの価値を損ないます。
そうしたバランスの取れたドメインモデルを創り育てる上では、異なる立場の関係者一人ひとりが、お互いにリスペクトを持ち、歩み寄ってドメインモデリングに向き合う必要があります。
顧客からの距離が近い方々が持つべき心構え
まず、ソフトウェアからの距離が遠く、顧客からの距離が近い方についてです。これはCSや営業などが当てはまるでしょう。デザイナーやドメインエキスパートもどちらかといえばこちらかもしれません。
顧客からの距離が近い方々が持つべき心構えは、端的に言えば「エンジニアリングに踏み込む」ことです。もちろん、ビジネス価値に寄りすぎてソフトウェア的な実現性を軽視しないことは重要ですが、それは言うまでもないことでしょう。よりはまりやすい落とし穴として、モデリングの主役がエンジニアであるように感じて遠慮してしまいがちだということです。
ドメインモデリングは事業に携わる全員が主役です。もちろん最終的にはソフトウェアで実現できるようソフトウェアからの距離が近い方も納得がいくモデルに落とし込む必要がありますし、思考方法や図解になれないうちはエンジニアにファシリテーションを任せがちかもしれませんが、だからといって自分が脇役というわけではありません。
顧客からの距離が近い方々が違和感を感じない言葉遣いや概念の関連に落とし込み、ビジネス価値を自然に実現することは、ソフトウェアで実現できるモデルを作ることと全く同じだけ重要です。ぜひ、萎縮することなく自信を持ち、対等な立場として議論をしてみてください。
※このセクションでは顧客からの距離が近い方々と、ソフトウェアからの距離が近い方々というステレオタイプに分けていますが、あくまで便宜上のものです。
ソフトウェアからの距離が近い方々が持つべき心構え
次に、ソフトウェアからの距離が近い方々についてです。これはエンジニアと同義かもしれません。組織設計や個々人のスタイルによっては、プロダクトマネージャやCTOもこちらかもしれません。UXデザイナーも、エンジニアを兼務している場合はソフトウェアからのほうが距離が近いかもしれません。
ソフトウェアからの距離が近い方々が持つべき心構えは、顧客からの距離が近い方々をドメインモデリングにおいて活躍させることです。モデリングをエンジニアの聖域と考えず、民主化しましょう。開発中も独りよがりでモデルを変更したり独自のモデルを作るのではなく、非エンジニアを巻き込みましょう。
もしかすると、最初は組織の練度が低いことで、手に入るモデルはエンジニアリング的に100点満点ではないかもしれません。ソフトウェアの専門家だけでやったほうが、質もスピードも高いかもしれません。しかし、そんなことはどうでもいいことです。最もインパクトが大きく、最も難しいのは、事業全体でドメインモデリングに取り組むカルチャーの醸成そのものだからです。そのインパクトに比べれば、モデルに負債ができたり、ソフトウェアでぎこちないCRUDが発生することなど、誤差だと考えます。
モデルの質を高めようとするのは、ドメインモデリングに事業組織全体で自然と取り組めるようになってからでよいと筆者は考えています。
2-3. ドメインモデリングのはじめ方
心構えを持ったとしても、実際に事業組織全体の仕事のやり方を変えるというのは大きなハードルが伴います。きっかけを作らなければドメインモデリングが行われることはないでしょう。きっかけを作ったとしても、それが非日常のイベントであったとしたら、すぐに忘れられてしまうでしょう。
ドメインモデリングを事業組織内に浸透させるというのは、誰でも日常的にドメインモデリングを行っている状態を作ることを意味します。この状態を作るためには、まずは業務上のイベントをトリガーにしてドメインモデリングを行うのが良いと筆者は考えています。
このセクションでは、そうしたドメインモデリングのトリガーをいくつか提案したいと思います。筆者は直近ではZaimo.ai含めてtoBのSaaS企業を多く支援していますので、ここで挙げる例はややtoB事業の組織に偏っているかもしれません。
要求定義やデザインの際にドメインモデリングしてみる
プロダクトマネージャやドメインエキスパートが関わって要求を定義する際にセットでドメインモデリングする癖をつけることは、最も王道だと思います。ちょうど要求を定義しているところなので、ドメインモデルを踏まえて要求を書き直すことができます。
エンジニアも一緒にドメインモデリングに参加するとよいでしょう。エンジニアがその場でソフトウェア的な実現性をチェックすることができるからです。
組織によっては、要求を定義するまえにデザイナーが入り、ドメインモデリングに近しいプロセスを行うかもしれません。その場合は、その活動にドメインモデリングのプラクティスを取り入れれば良いと思います。
既存機能を確認する際に既存機能をモデリングしてみる
経営企画の戦略検討や営業の商談の中で現状のプロダクトの機能を確認したくなることがあると思います。そうしたときには既存機能に対してドメインモデリングを活用しやすいかもしれません。
モデリングに慣れている方がいればエンジニアは不要でやっても良いかもしれませんし、エンジニアがいれば、機能追加の話に及んだ際にas-isのモデルをもとに皆でto-be像を描けるかもしれません。
顧客から問い合わせを受けた時のコミュニケーションを見直してモデリングしてみる
CSが顧客からの問い合わせを受けたようなときには、おそらく急いでコミュニケーションを取っていることかと思います。その場でドメインモデリングをしている余裕はないかもしれません。
その代わり、定例を組み、問い合わせを受けた際の社内コミュニケーションで苦労したものをSlack上やサポートチケットから取り上げて、振り返りながらドメインモデリングをしてみると良いかもしれません。コミュニケーションした相手（エンジニアであることが多いでしょう）やその機能を作ったエンジニアを定例に招待すると良いと思います。
簡単な既存機能を皆でモデリングするワークショップをやる
やはりハードルが高いのは最初の数回だと思います。そこで、モデリングの進め方や図解の切り口を知るために、5〜10人で既存機能のモデリングをやってみるというのは、良いアプローチかもしれません。
このとき、最優先は全員がモデリングに興味と成功体験を持てることです。難しい機能では、モデリングがスムーズに進まず苦手意識が生まれてしまうリスクがあります。ドメインモデリングのカルチャーを事業全体に浸透させることができれば、自ずと難しい機能も事業組織内のいたるところでモデリングされるようになります。ワークショップでは簡単な機能を取り上げましょう。
補足：Zaimo.aiでの導入状況
このセクションで紹介したアプローチのうち、実際に筆者が試せているものは半分程度です。Zaimo.aiでは要求仕様の定義時にドメインモデリング、モデリングのワークショップに取り組んぢます。
Zaimo.aiではまだCEOがドメインエキスパートや営業やPdMを全て兼ねているので、形式張った仕組みなしに日常使いできているという側面もあるかもしれません。はじめから文化を作っておくことで、ビジネス職が増えた後も自然とドメインモデリングに向き合えている組織を作るという戦略です。
ぜひ、色々試していただいて、事例を発信していただけると嬉しいです。
2-4. モデリングプロセス
2-1.ではドメインモデリングの場の出口、2-3.ではドメインモデリングの場の入り口を説明したつもりです。それでは、実際には1つ1つのモデリングの場において、どのような流れで作業を進めればいいのでしょうか。
ドメインモデリングは一般的には重厚なプロセスで説明されることが多いかと思いますが、そうしたやり方は、100点満点中90点のモデルを、エンジニアがリードしてワンショットで作り切るためのもののように筆者には思えます。
当然ながら、そうした世界観は筆者の目指すところではありません。60点でいいから事業組織全体で取り組むこと。そして、ワンショットではなく日常的に取り組み続けることが重要と考えています。そのため、極力ハードルを下げ、心理的負担なくカジュアルに行えることを重視すべきだと思っています。
ドメインモデルのスコープ
ドメインモデルはどの単位で創るべきでしょうか。プロダクト1つに対して大きなドメインモデルを1つでしょうか。あるいは機能の単位で創るべきでしょうか。
これは最初は深く考える必要はないというのが筆者の見解です。気になっている機能の周辺を適宜モデリングすれば良く、書いた図解に重複があって構いません。図解は副次的な成果物であり、主要な成果は一人ひとりの脳内にインストールされたドメインモデルだからです。さしあたってはGoogle SlidesやFigJamなどにまとめておいて、折にふれて図解を参照したり修正できる程度でよいでしょう。
もし事業組織全体でドメインモデリングに取り組むカルチャーが確立でき、その質にこだわるフェーズに入ったとすると、この論点に含まれる2つの難しさに向き合ってみてもいいかもしれません。1つはドメインモデルをいくつに分けるか、いくつの視点からプロダクトを構成するかという問いです。3-3.で詳細に触れていますので、ここでは割愛します
もう1つは、1つ1つのドメインモデルについて、どう図解を効果的に取りまとめるかという問いです。こちらは、正直なところ筆者にもまだ確信はありませんが、FigJamのような無限に広がるタイプのホワイトボードツールを使い、視点ごとといった形でスライドの単位を決めてメンテナンスしていくことになるのではと考えています。
モデリングの具体的な作業内容
例えば請求機能のドメインモデルを今いちど認識統一したくなったとします。上記のスコープの考え方に倣い、皆で話して周辺機能含めてカジュアルにモデリングしてみるとよいでしょう。それでは、具体的にどのようにモデリングの場を進めればよいでしょうか。
先述のように、一般的な（狭義の）ドメインモデリングは、ユースケース分析やイベントストーミングなど、重厚なプロセスとして説明される場合が多いですが、当然ながら筆者はそうした手法にいきなり飛びつくことは推奨しません。
筆者がよくやるのは、2-1.で紹介したようなクラス図ベースの図解をゼロベースで作ることで、その過程で参加者の中でドメインモデルが統一する進め方です。例えば以下のような単純なプロセスです。
- FigJamなどのブレストツールを真っ白な状態で用意する
- モデリング対象周辺でよく出てくる用語をブレストで出し、箱として脇に書き出していく
- 箱1つ1つについて議論して整理していく
- 揺れがある呼び方や同じ概念は統一し、箱の数を減らす
- 振る舞いや状態を表すものは、概念の属性にしたり、制約として図解上に直接書く
- 他の概念と関連を持つ概念は線でつなぎ、線の上にどういう意味合いの関連なのかを書く
- 概念の意味の統一が取れないときは、並行して概念集のようなもので言語化する
- 都度、色分けや吹き出しなどで現状と理想のギャップなどを表す
- 例えば現状は黒で書き、これから作ったり改善する部分は赤にする
- モデリングがいまいち納得いかない部分はふきだしにするなど
- 一通り箱を整理できたら（あるいは膠着したら）、ウォークスルーしてみる
- 「テナントの実態である"A社"にユーザーが"◯◯さん" "xxさん"がひもづいていて...」といった形で、概念を実体化させて違和感や矛盾がないか検証する
この程度のプロセスであれば、事前準備なしで誰でも日常的に行えると思います。重要なことは、非エンジニアが主役になれること、日常的に事業組織のいたるところで行われることです。そのために、形式張らないことや、（特に大人数の場合は）事前のたたき台で結論に誘導してしまわないことを推奨します。
再三ですが、あくまで図解は手段であり、ゴールはドメインモデルがその場において統一されたと全員が納得できることです。極論、図解がなくても構いません。その場にいる人のドメインモデルが統一されていれば、人づてなどにより組織内に共通認識が広がることも期待できるからです。参加者全員の心の中のドメインモデルのほうが図解よりも豊かになっている状態が目指すべきゴールです。
3. ドメインモデルとは何であり、何でないか
記事の最後であるこのセクションでは、ドメインモデルとは何かという問いを探求します。
このセクションは付録に近いものです。興味がわかない限り、このセクションは飛ばしていただいて結構です。モデリングテクニックは、高いに越したことはありませんが、必須ではないからです。この章を読解するより、ドメインモデリングを始めてみることのほうがずっと重要です。難解かつ技術的な話も少々出てくるため、読まれる方も全てを理解する必要はありません。
このセクションには、ドメインモデリングに関する筆者の個人的な思想と洞察を詰め込みました。内容は時代の最先端かもしれませんし、ゴミかもしれません。そこも含めて判断いただけたら面白いと思っていますし、筆者としては少しでもひらめきを与えることができれば嬉しいです。
本題に入ります。ドメインモデルとはなんでしょうか。この問いは深遠で、簡潔には答えることは難しいです。このセクションでは、4つの思考実験を通じて、ドメインモデルとは何であり何でないか、輪郭を浮かび上がらせたいと思います。
3-1. ドメインモデルは現実そのものではなく、特定の視点から現実を写した写像である
ドメインモデルとは現実そのもの、ドメインそのものでしょうか。先程の例でいえば、「本」は現実に存在します。現実をありのままに描くことがドメインモデリングなのでしょうか。明らかに違います。それでは、ドメインモデルと現実とは、どのような関係なのでしょうか。
モデルとは、特定の視点から現実を見た時の見え方のことです。リンゴを上から見るのと横から見るのとでは見え方が違うように、書籍レビューサイトと図書館内システムでは、現実を見ている視点が異なるのです。書籍レビューサイトの視点は書籍レビューサイト専用のドメインモデルを生み出し、その中には独自の「本」の概念が含まれています。その「本」の概念は、現実の「本」に対する見方の一種です。
現実世界の「本」を説明するためには、Wikipediaのような情報量が必要になります。しかし、書籍レビューサイトのドメインモデルにおける「本」は、「書籍の種類を指し、ユーザーがレビューできる」と一文で説明できます。このようにドメインモデルとは、現実を事業の色眼鏡に通し、都合よく解釈したものであるべきです。いらない情報を削ぎ落とし、重要な意味定義や関連のみにフォーカスすべきです。
次の思考実験は、ドメインモデルが重要なものにフォーカスすべきであることを裏付けます。
3-2. キャッチアップが難しいのは、現実ではなくドメインモデルである
事業組織に新しいメンバがジョインしたとします。このメンバはキャッチアップに苦しんでいるようです。「ドメインが複雑だから仕方がない」で済ますのは簡単ですが、何がキャッチアップを困難にしているのか考えてみましょう。
キャッチアップが難しいのは、事業が向き合っている現実世界でしょうか。それともドメインモデルでしょうか。
SaaS提供のようなエンジニアリングをコアとする事業においては、圧倒的にドメインモデルであると筆者は考えています。例えば書籍レビューサイトを操作していて、「本を登録」が出てきたとします。この「本」の意味が分からないとしたら、それは現実の「本」ではなく、現実に対するこのプロダクトの独自の視点が生み出した、ドメインモデル上の「本」の概念でしょう。現実世界の「本」という複雑で機微なニュアンスを持つ概念を、このプロダクトがどのような視点で見て、どう簡潔に意味を切り取ったか。それを理解することが難しいのです。
もし、この組織のナレッジベース上に「本とは：任意のユーザーが本を登録することで、ユーザーがレビューをつけられるようになる。本1冊ではなく本の種類を表す。」といった形でドメインモデル上の概念が定義されていれば、キャッチアップはずっと容易になるでしょう。このドメインモデルにおいては、現実の本がページ1枚1枚から構成されることなどはどうでもよいことであり、そうした情報を捨てることで生まれるメリハリが理解を助けます。モデリングとは、捨てることであるとも言えます。
3-3. プロダクトにドメインモデルが複数あってもいい
ECサイト事業者にとってのドメインモデル上の「商品」とはなんでしょうか。お客様の購買やレビューに紐づくでしょう。在庫には商品バリエーションが関わります。配送時の梱包の方法も商品ごとに違うとすれば、配送にも関わるでしょう。事業会計上は棚卸資産としても登場するでしょう。
このECサイトの「商品」は、事業にとって必要な意味を切り取ってドメインモデル上に定義しても、まだ複雑です。このような場合には、1つの事業やプロダクト内をドメインに対する複数の視点で構成し、視点ごとにドメインモデルを育てることもできます。
この図解において注目すべき点は、複数の視点が見つめる現実世界の範囲に被りがありつつ、見ている角度が違うということです。先程の例の商品が、まさにこの被りの部分に存在します。商品という現実の物事は、複数の視点から異なる角度で見られ、それぞれのモデルの中に独自の写像として表れます。このように、複雑な商品という物事を、いくつかの概念に分けて整理できるようになります。
視点をどういうアプローチで定めればよいのかは、とても本質的で難しい疑問です。視点の構成を決めることもドメインモデリングの範疇であり、個別の視点の中でドメインモデルを育てるのと同じくらい創造的な活動です。泥臭く前に進めやすい個別ドメインモデルの作成に比べ、視点の創造はアートにも近い性質があり、よりとっつきづらいかもしれません。
視点創造の指針について、この記事では筆者の考える注意点を3つ挙げるにとどめます。1つ目は、実際に事業を構成している「物事の見方」になっていることです。例えば、同じ商品でも、Eコマースの商品と在庫管理の商品では、概念が異なるでしょうか。事業における関心事が違うでしょうか。関わる人（アクタ）が異なるでしょうか。そうだとしたら、「Eコマース」と「在庫」は視点の候補です。
2つ目は、1つ1つのユースケースがより少ない視点に収まることです。例えばECサイトにとって「ポイント」は視点でしょうか。筆者ならそうはせずに始めます。ポイントの使用や付与が注文とセットで発生するとしたら、ポイントの視点単体でカバーできるユースケースが存在しないと思われるためです。こうした横割りに視点を分けるアンチパターンは、エンジニアのほうがやりがちかもしれません。
3つ目は、それぞれの視点が対象とするドメイン範囲の重複部分が小さく、重複の中にある物事を異なる概念として写していることです。例えば、Eコマースの視点を、購買体験の前半と後半で、さらにエンゲージメントとコンバージョンの2つの視点に分けるとします。もし、これらの視点が対象とするドメインの物事が、商品・商品バリエーション・カタログ・カートのように大部分同じで、かつ両視点がを同じ物事をほとんど同じ概念として写像しているとしたら、これらの視点は統合したほうが良いかもしれません。見ている角度が近く、分けるには視点が近すぎるからです。
イベントストーミングなどの視点定義のための手法や、分けた視点をどうソフトウェアに反映すべきかについては、この記事の趣旨から逸れるため議論のスコープ外とします。先述のとおり、まずは事業組織全体でドメインモデリングに取り組むことが最も重要であり、モデリングテクニックは後です。まずは、モデリング中に先程の「商品」のような複雑な物事が現れて困ったときに、適宜視点を複数に分けてみるとよいでしょう。
3-4. 視点とは境界づけられたコンテキストのことである
この記事では「視点」というワードを何度か出していますが、これは筆者が作り出した完全にオリジナルの概念です。DDDを詳しく知る方の中には、筆者の言う「視点」と、DDDにおける境界づけられたコンテキストの違いが気になった方もいらっしゃるかもしれません。
実は違いません。筆者は、境界づけられたコンテキストを、視点の概念と同じものだと解釈しています。筆者が傲慢にもあえて異なる概念を生み出すことにしたのは、20年近く信じられている境界づけられたコンテキストの考え方に一石を投じたいからです。
境界づけられたコンテキストの概念体系は、「境界」や「コンテキストマップ」といった、2次元的広がりを連想させるワードチョイスになっています。そのため、DDDを聞きかじった方が境界づけられたコンテキストを定義しようとすると、平面の「マップ」の上に「境界」を引き、領域を排他的に分けてしまいがちです。
このやり方の問題点は、境界で領域を分割した後、仕分けを行うように1つ1つの現実世界の物事をいずれかの区切られた領域に排他的に押し込めてしまう結果、ちょうど例の「商品」のような複数のコンテキスト（筆者がいうところの視点）に出てくる物事を上手く取り扱えないことです。つまり、境界づけられたコンテキストのメタファは、モデリングをミスリードします。
平面のマップの上に境界を引くようなやり方には、もう1つ問題点があります。それは「できたかのように錯覚してしまう」ことです。DDDを聞きかじった方が陥りがちな境界の引き方をもう少し見てみましょう。まず、平面のマップ上になんとなく現実の物事やドメインモデル上の概念を書き込みます。次に、物事をグルーピングするかのように恣意的に境界を引きます。一抹の不安を覚えつつ、これで終わりです。
このやり方は恣意的で再現性がありません。平面に境界を引くという考え方では、「商品」「顧客」「注文」といったデータ観点のグループができてしまいがちです。やりたいことは、関心事の境界を定義することであり、もっとメタな思考プロセスです。筆者が説明した「視点」の概念はとっつきづらく感じられたかもしれませんが、むしろそれは狙い通りです。先述のとおり、視点定義はアートに近い活動です。地図にいくつか箱を書いて見映えの良さそうな線を引く、といった単純作業ではないのです。
筆者が生み出した「視点」のメタファは、荒削りですが、このように境界づけられたコンテキストの概念体系が持つミスリードの問題を解決します。3次元的な広がりを示唆することで、「2つのコンテキストに現実世界の同一の物事が登場しうる」という性質を、平面上の同じ物事を異なる角度から見た結果の写像と表現できています。また、現実世界という2次元の平面に対して「視点」が1つ高次に存在することで、視点の定義という仕事が、平面上の現実世界の物事から切り離して行われる創造的活動であることを表現しています。
まとめ
この記事では、事業全体でのドメインモデリングの取り組みについて、以下のような切り口から筆者の考えを紹介しました。
- ドメインモデリングが解決する課題
- ドメインモデリングをどのように始めるか
また、最後のセクションは本編というより付録ですが、こちらでは望ましいドメインモデリングのあり方を探求しました。
ドメインモデリングが小難しく技術的なプラクティスだと誤解されていることはもったいないことです。むしろビジネスプロセス的・組織戦略的なツールとして使ったほうがインパクトが大きいということに、この記事を通じて少しでも共感いただけたら幸いです。
昨今の自社サービス企業・SaaS企業・事業会社のDXにおいて、事業組織全体でドメインモデリングに取り組むカルチャーを創ることは、難易度も高く時間もかかり、よく知られた成功事例も少ないかもしれません。しかし、成功すれば圧倒的に組織を強くすると、筆者は信じています。
ぜひ、あなたの組織でも事業組織全体でドメインモデリングに取り組んでみてください。
追伸
よければTwitterもフォローいただけると嬉しいです！
Discussion