■ この記事はこんな人におすすめ
- クラス名・変数名・メソッド名の命名に迷いがちな人
- 「とりあえず
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人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。