意味の受け取りかたは千差万別
命名するにあたり、同職種のメンバーが理解できるような言葉を用いたとしても、他職種のメンバーが同じ名前で同じ意味を想起できるかはわかりません。
たとえば「ユーザー」という言葉は、開発する者にとっては「プロダクトを使う人」という認識かもしれませんが、マーケティングやカスタマーサポートに関わる非開発者は違う人をイメージしているかもしれません。SmartHRが担う人事労務に関する領域でも、人事労務を管理する人とそれを享受する従業員など多くの種類があるため、「ユーザー」という言葉では不明瞭です。
そう考えると、「顧客」という表現も少し曖昧かもしれません。セールスの人にとっては製品を購入する担当者や決裁者を意味しますが、開発者はおおむね「プロダクトを使う人」と捉えるからです。
このように、デザイナーがデザイナーだけにわかるよう命名しては、デザイナー以外の職種のメンバーには伝わりにくくなります。他職種の文脈も把握するために、彼らの使う言葉を汲み取りながら命名していく必要があります。
ユビキタス言語とは
いきなりですが、ドメインモデリングの第一人者のエリック・エヴァンス氏が提唱した「ユビキタス言語」をご存知でしょうか。ユビキタス言語は、ユーザーが従事する業務の文脈からソフトウェアを開発するドメイン駆動設計のひとつのフレームワークで、開発者とユーザー間の正しい意思疎通を図るべく作られたものです。ドメイン内の言葉を厳格に定義した用語集のようなイメージです。
私のチームでは、新規プロダクトの立ち上げ時に他職種のメンバーが集まり、各要素や概念にどういった名称や意味が正しいのかを集めたユビキタス言語を作っています。作成方法は至ってシンプルで、プロダクト内で出てくる言葉をすべて洗い出し、それぞれのメンバーの専門分野をもちより、名前の妥当性を探ります。
上のようにユビキタス言語上で、プロダクトの中でどういう登場人物や要素があり、それらがどういう関係を示すのかを自然言語で表します。この組み合わせ表によって、開発中に仕様で迷うことがあっても立ち戻ることができます。
ユビキタス言語は、新規でプロダクトを作る際に非常に効力を発揮します。新規プロダクト開発では多くの選択肢があるため混乱することもありますが、ユビキタス言語があればソフトウェアの開発の進むべき方向性を見定めるひとつの手助けとなり、チームの効率を上げてくれます。
また昨今のリモートワークを基本とした働き方ではチーム内のコミュニケーションの質も求められるため、より高い効果が表れるでしょう。
命名からデザインが始まる
デザインをするということは、ルールを制定する意思決定の連続のように思えます。
構造としてのルールや、ビジュアルデザインの余白のルールもその中に入るでしょう。ですがそれらは、私たちのような作る側の思想が、使う側に正しく伝わるように設計されています。そのルールづくりがデザインの根幹のひとつであり、命名はルールの制定、ひいてはデザインの第一歩のような気がします。これを読んでいる方も、是非命名について意識していただけると嬉しいです。
それでは次回もSmartHRプロダクトデザイングループ連載をお楽しみに。
