はじめに

ドメイン駆動設計（Domain-Driven Design、DDD）という単語はエンジニアをやっていれば1度は聞いたことがあると思います。¹
しかし特徴的な名前が多く、ちょっととっつきにくい印象がありますよね。
私も正直、何度か本を読んでは挫折し、を繰り返しています。

今回、Software Design 2024年3月号の特集記事であった「ドメイン駆動設計[実践]ガイド」の第2章「ユビキタス言語定義と効果を理解しチームで実践してみよう」が大変わかりやすく、「たしかに『ユビキタス言語』、大事！」と感じました。

自社プロダクトの開発をしていると、たとえ「ユビキタス言語」という単語を認識していなくても、開発者は「ユビキタス言語」を定義することの重要性をわかっていて、なんとかそれを捉えようともがいています。
ただ、もがく過程で特集記事にあったポイントや定義の流れを念頭に置くと、スムーズに「ユビキタス言語」を定義することができると感じました。

そこで本記事では、ドメイン駆動設計の文脈で利用される単語のうち、「ユビキタス言語」にフォーカスして内容を深堀りしてみようと思います。

なおこれ以降、上記雑誌の記事を「ドメイン[実践]ガイドユビキタス言語」と記載します。

また、本記事は「ドメイン[実践]ガイドユビキタス言語」の内容に沿いつつ、個人的にポイントだと感じた点や加えて気にした方がよさそうな点、所感などを交えて記載します。

「ユビキタス言語」ってなに？

要は「サービスのターゲット業務や開発に関わるすべての人が、見聞きして同じ意図を連想できる一意の言葉」で、「関係者全員が同じ土俵に立つための共通認識を作るツール」で、
その言葉を使って滞りなくターゲット業務に関する会話ができるし、その言葉を使って悩むことなくコードやドキュメントが書ける状態になっていることだと理解しました。

関係者全員が同じ土俵に立つためには共通言語が必要

開発者だけではサービスを作ることはできません。
サービスのターゲットとなる業務が存在し、その業務を遂行するユーザーが存在し、そのユーザーを熟知し、支える社内メンバー（ドメイン駆動設計の世界では「ドメインエキスパート」²と呼ばれます）が存在します。
ターゲット業務を遂行しやすくするためのサービスを作る以上、そこにより近い人たちの意見は必要不可欠ですし、彼らと対話・議論することで開発者も業務への理解が深まり、実装すべき機能の解像度が上がります。

しかし、開発者は開発をしていると、ともすると技術ベース、コードベースでの会話になりがちです。
その状態で無邪気にドメインエキスパートと会話をすると、認識のずれを何度も合わせる必要が出てきます。

認識のずれを起こさないように、確実に1つの業務を一意に示すための共通の言葉（群）が「ユビキタス言語」です。

ケーススタディ：無邪気な開発者とドメインエキスパートの会話

たとえば、ユーザーが実際にやっていることが「シフト管理において、店長が一定の条件を満たした従業員に責任者の資格を与え、営業時間内に必ず1人責任者を配置する」だとします。

ユーザーやドメインエキスパートは、上記のように業務を表現します。

一方で開発者は、これを「シフト管理の権限を持つユーザーが、責任者管理テーブルに任意の従業員IDとスキルコードを紐づけてレコードを登録し、責任者管理テーブルにレコードのある従業員が時間別シフトデータに存在しない場合、エラーを返す機能」を利用した業務、と捉えているとします。

この状態で、開発者とドメインエキスパートに会話させてみます。

ド：「シフト表への責任者の配置について質問なんですが、責任者にはアルバイトを充てることも可能ですか？」
開：「責任者の配置・・・？もう少し詳しく説明してもらえますか？」
ド：「1日のシフトの中で、必ず各時間帯1人は責任者を配置する必要があるじゃないですか」
開：「責任者不在チェックのことですね。はい、そうですね」
ド：「そうですね、不在チェック・・・のことだと思います」
ド：「で、その不在チェックにアルバイトもかけることは可能ですか？」
開：「アルバイトは従業員テーブルにデータが入っているんですか？」
ド：「ちょっとテーブルのことはわからないですが、アルバイト雇用画面から登録して採用していますね」
開：「であれば従業員テーブルにデータ入ってるんで、アルバイトの従業員にも責任者のデータを追加してもらえばエラーチェック可能ですよ」
ド：「責任者のデータの追加っていうのは、通常の従業員と同じように従業員情報管理画面からできますかね？」
開：「そうですね、アルバイトを社員区分で分けているだけだったら、従業員情報管理画面から登録できると思いますよ」
・・・
ド：（開発の人、すぐにシステム用語で返答してくるから混乱するわ・・・）
開：（もうちょっと開発にもわかる言葉で話してくれりゃいいのに・・・）

このように、業務を理解するための言葉がそろっていないと、開発者とドメインエキスパートが該当業務について話しても、内容の認識合わせをするのに何ターンものやり取りを要します。しかも、このやり取りがしばしば発生することになります。
実際にはここまで殺伐とはしないとは思いますが、もうちょっとオブラートに包んだ状況はしばしば目撃します。

「ユビキタス言語」を定義するとうれしいこと

サービスに関わるすべての人・成果物の中で認識が揃う

前述のような、認識のずれを是正するための会話が不要になります。
認識がずれたまま開発が進んでしまった結果、一部修正が必要・・・などというコミュニケーションのずれによる手戻りも抑えられます。
メンバー間による、あるいは同一人物ですら起こり得る表記ゆれも、ユビキタス言語があることで起こることは激減します。

命名の時間を節約できる

コーディング時にどんな名前を付けるかは大変悩ましく時間を費やす問題ですが、予めユビキタス言語を定義しておくことで、何も考えずともその言葉をコード上でも利用すればOKです（むしろ利用しないと意味がありません）。

業務知識への理解が深まる

ユビキタス言語を定義するために、今自分が向き合っている業務をより深堀していく必要があります。
その過程でドメインエキスパートを含めた業務知識の豊富なメンバーとの会話などを通じ、自分が認識していなかったケースや背景が見えてくることもあります。

「ユビキタス言語」を定義するときに個人的にポイントだと思ったこと

全部がんばって定義する必要はない

「シフト管理において、店長が一定の条件を満たした従業員に責任者の資格を与え、営業時間内に必ず1人責任者を配置する」という前述の業務例の場合、ユビキタス言語の候補になりそうなのは『店長』『店舗従業員』『責任者』『資格』『与える』『営業時間』『配置する』あたりでしょうか。

そうです、すべてなり得ます。

「ユビキタス言語」という言葉をひとたび知ってしまうと、業務に関するあらゆる言葉をすべて定義しないといけないような、ユビキタス言語不在恐怖症に陥りかねません。

ヘッダに記載のとおり、あらゆる言葉をがんばってユビキタス言語として定義する必要がありません。
とはいえ、何をポイントに、どこまでユビキタス言語として定めればいいのでしょうか。

意味が広義／狭義すぎる場合は適切な粒度の名前を付ける

前述の例だと、シフト管理をするのは店舗を有する業態だけではありません。病院や工場、レジャー施設などでも同様にシフト管理が行われます。そのため、シフト管理に対して『店長』は具体的すぎる印象があります。

具体名だと店長／施設長／部門長などキリがなさそうなので、総称する『責任者』『シフト責任者』などが候補に挙げられそうです。

同一の呼称が複数のシーンや意味で用いられている場合は名前を分ける

『（シフト）責任者』と名付けたところで、冒頭の例に挙げた例で呼称が重複しているものがあります。
店舗従業員に与える『責任者』という資格の呼称です。
店舗従業員が与えられる『責任者』は、営業時間の各時間帯のシフトの中で責任者という役割を担うことを期待されています。
そのため、以下のようにユビキタス言語を定義するとよさそうです。

『責任者』という資格→『時間帯責任者資格』
『時間帯責任者資格』を持つ従業員→『時間帯責任者資格保有者』
『時間帯責任者資格』を持つ従業員がシフト上で担う役割→『時間帯責任者』
店長をはじめとしたシフト管理に責任がある立場の人→『シフト責任者』

頻繁に会話に出てくる単語のみを定義する

ターゲット業務や機能の話をしたりドキュメントを書いていると、頻繁に出てくるワードって存在します。
そしてそういうワードほど、個々人で名づけをして好き勝手呼んでいたりします。
誰かと会話しているときに脳内で相手の言葉を自分の言葉に変換しているものがあれば、それはユビキタス言語候補で、相手に「それってどういう意図で使ってる？」と質問して掘り下げるチャンスです。

いっぺんにえいやと決めようとしても、やりすぎたり後から定義した方がいい単語は出てくるので、やけに目につく、耳につく単語から順番に定義していくとよさそうです。

声に出して馴染むかを確認するとよい

ここまでで、いくつかのユビキタス言語を定義したことで、例示の業務は以下のように解像度を上げました。

「シフト管理において、シフト責任者は一定の条件を満たした従業員に時間帯責任者の資格を与え、営業時間内に必ず1人時間帯責任者資格保有者を配置する」

これを実際に読み上げてみると、『与える』という言葉がなんとなくしっくりこないなあと感じました。なんか、うまく言えないけれど、えらそうというか。³
改めて『与える』という単語を調べてみました。

自分の所有物を他の人に渡して、その人の物とする。現在ではやや改まった言い方で、恩恵的な意味で目下の者に授ける場合に多く用いる。「子供におやつを—・える」「賞を—・える」

あーーーなるほど、『資格』というものは自分のものを他人に渡すとか、そういう類のものではありません。違和感の正体はこれでした。
何らかの試験や経験を経て資格を得る場合、『認定』という言葉の方がよさそうです。
今回の『時間帯責任者』も、「一定の条件を満たした」状態になって初めて追加される資格なので、言葉の本来の定義にも合致します。

なお、今回は使用している単語の誤用でしたが、実際はドメインエキスパートなどと一緒に読み上げたうえで、もし誰かが違和感を感じた場合、その正体を探っていく、ということの意味合いの方が強いのではと思います。

日本語と英語、両方用意しておくといい

コーディングでも利用しやすいように、1つのユビキタス言語に対して、日本語・英語どちらも定義しておくとよいとされています。
日本語でユビキタス言語を作った結果、最適な英語がない場合は、英語を利用せずに日本語をローマ字表記にする方がいいこともありそうです。
日本語は漢字文化もあって、端的に用語を説明するのに長けています。また、漢字によって微妙なニュアンスを表現することも多いです。それを無理やり英語にすると、冗長になったりニュアンスが剥がれ落ちてしまったりするためです。

日本語名でのユビキタス言語とコーディングでの利用について、以下が参考になりました。

また、弊社のソースコードにも、敢えて日本語名を利用していそうなコーディングにおけるユビキタス言語が数多く存在しています（多くは古いソースコードで、当時敢えて日本語名でのコーディングをしたのかを知る術はないのですが）。

「ユビキタス言語」が意味する業務の解説を必ず用意する

言わずもがなですが、各ユビキタス言語を説明する文章は用意する必要があります。

ユビキタス言語を定義した時のメンバーがずっとプロジェクトに居続けるとは限りません。その言葉が何を意味するのかがわからなければユビキタス言語の意義はあっという間に失われてしまいます。
また、非日本語話者のプロジェクトメンバーがいるときなどは、特に英語名が日本語のローマ字表記が最適だった場合、ユビキタス言語の意味が全くわかりません。"そのサービスに関わる全ての人の認識を揃えるため"、解説は用意する必要があります。

ブラッシュアップを続ければよい

すべてを最初から定義しておくのは土台無理な話で、気づいたときに追加していくものであるという認識が大事そうです。

また、ターゲット業務を取り巻く状況も変わっていくので、1度定義したユビキタス言語を妄信的に利用するのではなく、定期的にユビキタス言語の定義が声に出して馴染むかを確認することが肝要そうだなとも。

つまりユビキタス言語は時代や状況に応じて常にアップデートしていくべきもので、製品やコードと同じ性質のもので、
だからこそ、陳腐化しない管理方法を考える必要があるなとも。

実際に、実務の中で頑張って考えたユビキタス言語が、実は10年近く前の開発者がちょっと違う単語で定義していて、しかもそれがとても古くて形骸化したwikiの中の1ページから発見される、という状況に遭遇したことがあります。

喫緊の課題の1つに挙げておきたいです。

「ユビキタス言語」の本質

「ドメイン[実践]ガイドユビキタス言語」では、ユビキタス言語の本質として以下のように記載されていました。

筆者としては、ユビキタス言語の本質を「プロジェクトにおいて、そのチームが解決しようとしている課題に対する現時点での解像度を示したもの。すなわち、そのチームが何を意識して、何を意識しないかを決める思考の枠組み」であると捉えます。⁴

例示の業務は、ユビキタス言語をいくつか定義したことで以下のようにアップデートされました。

「シフト管理において、店長が一定の条件を満たした従業員に責任者の資格を与え、営業時間内に必ず1人責任者を配置する」

　↓　↓　↓

「シフト管理において、シフト責任者は一定の条件を満たした従業員を時間帯責任者に認定する。シフト責任者は、営業時間内に必ず1人時間帯責任者資格保有者を配置する」

後者の方が各単語の定義が明確で、意図する業務がわかりやすくなりました。
他のエッジが効いてきたことで『営業時間内』という言葉がぼやけて見えるというのが浮き彫りにもなっています。

順番に単語の解像度を上げていくことで、さらに解像度を上げるべき部分がわかるというのも、ユビキタス言語の活用法の1つだと感じました。

「ユビキタス言語」をつくる流れ（概要のみ）

「ドメイン[実践]ガイドユビキタス言語」では、以下の流れで考えていくとよいとされています。超ざっくりなので詳しくは雑誌をお読みください。

対象の業務フローと要件を深く理解する
ドメイン知識なしで思いつく単語を挙げてみる
ドメインエキスパートと問題を分析してみる
ユビキタス言語を決定する

本来であれば、上記の流れに沿って具体的にユビキタス言語を作ってみたいところですが、本記事執筆に際してドメインエキスパート不在のため、実務でユビキタス言語を定義した暁には別記事で書こうと思います。

なお、実際にユビキタス言語を定義していった話は以下の記事が大変参考になりました。

おわりに

ユビキタス言語を定義することで、プロジェクトにもたらす恩恵が多いということが理解できました。
個人的には、ユビキタス言語を定義することで、企画書やコードを書く中で、幾度となく悩みぬいた結果、同じ業務に異なる用語を用いてしまう現象をかなり減らせそうだと思いました。

また、少々本題とはずれますが、ドメイン駆動設計で登場する用語が特徴的でわかりづらいと思う理由は、ドメイン駆動設計で利用する言葉自体がユビキタス言語になっているからかな、と感じました。
用語が馴染んで意識せずともイメージできたり、その利用の取捨選択をできるようになるためには、もう少し原典も含めたドキュメントを読み、それぞれの用語の理解を深め、解像度を上げる必要があるんだなあなどと。

ドメイン駆動設計[実践]ガイド第2章ユビキタス言語（Software Design 2024年3月号）などの書籍を読んでほしい

今回は「ドメイン駆動設計[実践]ガイド第2章ユビキタス言語」を読んでの個人の所感が多く、書籍の内容そのものはほとんど紹介できていません。
ユビキタス言語についてもっと理解を深めたい場合は、ぜひ書籍を購入して読んでみてください。

参考文献、Webサイト

文献

「Software Design 2024年3月号」 - ドメイン駆動設計[実践]ガイド第2章ユビキタス言語
「エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう」 - 第2章コミュニケーションと言語の使い方 - ユビキタス言語（UBIQUITOUS LANGUAGE）
「ドメイン駆動設計入門ボトムアップでわかる! ドメイン駆動設計の基本」 - 15.3 ユビキタス言語

Webサイト

おまけ

著者である大西さんご本人からコメントいただけてとっても嬉しかったので貼らせてください！

また、同SoftWare Design 2024年3月号の「ドメイン駆動設計[実践]ガイド第1章ドメイン駆動設計の概要」を書かれている増田さんからも感激のコメントをいただけたのでこちらも貼らせてください！

もしご存じない方は参考文献、Webサイトに記載したものを読んだり、"ドメイン駆動設計"で検索してみてください ↩
ユーザーと直接話す社内のフロント部門のメンバーや、過去に実際に該当業務の経験のあるメンバーなどが該当します ↩
なお、本当はここでドメインエキスパートや他の開発者と議論をしたいところですが、現在孤独に記事を書いているのでぶつぶつ呟いています。 ↩
Software Design 2024年3月号「ドメイン駆動設計[実践]ガイド」第2章「ユビキタス言語定義と効果を理解しチームで実践してみよう」P30 より ↩