■ この記事はこんな人におすすめ

クラス名・変数名・メソッド名の命名に迷いがちな人
「とりあえず User や Item でいいか」と思いがちな人
命名規則を意識はしているが、チームでの共通認識づくりに課題を感じている人
ドメイン知識を活かした設計に興味がある人

■ この記事で得られること

「存在駆動」ではなく「目的駆動」で命名する考え方が身につきます
曖昧な命名がどのような技術的負債につながるかを理解できます
命名の質を上げるための7つの実践的なポイントを習得できます
命名のアンチパターンと対策を知ることができます

■ 参考書籍

『良いコード／悪いコードで学ぶ設計入門』

1. 結論

命名規則において最も重要なのは、「業務の目的（要件）を理解した上で名前をつけること」です。

コードの中に登場するクラス名・変数名・メソッド名は、単なるラベルではありません。それは「このコードが何のためにあるのか」を表明するものです。

商品クラス や 金額 のような抽象的・存在駆動な命名は、意図せずロジックを一箇所に集中させ、後から読む開発者の理解コストを高めます。一方、予約品 請求金額 のような目的駆動な命名は、コードの責務を明確にし、保守性・可読性を大きく向上させます。

命名規則はコーディング規約の問題ではなく、設計・要件定義レベルの問題です。

2. 具体的にやること（7つのポイント）

■ ① 可能な限り具体的で、意味が狭い、目的に特化した名前を選ぶ

NG	OK
`商品`	`予約品` / `注文品` / `在庫品` / `発送品`

「商品」という名前は広すぎて、どのフェーズ・どのユースケースの商品なのかが伝わりません。

■ ② 存在駆動ではなく、目的駆動で名前を考える

NG	OK
`金額`	`請求金額` / `消費税額` / `延滞保証料`

モノの「存在」ではなく、「何のための〇〇か」を名前に込めましょう。

■ ③ どんな業務目的があるか分析する

登場人物・事柄・関係性などをチームで話し合うことが有効です。
「この画面では誰が何をするのか？」を言語化するだけで、命名の解像度が上がります。

■ ④ 声に出して話してみる

開発チームや顧客を交えた会話の中で、実際に命名したものを使ってみましょう。
そこで違和感や認識のズレが生まれれば、それは命名を見直すサインです。

■ ⑤ 利用規約を読んでみる

利用規約には、人によって解釈が変わらないよう厳格な表現が使われています。
命名の参考になる言葉が多く見つかります。

例：購入者 / 出品者 / 販売手数料 / サービス利用料

■ ⑥ 違う名前に置き換えられないか検討する

「ホテルの利用者」を起点に考えると、より目的に即した名前が見えてきます。

ユーザー → 顧客 → 請求者 / 宿泊者

支払人と泊まる人が同一人物とは限らない

このように、役割を分けて考えることで命名の粒度が上がります。

■ ⑦ 関心が分離されているか点検する

関係性の薄いロジックやクラスが紐づいている場合、名前設計が不十分な可能性が高いです。
「このクラスはどんな責務を持つか？」を一言で説明できるか確認しましょう。

3. 各項目の詳細説明

■ 名前に無頓着になるな

「なぜその名前なのか」「業務上どういう意味があるのか」をチームで共通認識として持つことが重要です。
名前はチームの会話の中で生きるものです。コードの中だけで使われている言葉と、会話で使われている言葉が違う状態は属人化につながります。

// NG：会話では「要注意人物」と呼んでいるのに、コードでは User で分岐対応
if (user.isSuspicious) { ... }

// OK：会話で使う言葉をそのまま命名に活かす
SuspiciousUser suspiciousUser = new SuspiciousUser(...);

■ 仕様変更による意味の変化に注意する

フェーズ	「顧客」の意味
開発初期	個人顧客のみを想定
開発中期	個人顧客＋法人顧客に対応

仕様が変わっても命名が変わらないと、コードと現実のズレが生じます。
対策：命名の変更、またはクラスを分ける

■ クラスの正体を見破れ（アンカリング効果に注意）

アンカリング効果とは、最初に提示された情報を無意識に基準にしてしまうことです。
ソフトウェア開発では、既存の命名規則に引っ張られて違和感に気づきにくくなります。

対策：「このクラスの目的や概念を説明できるか？」を問い直す

■ 形容詞が必要な名詞には注意を払う

// 一見わかりやすそうだが…
int maxHitPoint;

仕様を確認すると「補正前の最大HP」と「補正後の最大HP」の2種類が存在することが判明。
実装者しか理解できない状態になるため、命名を分けるべきです。

// OK
int maxHitPointBeforeCorrection;  // 補正前の最大HP
int maxHitPointAfterCorrection;   // 補正後の最大HP

■ 命名規則のアンチパターン

アンチパターン	例
技術駆動命名	`MemoryStateManager`
ロジック構造をなぞった名前	処理の流れをそのまま名前にしたもの
予想外の処理が中で行われている命名	名前から想像できない副作用を持つクラスや関数

まとめ

命名規則をする上では、業務の目的（要件）を理解することが重要
既存の命名について無頓着にならず、「これは何？」「なぜこの名前？」を問い続ける姿勢が大事
クラス名だけでなく、メソッド名・変数名・テーブル名・カラム名すべてに同じ原則が適用される
命名規則は、要件定義・設計の段階からチームで話し合い、ドキュメントに残すことが重要

結局何をすればいいの❓

現在のプロダクトで使われているクラス名・変数名について、「これは何のためのものか？」を一言で説明できるか確認する
チームで「業務用語」と「コードの命名」が一致しているか話し合う場を設ける
新機能の実装前に、利用規約・仕様書から命名のヒントを探す習慣をつける
抽象的な名前（User、Item、Managerなど）を見つけたら、より目的に特化した名前へ変えられないか検討する
命名規則の共通認識を、README やドキュメントに残す

株式会社シンシア

株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら

シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。