🏗️「あなたの仕事って100年残る？」と妻に聞かれて気づいたテーブル名の恐ろしい真実

この記事はLITALICO Engineers Advent Calendar 2025 カレンダー3 の 2日目の記事です

はじめに - 某企業CMを見ていたら...

先日、妻と一緒にテレビを見ていたときのこと。

テレビCM: 「地図に残る仕事。」（某大手建設会社）

妻: 「あなたの仕事って100年くらい残るかしら？」
私: 「システムだからね、10年くらいが限界かな」
妻: 「そうなのね。でも、それくらいがちょうどいいかもね、100年だと変な仕事も残っちゃうし」
私: 「あ、でも...テーブル名とか結構残っちゃうかも...😨」

この瞬間、背筋が凍りました。

そうです。テーブル名は思っている以上に長生きするんです。

注意: この記事で登場するテーブル名、システム名等は、すべてフィクションです。実在のLITALICOのシステム、データベースとは一切関係ありません。過去、色々なテーブル名・カラム名を拝読させていただいた経験からパターン抽出して記事を書いております。

---

📊 テーブル名の寿命調査（独自研究）

🏢 システムの寿命 vs テーブル名の寿命

対象	平均寿命	備考
システム全体	5-10年	リプレイス、リニューアルで一新
アプリケーション	2-5年	技術スタック変更で書き換え
テーブル名	10-20年	マイグレーション時も生き残る
変数名	1-2年	リファクタリングで消滅

恐ろしい真実: テーブル名はシステムより長生きします 😱

---

💀 歴代設計者による「テーブル名地層」の形成

第1世代：創設者（2005年〜）

-- 英語原理主義者
CREATE TABLE user_information (
    user_identification_number BIGINT,
    full_name_in_japanese VARCHAR(255),
    electronic_mail_address VARCHAR(255)
);

特徴: 真面目で長い。informationが好き。

第2世代：実用主義者（2010年〜）

-- 短縮命名派
CREATE TABLE usr_info (
    usr_id BIGINT,
    name VARCHAR(255), 
    email VARCHAR(255)
);

特徴: とにかく短く。母音を削ることに命をかける。

第3世代：ローマ字戦士（2015年〜）

-- 「英語わからないからローマ字で」
CREATE TABLE riyousya_jouhou (
    riyousya_id BIGINT,
    namae VARCHAR(255),
    meiru VARCHAR(255)  
);

特徴: 潔くローマ字。むしろ清々しい。

第4世代：略語マニア（2020年〜）

-- 「業界用語使えば通っぽい」
CREATE TABLE cstmr_mst (
    cstmr_cd VARCHAR(20),
    cstmr_nm VARCHAR(255),
    mail_addr VARCHAR(255)
);

特徴: 略語で知識をアピール。mst（マスタ）を多用。

---

🔄 テーブル名変更のコスト試算

💰 「users」を「user_master」に変更する場合

影響箇所	工数	備考
アプリケーションコード	2人日	全ファイル検索・置換
SQLファイル	1人日	バッチ処理、VIEW定義等
ドキュメント	0.5人日	テーブル定義書、ER図
テスト	3人日	全機能の回帰テスト
デプロイ作業	0.5人日	DDL実行、データ移行
心理的ダメージ	∞	プライスレス

合計: 約7人日（約56万円）

🎭 チーム内の反応

新人エンジニア：「なんでテーブル名変えるんですか？」
ベテラン：「昔の人が変な名前付けたから...」  
新人：「でも動いてますよね？」
ベテラン：「......（ぐうの音も出ない）」

PM：「工数どのくらい？」
エンジニア：「7人日くらい...」
PM：「え？名前変えるだけで？」
エンジニア：「はい...（小声）」

---

🏆 おっと思ったテーブル名ランキング（過去の職場で実際にこんなテイストのテーブルあった！）

第1位 🥇

CREATE TABLE temp_backup_user_mst_dtl_20241117_final_final2_really_final;

目を引くポイント: temp、backup、更にfinalが3つある
個人的意見: コード側での記述（Entityなど）をどうするか悩む。後々、棚卸しの際に、テーブルの目的を誤認しそう

第2位 🥈

CREATE TABLE t1;

目を引くポイント: 何のテーブルかわからない
個人的意見: 。クエリを短くしたかったのかな、その場合、エイリアスを使ってほしい

第3位 🥉

CREATE TABLE 🤔💭🧠_考え中_temporary_maybe;

目を引くポイント: 絵文字とローマ字と英語が混在している
個人的意見: データベース管理ツールがクラッシュしないか心配。また、コード側のEntity、どうするかなと悩む

第4位

CREATE TABLE zzzz_delete_this_after_migration_in_2001;

目を引くポイント: in_2001、ずいぶん長いこと残っちゃったな
個人的意見: 2016時点では存在していた。今はどうだろう、前の職場すぎてわからない。誰も触れない聖域となってないことを祈る、今だとスナップショットで残すことが多いから、こういうテーブルは減っていると思う

第5位

CREATE TABLE user (
    user_user_id INT,
    user_name_name VARCHAR(255)
);

目を引くポイント: 同じ単語の繰り返し
個人的意見: 気持ちはわかるが、整理いただきたい。特にname_nameは、コード実装で気づいて修正してくれると嬉しい。

---

🎯 現代的テーブル名設計のベストプラクティス

✅ 推奨パターン

-- 1. シンプルで分かりやすい
CREATE TABLE users (           -- ❌ user_information
    id BIGINT,                 -- ❌ user_identification_number  
    name VARCHAR(255),         -- ❌ full_name_in_japanese
    email VARCHAR(255)         -- ❌ electronic_mail_address
);

-- 2. 複数形で統一
CREATE TABLE orders;           -- ❌ order_table
CREATE TABLE order_items;     -- ❌ order_dtl

-- 3. 日本語が必要なら素直に
CREATE TABLE 顧客;              -- ❌ kokyaku, cstmr
CREATE TABLE 注文;              -- ❌ tyuumon, ord

🤖 現実的な選択肢：AI命名支援の活用

正直な話、2025年現在では「AIに相談する」というのが実用的な解決策になってきています。

ChatGPTに相談してみた実例

私: 「ユーザーの注文履歴を管理するテーブル名を考えて」

ChatGPT:

-- 提案1: 明確で標準的
CREATE TABLE user_orders;

-- 提案2: より詳細
CREATE TABLE order_history; 

-- 提案3: 日本語対応
CREATE TABLE 注文履歴;

結果: どれも人間が30分悩んで決めたものより適切。

🎯 AI命名の驚くべき効果

項目	人間の命名	AI支援命名
命名時間	30分〜2時間	3分
チーム内議論	1時間の会議	5分の確認
命名の一貫性	バラバラ	高い統一性
英語の正確性	怪しい	ネイティブレベル
後悔度	高め	低め

📝 実際のAI活用フロー

1. 要件をAIに説明
2. 複数の命名パターンを生成
3. チームで3分レビュー  
4. 採用して完了

従来の手順:

1. エンジニアが30分考える
2. 「なんかダサくない？」で振り出し
3. チーム会議で1時間議論
4. 「とりあえずこれで」で妥協
5. 3ヶ月後に後悔

💭 でも、何かが失われていく...

技術的には完璧。でも...

-- AI命名（完璧だが味気ない）
CREATE TABLE user_authentication_sessions;
CREATE TABLE product_category_mappings;
CREATE TABLE order_payment_transactions;

-- 人間命名（不完璧だが愛嬌がある）  
CREATE TABLE ログイン_who_when_where;  -- 新人の作品
CREATE TABLE omoshiro_categories;      -- 面白カテゴリ
CREATE TABLE okaikei_table;           -- お会計テーブル

AIの命名: 文法完璧、意味明確、国際標準準拠
人間の命名: 不完全だが、作った人の顔が見える

🤔 エンジニアの心境変化

導入前:
「テーブル名考えるの面倒だなあ...」

導入後:
「AIが完璧な名前付けてくれた！楽だー！」

3ヶ月後:
「なんか...全部のテーブルが同じ感じになってきた...」

6ヶ月後:
「昔、先輩が付けた user_omakase_table って、今思うと愛があったな...」

🎭 チーム内での温度差

新人エンジニア: 「AI最高！命名で悩まなくていい！」
中堅エンジニア: 「効率的だけど、なんか寂しいよね」  
ベテラン: 「昔は命名で夜中まで議論したもんだが...」
AI: 「規則に従った最適解を提供しました」

全員: 「......（なんとも言えない気持ち）」  

📊 推奨度とトレードオフ

使用場面	推奨度	効率	人情
新規大型プロジェクト	★★★★★	最高	普通
レガシー改修	★★★☆☆	高い	やや寂しい
チーム学習目的	★★☆☆☆	高い	薄い
個人プロジェクト	★★★★☆	最高	寂しい

結論: AIは優秀な相棒。でも時々、人間らしい「味」も大切にしたい。

現実的な落としどころ:

• 基本はAIに相談
• たまには人間の直感も混ぜる
• 完璧すぎる名前にあえて「愛嬌」を1つまみ

---

🎬 エピローグ：妻との続きの会話

私: 「結局、テーブル名って意外と長生きするんだよね」
妻: 「へー、じゃあ変な名前付けちゃダメね」
私: 「そうそう。昔の人が usr_mng_mst とか付けて、今でもみんな困ってる」
妻: 「ちゃんと日本語で書けばいいのに」
私: 「え？」
妻: 「だって日本人なんだから、『顧客』って書けばいいじゃない」

この瞬間、10年間の悩みが解決しました。

---

🎊 結論：未来のエンジニアへのメッセージ

親愛なる未来のエンジニアへ、

あなたが今日付けたテーブル名は、あなたが転職した後も、結婚して子供が生まれた後も、もしかしたらあなたの子供が成人した後も、しぶとく生き残っているかもしれません。

だから、愛を込めて名前を付けてください。

未来の誰かが「このテーブル名を付けた人、センスいいなあ」と思ってもらえるような、そんな名前を。

それが、私たちエンジニアが地図に残せる、小さくて大きな仕事なのかもしれません。

---

P.S. この記事を読んだ後、自分のプロジェクトのテーブル名を見返してみてください。10年後の自分に感謝されるか、恨まれるか、すぐに分かりますよ 😅