もっと識別子の命名をちゃんとしよう～それは英語力ではなく設計力の話～

Posted at 2026-05-06

はじめに

コードを書くとき、識別子の命名をどれくらい真面目に考えているだろうか。

getData
process
check

こういった名前が並ぶコードは珍しくない。
そして多くの場合、それらは「なんとなくそれっぽい」以上の意味を持っていない。

この記事で言いたいことはシンプルだ

命名は英語の問題ではない。設計の問題である。

そしてもう一つ

翻訳機に命名を任せるな。辞書を使って自分で選べ。

よくある誤解

英語力がないと良い命名はできない?

そんなことはない。

日本の学校教育での英語の成績は関係ない。
ネイティブ並みの語彙も不要。

必要なのは「知っている単語の数」ではなく、

候補を比較して、意味で選ぶ力

だけだ。

チーム開発だから単純な語彙でいい?

これもよくある逃げ道だが、成立していない。

「共通語彙」を理由にして、

雑な単語を使う
意味の違いを潰す

これらはただの手抜きだ。
本来揃えるべきなのは、

意味がきちんと切り分けられた語彙

であって、「誰でも知っている雑な単語」ではない。

翻訳機と辞書は別物である

ここは明確に区別したほうがいい。

翻訳機

入力: 1つの日本語
出力: 1つの英語
性質: 表面上の意味から「それっぽい答え」を出す

一見便利だが、本質的な問題がある。

意味の選択を勝手に済ませてしまう

識別子の命名は「どの意味を採用するか」を決める行為なのに、
その決定を外部に丸投げしてしまっている。

辞書

入力: 1つの単語
出力: 複数の候補 (ニュアンスの違いなどで分岐)
性質: 曖昧さを展開する

辞書は最終決定をしない。
その代わり、

選択肢を提示して、判断を要求する

翻訳機と辞書の決定的な違い

翻訳機は「決めてくる道具」
辞書は「選ばせる道具」

そして、

命名は決定の工程なので、 決定を肩代わりする道具を使ってはいけない

命名の実践プロセス

ではどうやるのか。

これは特別な才能ではなく、手順の問題だ。

1. 日本語を固定しない

まず「取得する」などと仕様書が押し付けてきた一語で決め打ちしない。

このように、日本語の段階でまず意味をくみ取る。
この段階で既に、雑な英単語割り当てをするのとは違って「それはつまりどういう事か」を真剣に考えている状態になる。

2. 英語の候補を出す

ここで翻訳機を使ってはいけない。
日本語の表面的な意味に対応した一語が決定されてしまう。
しかもその一語は、どの意味を採用したのかを説明してはくれない。
決定者はあなたでなくてはいけない。機械に任せないこと。

日本語の段階でバリエーションを出した単語のそれぞれを和英辞典で引いて出てきた単語を起点に、

定義
類語
用例

を確認する。特に類語がある場合はそれを英和辞典で日本語にしてみよう。これで幅がぐっと広がる。

retrieve

3. 違いを把握する

出てきた単語をしっかりと比較する。

例えば：

get
fetch
load
retrieve

それぞれ微妙に違う。

get: 最も広く用いる事ができるが、それ故に追加の情報が少ない (これを選ぶのは無難ではあるが「他の適切な選択肢に気づけなかった事」の自白にもなるだろう)
fetch: 外部から取りに行く
load: メモリや状態に読み込む
retrieve: 保存されているものを取り出す

4. 文脈に合うものを選ぶ

ここで初めて「決定」をする。

候補に使った日本語と、辞書で引いてきた英単語
これらのひとつひとつは「点」でしかない。

ただし、それらを一望すると
点が合わさって線を作り
線が合わさって面を作り
面が合わさって立体を作るように
そこに複数の語が紡ぎだす意味空間が広がるだろう。

この空間の中で、それぞれの点がどこにあるか、
これを感覚でとらえると、『適訳』は自ずと決まる
単語の方から、あなたに語りかけてくるはずだ
(これは実際には、定義や用例の差分が整理された結果、適切な語を潜在意識が「推し」ている状態だ。
顕在意識で論理的に決定するというより、潜在意識が選り分けてくれる感覚に近い)

翻訳機を使うと勝手に「点」を決めつけて押し付けてくる。
辞書による意味空間の把握は「立体」を紡ぎだし、あなたの潜在意識がそこから適訳を決定する。

命名の良し悪しは、この立体が見えているかで決まる。

しかし、「そこまでやるのはコストが高すぎる」と感じていないだろうか?

命名が悪いコードは何を生むか

適切でない命名は、単に「分かりにくい」では済まない。

毎回推定が必要になる

名前から意味が分からない
→ 周囲のコードを読む
→ 文脈を復元する
→ ようやく推定できる (しかもそれが正しい保証はない)

これが毎回発生する。

さらに悪いことに:

一度理解しても忘れる
別の人は最初からやり直し
未来の自分もやり直し

つまりこれは

無限に再発するコスト

良い命名がもたらすもの

適切な命名は、そのようなコストをほぼゼロにする。

それだけではない。

命名が情報になる

例えば:

loadUserFromCache
fetchUserFromApi

この時点で

データの出どころ
コスト感
操作失敗の可能性の程度

まで伝わる。

そしてこれはコメントではなく、活きているコードの一部だ。

命名そのものが、信頼できる情報源になる

投資対効果の話

話を戻そう。

「そこまでやるのはコストが高い」と感じていたはずだ。

短期的にはその通りだ。

しかし実際には

読解コストが消える
誤読リスクが消える
バグが減る
修正が速くなる
不要な摩擦やストレスが減る (バグが減った時、あなた以上にうれしいと感じる人が他にいるからだ)

結果として、

命名にかけた時間は、後の工程で何倍にもなって回収される

結論

英語ができる必要はない。

ただし、

単語を選ぶという工程をサボってはいけない

翻訳機で出てきた1語をそのまま使うのは、
命名を放棄しているのと同じだ。

翻訳機で終わるな。辞書で始めろ。