システム開発では、変数名・関数名・クラス名・DB カラム名・URL など、あらゆる場所で「命名」が必要になる。
適切な命名規則を採用することで、可読性・保守性・チーム開発効率が大幅に向上する。

以下では、実務で特に使用される命名規則を、用途ごとに解説する。

1. よく使われる命名規則（最重要）

◆ 1-1. スネークケース（snake_case）

形式：

単語_単語_単語  （すべて小文字）
例：legal_consultation_date

特徴：

• 単語の区切りが明確で可読性が高い
• “SQLやRDB” の世界では事実上の標準
• Python でも変数名・関数名として一般的

主な利用シーン：

• データベース（RDB）のテーブル名・カラム名
  • user_master
  • created_at
  • updated_by
• ログや設定ファイル（YAML, JSON）
  • max_retry_count
  • default_language_code

実務でのメリット：

• SQL で大文字小文字を気にしなくて良い
• 長いカラム名でも読みやすい
• 多くのチーム開発経験者が慣れているため採用率が高い

◆ 1-2. キャメルケース（camelCase）

形式：

先頭のみ小文字。単語の区切りは大文字。
例：legalConsultationDate

特徴：

• JavaScript 系で最も一般的
• JSON のキー名でもよく使われる

主な利用シーン：

• JavaScript / TypeScript の変数名・関数名
  • totalPrice
  • getUserList()
• Java / Kotlin のローカル変数
• API のレスポンス(JSON)
  • {“userName”: “Taro”}

実務でのメリット：

• モダンフロントエンド（React, Vue, Angular）と相性が良い
• JSON との整合性がとりやすい

◆ 1-3. パスカルケース（PascalCase）

形式：

すべての単語の先頭を大文字。
例：LegalConsultationDate

特徴：

• クラス名を表す記法として最も一般的
• C#・Java・TypeScript などのオブジェクト指向で必須

主な利用シーン：

• クラス名
  • UserController
  • CustomerRepository
• DTO／ViewModel／Entity の名前
  • UserDto
  • OrderViewModel
• C# のプロパティ名
  • public string UserName { get; set; }

実務でのメリット：

• ドメイン（概念）を明確に表現しやすく、保守性が高い

2. その他の命名ルール（特定分野・歴史的背景あり）

◆ 2-1. ケバブケース（kebab-case）

形式：

単語-単語-単語
例：legal-consultation-date

特徴：

• URL に適しており、SEO 的にも読みやすい
• HTML や CSS の一部でも使われる

主な利用シーン：

• REST API の URL
  • /api/user-list
  • /order-detail/123
• CSS クラス名（BEM 以前）
  • header-menu
  • btn-primary

実務でのメリット：

• ブラウザ表示で視認性が高い
• URL の規約と相性が良い

◆ 2-2. 全大文字スネーク（SCREAMING_SNAKE_CASE）

形式：

全て大文字＋アンダースコア
例：MAX_USER_COUNT

特徴：

• プログラム内の「定数」を示すために使われる

主な利用シーン：

• C言語の定数
  #define MAX_SIZE 100
• Java の定数(static final)
  public static final int TIMEOUT_SECONDS = 30;

実務でのメリット：

• 「変更されない値」であることを一目で判断可能

◆ 2-3. 全小文字／全大文字（区切りなし）

形式例：

userlist
USERLIST

特徴：

• レガシーなシステムで見られる
• 可読性は低い

主な利用シーン：

• 古い COBOL システム
• 古いバッチ処理で利用されることがある程度

実務での注意点：

• 基本的に新規開発では使用しない

◆ 2-4. ハンガリアン記法（先頭に型名や用途の接頭辞を付ける）

形式：

strName, dtDate, lstUser

特徴：

• 1990年代 Windowsアプリ（VB, C++）で一般的
• 現代では「型推論がある」「IDE が補完してくれる」ため非推奨

主な利用シーン（現在は非推奨）：

• 古い Excel VBA
• レガシー VB, C++ プロジェクト

実務での注意点：

• 新規プロジェクトで導入すると逆に可読性が落ちる
• モダン言語では避けるのがベスト

3. 実務的なまとめ（結論）

◆ データベース（RDB）

→ スネークケース（snake_case） が最も無難

• created_at
• customer_id

◆ アプリケーションコード（クラス・変数・メソッド）

→ パスカルケース／キャメルケース

• クラス名：PascalCase
• メソッド名・変数名：camelCase

◆ REST API の URL

→ ケバブケース（kebab-case）

• /api/user-detail

◆ 定数

→ SCREAMING_SNAKE_CASE

• MAX_RETRY_COUNT

4. 具体例まとめ（場面別）

ここからは、**実務でそのまま使える命名規則ガイドライン（社内標準として配布できるレベル）**をさらに詳しくまとめる。
また、言語別・用途別の比較表、悪い例と良い例、プロジェクト導入のポイントまで網羅して解説する。

5. システム開発で使う「命名規則ガイドライン」

（プロジェクト標準として利用可能）

以下は、実際のプロジェクトで「命名規約」として採用できるレベルでまとめたガイドラインである。

◆ 5-1. 命名の基本ルール

① 意味が分かる名前を付ける

悪い例：

x, y, data1, test, a001

良い例：

userId, orderDate, isDeleted, retryCount

② 短すぎず、長すぎず

極端に長い名前は避け、必要な情報だけを盛り込む。

悪い例：

customerInformationOfTheLastPurchaseDateColumn

良い例：

last_purchase_date

③ 否定形の論理値は避ける（可読性低下）

悪い例：

isNotEnabled

良い例：

isEnabled

④ 略語をむやみに使わない

NG：

crt_dt（created date のつもり）  
usr_nm（user name のつもり）

OK：

created_at  
user_name  

6. 言語別・用途別の命名規則一覧

以下は、主要言語で一般的に採用されている命名規則のまとめ。

◆ Java

◆ C#（.NET）

※ C# は他の言語と少し文化が異なる

◆ JavaScript / TypeScript

◆ Python

Python は PEP8 に従うため「変数・関数はスネーク」が標準。

◆ SQL / RDB

※ 一般的に大文字・キャメルケースは推奨されない

◆ REST API（URL）

URL ではハイフンが読みやすい。

7. 悪い名前・良い名前の比較例（実務で役立つ）

◆ ケース1：曖昧な名前

悪い例：

data, value, info

良い例：

orderInfo, productValue, userData

◆ ケース2：ただの略語

悪い例：

cnt, dt, flg

良い例：

count, date, isFlagged

◆ ケース3：逆に長すぎる

悪い例：

userLoginAuthenticationTimestampValue

良い例：

authenticated_at

◆ ケース4：否定形の論理値

悪い例：

isNotReady

良い例：

isReady

◆ ケース5：数字の乱用

悪い例：

item1, item2, user3

良い例：

firstItem, secondaryUser

8. 命名規則をプロジェクトに導入するポイント

◆ ① 最初にチームでルールを統一する

途中で変えると混乱を生むため、必ずプロジェクト開始時に決める。

◆ ② lint・formatter を活用する

言語ごとに設定すれば、人為的ミスを避けられる。

• JavaScript → ESLint, Prettier
• Python → flake8, black
• Java → Checkstyle
• C# → StyleCop

◆ ③ コードレビューで命名指摘を徹底する

ルールは 運用しないと意味がない。
レビュー時に命名を統一すると品質が安定する。

◆ ④ DB・API・フロントで整合性を取る

例）

• DB：snake_case
• API（JSON）：camelCase
• フロントJS：camelCase

このように変換ポイントを決めて全体を統一する。

◆ ⑤ ドキュメント化して社内に共有する

• Confluence
• Notion
• Wiki
• Teams の共有ドキュメント
  どれでも良いので、必ずドキュメント化する。

9. まとめ（実務での最適解）

つまり、
バックエンド → snake_case
アプリコード → PascalCase / camelCase
URL → kebab-case
が最も実務で安定する。