ハッ（笑顔）ということで・・・
はじめに
株式会社LegalOn TechnologiesでEngineering Managerを務めているYoshiokaです。2024年7月の入社からまだ半年ですが、様々なプロジェクトに携わり、多くの学びを得ています。
本記事では、ドメイン駆動設計（DDD）における重要な概念「ユビキタス言語」に焦点を当てます。この概念は私にとって特に印象深く、日々の業務で早速活用できているため、その実践方法と、我々がヘビーユースしているNotionを活用した具体例を紹介したいと思います。
こんなことありませんか？
皆さんは、次のような経験や課題に直面したことはありませんか？
- 新しい機能を開発するため、チームで議論しながら仕様を作成している
- 新しい用語が次々と登場し、同じ用語でも理解にズレが生じたり、呼び方が人によって異なったりして、円滑なコミュニケーションができない
- 理解の違いを解消しながら進めてきたものの、実装フェーズで細かな認識の違いが次々と表面化する。PMが仕様書を都度修正することになり、実装の進行に仕様書の更新が追いつかなくなってしまう
多くの方が「あるある！」と共感されるのではないでしょうか。
私自身、以前は上手くできていたつもりでしたが、LegalOn Technologiesに入社して環境が変わると、この問題が容易に発生することを実感しました。
つまり、これまでの「上手くできていた」という認識は、長年共に働いてきたメンバーとのコンテキスト共有があってこそのものであり、実は再現性のあるスキルではなかったのです。
ユビキタス言語とは
ユビキタス言語とは「チームの中の共通言語」です。
これはドメイン駆動設計（Domain-Driven Design、DDD）の重要な概念の一つであり、開発者とビジネス関係者が共有する共通言語のことです。つまり、チーム全体で統一的に使用する用語の集合といえます。
例えば、あるメンバーが「ログイン画面」と呼び、別のメンバーが「トップ画面」と呼ぶような状況を防ぎます。一見些細に思えるこのような呼び方の違いが、実はコミュニケーションの妨げとなり、最終的な成果物に対する認識のズレを生み出すことがあります。ユビキタス言語は、このような問題を未然に防ぐための重要なツールとして機能するのです。
(同じことを考えてるのに言葉が違うケース例)
新規機能開発でわかるユビキタス言語の威力
新規機能開発において、チームには新しい用語や概念が次々と登場します。仕様を検討してきたメンバーがこれらの用語に慣れ始める頃、開発メンバーが参加するのが一般的な流れですが、このタイミングで用語や概念の理解にギャップが生じると、開発の遅延や誤った実装を引き起こす可能性があります。
このため、仕様検討の段階でメンバー間の理解にわずかなズレでも感じた場合は、速やかにユビキタス言語として定義することが重要です。これにより、チーム全体での認識を統一し、円滑な開発進行を実現できます。
ユビキタス言語を定義する前に
ユビキタス言語を定義する際は、まずドメインの境界を明確に設計することが重要です。
例えばECサイトであれば、「ログイン」「商品情報」「検索」「購入」「在庫管理」といった機能単位でドメインを区切ります。このように境界を設けることで、「ユーザー」といった言葉の文脈による意味の違いを適切に表現できるようになります。
具体的には、購入機能のユーザーと在庫管理機能のユーザーは異なる存在です。各ドメインが独自の「コンテキスト」を持つことで、それぞれのドメイン内で「ユーザー」という言葉を適切に使い分けることができます。
何がユビキタス言語として定義されるべきか
ユビキタス言語として定義すべき内容に絶対的な正解はありません。専門用語に限らず、一見「当たり前」や「自明」と思われる言葉であっても、チーム内での共通理解を促進できるのであれば、ユビキタス言語として定義する価値があります。
これを実践した例として、私たちがFeature Flagの設計時に定義したユビキタス言語について紹介します。
なお、当社では英語と日本語の両方でユビキタス言語を定義していますが、ここではその具体的な内容は割愛させていただきます。これは、各用語の定義が開発チーム固有のコンテキストや解釈を含んでいるためです。
例1) Feature Flag (フィーチャーフラグ)
多くの開発者にとってFeature Flagは馴染みのある概念ですが、その解釈は人によって大きく異なります。プロジェクトメンバーの中には初めてこの用語に触れる人もいるため、プロジェクト開始時点で理解のギャップを解消すべく、Feature Flagをユビキタス言語として明確に定義しました。
例2) Managing Flags (定義されているFlagの管理)
「フラグの管理」という用語は、プロジェクトの初期段階から頻繁に使用されていましたが、議論を重ねる中で、この言葉が3つの異なる意味で使われていることが明らかになりました。
具体的には
- フラグの値の変更
- フラグの種類の管理
- フラグの追加・削除
という3つの意味で使用されていました。
これらの使い方はそれぞれ妥当でしたが、一つの言葉に複数の意味があることで混乱を招く可能性がありました。そこで、チームでの共通理解を促進するため、「Managing Flags (フラグの管理)」を明確に「フラグの種類を管理すること」と定義し、ユビキタス言語として確立しました。
例3) Toggle (トグルする)
「フラグの管理」の定義を明確にした後、「フラグの値の変更」を表す新しい用語が必要となりました。この概念を新たなユビキタス言語として定義することにし、「Feature toggle」「Toggle」「Switching」などの候補の中から、最終的に「Toggle」という用語に決定しました。
このような議論とユビキタス言語の定義プロセスは非常に重要です。もしこれがなければ、チームメンバーがそれぞれ異なる用語を使用することでコミュニケーションの混乱が生じ、運用上の問題につながった可能性があります。当社ではこれらのユビキタス言語をNotionのデータベースで一元管理しており、多種多様なドメインが存在する環境下でも、Single Source of Truthとして効率的に運用できています。特に、Notionのフィルタ機能を活用することで、大規模な用語集であっても、チーム全体で効率的に管理することが可能となっています。
必要に応じて、用語の定義を詳細に文書化する
Notionのデータベースでは、各ユビキタス言語に対して個別のページを作成できます。
これにより、用語の定義を必要な詳細度で文書化し、例えば「Toggle」の場合は機能のオン・オフに関する運用プロセスへのリンクを追加するなど、関連情報を効率的に整理することができます。
このような形で各用語の文脈を充実させることで、チーム全体の理解を深めることができます。
定義したユビキタス言語の仕様書への活用
ユビキタス言語を定義することは重要な第一歩ですが、それだけでは不十分です。実際の開発現場では、用語の解釈にズレが生じないよう細心の注意を払う必要があります。
仕様書はこの点で特に重要な役割を果たします。活用方法はシンプルで、仕様書内でユビキタス言語が登場する箇所をその定義ページへのリンクに置き換えるだけです。Notionではリンクがページタイトルとして自然に表示されるため、文章の読みやすさを保ちながら適切なコンテキストを提供できます。
この方法には二つの明確なメリットがあります。一つは仕様書をより簡潔に記述できること、もう一つはユビキタス言語の名称が変更された場合でもリンクを通じて自動的に更新される点です。これにより、ドキュメントの保守性が向上し、チーム全体で一貫した理解を維持できます。
以下、その例です。
もしかして新規機能に限った話では無いのでは…?
まさにその通りで、ユビキタス言語の活用は、実は新規機能開発だけに限らないです。既存機能の拡張やメンテナンスの際にも、新しいユビキタス言語を見つけて定義していくことがとても役立ちます。
ただし、既存の仕様書を全部書き直すのは大変ですよね。そこで、チーム横断的なユビキタス言語データベースを使って、少しずつドメインの内容を改善していくのがおすすめです。
このアプローチは導入が容易で、このブログで説明したユビキタス言語の活用方法を将来の機能開発にも応用できるなど、長期的なメリットがあります。
LegalOn TechnologiesのEngineering組織が大事にする価値観
私たちは「コードを書くスキル（＝質の高い"How"を考え、実行する）」と同様に、「正しく顧客課題を解決する（＝最適な"What"を考え、作る）」も重視しています。
ユビキタス言語などのツールを効果的に活用できることも、このスキルの重要な要素の一つです。
そして、こうしたプロダクトを正しく作るスキルが向上することで、実装フェーズではコーディングに集中できるようになり、結果として開発全体の質が向上する好循環が生まれると私たちは確信しています。
まとめ
ユビキタス言語は、機能開発において次のような重要な役割を果たします：
- チーム内の共通理解を促進し、コミュニケーションの混乱を防止します
- Notionのデータベースによる一元管理により、確実な情報源（Single Source of Truth）として機能します
- 仕様書への効果的な活用により、ドキュメントの簡潔さと保守性が向上します
高品質なプロダクトを開発するためには、ドメイン知識の深い理解とユビキタス言語の適切な活用が不可欠です。これらを実践することで、より効率的で質の高い開発が実現できます。
プロダクトの品質に妥協せず、より良い開発プラクティスを追求したい方、私たちと一緒に挑戦しませんか？ LegalOn Technologiesは、あなたの情熱とスキルを活かせるフィールドです。共にリーガルテックの未来を創っていきましょう！
