January 2, 2023

PM/デザイナー向け / ユビキタス言語の重要性と、そのコツ

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)・設計者(デザイナーとエンジニア)・開発者(エンジニア)が完全に分断されているプロセスであったなら、次のようになるでしょう。
  1. 名前が曖昧なまま物事が企画される
  1. デザインがしあがる
  1. 開発者におまかせ:最後に実装する段階で、開発者がどうせコード上でしか使わないしとひっそりと何か名前をつける
(世の中ではこういうことがけっこうある)どれぐらいこれにこだわれるかは、組織的に共通言語をもつモチベーションがあるか。

不揃いが不揃いを再生産するなら、最初からきちんと設計すべき

「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」https://ja.wikipedia.org/wiki/割れ窓理論
ユビキタスのおざなりな組織の名前空間はあっというまに荒廃します。
命名を重視しない文化、マスタ的な呼び名の不存在は、今日もあなたの知らないどこかで、新しい揺れを生み続けます。
そして、把握のできないものの見積もりはできません。ユビキタスに着手するモチベーションがあるなら、早くやるに越したことはありません。できることは、放っておいて管理コストをゼロにするか、今やるかです。
(しばらく放っておいて後で整理する、も立派な戦略です。事業が根幹からピボットするかもしれないフェーズであれば、命名どころじゃないかもしれません。)

命名にコストをかけるべきである

ユビキタス言語は当然、売上をつくってくれません。 しかし、事業のスピードに(経営者のあずかりしれない領域で)影響します。名前は、プロダクトに関わる多くの人が自社のドメインや技術を理解し、使うものです。
通常、事業は成長することを想定するので、関わる人も増える想定のなかで私たちは行動する。それらは早い段階で、少しでも滑らかであるべきです。
少なくとも、開発プロセスの凝集性を担保しやすいという意味では、あなたの所属が事業会社であるならば積極的にとりくむべきでしょう。
少し大げさにいうと、ユビキタス言語の策定と運用は、組織内のもっとも理解力や経験のある忙しい人を借り出してでも取り組む価値があることだと考えています。
もちろん、「名が実体を表している」「わかりやすい」「覚えやすい」をすべて中長期的に実現するのは現実的に難しいことです。中の人のわかりやすさのためにビジネスをしているわけではない。
だけど、ユビキタス言語について努力することは、とてもコスパのよい判断だと思っています。
タイトルを「PM/デザイナー向け」とわざわざ書いたのは、エンジニア以外の職種も言葉について考えることは、実はとても大きなレバレッジがあると考えたからです。
ユビキタス言語の必要性を感じたり、メリットを体感するということは、あなたが組織にむきあう射程が広い状態にあるということだと思います。 それも、領域的な広さ・時間的な広さとで。
 

個人的・ユビキタス言語の勘所

notion image
ユビキタス言語の重要性については、エンジニアを中心とした人々から多くの良記事がたくさんあります。
ユビキタス言語策定したらビジネス理解がめっちゃ捗った話
こんにちは、 Leaner Technologies の 石渡(@mishiwata1015) です。 最近、 レヴィアス というボードゲームにハマっていて、子供が寝た後に妻と遊んでいます。 今回は、 Leaner見積 におけるユビキタス言語を策定したので、その話をします。 ユビキタス言語は、開発者やドメインエキスパートを含むチーム全体の共通言語として定義され、チーム内の会話、ドキュメントやコードに至るまで統一的に使用される言葉になります。 DDD の文脈で登場するものですね。 ユビキタス言語によって同じ単語で同じ認識を得ることが可能となるため、チーム内のコミュニケーションが円滑になります。コミュニケーションミスを減らす効果もあります。 とにかく表記揺れを統一したい! というモチベーションでユビキタス言語を策定しようと思いました。このときは特に DDD 目的では無かったです。 具体的には以下のような状況でした。 プロダクトの UI 上で表記揺れ ヘルプページや自動送信メール内にも表記揺れ チーム内での会話でも同じ意味で異なる言い回しが散見 カオスですね。 それぞれ絶妙な揺れ方だったので意味は通じており、今のところ大きな問題にはつながっていませんでした。 社内にはユビキタス言語の原型となるドキュメントもあるにはあったのですが、作成途中のまま放置されていました。悲しい。 表記揺れが多い状態を放置すると、扱う概念が増えたときに破綻する(コミュニケーションコストが爆増する)という個人的な経験もあり、 整備するならプロダクトやチームの規模が小さい今しかないかなーと考えて、石渡がオーナーとなってユビキタス言語を策定していくことにしました。 また、Leaner へ入社したばかりだったのでユビキタス言語策定を通してプロダクトの現状理解や、「調達」という対象ドメインへの理解を深めたい、という狙いもありました。 ユビキタス言語をどこで管理するか迷ったのですが、以下の理由により Notion で管理することにしました。 Leaner ではドキュメントツールに Notion を使用している まだオープンにできない開発中の機能に関する単語が含まれることもある GitHub ではプライベートリポジトリで管理せざるを得ない ビジネスメンバーにも GitHub アカウント持ってもらうのは面倒かも ユビキタス言語だけ中途半端に GitHub 管理するよりは、 Notion で一元管理できるメリットの方が大きそう 変更履歴の情報は、 Notion 上でもメモとして残しておけるのでそれで十分そう 情報の永続化も、Notion のページロック機能で十分そう Notion 使い倒してみたい まずは、プロダクト内の文言とか社内の会話から重要そうな概念をピックアップして一覧化し、それからチーム内で各単語の認識を擦り合わせていこうと考えました。 Notion 上にざっくり洗い出した単語に対して、ドメインエキスパートであるビジネスサイドのメンバーも交えて以下の観点で話し合いました。 この単語が何を指すかパッと分かるか もっと分かりやすい、より良い単語はないか 同じ意味としてまとめてしまって良い単語なのか、悪い単語なのか 微妙なニュアンスの違いを区別する必要があるのか、ないのか ビジネス上重要な概念について、どんな単語で識別するのが自然なのか この時間はとても有意義でした。 対象ドメインを理解するならドメインエキスパートとの会話が一番、ということを実感できました。 例として、 「発注依頼」 という単語のディスカッションが面白かったので紹介します。 Leaner見積 は、見積業務の効率化を目的としたプロダクトで、以下の概念が登場します。 見積依頼・発注する側の「バイヤー(買い手)」 見積回答・納品する側の「サプライヤー(売り手)」 バイヤーにとっての「発注依頼」アクションは、「発注書」のやり取りがなければそれは口頭合意レベルであり、正確には「発注依頼」とは呼べなくて「発注先確定」が合ってそう、みたいな突っ込んだところまで整理できました。 画像引用元: https://advisors-freee.jp/article/category/cat-big-03/cat-small-10/7460/ このディスカッションを通して、発注を含む単語をうかつに使わない方がよさそうだな、とか、書類のやり取りが発生するかどうかが重要、みたいな知見を開発チーム内にも共有できました。 今後のモデルやメソッドの命名にも役立ちそうですね。 こんな感じで、ユビキタス言語策定の中で ...
ユビキタス言語策定したらビジネス理解がめっちゃ捗った話
 
ただ、具体的な勘所については組織や経験則によって万別で、あまり知見がでていない。
それではユビキタス言語をどのようなスタンスで策定・運用するかを少し考えてみる。
ということで、ユビキタスに取り組むひとのために、個人的な経験則からの勘所をいくつか紹介しますので、参考までにご覧ください。(相性は組織によるので、所属するマイベストにも合うかはまだ考えているところです)
 
notion image

英語でつける・英語を添える

個人的にまず勧めたいのは、ほとんどのものを英語で呼ぶようにすることです。
  1. 前半で述べたように、ユビキタスがあろうとなかろうと、あらゆる概念はコードやデータベース設計で応用できるから。
  1. 口頭での揺れをふせぐことができるから。
私たちは日本語でつけられた通称名のようなものをつい言い換えて使いがちです。しかし、英語でいわれていれば、一般名詞と、業務上何らか意味をもつ名詞を区別することができます。
たとえば、ユーザーが一番最初に目にする画面、すぐトップ・ホーム・マイページ……って揺れがちです。それがHomeと文字で呼び習わされていて、エンジニアがHomeを共通言語としているならば、他の職種もきちんと統一される気がしませんか?
昔いた英語公用語の会社では、仕様書を書くときの決まりとして「見出しには日本語 - 英語 で併記すること」がありました。それは単純に海外の開発者のためのものでしたが、日本人同士でも英語の固有名詞を好んで使っていた経験があったからの学びでした。
なので、私がNotionなどで仕様書を書くときはかならず英語名を書くようにしていますし、新しいワードがあれば、英語でなんていいならされているか調べてドキュメントに落としています。
 
 
notion image

ユーザーが見ているものに揃えすぎない

通常、呼び方と、画面に表示されているものが共通していることはとてもわかりやすい。たとえば、「購入」というボタンがあったら、やはり「購入ボタン」とよべば一目瞭然です。わかりやすい。マイベストでは長年緑色のボタンがあるので「緑ボタン」として親しまれています。かわいくてわかりやすい。
問題は、サービス上での表示は結局ビジネス最適で変化しうることです。表示するテキストや色は、プロダクト改善ですぐに試せるオプションの筆頭です。
だから、そうしたものには潔くConversionButtonとか、CTAとか、購入動線とか、概念的な名前をつけておくとつぶしが効きます。
それに、ユーザーに表示しているテキストは、そのコンテクストでユーザーに最適なテキストを表示するわけなので、プロダクト全体を把握すべき中の人たちが区別しやすいものになっているとは限りません。ページAでは購入、ページBでは詳細、というラベルがついててもおかしいとは限らない。
だから、実際の表示と揃えるべきという縛りをもたないほうが中長期的に望ましいと捉えています。
デザインチームでは、色名もgreenではなくprimaryとよぶことにしました。マイベストのprimary colorがいま、たまたまgreenであるだけのことです。

少し別の話で言えば、サービス名もそう。サービス名もドメインもいつかリニューアルするときが来ます。今時点の「どうせこないでしょ」という見立てにはあまり価値がない。サービス名は至るところで使用されるので、一見意味のなさそうなコードネームを設けておくと最小限の置き換えで済むので便利です。
私も昔はあまりいい響きではないコードネームに違和感を感じてましたが、中長期で関わったサービスはほぼ必ず途中でサービス名変更を経験しています。
 
 
notion image

略さない・造語を発明しない

社内独自の略語は、なるべくつくらないほうがよいと思っています。
  • 略語が混ざっている状態は、どの言葉が略されていて略されていないかわからない。
  • ユビキタスの趣旨からすれば、略さない用法と、略した用法がどちらも通用する時点で怪しい。
略語のメリットはそのドメインに詳しい人が書きやすい・読みやすいことがピークです。そこから見る人が広がったり時間が経つとデメリットにかわります。
造語も同様です。どれとして全く同じプロダクトはこの世にありませんが、それを構成する概念はだいたい世の中から流用できるはず。
略語・造語がワークするような場面もあると思います。社内の誰もが必ず無理なく理解できるようなメジャーな用語(部署名とか、mixiの「マイミク」のような象徴的な用語)に対しては問題ないかもしれません。
また、世間一般で通用する略語(MTG・Meeting・打ち合わせ)の揺れも、検索性を高めるためにはなるべく方針を統一したほうがよいでしょう。
 
 
notion image

シンプルにつける・具体的につける

先にシンプルにしてみましょう。
たとえば、検索機能の画面に名前をつけるとします。シンプルにしすぎると
日本語
英語
検索
Search
履歴
History
結果
Result
のように、他のドメインでもつかえなくなってしまいます。
これを少し具体的にするとこうなります。
日本語
英語
検索
Search
検索履歴
SearchHistory
検索結果
SearchResult
こうすると、すべてSearchのドメインに属することがわかり、そして「検索画面 - Search」がもっともそれらの上位にあることがわかります。整理された名前は構造化の表れ。
ざっくりいうと、構造的に命名をすると、メジャーなものはシンプルに、マイナーなものは複雑になるはずです。
複雑な名前がついているということは、ひと目でドメインが深いことがわかります。 「〇〇向けXX」というユビキタスがあれば、XXには〇〇以外のバリエーションがあることがわかります。
 
ドメインを識別する
一方で、具体的にするときに、他の領域と識別しやすい命名を考えたほうがいいでしょう。
よくある言い方に「表側・裏側」という便利そうなことばがあります。 シンプルで端的ですが、コンテクストによってかなり捉え方がブレるおそれがあります。画面に対してこれを言うと「公開画面・非公開画面」「ユーザー画面・管理者画面」「フロントエンド・バックエンド」という色々な解釈ができます。
だから、あまりに包括的な・抽象的な名称は避けて、そのとき可能な方法で限定化につとめた呼び名がよいでしょう。
 
 
notion image

慣れのコストを恐れない

命名の整理が業務内容にかかれている人はいないし、給料が上がる人もいません。命名について話し合うなど、THE 重い腰をあげることです。
もし、すでに社内で慣れている呼び方があるがために、変更の提案をためらう必要はありません。人は業務で使うものに関してはあっという間に慣れてしまうものです。過去の文書との整合性が気になるにしても、よい命名をすればよかったと噛みしめればよいのだと思います。
ただし、以下の場合は命名は大きなコストになりうるので検討の余地があります。
  • 社外のステークホルダが関係する場合
  • ソースコードを大幅にリファクタする必要がある場合
もし命名を変えていくのであれば、緩い温度感ではなくいままでも長い寿命で運用に使っていく気概と品質が必要だとおもいます。
 
 
notion image

運用にのせる

こうしたものを整備する努力には、浸透しないのではないかという恐怖がつきまといます。
ユビキタス言語が定着するために大事なのは、揃えるメリットを体感できること、逆をいえば揃えないデメリットがあること。
あらかじめ用語の正しさ・わかりやすさが、運用フローに必須の状態になっていることが効果的です。
 
個人的に、仕組みやルールの言い出しっぺになることが多いので、よくつかう組織変革のフレームワーク イノベーション普及理論をベースに普及策を考えたりしています(本来はもっとスケールの大きなものに使うのですが)。
 
  1. 推進役を複数名たてる
    1. 誰か1人ががんばっても普及しないので、最初からどうすると組織内にいきわたるかを人員面から設計する。
    2. 関係するエリアの人がバランスよく含まれていること。エンジニア・ディレクター・デザイナーを含めたり、複数のプロジェクトに関与している人をあてる。
  1. 使いやすいかたちを考える
    1. ユビキタスがない場合にどうするかを示しておく
    2. 検索性の高いマスタ文書を
    3. Notion Databaseで呼び出しやすい形式にしておく
    4. その時点で決まっていないルールがあれば積極的に言語化する
  1. 短期的成果 = ケーススタディを実現する
    1. 人は、あたらしいものが観察可能なかたちで適用され始めると一気に順応することができる。
    2. 見る人の多い大きな仕様書やドキュメントを作成する機運があれば、一気に変える。 それをユビキタス言語のショーケースにすることができる。
    3. 一括で置換ができる過去の成果物があれば、ぜひアップデートする。
  1. 定期的に見直す
    1. 概念は期中にも自然発生するので、それらを回収する取り組みを定期化する
    2.  
 
 
notion image

言葉のあり方は、組織をある側面から象徴する

 
冒頭でさんざん意義を強調しましたが、所詮呼称なので時間がたつと多少不揃いがでてくるのはふつうだと思います。
正解はないものなのだから、多少わかりにくくても・堅牢さに欠けていても、組織内で命名に関するスタンスが議論されること。一定のレベルで共通言語を運用していること自体が大事だと思います。
ユビキタス言語の浸透度合いは、いくつかの側面からプロダクト組織を象徴していると思います。それがしめすのは、
  1. 効果的な仕組みを整備する・それを提言する土壌があること
  1. 組織のプロセスが職種を超えて一体化していること
これから組織に入ってくる人はそれを見ています。
以上。先日、ドキュメント書こうぜという記事も書いたので、興味のある人はこちらもどうぞ。
 

Author

Yasuhiro Yokota

1991-, Designer

Drafts

Google Meet / Zoomを会議時間になったら自動起動する方法

a year ago

Updated a minute ago

Drafts

Yasuhiro Yokota Today