PM/デザイナー向け / ユビキタス言語の重要性と、そのコツ
January 1, 2023
Last edited time
Jan 15, 2023 04:08 PM
すべての事象には名がある。我々は先ずその対象に名前を付ける。そのためには対象の概念を明確にし、またそれ以外の事象との区別を持たなければならない。この過程で名前を付けた対象が明確になる。名前がないものは、他人にその対象を説明できないため存在を認識させるのが難しく、自らもその対象を明確にできなくなる。https://ja.wikipedia.org/wiki/名前
プロダクト組織の中でのユビキタス言語や命名について。名前というものにプロセスとしてどれぐらい向き合うかは、組織によって・また組織内でも温度差があります。
では、どれぐらい大事なのか。
大事にするというのはどれぐらいコミットすることなのか。
この記事では、名前をつけるということについて書くことにします。
ユビキタス言語とはなぜユビキタス言語は大事か不揃いが不揃いを再生産するなら、最初からきちんと設計すべき命名にコストをかけるべきである個人的・ユビキタス言語の勘所英語でつける・英語を添えるユーザーが見ているものに揃えすぎない略さない・造語を発明しないシンプルにつける・具体的につける慣れのコストを恐れない運用にのせる言葉のあり方は、組織をある側面から象徴する
ユビキタス言語とは
私たちがむきあうデジタルプロダクトはとても複雑で、遅かれ早かれ、概念を効果的に整理する必要性にかられます。そこで登場するのがユビキタス言語です。
ユビキタス言語は、ドメイン駆動設計（DDD, Domain-driven design）の注視的な概念のひとつで、今日ではしばしばエンジニア発信で提示されます。
Eric Evansの「Domain Driven Design」（2003年）で紹介された設計手法で、ソフトウェア製品の要件に関する議論だけでなく、設計の議論や「製品のソースコードそのもの」まで、あるビジネスドメインの語彙を使うように努める設計思想https://www.agilealliance.org/glossary/ubiquitous-language/
要は、組織内で共通言語で物事を扱っていくことで、スムーズにプロジェクトを進めよう、そして共通言語を整備することに価値をみとめようという運動と解釈しています。
なぜユビキタス言語は大事か
何らかのかたちでコードで開発されているということは、名前のあやふやなものがあっても、最後はどうせ誰かがつけています。そして、変数名などはPMやデザイナーの知らないところで、コードレビューや議論されていたりします。
ということは、全体感をもってプロジェクト内の概念をみわたせる立場の人が、上流時点で命名を大事にしたほうがよい。そのとき見えてる範囲でもいいので。
仮に、企画者（PM）・設計者（デザイナーとエンジニア）・開発者（エンジニア）が完全に分断されているプロセスであったなら、次のようになるでしょう。
- 名前が曖昧なまま物事が企画される
- デザインがしあがる
- 開発者におまかせ：最後に実装する段階で、開発者がどうせコード上でしか使わないしとひっそりと何か名前をつける
（世の中ではこういうことがけっこうある）どれぐらいこれにこだわれるかは、組織的に共通言語をもつモチベーションがあるか。
不揃いが不揃いを再生産するなら、最初からきちんと設計すべき
「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」https://ja.wikipedia.org/wiki/割れ窓理論
ユビキタスのおざなりな組織の名前空間はあっというまに荒廃します。
命名を重視しない文化、マスタ的な呼び名の不存在は、今日もあなたの知らないどこかで、新しい揺れを生み続けます。
そして、把握のできないものの見積もりはできません。ユビキタスに着手するモチベーションがあるなら、早くやるに越したことはありません。できることは、放っておいて管理コストをゼロにするか、今やるかです。
（しばらく放っておいて後で整理する、も立派な戦略です。事業が根幹からピボットするかもしれないフェーズであれば、命名どころじゃないかもしれません。）
命名にコストをかけるべきである
ユビキタス言語は当然、売上をつくってくれません。
しかし、事業のスピードに（経営者のあずかりしれない領域で）影響します。名前は、プロダクトに関わる多くの人が自社のドメインや技術を理解し、使うものです。
通常、事業は成長することを想定するので、関わる人も増える想定のなかで私たちは行動する。それらは早い段階で、少しでも滑らかであるべきです。
少なくとも、開発プロセスの凝集性を担保しやすいという意味では、あなたの所属が事業会社であるならば積極的にとりくむべきでしょう。
少し大げさにいうと、ユビキタス言語の策定と運用は、組織内のもっとも理解力や経験のある忙しい人を借り出してでも取り組む価値があることだと考えています。
もちろん、「名が実体を表している」「わかりやすい」「覚えやすい」をすべて中長期的に実現するのは現実的に難しいことです。中の人のわかりやすさのためにビジネスをしているわけではない。
だけど、ユビキタス言語について努力することは、とてもコスパのよい判断だと思っています。
タイトルを「PM/デザイナー向け」とわざわざ書いたのは、エンジニア以外の職種も言葉について考えることは、実はとても大きなレバレッジがあると考えたからです。
ユビキタス言語の必要性を感じたり、メリットを体感するということは、あなたが組織にむきあう射程が広い状態にあるということだと思います。
それも、領域的な広さ・時間的な広さとで。
個人的・ユビキタス言語の勘所
ユビキタス言語の重要性については、エンジニアを中心とした人々から多くの良記事がたくさんあります。
ただ、具体的な勘所については組織や経験則によって万別で、あまり知見がでていない。
それではユビキタス言語をどのようなスタンスで策定・運用するかを少し考えてみる。
ということで、ユビキタスに取り組むひとのために、個人的な経験則からの勘所をいくつか紹介しますので、参考までにご覧ください。（相性は組織によるので、所属するマイベストにも合うかはまだ考えているところです）
英語でつける・英語を添える
個人的にまず勧めたいのは、ほとんどのものを英語で呼ぶようにすることです。
- 前半で述べたように、ユビキタスがあろうとなかろうと、あらゆる概念はコードやデータベース設計で応用できるから。
- 口頭での揺れをふせぐことができるから。
私たちは日本語でつけられた通称名のようなものをつい言い換えて使いがちです。しかし、英語でいわれていれば、一般名詞と、業務上何らか意味をもつ名詞を区別することができます。
たとえば、ユーザーが一番最初に目にする画面、すぐトップ・ホーム・マイページ……って揺れがちです。それがHomeと文字で呼び習わされていて、エンジニアがHomeを共通言語としているならば、他の職種もきちんと統一される気がしませんか？
昔いた英語公用語の会社では、仕様書を書くときの決まりとして「見出しには日本語 - 英語 で併記すること」がありました。それは単純に海外の開発者のためのものでしたが、日本人同士でも英語の固有名詞を好んで使っていた経験があったからの学びでした。
なので、私がNotionなどで仕様書を書くときはかならず英語名を書くようにしていますし、新しいワードがあれば、英語でなんていいならされているか調べてドキュメントに落としています。
ユーザーが見ているものに揃えすぎない
通常、呼び方と、画面に表示されているものが共通していることはとてもわかりやすい。たとえば、「購入」というボタンがあったら、やはり「購入ボタン」とよべば一目瞭然です。わかりやすい。マイベストでは長年緑色のボタンがあるので「緑ボタン」として親しまれています。かわいくてわかりやすい。
問題は、サービス上での表示は結局ビジネス最適で変化しうることです。表示するテキストや色は、プロダクト改善ですぐに試せるオプションの筆頭です。
だから、そうしたものには潔く
ConversionButtonとか、CTAとか、購入動線とか、概念的な名前をつけておくとつぶしが効きます。それに、ユーザーに表示しているテキストは、そのコンテクストでユーザーに最適なテキストを表示するわけなので、プロダクト全体を把握すべき中の人たちが区別しやすいものになっているとは限りません。ページAでは購入、ページBでは詳細、というラベルがついててもおかしいとは限らない。
だから、実際の表示と揃えるべきという縛りをもたないほうが中長期的に望ましいと捉えています。
デザインチームでは、色名も
greenではなくprimaryとよぶことにしました。マイベストのprimary colorがいま、たまたまgreenであるだけのことです。少し別の話で言えば、サービス名もそう。サービス名もドメインもいつかリニューアルするときが来ます。今時点の「どうせこないでしょ」という見立てにはあまり価値がない。サービス名は至るところで使用されるので、一見意味のなさそうなコードネームを設けておくと最小限の置き換えで済むので便利です。
私も昔はあまりいい響きではないコードネームに違和感を感じてましたが、中長期で関わったサービスはほぼ必ず途中でサービス名変更を経験しています。
略さない・造語を発明しない
社内独自の略語は、なるべくつくらないほうがよいと思っています。
- 略語が混ざっている状態は、どの言葉が略されていて略されていないかわからない。
- ユビキタスの趣旨からすれば、略さない用法と、略した用法がどちらも通用する時点で怪しい。
略語のメリットはそのドメインに詳しい人が書きやすい・読みやすいことがピークです。そこから見る人が広がったり時間が経つとデメリットにかわります。
造語も同様です。どれとして全く同じプロダクトはこの世にありませんが、それを構成する概念はだいたい世の中から流用できるはず。
略語・造語がワークするような場面もあると思います。社内の誰もが必ず無理なく理解できるようなメジャーな用語（部署名とか、mixiの「マイミク」のような象徴的な用語）に対しては問題ないかもしれません。
また、世間一般で通用する略語（MTG・Meeting・打ち合わせ）の揺れも、検索性を高めるためにはなるべく方針を統一したほうがよいでしょう。
シンプルにつける・具体的につける
先にシンプルにしてみましょう。
たとえば、検索機能の画面に名前をつけるとします。シンプルにしすぎると
日本語 | 英語 |
検索 | Search |
履歴 | History |
結果 | Result |
のように、他のドメインでもつかえなくなってしまいます。
これを少し具体的にするとこうなります。
日本語 | 英語 |
検索 | Search |
検索履歴 | SearchHistory |
検索結果 | SearchResult |
こうすると、すべてSearchのドメインに属することがわかり、そして「検索画面 - Search」がもっともそれらの上位にあることがわかります。整理された名前は構造化の表れ。
ざっくりいうと、構造的に命名をすると、メジャーなものはシンプルに、マイナーなものは複雑になるはずです。
複雑な名前がついているということは、ひと目でドメインが深いことがわかります。
「〇〇向けXX」というユビキタスがあれば、XXには〇〇以外のバリエーションがあることがわかります。
ドメインを識別する
一方で、具体的にするときに、他の領域と識別しやすい命名を考えたほうがいいでしょう。
よくある言い方に「表側・裏側」という便利そうなことばがあります。
シンプルで端的ですが、コンテクストによってかなり捉え方がブレるおそれがあります。画面に対してこれを言うと「公開画面・非公開画面」「ユーザー画面・管理者画面」「フロントエンド・バックエンド」という色々な解釈ができます。
だから、あまりに包括的な・抽象的な名称は避けて、そのとき可能な方法で限定化につとめた呼び名がよいでしょう。
慣れのコストを恐れない
命名の整理が業務内容にかかれている人はいないし、給料が上がる人もいません。命名について話し合うなど、THE 重い腰をあげることです。
もし、すでに社内で慣れている呼び方があるがために、変更の提案をためらう必要はありません。人は業務で使うものに関してはあっという間に慣れてしまうものです。過去の文書との整合性が気になるにしても、よい命名をすればよかったと噛みしめればよいのだと思います。
ただし、以下の場合は命名は大きなコストになりうるので検討の余地があります。
- 社外のステークホルダが関係する場合
- ソースコードを大幅にリファクタする必要がある場合
もし命名を変えていくのであれば、緩い温度感ではなくいままでも長い寿命で運用に使っていく気概と品質が必要だとおもいます。
運用にのせる
こうしたものを整備する努力には、浸透しないのではないかという恐怖がつきまといます。
ユビキタス言語が定着するために大事なのは、揃えるメリットを体感できること、逆をいえば揃えないデメリットがあること。
あらかじめ用語の正しさ・わかりやすさが、運用フローに必須の状態になっていることが効果的です。
個人的に、仕組みやルールの言い出しっぺになることが多いので、よくつかう組織変革のフレームワーク や イノベーション普及理論をベースに普及策を考えたりしています（本来はもっとスケールの大きなものに使うのですが）。
- 推進役を複数名たてる
- 誰か1人ががんばっても普及しないので、最初からどうすると組織内にいきわたるかを人員面から設計する。
- 関係するエリアの人がバランスよく含まれていること。エンジニア・ディレクター・デザイナーを含めたり、複数のプロジェクトに関与している人をあてる。
- 使いやすいかたちを考える
- ユビキタスがない場合にどうするかを示しておく
- 検索性の高いマスタ文書を
- Notion Databaseで呼び出しやすい形式にしておく
- その時点で決まっていないルールがあれば積極的に言語化する
- 短期的成果 = ケーススタディを実現する
- 人は、あたらしいものが観察可能なかたちで適用され始めると一気に順応することができる。
- 見る人の多い大きな仕様書やドキュメントを作成する機運があれば、一気に変える。 それをユビキタス言語のショーケースにすることができる。
- 一括で置換ができる過去の成果物があれば、ぜひアップデートする。
- 定期的に見直す
- 概念は期中にも自然発生するので、それらを回収する取り組みを定期化する
言葉のあり方は、組織をある側面から象徴する
冒頭でさんざん意義を強調しましたが、所詮呼称なので時間がたつと多少不揃いがでてくるのはふつうだと思います。
正解はないものなのだから、多少わかりにくくても・堅牢さに欠けていても、組織内で命名に関するスタンスが議論されること。一定のレベルで共通言語を運用していること自体が大事だと思います。
ユビキタス言語の浸透度合いは、いくつかの側面からプロダクト組織を象徴していると思います。それがしめすのは、
- 効果的な仕組みを整備する・それを提言する土壌があること
- 組織のプロセスが職種を超えて一体化していること
これから組織に入ってくる人はそれを見ています。
以上。先日、ドキュメント書こうぜという記事も書いたので、興味のある人はこちらもどうぞ。
Author
Yasuhiro Yokota
1991-, Designer
大学卒業後、行政機関で情報政策部門で勤務。株式会社ワークスアプリケーションズを経た後、フリーランスでグラフィック・デジタル双方のデザイン及びディレクションを通し、様々なプロジェクトに携わる。株式会社TERASSに創業期からシリーズBまで参画した後、2022年9月にマイベスト入社。グロービス経営大学院卒業。
Drafts
Yasuhiro Yokota Today
This website is a private and sloppy collection of writings and personal information by Yasuhiro Yokota, a designer in Tokyo.
All data is based on the Notion Database and several APIs.
Built with Chakra UI, NextJS & Vercel.