命名における「関心」と「語順」 ~日本語の語順のまま英訳しよう~

システム開発における命名の重要性

「命名」について、考えたことはありますか？
命名とは、文字通り命を与えることです。つまり、システムの肝となりうるものということです。
したがって、不適切に命名されたシステムはその生命を十分に発揮することができません。
軽く考えられがちな「名前をつける行為」ですが、この行為の質がプロジェクト全体の健全性を左右すると言っても過言ではありません。
今回は、「命名」を「ドキュメンテーションにおける最も基本的な手段」にまで昇華させるために重要なことについて説明をします。

命名における関心とは

命名における関心 (Domain)とは、対象となるビジネス領域の本質的な概念や規則を反映する要素です。
これは単なる技術的な区分ではなく、実際のビジネスプロセスや業務知識に基づく分類軸を意味します。

関心は以下のような要素から構成されます。

• ドメインエンティティ：業務上の主要概念
  • 生徒
  • 会員
  • 商品
  • 注文
• ドメインプロセス：業務上の重要な処理
  • 入会
  • 退会
  • 請求
  • 集計
• ドメイン状態：業務上の条件や状態
  • アクティブ
  • 休会中
  • プレミアム
  • 月次
• ドメイン規則：業務特有のルールや制約
  • 割引条件
  • 承認フロー
• ドメインコンテキスト：適用される業務文脈
  • 販売
  • マーケティング
  • 教育

中核の関心

例えば、「プレミアム会員の月次利用統計」には「プレミアム会員」という顧客区分と「月次」という集計期間、「利用統計」という分析対象といったように複数の関心が含まれています。
しかし、この中でもっとも重要な関心は「利用統計」です。
このように、複数の関心が組み合わさっていてもその中にひとつ主軸となる「中核の関心」が存在することがわかります。
そして、命名において重要なことは、中核の関心と補助の関心(それ以外の関心)の境界を明確に理解し、関心を過不足なく表現しきることです。
また、分類においても中核の関心は重要なポイントとなります。
例えば、「プレミアム会員」、「月次」、「利用統計」というカテゴリーがあったとき、「プレミアム会員の月次利用統計」はどこに分類するべきでしょうか？
ここまでの話から、中核の関心をもとに「利用統計」に分類するべきであることがわかるとおもいます。

関心を表現し切ることの重要性

よくある命名の失敗のひとつが、「関心を表現しきれていないこと」です。
例えば、「プレミアム会員の月次利用統計」の中核の関心は「利用統計」ですが、「プレミアム会員」と「月次」も重要な関心であることに変わりはありません。
しかし、命名する際に中核の関心以外の補助の関心が抜け落ちてしまうことがあります。
「プレミアム会員の月次利用統計」を英訳するとPremiumMemberMonthlyUsageStatisticsとなります。そして、これがそのまま関心名となっているべきなのです。
例えば、「プレミアム会員の月次利用統計を取得する関数」の命名はgetPremiumMemberMonthlyUsageStatisticsであるべきです(getが妥当かは別問題として)。
名前が長くなるのをおそれて、getUsageStatisticsのように関心を省略してしまうのは典型的なアンチパターンとなるため注意しましよう。

関心は後方一致でまとめよう

中核の関心は、関心名の最後に現れる状態にしましょう。
なぜなら、日本語の語順において中核の関心は最後に現れるためです。
例えば、「プレミアム会員の月次利用統計」の中核の関心は「利用統計」ですが、関心名の最後に現れています。
この「関心名の末尾に中核の関心が現れる状態」は認知上のパフォーマンスにおいて非常に重要となります。

日本語の語順のまま英訳しよう

実を言えば、日本語において中核の関心が名前の最後に現れるのは当たり前のことです。
というよりも、名前の最後に現れている関心が中核の関心であるといった方が正しいです。
ではなぜこのような話をしているのかと言うと、英語にした際にこの当たり前が崩れることがあるためです。

「契約プラン別のユーザ」を例にみていきましょう。
まず、「契約プラン別のユーザ」を直訳すると「Users by Contract Plan」となります。
そして、「契約プラン別のユーザ」の中核の関心は「ユーザ」です。
しかし、「Users by Contract Plan」の末尾についているのは「Contract Plan」です。
このように、日本語では問題なかった命名が英語にした途端問題が発生してしまうことがあります。

では、どのように英訳すればよかったのでしょうか？
重要なポイントは、「日本語の語順のまま英訳する」ことです。
英訳する際に、日本語の語順を保つようにすれば中核の関心を最後に持ってくることが可能となります。

私は英語の専門家ではないので、AIに頼ってみましょう(Claude 3.7 Sonnetを使用)。

---

Q: 「〇〇別のXxx」を、「Xxx by 〇〇」ではなく、Xxxの前方につく修飾語で表現できると嬉しいのですが、何か案はありますか？

A: 修飾語による表現方法の提案

「〇〇別のXxx」を「Xxx by 〇〇」ではなく、前方修飾語で表現する方法としては、以下のようなパターンがあります：

一般的なパターン

1. 形容詞形に変換する
   例：「地域別の売上」→ "Regional sales"
   例：「性別の統計」→ "Gender-specific statistics"
2. 所有格を使う
   例：「部門別の予算」→ "Departmental budget"
   例：「季節別の計画」→ "Seasonal plan"
3. 複合語を形成する
   例：「年齢別の分析」→ "Age-based analysis" または "Age-group analysis"
   例：「業界別のレポート」→ "Industry-specific report"
4. 接頭辞を活用する
   例：「国別のデータ」→ "Country-specific data" または "Per-country data"
   例：「時間別の記録」→ "Time-segmented records"

Q: このようなケースで使用できる前方修飾語をまとめてください。

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

各表現が示す基準や関係性の違いを整理します：

分類・区分に関する表現

• 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（部門の観点からの予算編成）
  • 適した用途: 分析視点、複数の観点からの考察

---

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（部門の観点からの予算編成）	分析視点、複数の観点からの考察

---

AIに質問したところ、上記のような前方修飾語に変換する方法をまとめてもらえました。
では、これをもとに「契約プラン別のユーザ」を英訳してみましょう。

「契約プラン別」というのは、分類・区分に基づく表現です。
そのため、今回のケースでは「based」が適切であると考えられます。
よって、「契約プラン別のユーザ」を英訳したものはContractPlanBasedUserとなります。

このように、中核の関心が後方一致になるように命名することが重要です。

Byは使用できないのか？

すべての命名においてByが使用できないのかというと、そうではありません。
あくまでも、関心な名前として語順が崩れる場合に使用できないということに留意してください。

例えば、データベースからユーザIDでユーザを取得してくる関数の名前はgetUserByUserIdなどと命名することが一般的だと思います。
このとき、関心はUserであり、ByUserIdは関心ではありません。
したがって、このようなケースではByを使用することができます。
ただし、契約プランIDで契約プラン別のユーザ一覧を取得してくる関数の場合はgetContractPlanBasedUsersByContractPlanIdとなります。
なぜなら、この場合の関心は「契約プラン別のユーザ(一覧)」であり、「契約プラン別」も関心に含まれているためByを避け日本語の語順を保つようにするためです。

後方一致であることのメリット

関心を後方一致でまとめることのメリットは、語順を保つことができる点です。
そして、語順を保つことのメリットは、一貫性と対称性を担保することができる点です。

一貫性

命名における一貫性とは、概念順序規則にしたがっていることです。
概念順序規則とは、「名前の要素を意味のある概念ごとに順序立てて配置する考え方」です。
例えば、getUserByUserIdを概念ごとで分けるとget / User / ByUserIdとなります。
まず、getは操作(動詞)です。他には、findやremove、createなど。
次に、Userは関心です。そして、ByUserIdは方法・条件です。
つまり、データベースの操作というパターンにおいて、その関数名は常に操作 -> 関心 -> 方法・条件という概念順序で命名されるべきであるということです。
この、概念順序規則にしたがって命名されている状態を一貫性が高いと表現します。
もちろん、パターンが異なればその概念順序も異なります。
例えば、コンポーネント名であれば、その概念順序は関心 -> 状況・状態 -> UIの型となります。
ここで重要なのは、同一パターン内では常に一定の概念順序規則にしたがっているという点です。
概念順序規則を遵守することで、命名の一貫性を向上させることができます。

対称性

命名における対称性とは、複数の命名を並べてみたときに、それぞれの概念が対応していることです。
例えば、コンポーネント名における概念順序が関心 -> 状況・状態 -> UIの型のとき、「記事を投稿するフォーム」がArticlePostFormなら「コメントを投稿するフォーム」はCommentPostFormであるべきということです。
日本語において「コメント」という単語は名詞だけでなく「コメントする」という動詞的な意味も含まれがちですが、それに引っ張られて「コメントを投稿するフォーム」をCommentFormと命名するのは早計かもしれません。
もし、あとから「コメントを編集するフォーム」が必要になった場合、そのコンポーネントはCommentEditFormと命名されるでしょう。ところが、「コメントを投稿するフォーム」はCommentFormと命名されているのです。
これが対称性を崩す要因となります。　
あとから類似のものが出てきた際に、対称性が崩れないかに注意して命名しましょう。

まとめ

今回の記事で重要なポイントは以下の4つです。

• 関心には、「中核の関心」と「補助の関心」が存在する。命名する際は「補助の関心」も含めて表現しきる必要がある
• 中核の関心が英語名の末尾になるように、日本語の語順のまま英訳する
• 命名は「操作 -> 関心 -> 条件」や「関心 -> 状況・状態 -> UIの型」など、概念順序規則に従うことで一貫性を保つ。
• 同じパターンの命名間で構造を揃えることで対称性を実現する。

これらのポイントを意識し、一貫性と対称性が高い命名ができていると、迷いが生じなくなっていきます。
なぜならば、名前自身がどうするべきか教えてくれるようになるからです。
例えば、適切に命名されたディレクトリ構造では、ファイルをどこにいれるべきか、どのようなファイル名・ディレクトリ名にするべきかに迷うことはなくなります。
命名は、コードにコメントを書くことと同様、もしくはそれ以上に「それが一体何なのか・何ではないのか」を説明することができます。

こうして「命名」は「ドキュメンテーションにおける最も基本的な手段」となっていくのです。