こんにちは、 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 の Table view でまとめています。
表記揺れを正したい、というモチベーションから始まったので素朴な単語の羅列になっています。
各ユビキタス単語について、主に以下の項目で整理しています。
- 単語
- よくある間違い
- プロダクト内文言
- 意味
それぞれ簡単に説明していきます。
単語
ユビキタス言語として定義する単語です。
Notion の Table view の行の 1 つ 1 つはページとなっているので、プロダクト内の使用箇所のキャプチャや策定経緯のメモなんかを自由に追記できます。便利ですね。
Leanerでは開発タスク管理もNotionで行っているため、単語が生まれた開発タスクやディスカッションしたページのリンクなんかも簡単に貼れます。
よくある間違い
ユビキタス単語の同義語です。
観測した表記揺れの単語を追記しています。
使ってる人を見かけたら取り締まっています👮♂️
今回、表記揺れを正す目的でユビキタス言語策定を始めたので、かなり重要な項目になります。
同じ意味の単語が既に定義済みかどうかの検索用にも役立っています。
プロダクト内文言
プロダクト内の UI、ヘルプページ、メールなどで使用可能な単語です。
ユビキタス単語を UI まで一貫して使用できるのが理想ですが、チーム内の会話やユースケースの記述で使用するユビキタス単語と、UI 上の表記は分けて考えることにしました。
Leaner 見積では、見積依頼する「バイヤー」と見積回答する「サプライヤー」という概念が存在します。
本来であれば、バイヤーとサプライヤーをサブドメインとして、それぞれユビキタス言語を定義すべきです。
画像引用元: https://qiita.com/crossroad0201/items/875c5f76ed3794ed56c4
確かにサブドメインを分けると綺麗に管理できそうです。
ただ、実際の会話での使用を考えると厳密に分けるメリットはそんなに無いように感じました。
バイヤー・サプライヤー内で同じ単語を定義した場合に、その単語を聞いてどちらを指しているのか特定できません。
サブドメインのプレフィックスを意識して会話するよりは、ユビキタス単語はフラットに定義しつつ、UI 上の表記をサブドメイン内に適した単語で表記するように管理した方が実運用に耐えうるのでは、と考えました。
破綻しそうになったらまた検討します。
意味
ユビキタス単語の意味です。
他の単語との関連性が分かるような例文を書いてますが、名詞と動詞（振る舞い）を分かりやすく区別するためにも、ここは図にしたいところですね。
良いプロダクトの設計・開発にはビジネス理解が必須
ユビキタス言語策定を通して開発チームもビジネス理解が深まりました。
プロダクト開発において、エンジニアもビジネス理解がとても重要です。
ビジネス理解が未熟な状態で考え出されたモデルは、課題を上手く解決できず、機能性に不備が生じます。
ユビキタス言語を策定した結果、現状のモデル構成でちょっと微妙そうなところが顕在化しました。
モデル構成にもユビキタス言語で整理した概念を反映していきたいなと考えてます。
個人的に、良い設計は良い名前付けに終始すると考えています。
良い名前付けするためにはビジネス理解が必要で、そのためにはドメインエキスパートとの会話が必要不可欠です。
ドメインエキスパートとの円滑なコミュニケーションにユビキタス言語はとても役立ちます。
ユビキタス言語策定は結構大変ですが、作る価値あるなと再認識しました。
ユビキタス言語は策定するだけでは意味がない
ユビキタス言語策定の一番のハードルはドメインエキスパートの協力ですが、Leaner のビジネスサイドは異常なくらい協力的なので助かりました。
本番はこれからです。
ユビキタス言語によるコミュニケーションを普及、浸透させるのが大変です。
こうして、発見や、創造したユビキタス言語ですが、これが、悲しいくらい、共通で使われません。ビジネス側のドメインエキスパートが利用してくれないのはまだわかりますが、DDDを実践しているはずの、開発チームですら共通で使ってくれないことが多々あります。 そして、あなた、自分自身もおそらく、違う言葉で話したり、書いたりするでしょう。
これ、本当にその通りだなと感じます。
ユビキタス言語の浸透に銀の弾丸はありません。とにかく使うしかないです。
オーナーを立てて、よくある間違いの単語に対して地道に訂正していくことが重要です。
「ユビキタス言語違反してるとめんどくせーな」くらい思わせたら勝ちです。
「この単語だと使いにくいんだけど？」っていう話が上がってきたら、ユビキタス言語をアップデートしましょう。
それでようやくユビキタス言語運用の第一歩を踏み出せたことになります。
ユビキタス言語普及のために
いくつかユビキタス言語普及の取り組みを始めたので紹介します。
デイリースクラム内でユビキタス言語一問一答
毎日適当な単語をピックアップして出題しています。
問題のストック貯まってきたらテスト実施しても良さそうですね。
ミーティング内で訂正コメントを流す
ミーティング中に間違った単語使用を発見したら Zoom のチャットやコメントスクリーンなどで訂正コメントを流しています。こうした地道な活動が一番重要です。
他には、Slackのカスタムレスポンス設定も検討しています。
「うちはユビキタス言語こういう風に管理してるよ！」とか、「こういう風に普及させたよ！」みたいなのがあったら是非情報交換したいです！
まとめ
- ユビキタス言語策定したらビジネス理解がめっちゃ捗った
- 社内に協力的なドメインエキスパートがたくさんいるのは心強い
- ユビキタス言語は会話に使えないと意味がない
- 会話での使用に耐えうるならユースケース記述にも使える
- ユビキタス言語策定まではいいけど、普及させるのが大変
参考文献
- エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- ビジネス考えてるかい？事業の持続的成長を促進させるシステム設計の考え方 / buisiness_purpose_system_design - Speaker Deck
- ドメイン駆動設計(DDD)との格闘 - ユビキタス言語には不屈の闘志が不可欠 - FLINTERS Engineer's Blog
- ドメイン駆動設計に2年間関わって学んだこと - RAKUS Developers Blog | ラクス エンジニアブログ
宣伝
Leaner Technologies ではドメインエキスパートとユビキタス言語でコミュニケーションしたいエンジニアを募集しています！
Discussion