ユビキタス言語は難しい！それでも挑戦する価値がある理由

この記事は BABY JOB Advent Calendar 2024 の 4 日目の記事です。

はじめに

BABY JOB株式会社 開発部 手ぶら登園開発課のOKWRKです。
昨日に引き続き連日の登場です。よろしくお願いします。

私が担当する 手ぶら登園 を含め、BABY JOBでは基本的にドメイン駆動設計 に倣って設計・実装されています。

ドメイン駆動設計とは、事業内容（ドメイン） の知識をソフトウェアの設計と実装の中心に据える手法です。
そのドメイン駆動設計の重要な要素の１つであるユビキタス言語の考えは、ドメイン駆動設計の他の考えを捨て、ユビキタス言語だけを運用するという場合でも有用と思えるものです。

しかし、前職でもドメイン駆動設計に倣って設計・実装を行い、ユビキタス言語の策定・運用も行っていた私にとって、ユビキタス言語の策定・運用は難しいものだと感じています。

本記事では、ユビキタス言語の策定・運用における課題を解説し、それを乗り越えるための具体的なアイデアを共有したいと思います。

ユビキタス言語とは

ユビキタス言語とは、ドメイン駆動設計の重要なコンセプトの１つです。
開発者だけでなく、営業やカスタマーサクセスといったその業務（ドメイン）にかかわるメンバー全員の間で使用される、共通言語になります。

例えば「注文を受ける」という業務では、「顧客」「商品」「注文」という用語が頻繁に登場します。この時、それぞれの用語を明確に定義し、全員が統一して使用するのがユビキタス言語の役割です。

ユビキタス言語は、設計書やコードではもちろんのこと、ドキュメントやチーム内の会話など、そのドメインに関して表現するすべての場面で統一的に使うことが求められます。

チーム内で統一された単語を使うことでチーム内のコミュニケーションを円滑にし、同じ単語を別の意味で認識することによるミスコミュニケーションを減らすことが期待できるのです。

なぜユビキタス言語は難しいのか

しかし、ユビキタス言語の策定は難しく労力を必要とするのです。
さらに、苦難の末に策定することに成功しても、そのあとの運用はより多くの困難と苦労が待っています。

実のところ、前職ではユビキタス言語を策定し、しばらく運用を行っていましたが、最終的には失敗して形骸化してしまうという経験をしています。

なぜユビキタス言語の策定・運用は難しいのか。実際に策定・運用を経験した身として分析してみたいと思います。

チーム外のメンバーへの定着

ユビキタス言語は先述した通り「開発者だけでなく、営業やカスタマーサクセスといったそのドメインにかかわるメンバー全員の共通言語として使用するもの」という性質上、開発チームだけで運用するものではありません。ビジネス側にも継続的に運用してもらわないと意味がなくなってしまいます。

前職でも、開発チーム内ではユビキタス言語を運用し、コードや設計で有効に活用できるようになってきていましたが、ビジネス側への定着に失敗してしまっていました。

ユビキタス言語の策定当初はビジネス側の同意も得られているものでしたが、ビジネス側のメンバーの入れ替わりや、業務変更に伴うユビキタス言語の修正が発生した際に少しずつ運用が次第に忘れ去られ、形骸化してしまいました。

これを防ぐためにはビジネス側のオンボーディングにも取り入れてもらう必要があったり、ユビキタス言語の修正のたびにビジネス側でも再普及に協力してもらう必要があり、継続的に労力を割いてもらう必要があります。

業務フローの正しい理解が必要

ユビキタス言語を策定する場合、実際に行われている業務フローを正しく理解している必要があります。
そして、その業務フローに即した形で、ユビキタス言語を整理していくのです。

業務フローを俯瞰的に、正しく理解しているメンバー（いわゆるドメインエキスパート）にユビキタス言語の設定を担当してもらえれば一番良いのですが、大抵の場合、ドメインエキスパートとなるようなメンバーは非常に忙しく、ユビキタス言語の策定を丸投げできるような状態ではありません。

そのため、多くの場合は開発メンバーが業務フロー全体を理解し、整理してドメインモデル図やイベントストーミングといった形で資料にまとめる工程が必要になります。
これらはドメイン駆動設計においても非常に重要な資産になるため、決して無駄にはなりませんがその作成自体に非常にコストがかかるため、この時点で頓挫してしまうケースも多いように感じます。

人の言葉を訂正する事が必要な場合もある

そして定着のためには、ユビキタス言語とは異なる言葉の使い方を耳にしたり目にした場合には、誤った認識が広まらないようにそれを訂正する必要があります。

コードレビューでも、ドキュメントを読んでいる場合でも、チャットしている場合でも、会議中でも、相手がユビキタス言語を使わずに誤った言葉を使った場合は、何度でも丁寧に指摘し、言い直さなければなりません。

指摘によって空気が悪くなったり、委縮してコミュニケーションが減ってしまうことを懸念して、ユビキタス言語に沿わない言葉の指摘をためらってしまうこともあるかもしれませんが、それではいつまでのユビキタス言語は浸透しないままになってしまうのです。

これは指摘する側も、指摘される側も精神的な負荷の大きいもので、ユビキタス言語の運用を挫折してしまうポイントの一つになっていると考えています。

それでもユビキタス言語を策定するべき理由

上記のように、ユビキタス言語の策定・運用には多くの困難が伴い、私自身も失敗を経験しました。
しかしそれでもなお、私はユビキタス言語は策定・運用に挑戦する価値のある仕組みだと考えています。

言葉が見つかるだけで解決する問題というものが存在する

ユビキタス言語はその策定の過程で、業務フローを分解し、ドメインを整理し、名前を付けます。この策定の過程で、「今まで存在は認知しつつも適切な言葉が明確に存在しなかったために対処できていなかった問題」などに名前が付き、明るみに出てくることがあります。こうした問題は、言葉が見つかり認識されるだけで、一気に解決に近づくこともあり、前職でも「ユビキタス言語策定の過程で、今まで認識されていなかった問題が見つかり、同時に解決した」といったことがありました。

チーム全体の理解を深め、一体感が生まれる

ユビキタス言語を運用することで、開発者とビジネス側の「認識のズレ」を最小限に抑えられます。これにより、要件定義や設計の段階での誤解が減り、仕様変更への対応もスムーズになります。同じ言葉を使うことで、チーム全体が同じ方向を向けるようになるのです。

長期的なメンテナンス性が向上し、設計時・命名時のコストも下がる

統一された言語がコードや設計に反映されることで、プロジェクトが長期間続いた場合や、新しいメンバーが加わった際でも、理解しやすく変更しやすいシステムを維持できます。これは短期的な労力を超える価値をもたらします。また、決まった単語があるため設計時や命名時に迷うこともありません。

ユビキタス言語導入を成功させるためには

私は、とにかく小さく、少しずつ策定し、運用を開始するのが望ましいと考えています。

例えば、既存のシステムに対する機能追加のタイミングであれば、その新機能の部分だけで初めて見るのは良いかもしれません。新しい機能の導入時であれば、ビジネス側のメンバーとのコミュニケーションの機会も多く、自然とユビキタス言語の策定の提案も行えるかもしれません。

何度も言うように、ユビキタス言語は作って終わりではなく、むしろそこからが本番です。
小さい範囲でユビキタス言語を運用することで、ユビキタス言語の運用というものにチーム全体が少しずつ慣れる必要があります。
開発チームだけでなく、全員の協力が必要なこの取り組みを成功させるためには、とにかくユビキタス言語の有用性を理解し、協力してくれる仲間を各所に増やすことが大切なのです。

ユビキタス言語の小規模な運用が成功して初めて、その範囲を広げていくことを検討してもよいかと思います。

おわりに

ユビキタス言語の導入・運用には多くの課題がありますが、それを乗り越えた先に得られる価値は非常に大きいものです。

実のところ、BABY JOBでもユビキタス言語の策定は何度か検討してはいるものの、現時点ではまだ策定できていません。
しかし、BABY JOBではユビキタス言語の策定を含めて、ドメインを正しくシステムに反映するための取り組みを継続しています。

この記事が皆様のプロジェクトに良い影響を与えられれば幸いです。