はじめに
チーム開発をしていると、こんなことってありませんか？
「あれ？その機能って、どういう動き想定してたっけ？」
「言われた通り作ったのに、レビューで“意図と違う”って言われた…」
コードの書き方や設計手法をどれだけ学んでも、
言葉の解釈のズレがあると、最終的なアウトプットに違いが出てしまいます。
このズレを埋めるためにどうしたらいいか調べたところユビキタス言語に辿り着きました。
この記事では、
- なぜ「言葉の解釈のズレ」が問題になるのか
- ユビキタス言語として使う言葉を定義することによってどのようなメリットをもたらすのか
を紹介していきます
言葉の曖昧さが引き起こすすれ違い
たとえば、以下のような仕様があったとします。
「イベントが発生したら、ユーザーに通知を送ってください」
一見、シンプルな要件に思えます。
しかし、いざ設計に落とし込もうとすると、次のような疑問が浮かびます。
- 通知手段は何か？（メール？プッシュ通知？LINE？）
- 対象ユーザーは？（全員？条件に合う一部だけ？）
- 通知のタイミングは？（即時？毎回？1日1回？）
こうした定義を曖昧にしたまま進めると、
- 実装者ごとに異なる解釈で作業してしまう（手戻りが発生する）
- レビュー時に「そもそもこの言葉ってどういう意味？」と仕様に立ち返る羽目になる
- ドキュメントとコードと会話の内容がそれぞれ微妙に違って混乱する
このようなズレを防ぐために活用できるのが「ユビキタス言語」です
ユビキタス言語とは？
ユビキタス言語（Ubiquitous Language）は、
ドメイン駆動設計（DDD）における概念のひとつで
開発者やドメインエキスパートを含むチーム全体で共有された言語を指します。
簡単に言えば、
「チーム内で共通の言葉を使い、共通の意味で理解すること」
です。
ユビキタス言語を定義することによって、次のようなメリットがあります：
-
認識のズレを減らせる
曖昧な言葉に対して明確な定義を与えることで、
認識のずれによる手戻りなどを防ぐことができます。 -
非エンジニアとの会話もスムーズになる
開発者でない方と話すときも、共通の前提で会話ができるようになります。 -
レビューや引き継ぎがしやすくなる
言葉の意味をチームで定義しておくことで、属人化を防ぎやすくなります。
「通知」を共通言語として定義してみる（例）
「通知する」という言葉は曖昧で解釈に幅があります。そこで、具体的な種類ごとに名前と意味を定義してみます。
全体通知
すべてのユーザーに一斉に送られる通知。
例：システムメンテナンスのお知らせや、障害発生の告知など。
条件付き通知
特定の条件（例：操作完了、イベント発生など）を満たしたユーザーのみに送る通知。
例：予約が確定したときに送られる通知など。
1日1回通知
同じ内容の通知は1日1回までしか送られないように制御された通知。
例：リマインダーや「未対応のお知らせ」など、繰り返しが煩わしい通知。
設定可能通知
ユーザー自身が「受け取る・受け取らない」を設定できる通知。
例：キャンペーン情報やアンケート依頼など、任意での受信が想定される通知。
このように、通知を種類ごとに具体的な名前と定義を与えることで、
設計や命名、関係者との会話でのズレを防ぐことができます。
非エンジニアとのコミュニケーションでも役立つ
共通言語の価値は、エンジニア同士の会話だけにとどまりません。
むしろ、非エンジニアとの連携にこそ効果を発揮します。
たとえば
•「通知をユーザーに飛ばしたい」と依頼されたとき、
→ 「それは全体通知でしょうか？それとも条件付き通知でしょうか？」と、正確な意図を確認できます
共通言語を定義しておけば、認識の食い違いによる手戻りや仕様漏れを防ぐことができます。
まとめ
「通知する」といったシンプルな言葉でも、
チームメンバーや関係者の間で解釈が異なることは多々あります。
そしてそのズレは、実装のミスやレビューでの手戻り、
さらには「言った・言わない」の認識違いへとつながってしまいます。
こうした事態を防ぐために有効なのが、
チーム全体で同じ意味で言葉を使うというユビキタス言語の考え方です。
ユビキタス言語を取り入れることで、
- 認識のずれを減らせる
- レビューや引き継ぎがしやすくなる
- 非エンジニアとの会話もスムーズになる
といった効果が得られます。