ユビキタス言語が打ち砕く専門家とユーザーの壁

こんにちは！PIVOTスマホアプリ開発チームの遠藤です。

突然ですがこんな経験ありませんか？

1.  他職種の方が使う専門用語の意味が分からず、話についていけなくなる
2.  案件特有の分かりにくい造語や用語が存在する
3.  文脈によってどちらとも取れるような用語を使用している

この中で１つでも「あるある」と思ったら「ユビキタス言語」で解決できるかもしれません。
この記事では、Eric Evansが著書『Domain Driven Design』で述べている「ユビキタス言語」について、できる限り噛み砕いて説明してみようと思います。

　　　　　　　　　Eric Evans著 『Domain Driven Design』

ユビキタス言語とは

ユビキタス言語とは「開発者、クライアントなどプロジェクトに関わる人全体で作り上げ共有する言語」のことです。

そのプロジェクト専用に言語を作成することで、円滑にコミュニケーションが行え堅牢なソフトウェア開発が進められます。
例えば、仮にあなたが誰も知らない無名のアプリ「ツイッター」を開発するエンジニアだとします。

■ 登場人物
- あなた（エンジニア)
- 他職種の人（デザイナー, マーケター, ディレクターなど)
- ユーザー
- 助っ人エンジニア

ステップ1 : コードの専門家と他職種の人の言葉を揃える

あなたと他職種の人たちでミーティングをしています。

他職種の人「つぶやき機能について変更がしたいんだけど・・・」
あなた　　「ツイート機能ですね」

ミーティングでは「つぶやき機能」と呼んでいるものの、実際にコードで表現する際には「ツイート機能」と書いています。
これでは毎回、脳内で変換するコストがかかってしまいますし、誤って認識してしまうリスクも発生します。
（「つぶやき機能」 → 「ツイート機能」程度なら良いかもしれませんが。） 一律で「ツイート機能」と呼ぶことで、上記のリスクは減らせます。

ステップ2 : 理解、区別できる名前にする

一律で「ツイート機能」と呼ぶことで、やっと円滑にミーティングが進められそう...？ でしょうか。
もう少し想像してみます。
あなたが一生懸命になって作った「ツイート機能」をユーザーに公開することを想像すると...

あなた　「ツイート機能を追加しました！」
ユーザー「ツイートってなに・・・？」

「ツイート」という単語自体、サービスが流行る前は知らない人も多かったかと思います。
ユーザーからすると「ツイート機能」よりも「ポスト機能」のほうが分かりやすいかもしれません。
しかし「ポスト機能」とすると写真を投稿する機能の「フリート機能」と区別ができなくなってしまいます。（※現在フリート機能は廃止されています)

ここで大事なのが、
「ツイート機能」より「ポスト機能」のほうが良い？悪い？ではなく、
ユーザーがわかる様になっているか、です。
一度付けた名前が第三者からみて理解、区別できるか確認するステップが必要になります。

ステップ3 : 用語集をつくる

ステップ2で吟味した結果、名前は「ツイート機能」に落ち着きました。
やっと開発に入れます。
ここで、チームに助っ人エンジニアが新しく加わるとします。 あなたと助っ人エンジニアが現状のすり合わせを行っています。

あなた「ツイート機能の仕様についてなんだけど・・・」
助っ人「ツイートってなに・・・？」

新しくメンバーが増えるたびに「ツイート」の説明をしないといけません。 これは用語集をつくることで解決できます。用語集には「ツイート」の定義とふるまいを記述します。
「定義とふるまい」でピンと来る方もいるかも知れませんが、その作成した用語集がそのままコードに反映できます。

例えば、「ツイート機能」のオプション機能として「ライク」があります。

ツイート機能 : ユーザーがつぶやきをタイムラインに投稿する機能
ライク : ツイートに対して評価する機能。一人のユーザーがひとつのツイートに対してできるライクは＋1

この用語集をもとにコードでは「Tweet」「Like」と記載します。
そうすれば新規メンバーが増えた際や、コード理解で詰まった際にも役に立ちます。これは、エンジニアはもちろん、他職種の人とも一緒に作成するものです。

つまり、極論ミーティングを通じて設計も行えますし、エンジニア以外の方がコードを見ても内部の細かい動作は分からなくても振る舞いがわかるので実装がクリアになります。

ディレクターの方がここの部分どういう実装方法にしているんだっけ？という理解の手助けにもつながるということです。

まとめ

みんなが同じ言葉を使うことで、コミュニケーションが円滑に進み認識の齟齬が減らせます。逆に、複数の言い回しや解りにくい言い回しが混在しているとプロジェクト全体としてブレが生じてしまいます。
もしあなたが「言葉」で違和感を感じているのなら「ユビキタス言語」を作成すべき合図かもしれません。