デザインにおける命名について考える

命名スルこと

日本語には漢語由来の熟語がいくつもありますが、日本人からするといくらか記号的に見えてしまうことがあります。とはいえ漢字の意味を知っているので読んで差し支えはないのですが、それらの字の間に「の」を挟みこむことで記号的な記述であった熟語を和語的な言葉として読むことができるようになります。例えば「命名」という熟語でそれを試すと「命の名(いのち の な)」という具合になりますが、「命名(スル)」という言葉を思い浮かべるよりかは「命の名(を付ける)」の方が、より一層にある概念に命を吹き込む行為であることが強調されるので、それがとても尊い行いであると改めて理解することができます。

命に名前を与える、あるいは名前を与えて命を吹き込む、すなわち命名スルという行いは、名付けによってその存在の意味性を明らかにすることなのだろうと考えられます。親が生まれた子にまず与えるのは名前です。名前を与えることで彼がこの世界にとって意味がある存在だと明らかにする、あるいはそうあってほしい、この言葉にはそういった名付け親の思いまでもが込められているような気がします。

ソフトウェアデザインに携わると、命名という行為は日常茶飯事になります。ソフトウェアエンジニアと呼ばれる人たちの仕事の幾らかは命名というタスクをこなすものであるはずです。概念定義、DB名、テーブル名、カラム名、プロパティ名、クラス名、メソッド名、変数名、API名など……。関数やメソッドを外部から利用するためにはまずその存在を示すための宣言文を明らかにしなければならないプログラミング言語もあります。全ては命名することで個々の存在が明らかになるというわけです。概念があったとしても認知できなければ存在しないも同じです。ただし、それに名前があれば存在が明らかになるので外部から参照できるようになります。名前があれば仕様書でその存在について言及できるため、仕組みを解説できるようになります。

ソフトウェアデザインやUIデザインを考えたときに、デザインが広義のシステム設計として捉えられるならば、そこにある全ての存在には意味があり、前提があり、必ず名前があるはずです。エンジニアリングの世界では主にソフトウェアエンジニアたちが名付け親でもありました。では、より広くデザインの文脈では一体誰が名付け親となるのか、私はそれがデザイナーと呼ばれる人たちであると考えます。私たちはデザインという行為の中で、全ての概念に対する名付け親になる必要があるのだと思います。

命名することがデザインの第一歩

抽象的なモノ、具体的なモノ、いずれにおいてもその仕組みを明らかにするためには言語化が求められ、名前が必要になります。『画面の上にある細長いアレ』とか『押せるソレ』とか『ぐるぐる回るやつ』ではなく、ナビゲーションバー、ポップアップボタン、プルダウンメニュー、アクティビティインジケータ、Pull-to-refresh といったような概念を明らかにする名前があるからこそ、私たちはその存在を認知し、理解し、言及し、会話し、設計に盛り込むことができるようになります。デザインにおいてまずやることは、個々の概念の範囲を決めてそれらに対して命名する、あるいは正しい名前を用いて会話することなのだと思います。

例えば Atomic Design という方法論ではUIコンポーネントを粒度ごとに区分を定義していますが、それらの名前には物理学から拝借した表現が用いられています。物質を構成する原子をメタファとすることによって粒度そのものや粒度間の関係性をわかりやすくしているのだと思います。最小単位の部品は Atoms、最も具体的な部品は Pages という区分名です(Pages は物理学とは関係ありませんが)。『一番小さい粒度』『一番大きい粒度』といった抽象度の高い表現で会話するよりもこのような統一的な名前を用いることで、デザインをシステム的に捉えやすくなるわけですね。

しかしながらAtomic Designをデザインシステムと呼ぶには何かが弱い気がしていて、私の目には「ユーザーインターフェイス要素の特に画面上に現れるものの分類を構造化したもの」ぐらいに見えてしまいます。もう少し広くインタラクションデザインという文脈でUIというものを捉えると、そこにはユーザーのジェスチャとそれに対するシステムのフィードバックといった、入出力双方揃ったインタラクションの語彙(イディオム)に関する検討が不可欠であることがわかります。デザインにおける命名という文脈では、画面上に現れる要素のほか、ユーザーが捉える概念や自己の振る舞いそのものに対しても何を明らかにするのかを考慮する必要があります。ソフトウェアの要件定義の工程で作られるであろうカスタマージャーニーマップやペルソナモデルというものは、UIが備える原始的要素から如何にしてイディオムを構築するかを考える上での重要なスパイスの役割を果たすでしょう。
これを『About Face 3』では次の図のような逆三角形モデルを用いて構造と関係性を明らかにしています。

インタラクションの語彙を形成する逆三角形モデル

ユビキタス言語の醸成

ドメイン駆動設計(DDD)の世界では概念定義に関する考え方を「ドメインを見つける」だとか「ユビキタス言語の定義と普及」と呼んでいます。認識の齟齬をなるべく無くし、関係者全員が統一見解を持ちながらシステム設計、ユーザーインターフェイスデザインを精緻化してゆく方法論です。ドメインを見つけるためにはまずドメインエキスパートと呼ばれるその概念に詳しい方と会話しながら、システムに現れるであろう概念を明らかにしていきます。概念に統一的な名前を付けてユビキタス言語辞典としてまとめることにより、それらをプロジェクトチーム内での統一言語・統一見解とすることができるようになります。
あるコンテンツをユーザーの手元に保管できる機能を考えるときに、その仕組みを「お気に入り」「ブックマーク」「栞」「いいね」のいずれの名前にするかによってはUIでの表現の仕方や受ける印象は大きく変わることになりますし、サービス上では「お気に入り」なのにアプリケーションの実装では 「liked」、APIでは「isBookmarked」になっていたならばそれはあまり気分の良いものではありません。

CEDEC2017 の任天堂の公演では、「ゼルダの伝説 ブレス オブ ザ ワイルド」の特徴的な「ゼルダホワイト」と名付けられた色についてのコンセプトが紹介されていました。単なる『白色』だとか『RGB値いくつの色』と呼ぶのではなく、『この色は「ゼルダホワイト」だ』とユビキタス言語でそれを定めたのです。この区別によって、おそらくはゼルダの開発チーム内ではゼルダホワイトとそのほかの白系統の色を明確に区別することができるにようなり、どのような意図でどの色を扱うべきかという統一見解が醸成できていたのではないかと考えられます。

デザイナーの役割

概念に命名することで意味性が生まれ、存在が明らかになり、それはおそらくオブジェクトとして捉えることができるようになります。そして概念の言語化によってデザインに関わる人々のコミュニケーションを促すことになるでしょう。
「ソレ」がそこにあるから名前で呼ぶことができる、逆にいえば、名前を与えることで「ソレ」がそこに存在することができるようになる、という具合でしょうか。デザイナーがシステムの設計者であるとしたなら、宇宙(=システム)の創造主であるかのごとく、デザイナーとは、あらゆる概念をそこにおき、名付け親となることで「ソレ」を形あるオブジェクト(=銀河、惑星)として具現化させ、あらゆるインタラクションのルール(=物理法則)を設計することのできる存在である——。
と考えています。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

68

#デザイン 記事まとめ

デザイン系の記事を収集してまとめるマガジン。ハッシュタグ #デザイン のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。
4つのマガジンに含まれています

コメント1件

なんかカッコいい❗
命名ってみんながわかりあえる行為なんですね👺❤️
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。