こんにちは、株式会社FLINTERSで企画職 （Product Owner、ProductManager、ProjectManager、雑用係などの総称）として働く加藤と申します。 私は、主に、インターネット広告代理店などデジタルマーケティングを実践されている企業へ、Yahoo!やGoogle、Facebookなどの広告媒体が提供するAPIなどを活用した、業務用のアプリケーションを開発提供するお仕事に携わっております。
ただいまFLINTERSでは、ブログ投稿強化月間ということで、前回のブログ ドメイン駆動設計(DDD)との格闘 - 突然DDD実践チームにPOとして参加することになったら - FLINTERS Engineer's Blogに続き、ドメイン駆動設計(DDD)を実践するチームに企画職として参加する時の心得について書いていきたいと思います。
この投稿の内容
第2回となる今回は、ドメイン駆動設計(DDD)における、ユビキタス言語(UBIQUITOUS LANGUAGE)との付き合い方について、紹介していきたいと思います。
企画職に求められるドメイン駆動設計(DDD)への貢献(前回からの引用)
おそらく、ドメイン駆動設計(DDD)の開発プロジェクトへ企画者として参加する場合、ドメイン （一旦、ここでは、その開発プロジェクトで解決したいビジネス上の課題というような定義にしておきましょう）にたいして、そのエキスパートである、または、相対的にチーム内で知見があり、発注者・利用者の中のドメインエキスパートから課題や知識をヒアリングし、ソフトウェアで解決できるように落とし込んでいくことが期待されていると思います。
こうした、期待に応えるために、企画職として実践できるようになっておきたい、ドメイン駆動設計(DDD)の手法は4つです。
では、さっそく今回は、ユビキタス言語の謎に迫っていきましょう。
ユビキタス言語がなぜ大切なのか？
ドメイン駆動設計(DDD)では、ユビキタス言語を使おうというのは、ubiquitous ： いつでもどこでも偏在する というこの単語から想像されるように、『みんなで』同じ言葉を使いましょうねということです。みんなで同じ言葉を使って、読み、書き、話しを、すれば、意思疎通しやすいよね。というとても簡単な話です。以上です。
と、簡単にはいかないのですが、みんな同じ言語を使えば、通訳・解釈の必要性・余地が減って、解きたい課題や解決方法が関係者の中でブレにくいよねというのは、確かにそうですよね。そして、『みんな』の中には、人の話し言葉や、ドキュメント・メモだけではなくて、プログラミングのコード（主に、関数名や変数名の名付けのときに）含めて、同じ言葉を使いましょう、と言われれば、そうあるべきだし、努力しようねってなりますよね。
でも、これが想像している以上に難しいんです。
ドメイン駆動設計(DDD)に通訳者はいらない
ドメイン駆動設計(DDD)の説明でよく言われるのが、ドメインエキスパートと開発チームが会話しながらドメインモデル（今はまだ、プログラムの設計のことと、ゆるく捉えていてください）を作り上げていけるようにするべきだという話です。
下の図は、よくある広告代理店向けの開発チームの簡略図です。広告主の課題を、営業部署の企画担当がヒｙリングし、それをシステム担当部署の企画者であるシステム企画者（あなたです！）に要望を伝え、システム企画者が要求・仕様としてまとめて、開発実装者に伝えて、プログラムのコードを実装する。質問がある場合や、実装したもののへフィードバックをもらうときは、この逆の流れで行います。
人がコミュニケーションにより、100の情報を100そのまま相手に伝えられるなんてことはあるわけがなく、コミュニケーションのたびに情報が減る・もしくは・間違っていくことは避けて通れません。 100の情報が20％ずつ姿かたちをかえるとするとすると、実装コードに落とし込まれる頃には、元の半分の50の正しさしかありませんし、その50の内容について、広告主へ質問する頃には、さらに半分以下に正しさがなってしまいます。
では、コミュニケーションルートを短絡して関係者を減らしたらどうかというと、確かにそれは有力な情報欠落に対する解決策ではあるのですが、広告主やドメインエキスパートは当然、開発以外の他の仕事もしているわけで、1日中、実装者と対話できる時間の余裕はないわけです。
この情報流通の過程における問題を、関係者みんなで、同じ言葉を使って、通訳をせずに、読み、書き、話しができれば、精度高く、課題の認識や解決方法の考案・構築ができるよねってことですね。
弊社の技術指針技術のDDDのところ改めて抜粋しておきますね。
ドメイン駆動設計はユビキタス言語という言葉と実装を一致させる言語を用いてビジネス要件の芯を設計の中核におく手法です。
「エンジニア以外にも翻訳不要で伝えることができる」「設計と実装に対する価値観が共有できる」という特徴があり、チーム全員で要件の芯を捉える助けになることを期待しています。
具体的には、やらねばならないことのコストをプロダクトオーナーが認識しやすくなる／レビューや仕様検討時に、言葉と実装が一致しているか、というチェックを行えるようになる／設計や概念がまずい場合、言葉にすると自然と大仰に成り危険な感じになる、といった効能を期待しています。
うん。いいこと言ってるな〜
ユビキタス言語には時には、創造が必要
でも、同じ言葉を使い続けるのって、すごく難しいんです。現代日本語の特性なのかもしれませんが、主語をあまり意識せずに会話ができますし、実態としては同じモノ(※1)を別の言葉で説明することも数多くあります。例えば、広告主が当月出稿した金額のことを、売上、請求金額、利用金額など別の表現を使って説明を受けることが、ヒアリング現場では多々あります。一方、開発チーム側も、開発側で勝手に名付けた関数名や変数名などで会話をしてしまうことが多いです。
下の図を見てください。あくまで私の経験上の話ですが、ユビキタス言語の構築は、ドメインエキスパートの利用する専門用語と開発者の利用する専門用語をすり合わせながら、お互いこの言葉を使って話そうという、『発見的ユビキタス言語』と、お互い、今まで使っていなかったけど、この開発プロジェクト(※2)のなかでは、新たにこの言葉を使いましょうという、『造語的ユビキタス言語』があると思っています。
基本的には、たいていの本を読むと、なるべくシステムの利用者・ドメインエキスパートに寄り添った言葉を選択しましょうという指針が書かれていて、それはその通りなのですけど、ドメイン側に、全ての適切な言葉があると思うと失敗します。
適切な言葉が明確に存在しないために、業務上の問題が起きていて、適切なユビキタス言語を創造出来たら、問題の半分くらいが解決しているということが、実際にあったりします。
例えば、Yahoo広告やGoogleAdsを扱う広告代理業務に置いて、ある広告主が、YahooやGoogleなど広告媒体毎の広告アカウントを開設し、新発売する車について宣伝するとします。一般的には、新車のキャンペーンをするとか言うのかもしれません。
でも、デジタル広告では、「キャンペーン」というと、YahooやGoogleなどの広告アカウント内部の設計の話。つまりアカウント > キャンペーン > 広告グループ > アド ＆ クリエイティブ（クリエーティブ）という、アカウント構造のことを指すことが多かったりします。
私達が関わった開発プロジェクトでは、同一広告主の、同一広告目的を有する、複数の広告アカウントの塊を一括でアレコレする必要があったのですが、ドメインエキスパート側に、この塊を適切に表す、表現が存在していなかったり、少なくとも皆が使うような共通の表現がなかった状況でした。
こういった時は、一旦、エイヤっと、それっぽい言葉を当てはめるんです。この例でいうと、もうこの塊は『プロモーション』という言葉にしようと創造するわけです。
ちなみに、弊社では、開発側が、プログラミングで、日本語を使い続けるんだという、野心的な取り組みをしているプロジェクトもあったりします ==> 日本語とScalaでプロダクトを作る - FLINTERS Engineer's Blog
ユビキタス言語には不屈の闘志が必要
こうして、発見や、創造したユビキタス言語ですが、これが、悲しいくらい、共通で使われません。ビジネス側のドメインエキスパートが利用してくれないのはまだわかりますが、DDDを実践しているはずの、開発チームですら共通で使ってくれないことが多々あります。 そして、あなた、自分自身もおそらく、違う言葉で話したり、書いたりするでしょう。
で、DDD本に書いてあったことを思い出すわけです。ユビキタス言語が利用されない、それはその言語に違和感があり、正しくドメインを理解できていなかったり、問題とその解決を適切にモデルに表現できていないからだと。
これはこれで、素晴らしい指摘ではありますが、一旦、こんなアドバイスは忘れてしまいましょう。
とにかく使うんです。話す時もチャットする時もドキュメント書く時も、とにかく、使うし、相手が使わなかったら、何度でも言い直しするくらいしつこく使うんです。忍耐です。
本当に、言葉が適切でない場合は、何度も使用を強制していると、相手が怒りとともに、もっと適切な言葉を使いたいと提案してきてくれます。その時に初めて、ユビキタス言語の変更を検討すれば良いと思います。特に、プロジェクトの初期は、ユビキタス言語が本当に定着しないので、あなたは相当強い気持ちで望む必要があります。
違和感は忘れずに記録しておく
いきなり、前言撤回、矛盾したことを言っているようですが、ユビキタス言語を使っているうちに感じた違和感は、システム開発において貴重な発見につながる可能性があります。
とくに、仕事/業務の、領域・境界に関係しそうな違和感は、大事にしてください。
実態としては同じモノ(※1)を別の言葉で説明することも数多くあります。例えば、広告主が当月出稿した金額のことを、売上、請求金額、利用金額など別の表現を使って説明を受けることが、ヒアリング現場では多々あります。
さきほどは、売上、請求金額、利用金額が、同じ金額であり、実態として同じモノである、と乱暴な説明をしてしまいましたが、これは正解のときもあれば、間違いの場合もあります。これが同じモノなので、同じ言葉で表現するべきなのか、金額は同じでも別のモノとして、別の言葉で表現するべきなのかは、あなたが関わっている開発プロジェクトが『何を解決する』プロジェクトで、そのプロジェクト内の『どのようなシステムの中に』登場するののかによって決まります。
お互い、今まで使っていなかったけど、この開発プロジェクト(※2)のなかでは、新たにこの言葉を使いましょう
この、「この開発プロジェクト(※2)のなかでは」という、範囲の特定、切り出しが適切に行えていると、開発プロジェクト内で、ユビキタス言語が上手く定着して、スムーズな開発ができますし、範囲の特定、切り出しが不味いと、言葉がギクシャクして開発プロジェクトもギクシャクします。
ちょっと、何言っているか全然わからねーよとなってしまったかもしれませんね。
では、いよいよ、ドメイン駆動設計(DDD)に関わる、企画者としての一番楽しい部分でも有り、腕のみせどころ？でもある、ドメインとコンテキスト境界の話を次回からしていきたいと思います。
