airRnot.dev

命名について考えていること

命名に秩序をもたらすのは、一貫性と対称性です。コンテキストの概念を明らかにして順序を守り、同一粒度で密度を揃えることで、物事の本質を捉え「明名」する重要な思考プロセスについて解説します。

Podcast



Presented by NotebookLM
内容は正確ではない可能性があります。

はじめに



わたしが最近一番考えていることは命名についてです。

命名とは何でしょうか?

命名とは、コンテキストが持つ概念を明らかにし、一定の順序で並べることだとわたしは考えています。

前提



わたしの命名に関する思想は、BCD Designに強く影響を受けています。

また、良いコンポーネント名の法則である何の何をどうするUIについて知っておくと理解の助けになるかもしれません。

内容はフロントエンド寄りですが、フロントエンド以外の分野でも通じる部分があると思います。

結論



命名において、最も重要なことは一貫性対称性です。

一貫性



命名における一貫性とは、名前を構成している概念が、一定の順序で並んでいることを指します。

そして、その規則をわたしは概念順序規則と呼んでいます。

概念順序規則



概念順序規則とは、良いコンポーネント名の法則である何の何をどうするUIをより一般化した考え方です。

何の何をどうするUIでは、コンポーネントを構成する関心, 状況・処理, UIの型という3つの概念を、何の何を(関心) -> どうする(状況・処理) -> UI(UIの型)という順序で並べることを推奨しています。

つまり、何の何をどうするUIでは概念を並べる順序を規則化しているということです。

しかし、何の何をどうするUIはあくまでもフロントエンドにおけるコンポーネント名の命名規則です。

そこで、わたしは概念を並べる順序の規則化という部分に着目し、命名全般に適用できるのではないかと考えました。
そして、それを概念順序規則と名付けました。

概念順序規則においてやるべきことはただひとつです。それは、そのコンテキストにおける概念順序を明らかにすることです。

概念順序



概念順序とは、コンテキストが持つ概念を並べた際の順序のことです。

たとえば、コンポーネント名というコンテキストにおいて、概念順序は関心 -> 状況・処理 -> UIの型となります。

BCD Designや何の何をどうするUIで行ったような概念を並べる順序の規則化こそが、まさに概念順序ということになります。

意味逆転の禁則



概念順序規則において、最も重要なことは常に概念順序を守ることです。
概念順序を守ることこそが、概念順序規則の本質なのです。これを守らないことには何もはじまりません。

そういうことですので、わたしは特別に禁則として名前をさずけました。
それが意味逆転の禁則です。

意味逆転の禁則では、概念順序の順番を入れ替えることを禁止します。
たとえば、関心 -> 状況・処理 -> UIの型という概念順序において、状況・処理 -> 関心 -> UIの型というように、概念順序が逆転してしまうことを禁止します。
create-user-formという名前はまさにこの禁則に違反しています。概念順序にしたがえば、user-create-formとするべきです。

ただし、意味逆転の禁則は、あくまでも概念順序の逆転を禁止するものであり、概念順序が欠けることを禁止するものではないということに留意してください。
たとえば、user-cardという名前は、userという関心とcardというUIの型があるだけで、状況・処理の概念が欠けています。
しかし、関心 -> 状況・処理 -> UIの型という矢印の流れに反しているわけではないので、意味逆転の禁則には違反していません。

※しかし、BCD Designや何の何をどうするUIでは、UIの型の概念が欠けていることは禁止されています。このように、各概念規則において個別のルールが存在することはあります。

日本語順序保持の原則



日本語順序保持の原則とは、英語で命名する際に、もとの日本語の語順を保ったまま英訳するという原則です。

日本語順序保持の原則には、概念内の語順を整理することで意味逆転の禁則の違反を防ぐ狙いがあります。

たとえば、「年齢別のユーザ」という関心があったとき、これを直訳すると「Users by Age」となります。

ここで両者を比べてみると、語順が入れ替わっていることがわかります。
この違いから生まれる命名の不一致を避けるため、日本語順序保持の原則では、日本語の語順をそのまま英語の命名に反映させることを原則とします。

日本語の語順と英語の語順が異なる場合、他の概念と組み合わせた際に不都合が生じる場合があります。

たとえば、「年齢別のユーザ」に「一覧」を加えた「年齢別のユーザ一覧(User List)」を英訳するとどうなるでしょうか?
「List of User by Age」、「User List by Age」、「User by Age List」など、複数のパターンが考えられます。

しかし、日本語で考えてみるとどうでしょうか?
「年齢別のユーザ」に「一覧」を加えろと言われたら、十中八九「年齢別のユーザ一覧」になると思います。

つまり、日本語の語順を保持することで、表記ブレを抑えることができるのです。

ある箇所では「List of User by Age」と呼ばれていたものが、違う箇所では「User List by Age」と呼ばれている。
同じものが複数の名前を持ってしまうと、認知上のパフォーマンスに悪影響をもたらします。

では、「年齢別のユーザ一覧」を日本語の語順を保ったまま英訳するにはどうしたらいいのでしょうか?
こういった場合に使える単語一覧を以下に提示します。

※わたしは英語に詳しくないので、AIに聞いて以下の単語一覧を作成してもらっています。

修飾表現別の「示す基準」比較表

分類・区分に関する表現

表現意味適した用途
based〜に基づいたAge-based grouping(年齢に基づくグループ分け)データ分類、カテゴリ分け、客観的基準による整理
specific〜に特化したIndustry-specific regulations(業界に特化した規制)特定分野だけに適用される事柄、限定された適用範囲
segmented〜で区分されたPrice-segmented offerings(価格帯で区分された商品)マーケティング分析、戦略的区分け
classified〜で分類されたSkill-classified employees(スキルで分類された従業員)階層化された分類、評価基準による区分
焦点・方向性に関する表現

表現意味適した用途
focused〜に焦点を当てたSolution-focused approach(解決策に焦点を当てたアプローチ)戦略や方法論、特に重視する側面の強調
oriented〜志向のResult-oriented metrics(結果志向の指標)思想的傾向、アプローチの方向性
centric〜中心のUser-centric design(ユーザー中心の設計)設計思想、価値観の中心
対象・用途に関する表現

表現意味適した用途
targeted〜を対象としたSenior-targeted services(高齢者を対象としたサービス)マーケティング、サービス提供の対象指定
tailored〜向けに調整されたClient-tailored solutions(クライアント向けに調整されたソリューション)パーソナライズされたサービス、個別調整された提案
dedicated〜専用のDeveloper-dedicated tools(開発者専用のツール)特定グループだけが使用するもの、専用設計された製品
観点・視点に関する表現

表現意味適した用途
wise〜の観点からDepartment-wise budgeting(部門の観点からの予算編成)分析視点、複数の観点からの考察

「年齢別」というのは分類や区分の基準を示しているため、「年齢別のユーザ一覧」は「Age-based User List」と英訳することができます。

このように、日本語順序保持の原則を遵守することで、一貫性をより向上させることができます。

対称性



命名における対称性とは、粒度が同一のものは概念密度も同一である状態を指します。

概念密度



概念密度とは、概念順序において概念がどれほど含まれているかを示す指標です。

意味逆転の禁則の項では、意味逆転の禁則は概念順序が欠けることを禁止するものではないと述べましたが、概念順序が欠けている場合に概念密度は小さくなります。

概念密度対称の原則



命名における対称性は、概念密度対称の原則によって担保されます。

対称性において、概念密度が小さいことは特に問題ではないのですが、粒度が同一のもの同士の中で概念密度が異なることは問題です。

たとえば、コメントを投稿するフォームを命名してみましょう。
えーと、では、comment-formとしてみましょうか。

では、コメントを編集するフォームはどうでしょうか?
comment-edit-formとするのが自然でしょうか。

あれ? comment-formcomment-edit-formはコンポーネントの粒度としては同一のものなのに、概念密度が異なりますね。

これが、対称性が低い状態です。

基本的に、概念密度が高くなるほど命名の具体性は上がると考えてください。

つまり、同じ具体性のもの同士は、同じ概念密度を持つべきなのです。

先ほどの例では、実はコメントを投稿するフォームをcomment-formと命名したことが誤りでした。
日本語の感覚だと「コメント」という言葉自体に「投稿する」という意味が含まれがちですが、本来「投稿する」という概念は状況・処理にあたります。

コメントを編集するフォームでは、editとあるように、しっかりと状況・処理の概念が名前にあらわれています。
comment-formでは状況・処理の概念が不当に欠けているため、概念密度が小さくなっているのです。

したがって、コメントを投稿するフォームはcomment-post-formと命名するのが適切でしょう。

大切なことは、同じ粒度のもので異なる概念密度を持つ名前があった際は、概念密度の高い方に合わせてあげることです。

これを、概念密度対称の原則と呼びます。

まとめ



改めてになりますが、命名において最も重要なことは一貫性対称性です。

そして、一貫性と対称性は命名に秩序をもたらします。

また、命名の肝とはコンテキストに最適な概念順序を導き出すことだと考えています。

命名はその重要性に反して軽視されがちですが、まずはそこからはじめてみてはいかがでしょうか。

さいごに



命名は、わたしにとって非常に重要なテーマです。

しかしながら、今回の内容はあくまでもわたしの考え方に過ぎません。

これが絶対だとは思っていませんし、他の人の考え方を否定するつもりもありません。

特に日本語順序保持の原則は受け入れがたい部分も多いと思っています。

しかし、この記事が命名という行為に新たな視点をもたらし、日々の開発や設計において迷いが少なくなる一助となれば幸いです。


さいごに、これはBCD Designからの受け売りですが、明名という言葉があります。

名前は決めるものではなく決まるもの

名前を決めるのは主観で、名前が(依存や性質によって勝手に)決まるのが写像です。

"命名" するのではなく "明名" すると考えるのが良いでしょう。

わたしが命名に興味を持ったのは、まさにこの考え方からです。
だからこそ、冒頭で命名とはコンテキストが持つ概念を明らかにし、一定の順序で並べることだと述べました。

命名とは単なる表面的な作業ではなく、物事の本質を捉え、表現する重要な思考プロセスなのです。