Unix 系 OS に慣れた開発者でも「/usr が何の略か」をすぐに説明できる人は意外と少ない。実際、 “Unix System Resources” などのもっともらしい後付け説が広まった背景には、省略形が本来の意味を覆い隠し、読み手を混乱させてきた歴史がある。まず語源をたどり、次に命名と省略がなぜ誤解を生みやすいのかを考えてみよう。
/usr の語源は “user”
一九七〇年代初期、ベル研究所の PDP-11 で動いていた Unix にはホームディレクトリが /usr/dmr などの形で置かれていた。すなわち /usr はそのまま “user” の略であり、当時は「ユーザーファイルを納める場所」に過ぎなかった。ところがディスク容量が限られていたため、後にシステムバイナリを別パーティションへ逃がす目的で /usr/bin が誕生し、ユーザー領域とシステム領域が混在していく。結果として本来の意味が薄れ、後年になって「Universal System Resources」「Unix System Repository」など多様な解釈が派生した。 
後付けの「Unix System Resources」説
インターネット黎明期の ML やフォーラムでは、「usr ＝ Unix System Resources」と説明する投稿がしばしば引用された。しかし BusyBox ML の議論では「それは後世のレトロニム（後付けの頭字語）で、本当は user だ」と指摘されている。歴史的事実と合わない略称が拡散される過程そのものが、省略語のあいまいさを示している。 
省略がもたらす読み手の負荷
名前は書く瞬間より読む回数の方が圧倒的に多い。Python の作者 Guido van Rossum も「コードは書かれるより読まれる回数の方が多い」と語っており、読みやすさを犠牲にした省略は長期的にコストを増大させる。 
Software Engineering Stack Exchange でも「i のような慣用的な場合を除き、略語は情報を減らすだけだ」という回答が高評価を得ている。つまり省略が読解の負担になるという認識はコミュニティでも共有されている。 
命名は「書き手の手間」より「読み手の時間」を基準に
略称は入力の手早さという短期的な利点を提供するが、保守フェーズでは第三者が文脈を推測するコストが発生する。/usr の例のように、一度意味を見失うと誤解が連鎖し、ドキュメントの追補や研修コストまで膨らむ。省略を採用するならドメインで標準化されている場合に限定し、それ以外はフルスペルで意図を明確にする方が長期的には安上がりだ。
開発現場への示唆
プロダクトのディレクトリ構成や API 名も同様に、「一見して分かるか」を第一基準に据えたい。たとえば log ファイルを置くディレクトリを /lg としてしまうと、/usr のように後年まで説明が必要になる。逆に /logs と書けば説明なしでも理解できる。短縮形を使わないことでバイト数は増えたとしても、レビューやデバッグに要する合計時間は確実に減る。
おわりに
/usr が “user” の略である事実は、システムの歴史的制約と命名のあいまいさが重なると、本来の意味が簡単に風化することを物語っている。コードでもディレクトリでも、名前は「読む人のためのインターフェース」だ。不要な省略は控え、文脈を持たない第三者でも一読で理解できる名称を選ぶことが、将来の自分や仲間を助ける最良のドキュメントになる。
参考URL
https://askubuntu.com/questions/130186/what-is-the-rationale-for-the-usr-directory
https://news.ycombinator.com/item?id=31336396
https://softwareengineering.stackexchange.com/questions/72593/how-to-abbreviate-variable-names
https://dev.to/dvddpl/harmless-code-and-obvious-code-a-code-review-chronicles-about-date-validation-11m9