2025/12/12 3:06
Programmers and software developers lost the plot on naming their tools
RSS: https://news.ycombinator.com/rss
要約▶
日本語訳：
Richard Stallman の 2022 年 EmacsConf 講演は、パッケージの目的を明確に伝える 「覚えやすい名前」 の重要性を強調しました。彼は、従来から名前が明快だったエコシステム（例：
diredeshell対照的に、工学分野では機能や由来を直接表す名前（橋、ダム、バルブなど）が日常的に使われており、認知負荷が低減されます。1970‑80 年代の歴史的ソフトウェア（例：
grepawksedcatdiff風変わりな名前へのシフトは 2010 年代のオープンソースプロジェクトで始まり、GitHub やスタートアップ文化によって加速し、「意味不明な呼称の動物園」を生み出しました。曖昧な名前は開発者に認知的課税を課し、目的を調査・推測する時間が必要となり、その労力はプロジェクトを越えて蓄積されます。
「マーケティング効果」「退屈回避」「ただ楽しい」などの名前付けの言い訳に対して、非消費者向けライブラリやツールでは明瞭さが最優先であるという主張が反論します。著者は文化的修正を提案し、具体的・複合的な名前を採用すること、エンドユーザー製品には可愛いまたはブランド化されたタイトルを保留し、マスコットは別途使用（例：PostgreSQL の Slonik）とします。推奨実践としては、機能名で命名（
http-request-validator総合メッセージは、開発者の時間を尊重し、任意またはミームベースの名前よりも明確で意味ある名前を選ぶようソフトウェアコミュニティに促すものです。
本文
プログラミング – 命名規則
2022年12月、私はEmacsConfでリチャード・スタールマンが行った「What I’d Like to See in Emacs（エマックスに望むこと）」という講演を視聴しました。
彼の主張の一つは、「すべてのパッケージにはその機能が思い出しやすい名前を付けるべきだ」という点でした。
2022年でもまだこのような注意喚起が必要だったことから、エマックス・エコシステムにおける記述的命名規則からどれだけ逸れてしまったかが浮き彫りになります（例：ディレクトリ編集用は dired 、Emacs シェルは eshell など）。
現代の命名問題
今日では、ソフトウェアをランダムな名詞や神話上の生物、好きな架空キャラクターにちなんで名前付けするケースが一般的です。
これはほとんどの他分野では「キャリア自殺」と言えるほど危険です。
ある同僚は次のようにスタックを説明していました：
「Viper を設定管理に使い、CLI は Cobra が担当し、WebSocket 接続は Melody が処理、権限は Casbin が管理、ジョブキューは Asynq でやっています。」
Viper, Cobra, Melody, Casbin, Asynq といった名前は、その目的をすぐに想起させるものではありません。
対照的に：
- ゴールデン・ゲート・ブリッジ はゴールデン・ゲート海峡を渡っていることが一目で分かります。
- フーバー大坝 はフーバー大統領の名前から名付けられたダムです。
- I‑beam（Ｉビーム） は形状が「I」に似ているため、構造用部材と直感的に結びつきます。
- バタフライ・バルブ は蝶の羽を連想させる形状です。
こうした名前は機能を示し、余計な説明なしで覚えやすくします。
歴史的背景
ソフトウェア開発では昔から似たような命名パターンが見られます：
| ツール | 説明 |
|---|---|
| grep | global regular expression print（全体の正規表現を表示） |
| awk | Aho, Weinberger, Kernighan の頭文字から |
| sed | stream editor（ストリーム編集器） |
| cat | concatenate（連結） |
| diff | difference（差分） |
初期のプログラミング言語も同様に記述的でした：
- FORTRAN – Formula Translation
- COBOL – Common Business‑Oriented Language
- BASIC – Beginner’s All‑purpose Symbolic Instruction Code
- SQL – Structured Query Language
- Lisp – List Processing
2010年代に入ると「メミックウイルス」がソフトウェア工学に浸透しました。
MongoDB など一部のユニーク名は語源を持つものもありますが、ほとんどは意味不明な呼称となり、名前と機能との結び付きを断絶させています。
認知コスト
あいまいな名前は開発者に探偵モードを強います：
- 未知の用語を見つける。
- ドキュメントや README を調べる。
- その目的を解読する。
現代プロジェクトでは数十もの依存関係があるため、これらの追加秒は合計で数分――場合によってはキャリア全体にわたる無駄な労力となります。
例として上記文をコードベース構造を説明する際に使うとしましょう：
「Viper は設定、Cobra は CLI、Melody は WebSocket、Casbin は権限、Asynq はジョブキュー」と語るとき、精神的なバンド幅の半分が無作為に選ばれたトークン（蛇、音楽、ミステリー）を実際の機能へマッピングする作業に費やされます。
よくある弁解と反論
| 弁解 | 反論 |
|---|---|
| 覚えやすい名前はマーケティングに役立つ | 消費者向け製品には関係しますが、ライブラリやユーティリティはエンドユーザーを対象としておらず、明瞭さの方が重要です。 |
| 記述的な名前は退屈だ | クリアさが最優先なら退屈でも構いません ― これは創作文学の授業ではありません。 |
| 楽しい名前は楽しみになる | 楽しめる名前はユーザー全員に認知負荷を課し、業界全体でその影響が増大します。 |
| すべての良い記述的名前は既に使われている | 名前空間やプレフィックス、複合語（例：http‑request‑validator）を利用すれば解決できます。技術的には十分にサポートされています。 |
今後への道筋
- 機能で命名する。 必要ならば複合語を使い、曖昧さよりも冗長性が望ましいです。
- ブランド重視のエンドユーザー製品にのみ遊び心のある名前を残す。 インフラやツール・ライブラリでは明瞭さを優先します。
- マスコットは製品名とは別物として扱う。 PostgreSQL の Slonik（象）はマスコットであり、データベース自体は PostgreSQL です。
- 社会的圧力と教育を通じて文化的修正を行い、規制ではなくプロフェッショナル基準で明瞭な命名を推進する。
最後に
次のプロジェクトをアニメキャラクターや好きな生物の名前で呼ぶ前に、一度立ち止まって質問してください：
「土木技師は橋の支持構造をこのように名付けるでしょうか？」
答えが いいえ なら、もっと良い名前を選びましょう。
私たちの分野には、ユーザーの時間と認知リソースを尊重した名前がふさわしいと言えるはずです。
おすすめ読書
(関心を持つための作品一覧)