ユビキタス言語づくりには、どんなメリットがあるのか
先日、社内ドキュメントとして「ユビキタス言語って、何がおいしいの？」というタイトルで、ユビキタス言語というものについて、徒然なるままに書きました。これは、それに加筆・修正したリライト版です。
“ユビキタス”とは
ユビキタス (ubiquitous) は、遍在（いつでもどこでも存在すること）をあらわす言葉。元はラテン語で、「（神は）あまねく存在する」という宗教用語です。
転じて、ユビキタス・コンピューティングという概念で、「いつでも、どこでも」ほしい情報が得られ、大量の情報を交換でき、だれもが利用しやすいコンピュータ環境をつくることを指していました。その後、ユビキタス・ネットワークだとか、ユビキタス社会だとかという概念に派生していきました。
ユビキタス言語を語るには避けて通れない「ドメイン駆動設計（DDD)」
ユビキタスが表す概念を説明したところで、もう一つユビキタス言語を説明するうえで説明が必要なものがあります。それが「ドメイン駆動設計(以下、DDD)」です。ユビキタス言語は、開発手法の一つであるDDDで、開発プロセスの一つとして推奨されています。
DDDは、エリック・エヴァンスが考えたソフトウェア技法。現実世界の複雑な問題領域を“ドメイン”と呼び、それをソフトウェアに落とし込むためのアプローチを体系立てています。
特徴的なのが、DDDは、エンジニアに限らずプロダクトに関わるメンバー全員で実践することを提唱しています。ドメインエキスパートを筆頭に、セールス、カスタマーサクセスなどからも情報を得て、ドメインに対する共通認識を持ちます。
SmartHRは、意識的にDDDを取り入れていると断言できませんが、PMM(プロダクトマーケティングマネージャー）が開発チームとマーケティング、セールス、カスタマーサクセスとの橋渡しをしてくれたり、カスタマーサポート（チャット対応をするメンバー）がプロダクトサイドに属していたり、ドメインエキスパートがPMを務めるプロダクトがあるなど、自然とDDDを実践できる土壌ができあがっていると考えています。（これは、私個人の意見です）
ユビキタス言語は単なる「用語集づくり」ではない
「ユビキタス言語」とは、ドメインに対して、同じ言葉を使い、同じモノを認識するための定義のことを指します。
最初に説明した「ユビキタス＝いつでもどこでも偏在する」という単語は、いつでもどこでも誰もが使う言葉という意味を持っています。ここで大切なのは、「いつでもどこでも誰もが」と「使う」という2つの観点です。
この観点を損なえば、ただの用語集で終わってしまいます。
言葉を使うことで、共通認識が生まれる
人間は言葉を通して、概念を構築して「知った」「わかった」という状態になります。同じ言葉を使ってコミュニケーションをとれば、そこに共通認識が生まれるというわけです。
「ユビキタス言語は作るだけではダメで、使わなければ意味がない」と言われます。DDDが向き合う課題は、複雑であることが前提にあります。複雑ということは、その解釈も人それぞれになりかねません。そこに、ドメインという複雑な世界を理解するための土台として、必要不可欠な言葉（概念を定義したもの）があって、それらを使って会話をすること自体、ドメインに対する共通認識に繋がっていきます。
開発者に限らず、「みんな」で使う
「ユビキタス言語」は、開発者にしか馴染みが薄いかもしれません。しかし、そこで定義した言葉は、プロダクトやサービスを通じてユーザーはもちろん、それを届けるセールスやマーケティングも関わるすべての人が使うことが理想です。
開発者のうち、UXライターがユビキタス言語づくりをリードすると良いのは、プロダクトの扱うコンテキストを把握し、ユーザーのメンタルモデルを理解しているからです。（UXライターがいない方が多いと思うので、その場合はプロダクトマネージャーやプロダクトデザイナーがそこを担うことになるでしょう）
新しい言葉を生み出す場合には「使いやすい」言葉、すでにユーザーにとって馴染みのある言葉があれば、それを用います。
メンタルモデルの詳しい説明は、このドキュメントを読んでね。（スライド有）
ユビキタス言語のつくり方
では、実際に私がどうやってユビキタス言語を作ったかを2023年8月にリリースした「スキル管理機能」を例にとって、少しまとめたいと思います。
モデルの設計段階で検討する
理想的なのは、データモデルの設計段階(※)からオブジェクト図を見ながら名前を考えられると良いです。オブジェクトの関係性が俯瞰して把握できるので、エンジニアやデザイナーが作成したモデルの物理名を見ながら、「一貫性を保てているか」「理解しやすいか」「拡張しやすいか」「名付けは適当か」という視点で見ていきます。
その上で、論理名の方を決めると、よりよいユビキタス言語が作れます。
【用語解説】
論理名
アプリケーションのインタフェースなどにおいて人間にとって識別しやすい名前。ユーザー向けには論理名を使います。
物理名
コンピューターが情報処理するときに必要な名前。データベースがテーブルを識別するために使われます。
スキル管理機能は、2023年9月時点では、従業員の「スキル」、「資格」、「研修」の項目を登録・管理できます。実は、一番最初にUXライターに声がかかった時には、開発チームは「従業員のスキル」を定義するものとして「技能」「資格」「研修」というオブジェクトを管理することを考えていました。それに対して、「技能」と「スキル」の違いは分かりづらく混乱を生みそうだと気になりました。そこで、いっそのこと「技能」を「スキル」にしてしまい、関連する「資格」や「研修」がある場合は紐づけできるようにすればという結論に至りました。
先ほどのエピソードの他にも、開発過程でモデリングのレビューに加わったりしながら、名前を作っていきました。（スキル管理機能の立ち上げチームは、スクラムの手法を取り入れていたので、他職種もレビューに加わることが多くありました。その辺りの話は明日9月26日にオンラインイベントを実施するのでご興味ある方はぜひ。まだ枠あります！ご自宅から参加できます！！）
後からでも遅くはない
「もう、すでにプロダクトは動いているよ…」という場合でも遅くはありません。その場合の作り方は以下の順番が早いでしょう。
オブジェクトとプロパティ、オブジェクトに対するアクションを洗い出す
オブジェクトごとにセクション分けして論理名をつけていく
ユビキタス言語を管理する場所
作り方よりも大事なのは、「使っていく」ための工夫です。
ユビキタス言語は、「みんな」の目につくところに置いておくことが肝心です。
Spreadsheetなどで管理した方が正直記載しやすく、ラクですが、私たちは会社のドキュメントツールの中に作成しました。開発者だけしか閲覧しない場所に置いておけば、冒頭で説明したユビキタス言語を定義する意義が半減してしまうと考えたからです。
実際、スキル管理機能のユビキタス言語を公開するなり、真っ先に「お気に入り」に入れてくれたのは、マーケティングプランニングの担当者でした。スキル管理機能に関しては、ユビキタス言語とは別にプロダクトにはないけれど、プロダクトを説明するときに表現がユレてしまう業務（例：人員配置 or 人材配置）を訴求文言リストとして別に管理していました。これは個人的な考えですが、ユビキタス言語を作って使うことはドメインに対する共通認識を作るためなのだから、物理名がないものもユビキタス言語としてまとめるのが最終的な理想形なのではないでしょうか。そうすることで、プロダクトやサービスの導入検討時点からのタッチポイントも含めたUXが連なっていくと考えられます。
誰が管理するの？
少し話が逸れてしまいましたが、実運用の話に戻ります。
ユビキタス言語の管理は、基本的には開発者になるでしょう。ただし、論理名を考えるのは開発者である必要はありません。ドメインを意識した名づけを開発者自身ができるようになることも大切ですが、スプリントレビューでステークホルダーからのFBをもらう意識を持つことの方が、すぐにできるアクションです。
繰り返しになりますが、ユビキタス言語は「みんな」のものです。
フィードバックを消化して開発に活かす
最後に、ユビキタス言語よりもスコープを広げた話をします。ユーザーのドメインを意識して開発することは、簡単なことではありません。
特に「さまざまな属性のユーザーを対象としていること」、「アップデートを繰り返し、拡張していくことが前提でユーザーに使い続けてもらうこと」という特徴をもつ業務アプリケーションSaaSの開発では、社内の開発者以外からのフィードバックやVoCに耳を傾け、ドメインを理解しながら、どの課題に優先的にリソースを投下するかを考える必要もあります。
そこで大切なのは、フィードバックを鵜呑みにしないことだと思います。フィードバックはさまざまな立場からもたらされます。それらを開発チームとして消化して解決していくこと、そしてその考えを周囲にきちんと伝えることが必要だと思います。
そうしたときに、ユビキタス言語を使ってコミュニケーションが成立すれば、ユビキタス言語も発展し、プロダクトやサービスを中心とした共通認識が広く作られるのではないかと思います。
私たちもまだまだ道半ばではありますが、これからもユーザーの課題解決のためのさまざまなアプローチを試行錯誤していきたいなと考えています。
【注釈】
※ SmartHRでは、データモデルを媒介にして要件定義を詰めていくことが多いです。私は、以下の本で勉強しました。