ここ5、6年のあいだに、多くの開発者がささやかだが少し落ち着かない変化に気づいたはずだ。見慣れた言葉が、いつの間にか置き換えられていった。
GitHubをはじめとするプラットフォームでは、2020年代から、新しいリポジトリのデフォルトブランチ名が master ではなくなった。代わりに使われるのは main。ドキュメントでは「whitelist」や「blacklist」が「allowlist」「blocklist」に置き換わり始めた。一部のシステムでは「master/slave」という関係が「primary/secondary」や「leader/follower」に改められた。
これらの変更でソフトウェアが壊れたケースは少ない。システムの動作に影響したものもほとんどない。だが、どれも意図的に――しかも広範囲にわたって行われた。
ある人にとっては、不要な変更、あるいは余計なお世話に映っただろう。業界で長く通用してきた用語を、なぜわざわざ変える必要があるのか。別の人にとっては、むしろ遅すぎた変化だった。テクノロジーをより多くの人に開かれたものにし、歴史的・文化的に荷重のある比喩から解放するための取り組みの一環として。
注目すべきは、用語が変わったこと自体だけではない。その変化がいかに異なる解釈を受けているか、という点だ。
多くの国際的なオープンソースコミュニティでは、議論は実務的な問いに集中する傾向がある。代替用語のほうが明確か、英語を母語としない人にとって理解しやすいか、システムの実際の動作をより正確に表しているか、といった観点だ。一方、日本語圏の議論の一部では、同じ変化が「言葉狩り」やポリティカル・コレクトネスという枠組みで語られやすい。言葉を洗練させるというより、言葉を制限する試みとして。
この解釈のギャップは、より根本的な問いを浮かび上がらせる。ソフトウェアがグローバルに分散したコミュニティによって構築・維持されているとき、言葉はどのような役割を果たすのか。用語はたんなる慣例にすぎないのか、それとも人々がコードを読み、理解し、貢献するプロセスを形づくるインフラの一部なのか。
その問いに答えるには、何が変わったのか、なぜその変更が提案されたのか、それが主要プロジェクトにどう広がったのか、そしてなぜそれに対する反応がこれほどまちまちなのかを、もう少し詳しく見る必要がある。
浮かび上がるのは、「禁句」をめぐる単純な物語ではない。エンジニアリングの実践、グローバルな協働、そして社会的期待がテクノロジーの言語のなかで——ときに居心地悪く——交差する、より複雑な構図だ。
何が実際に変わったのか（具体例）
動機や論争を検討する前に、実際に何が変わったのかを確認しておきましょう。変化は、いくつかの注目度の高い用語にとどまりません。システム設計、ドキュメントのスタイル、日常的な開発者コミュニケーションにまで及んでいます。
システム・インフラ用語
もっとも目に見える変化は、コードベースやプロトコル、ツールで使われるコア技術用語に起きています。
- master / slave
→ primary / secondary、primary / replica、leader / follower、controller / device
置き換え後の用語は、システム上の役割をより直接的に記述することを目指しています。たとえば、協調（「leader」）と複製（「replica」）の区別がより明確になります。 - whitelist / blacklist
→ allowlist / blocklist、denylist
代替語は動作を明示的に表します。何が許可され、何が拒否されるのか。 - master branch
→ main branch、development branch
GitHubのデフォルト変更によって広まり、現在ではリポジトリやツール全般に多く採用されています（developmentブランチを使う潮流もある）。
こうした変化は新規システムから先に現れる傾向があり、既存システムでは互換性のためにレガシー用語が残ることもあります。
ドキュメント・テクニカルライティング
コード以外でも、スタイルガイドやドキュメント標準がより中立的で記述的な表現へと進化しています。
- dummy variable
→ placeholder / example value
「ばか、まぬけ」のような意味にも文脈によって取れる言葉から、日本語でも言われるダミーという用語が生まれたので、「プレースホルダー」などへの言い換えが進んでいる。 - sanity check
→ consistency check / final check
「正気チェック→整合性チェック」のような意味合い。 - man-hours
→ person-hours / engineering hours
男性への固定観念を減らす。 - he/she
→ 単数の「they」、または文の書き換え
ここで重視されているのは、とりわけグローバルな読者に対する明確さと可読性です。同じ慣用的な文脈を共有しない読者にとって、こうした配慮は重要になります。
日常的な開発者コミュニケーション
フォーマルではないものの、影響力があるのが、ドキュメント、イシュートラッカー、チームでの議論における開発者のコミュニケーション様式の変化です。
- “guys” → “everyone”、”folks”、”team” – 「みなさん」
- “grandfathered” → “legacy exemption”、”existing exception” – 「既存の例外」
- “crazy”、”insane”、”blind to” といったカジュアルな表現を、より正確な言い回しが使える場面では避ける
こうした変化は標準化の度合いが低いですが、編集ガイドラインやコミュニティの規範にますます反映されるようになっています。
パターン：比喩から記述へ
これらの例全体に共通するパターンがあります。従来の用語の多くは比喩に依存しています。歴史的、文化的、あるいは慣用的な比喩です。新しい代替語は、機能や役割を直接記述する方向に向かう傾向があります。
もちろん、一対一の置き換えが常に存在するわけではありませんし、すべての変更が普遍的に採用されているわけでもありません。複数の代替語が共存するケースは多く、「最適な」用語は文脈によって異なります。
それでも、これらの例を総合すると、この変化が仮定の話ではないことがわかります。ツール、ドキュメント、協働のプラクティスにすでに組み込まれており、今も進化し続けています。
なぜこれらの変更が起きたのか（複数の動機）
一見すると、こうした用語変更の多くは象徴的、あるいは恣意的にさえ見えるかもしれません。しかし、変更を導入したコミュニティの内部では、実務的な考慮と社会的な考慮を組み合わせた形で正当化されるのが通常です。単一の説明では不十分であり、複数の動機が重なり合っています。
明確さと正確さ
もっとも率直な論拠のひとつは、技術的なものです。
レガシー用語の多くは、記述ではなく比喩に依存しています。それらの比喩は特定のコミュニティ内では広く理解されていたかもしれませんが、常に正確であるとは限りません。たとえば：
- 「allowlist/blocklist」はシステムの動作を直接記述します
- 「leader/follower」や「primary/replica」は、「master/slave」よりもシステム上の実際の役割をより的確に反映できます
システムが複雑化し、ドキュメントの重要性が増すにつれて、標準化団体や大規模プロジェクトでは特に、機能を暗示するのではなく記述する用語が好まれる傾向が強まっています。
この意味で、一部の変更は言葉の置き換えというよりも、技術的コミュニケーションの改善と捉えるほうが適切です。
グローバルな協働と非ネイティブ英語話者
現代のソフトウェア開発は、本質的にグローバルです。大規模なオープンソースプロジェクトや標準化団体には、多様な言語的・文化的背景を持つ貢献者が参加しており、その大多数は英語のネイティブスピーカーではありません。
こうした文脈では：
- 慣用的あるいは文化固有の比喩は混乱を招きうる
- 歴史的に荷重のある用語は、地域によって異なる含意を持つことがある
- よりシンプルで記述的な言語は、理解のハードルを下げる
ネイティブスピーカーにとっては些細な言い回しの選択が、そうでない人にとっては理解上の障壁になりうるのです。スケールにおけるアクセシビリティを重視するプロジェクトは、用語をオンボーディングやユーザビリティの一部としてますます扱うようになっています。
参加とコミュニティ規範
もうひとつの動機は、技術的な議論ではあまり目に見えませんが、それでも影響力があります。参加の問題です。
一部の貢献者は、特に「master/slave」のような歴史的な連想を持つ用語が不快感や疎外感を与えうると主張してきました。すべての個人がその反応を共有するかどうかにかかわらず、大規模な協働コミュニティは個人の好みよりも幅広い参加に最適化する傾向があります。
この観点からすると、用語の調整は過去の言語を「正す」ことが主目的ではありません。次のような環境を形づくることが目的です：
- より多くの人が貢献しやすいと感じられる
- 議論が用語論争ではなく技術的な課題に集中できる
- コミュニティが掲げる価値観と規範が一致する
これはとりわけオープンソースにおいて重要です。参加は任意であり、コミュニティの健全性がプロジェクトの持続可能性に直結するからです。
スタイルガイドと標準による制度化
個別のプロジェクトにおける散発的な変更として始まったものが、時間とともにより体系化されてきました。
主要な組織や機関が、インクルーシブあるいは記述的な用語を奨励・標準化するガイダンスを公開しています：
- テクノロジー企業（Google、Microsoftなど）がドキュメントスタイルガイドを通じて
- 標準化団体（IETFなど）が声明やドラフトを通じて
- Inclusive Naming Initiativeのような業界横断的な取り組みを通じて
これらの取り組みは、特定の置き換えを義務付けるものばかりではありません。多くの場合、提供されるのは：
- 推奨される代替語
- 文脈に応じたガイダンス
- 互換性上の制約に対する認識
こうした制度的な層が、議論を個別の判断からより共有された実践へと移行させる役割を果たしてきました。ただし、採用の度合いは依然として不均一です。
単一の運動ではなく、蓄積
重要なのは、これらの動機が一斉に現れたわけではないということです。一部はテクニカルライティングの明確さに関する長年の懸念に根ざしており、他の一部はソフトウェア開発がよりグローバルかつ社会的に意識されるようになるにつれて、最近になって注目度を増したものです。
突然の「波」のように見えるものは、技術的・組織的・文化的な圧力の蓄積として理解するほうが正確です。それらがやがて臨界点に達したのです。
その結果、変更は均一でもなければ、普遍的に合意されているわけでもありません。しかし、現代のソフトウェアが構築される方法——協働的に、国境を越えて、大規模に——を反映しているがゆえに、無視することはますます難しくなっています。
トレンドはいかに広がったか（歴史とタイムライン）
テック業界における現在の用語変更の波は、突然の転換という印象を与えることがあります。実際には、単一の転換点ではなく、重なり合う一連の展開を通じて、徐々に形成されてきたものです。
前史——目に見えるようになる前
技術的な文脈における言語への懸念は、新しいものではありません。「main branch」や「allowlist」といった用語が一般に使われるようになるはるか以前から、テクニカルライティングにおける明確さ、アクセシビリティ、バイアスについての議論は、ドキュメントの実務やアカデミックの分野にすでに存在していました。
スタイルガイド——とりわけグローバルな読者を対象としたもの——は、すでに以下のような方針を推奨し始めていました：
- よりシンプルで記述的な表現
- 慣用的あるいは文化固有の表現の回避
- ユーザーや開発者への、より中立的な言及方法
ただし、この段階ではこうしたガイダンスはドキュメントの範囲にとどまることが多く、コアなシステム用語にはほとんど影響を与えていませんでした。
漸進的な採用——プロジェクト単位の変更（2010年代）
2010年代に入ると、個別のプロジェクトやコミュニティがローカルな変更を行い始めます：
- ドキュメントやAPIで特定の用語を置き換えるもの
- レガシー用語と並行して代替用語を導入するもの
- イシュートラッカーやメーリングリストで命名規則に関する議論がより目に見える形で行われるようになったもの
こうした取り組みは大部分が分散的でした。異なるプロジェクトが独立に実験を行い、単一の標準や組織的な運動は存在しませんでした。そのため、採用は不均一なままで、多くの変更は特定のコミュニティの外では気づかれずに終わりました。
加速——2020年前後
2020年前後に変化のペースは大幅に加速し、この問題は業界全体で広く認知されるようになります。
いくつかの注目度の高い動きが、この加速に寄与しました：
- GitHub が、新規リポジトリのデフォルトブランチ名を
mainにすると発表。数百万人の開発者にとって即座に可視的な変化となりました - Linuxカーネルプロジェクト が、コーディングスタイルガイドラインを更新し、「master/slave」や「blacklist/whitelist」といった用語の新規使用を非推奨としました。ただし実用的な例外は明示的に認めています
- IETF（Internet Engineering Task Force） が、技術標準におけるインクルーシブな言語に関する声明やドラフトを発出しました
- Inclusive Naming Initiative が、企業やオープンソースコミュニティを横断して推奨事項の調整とガイダンスの共有を行う場として立ち上げられました
これらの動きが普遍的な標準を課したわけではありませんが、クリティカルマスを形成しました。それまで散発的だった取り組みが、業界規範のより広範なシフトとして見え始めたのです。
定着——2020年代前半から中盤
この加速期を経て、変更は定着していきます：
- 新しいツール、フレームワーク、プロジェクトが、デフォルトで更新された用語を採用するようになりました
- ドキュメントや教材がますます新しい用語を反映するようになりました
- 開発者が学習過程の初期段階でこれらの変更に出会うようになり、後から調整するものではなくなりました
同時に、レガシー用語が消えたわけではありません。多くの既存システムは互換性の理由から古い用語を維持しており、一部のドメインでは代替表現がまだ議論の途上にあるか、不明確なままです。
単一の方向ではなく、収束
重要なのは、この進化が単一の組織やイデオロギーによって推進されたものではないということです。複数の要因が収束した結果です：
- グローバルな協働の規模の拡大
- ドキュメント品質への関心の高まり
- 主要組織からの制度的ガイダンス
- そして、技術コミュニティに影響を与えた、より広い社会的意識
2020年前後に変わったのは、用語そのものだけではありません。その可視性です。大規模なプラットフォームや広く使われるプロジェクトが新しいデフォルトを採用したことで、この議論に以前触れたことがなかった人にとっても、変化は無視しがたいものになりました。
このタイムラインを理解することは、変化への反応がなぜこれほど幅広いのかを説明する助けになります。ある人にとっては、突然の、外部から押しつけられたトレンドに見えます。別の人にとっては、何年も前から進行していた漸進的な調整の自然な延長です。
主要OSS・機関のケーススタディ
用語の変化は、広く使われるプラットフォームや組織が下した具体的な判断を通じて見ると、より鮮明になります。これらのケースが示しているのは、変更が抽象的な議論ではなく、大規模な実システムにおける実務的な選択であったということです。多くの場合、トレードオフを慎重に検討した上で行われています。
GitHub——デフォルトをmainに変更
2020年、GitHubは新規作成されるリポジトリのデフォルトブランチ名をmasterからmainに変更すると発表しました。
この決定が重要だったのは、変更自体が技術的に複雑だったからではありません——複雑ではありませんでした。重要だったのは、現代のソフトウェア開発における中心的なプラットフォームとしてのGitHubの立場です。デフォルトを変更することで、GitHubは数百万のプロジェクトに対して事実上の新しい基準を設定しました。用語の議論を積極的にフォローしていなかった開発者が作成するプロジェクトも含めてです。
重要な点として、GitHubは既存のリポジトリにブランチ名の変更を強制しませんでした。代わりに移行のためのツールとガイダンスを提供し、各プロジェクトが自らの制約に基づいて判断できるようにしました。強調されたのは、強制ではなく摩擦の少ない採用でした。
提示された根拠は、いくつかの要素を組み合わせたものです：
- 進化するコミュニティ規範との整合
- ワークフローへの最小限の影響
- デフォルトの選択が長期的な習慣を形づくるという認識
この意味で、この変更はデフォルトがソフトスタンダードとして機能しうることを示す好例です。正式な命令なしに、徐々に実践を変えていくのです。
Linuxカーネル——純粋さよりも実用主義
Linuxカーネルプロジェクトは、保守的かつ実用主義的なエンジニアリング文化で知られていますが、この問題には異なるアプローチをとりました。
包括的な変更を強制するのではなく、コーディングスタイルガイドラインにおいて、「master/slave」や「blacklist/whitelist」といった用語の新規使用を避けることを推奨しています。ただし、以下のような場合には明示的に例外を認めています：
- 用語が外部仕様の一部である場合
- 変更によってユーザー空間インターフェースが壊れる場合
- 変更のコストが利点を上回る場合
推奨される代替語——「primary/secondary」「leader/follower」「allowlist/blocklist」など——は、普遍的な置き換えではなく、文脈に応じた選択肢として提示されています。
このアプローチは、ひとつの重要な原則を反映しています：技術的安定性が優先される。ただしその制約の中でも、用語は進化しうる、ということです。不必要な変更に懐疑的なプロジェクトであっても、実務的な考慮と合致する場合にはインクルーシブな言語を取り入れることができる——それを示しています。
シンボル名やドキュメントにおいて、’master / slave’（または’master’から独立した’slave’）および’blacklist / whitelist’の新規使用を導入することを避けてください。
‘master / slave’の推奨される置き換え：
'{primary,main} / {secondary,replica,subordinate}' '{initiator,requester} / {target,responder}' '{controller,host} / {device,worker,proxy}' 'leader / follower' 'director / performer'
‘blacklist/whitelist’の推奨される置き換え：
'denylist / allowlist' 'blocklist / passlist'Linux kernel coding style. https://docs.kernel.org/process/coding-style.html から翻訳。
IETF——標準の一部としての言語
多くの基盤的なインターネット標準を策定するInternet Engineering Task Force（IETF）は、正式な仕様のレベルで用語に取り組みました。
2021年、IETFは特定の用語が排他的あるいは有害と見なされる可能性があり、それが標準策定への参加に影響しうることを認める声明を発出しました。その後のドラフトや議論では、より記述的でインクルーシブな代替語を検討するよう著者に促しています。
IETFのケースが注目に値するのは、そのフレーミングです。議論は主に道義的なものではなく、手続き的かつ機能的なものとして構成されています：
- 標準は定義上グローバルなものである
- 明確さと共有された理解が不可欠である
- 多様な貢献者からの参加が成果の質を向上させる
この観点からすると、用語は仕様の単なる表現上の問題ではなく、技術的品質の一部として扱われています。
IETFへの貢献——Internet-DraftやRFCを含む——は、多様な背景や文化の読者にとって明確で、正確で、広くアクセス可能な用語を使用する場合に、もっとも理解しやすく効果的になります。
IESG Statement on Inclusive Language, 2021年5月11日. https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-inclusive-language-20210511/ から翻訳。
GoogleとMicrosoft——スタイルの制度化
主要テクノロジー企業は、公式のドキュメントスタイルガイドにインクルーシブな言語を組み込んでいます。
- Googleの開発者向けドキュメントガイドラインは、グローバルな読者を対象に書くこと、慣用的表現の回避、明確でインクルーシブな用語の使用を強調しています。
- Microsoftのスタイルガイドは、バイアスのないコミュニケーションを推奨しており、ジェンダーニュートラルな言語や「master/slave」などの用語に対する代替語を含んでいます。
これらのガイドは社内利用に限定されません。影響を及ぼしているのは：
- 公開ドキュメント
- 開発者教育の教材
- これらの標準を参照またはフォローするサードパーティの執筆
時間とともに、こうしたガイダンスは期待の共有された基準の形成に寄与します。特に、キャリアの早い段階でこれらの慣例に触れる開発者にとっては、なおさらです。
Inclusive Naming Initiative——プロジェクト横断の調整
個別のプロジェクトや企業とは異なり、Inclusive Naming Initiativeは業界横断で用語変更を調整する試みです。
提供されるのは：
- 再検討すべき用語のキュレーションされたリスト
- 推奨される代替語
- 変更が適切である場合と不要である場合のコンテキスト
その役割は標準を強制することではなく、断片化を減らすことです。異なるプロジェクトが同じ議論を独立にゼロから繰り返さなくて済むよう、共通の参照点を提供するものです。
共通パターン：中央権威なき変化
これらのケースを横断して、一貫したパターンが浮かび上がります：
- 単一の組織が変更を命じたわけではない
- 判断は各プロジェクトの優先事項に基づいてローカルに行われた
- 採用は可視性、デフォルト、共有された実践を通じて広がった
同時に、根拠は収束しています：
- 明確さの向上
- グローバルな協働の支援
- 参加の維持または拡大
その結果は、分散型の標準化とでも呼ぶべきものです。用語はトップダウンの統制によってではなく、影響力のあるデフォルト、制度的ガイダンス、コミュニティの採用の組み合わせを通じて進化しています。
このことは、変化の到達範囲と、意見の不一致が続いている理由の両方を説明する助けになります。中央権威がない以上、合意は部分的なままです。しかし、いったん主要なアクターが確立した変化の方向は、無視しがたいものとなります。
↑ NotebookLM で生成しました。
批判と抵抗——フレーミングのギャップ
よりインクルーシブな用語への移行は、普遍的に歓迎されたわけではありません。グローバルな開発者コミュニティ全体を通じて、反対意見はいくつかのよく知られた方向に沿って展開される傾向があります。変更が不要な混乱を招くという主張、互換性や蓄積された知識を損なうという主張、あるいは実務的な利益の乏しい象徴的なジェスチャーにすぎないという主張です。ガイドラインや制度的圧力を通じてではなく、用語は自然に進化すべきだと主張するエンジニアもいます。
これらの懸念は些末なものではありません。大規模なシステムでは、小さな命名変更であっても実際のコストが発生しえます。ドキュメント、ツール、長年確立されたワークフローに影響するのです。Linuxカーネルのようなプロジェクトはこの点を明示的に認めており、代替用語を推奨しつつも、互換性や外部標準によって変更が非実用的である場合には例外を認めています。インクルーシブな言語の支持者でさえ、これらの変更は文脈に即して実用的に行われるべきであり、盲目的に強制されるべきではないとしばしば強調しています。
同時に、批判のトーンと焦点は文脈によって異なります。多くの国際的なオープンソースおよび標準化コミュニティでは、議論はトレードオフを軸に展開される傾向があります。明確さ対継続性、インクルーシブネス対安定性、象徴性対実用性。意見の相違が鋭い場合でも、議論は言語が現実の協働にどう影響するかという点に根ざしていることが多いのです。
しかし日本では、異なるパターンが見られることがあります。「master/slave」や「whitelist/blacklist」の置き換えといった変更は、実務上の根拠から疑問視されるだけでなく、「言葉狩り」やポリティカル・コレクトネスとして頻繁にフレーミングされます。このフレーミングにおいて、問題は主に制限として理解されます。特定の表現が抑制されており、それが表現の自由への侵食を意味するのだ、と。
そのフレーミングは、事態の一面を捉えてはいます。しかし、見落としている部分もあります。
多くのグローバルなエンジニアリングコミュニティでは、代替用語の推進は、個人が何を言えるかを制限することが主目的ではありません。異なる言語的・文化的・社会的背景を持つ参加者がいる環境で、共有言語を最適化することが主眼です。問いは「どの言葉が許されるか」ではなく、「どの言葉が大規模な協働をより明確に、よりアクセスしやすくするか」なのです。
この観点からすると、インクルーシブな用語は表現の縮小ではなく、誰が快適に参加できるかを広げる試みとして理解できます。たとえそれが不完全な試みであるとしても。
こう見ると、一部の「表現の自由」の議論にはアンバランスさが浮かび上がってきます。表現の自由への訴えは、馴染みのある用語や挑発的な用語の継続使用を擁護する際にもっとも目立つ形で現れます。しかし同じ原理が、既存の言語自体が参加を妨げたり、曖昧さを生み出したり、不必要な認知的障壁を課したりしていないか——とりわけ狭い言語的・文化的規範の外にいる人々に対して——という問いに適用されることは、はるかに少ないのです。
これは、行き過ぎ、パフォーマティブな（形だけの）変更、不必要な混乱についての懸念を無効化するものではありません。それらの懸念は実在しており、インクルーシブな言語を支持するコミュニティの中でも広く認められています。しかし、この議論が単に自由対制限という構図ではないことを示唆しています。自由のどの側面が優先されているのかという問題でもあるのです。
言語が、誰が読み、書き、貢献できると感じるかに影響を与えるのだとすれば、用語についての選択は中立ではありえません。それは、システムがどのように記述されるかだけでなく、誰がそのシステムをアクセス可能だと感じるかにも影響を及ぼします。
こうした二つの視点——保持すべきものとしての言語と、参加のために継続的に最適化すべきものとしての言語——のギャップが、同じ変更がある人には不要な干渉に、別の人には遅すぎた改善に見える理由を説明する助けになります。ソフトウェア開発がますますグローバルになるにつれて、このギャップは中心的な緊張であり続ける可能性が高いでしょう。
並行するトレンド：ジェンダーニュートラルな言語
技術用語の変化と並行して、もうひとつの変化が進行しています。コードにおける可視性は低いものの、ドキュメント、コミュニケーション、ユーザー向けテキストにおいてますます存在感を増しているものです。ジェンダーニュートラルな言語への移行です。
「allowlist」や「main branch」といった用語変更と一括りにされることも多いですが、このトレンドの起源と根拠はやや異なります。
想定されたデフォルトから、未知の読者へ
英語の伝統的なテクニカルライティングでは、しばしばデフォルトのユーザー像が想定されていました：
- “the user… he can configure…”
- “when a programmer writes his code…”
こうした表現はかつて中立的と見なされていましたが、グローバルかつ多様な文脈においては、狭い、あるいは時代遅れなものとして映るようになっています。現代のガイダンスが代わりに推奨するのは：
- 単数の「they」 の使用
- ジェンダーのある代名詞をそもそも使わないよう文を書き換えること
- 想定されたアイデンティティではなく役割に言及すること
たとえば：
- “the user configures their settings”
- あるいは単に “configure the settings”
この変化は、前提の根本的な転換を反映しています。読者はもはや特定のタイプの人物として想像されるのではなく、デフォルトで未知かつ多様な存在として扱われるのです。
代名詞の先へ：トーンと呼びかけ
ジェンダーニュートラルな言語は、開発者がより広い意味で読者に語りかける方法にも影響を与えています。
- 構成が不明または混成のグループに対して「guys」といった表現を避ける
- 代わりに「everyone」「team」「folks」を使う
- 特定の背景やアイデンティティを前提としない指示文を書く
こうした変更は些細に見えるかもしれませんが、ドキュメントやコミュニケーションを暗黙的に排他的ではなく、広くアクセス可能なものにするためのより広い取り組みの一部です。
なぜ別の話題として扱われることが多いのか
「master/slave」のような特定の歴史的比喩に結びついた置き換えとは異なり、ジェンダーニュートラルな言語はどちらかといえば用語そのものよりもオーディエンス・デザインに関わるものです。
主な動機には以下が含まれます：
- 非ネイティブスピーカーを含むグローバルな読者に向けて書くこと
- ユーザーに関する不必要な前提を避けること
- 専門的コミュニケーションにおいて進化する規範と整合すること
このため、ジェンダーニュートラルな言語は：
- ドキュメントや教育においてより一貫して採用される傾向がある
- 特定の技術的制約との結びつきが薄い
- そして多くの文脈で、用語の置き換えよりも議論を呼びにくい
それでも議論がないわけではない
とはいえ、この変化がまったく抵抗なく進んでいるわけではありません。
以下のような主張もあります：
- 単数の「they」は文法的に馴染みにくいと感じられることがある
- 文の書き換えが簡潔さを損なう場合がある
- 過度に慎重な言語は不自然あるいは没個性的に感じられることがある
用語変更と同様に、採用は不均一です。これらのガイドラインを一貫して適用しているプロジェクトやコミュニティもあれば、特に問題なく旧来の慣例を使い続けているところもあります。
共通する方向性
こうした違いにもかかわらず、用語変更とジェンダーニュートラルな言語という二つのトレンドは、同じ方向を指し示しています。
いずれも以下からの脱却を反映しています：
- ユーザーに関する暗黙の前提
- 文化固有の、あるいは歴史的に荷重のある表現
そして以下に向かう動きです：
- 明示的で、記述的で、広くアクセス可能な言語
動機は異なり、議論が完全に重なるわけでもありませんが、両者を合わせて見ると、技術的コミュニケーションがそれに依拠するグローバルなコミュニティとともにいかに進化しているかが見えてきます。
変わっていない日常
最近の用語変更の注目度を考えると、テック業界が急速かつ包括的な言語のシフトを経験したと思ってしまうかもしれません。実際には、状況はもっとまだらです。
レガシー用語は依然として広く使われている
多くの広く利用されるシステム、プロトコル、コードベースは、古い用語を使い続けています：
- 長く確立されたAPIや標準は、元の命名を維持していることが多い
- 内部識別子、データベーススキーマ、設定キーが遡及的に変更されることはまれである
- ドキュメントでは、特に大規模あるいは長寿命のプロジェクトにおいて、新旧の用語が混在することがある
多くの場合、用語の変更は単にテキストを編集するだけの問題ではありません。以下に影響する可能性があります：
- 後方互換性
- 他のシステムとの相互運用性
- 長期にわたって築かれた開発者の期待
その結果、一貫性よりも安定性が優先されることが多いのです。
唯一の「正しい」置き換えは存在しない
変更が推奨される場合でも、合意された単一の代替語が存在することはまれです。
たとえば：
- 「master/slave」は文脈に応じて「primary/secondary」「leader/follower」「controller/device」のいずれにもなりうる
- 「whitelist/blacklist」は「allowlist/blocklist」にも「denylist/allowlist」にもなりうる
それぞれの代替語は、わずかに異なる含意を持っています。「正しい」選択は以下によって異なります：
- システムのアーキテクチャ
- 記述しようとしている関係性
- プロジェクト内の既存の用語
この不統一それ自体が摩擦の原因になりうります。特に、プロジェクト間を移動する開発者にとっては顕著です。
採用は不均一
すべてのコミュニティや組織が同じペースで——あるいはそもそも——これらの変更を採用しているわけではありません。
- 用語やドキュメントを積極的に更新しているプロジェクトもある
- 議論は認識しつつも最小限の変更にとどめているプロジェクトもある
- 既存の言語を全面的に維持することを選択しているプロジェクトもある
単一のエコシステムの中でさえ、差異は目に見えることがあります。ある開発者が、あるツールでは最新の用語に出会い、別のツールではレガシー用語に出会う——同じワークフローの中でさえ、そうしたことが起こりえます。
強制はまれ
「禁止用語」や厳格な取り締まりへの懸念があるにもかかわらず、ほとんどのプロジェクトは厳密なルールを課していません。
代わりに、一般的なアプローチとして見られるのは：
- スタイルガイドでの推奨
- コードレビューでの提案
- 新しいツールやテンプレートにおけるデフォルトの選択
言い換えれば、この変化は通常、正式な禁止ではなく、慣例と選好によって導かれています。開発者が古い用語を使うことを阻止されるケースはまれですが、代替語を検討するよう促されることはあるかもしれません。
方向は明確だが、道筋は明確ではない
これらの点を総合すると、業界が過去との明確な断絶を経験しているわけではないことがわかります。
- レガシー用語は存続している
- 置き換えは文脈に依存する
- 採用はコミュニティによって異なる
同時に、全体としての方向は見て取れます。新しいプロジェクト、ドキュメント、教材は更新された言語をますます反映する一方、古いシステムは歴史的な慣例を引き続き保持しています。
完全な変容というよりも、浮かび上がっているのは「重層的な景観」（多層的な状況）です。異なる世代の用語が共存している景観です。この共存を理解することが、テクノロジーにおける言語をめぐる進歩と進行中の議論の両方を理解するために不可欠です。
今後の展望
この10年が示してきたことがあるとすれば、テック業界の用語は変わりうるということです。ただし、一直線には進みませんし、完全に足並みが揃うこともほとんどありません。現在の流れからは、いくつかの方向性が見えてきます。いずれも確定的なものでも、万人に受け入れられたものでもありませんが。
記述的な言語への移行は続く
もっとも起こりそうなのは、比喩に頼るよりも機能を記述する用語が徐々に好まれるようになる流れの継続です。
システムが複雑化し、ドキュメントが開発プロセスの中でより中心的な位置を占めるようになるにつれて、次のような圧力は引き続きかかり続けます：
- 曖昧さを減らす
- 言語をまたいでも理解しやすい用語にする
- 命名をシステムの実際のふるまいにより近づける
古い比喩がすべて消えるわけではないでしょう。しかし新しいプロジェクトでは、後から用語を見直すのではなく、最初から記述的な命名をデフォルトにするケースが増えていくかもしれません。
実践を通じた静かな標準化
正式な標準化よりも、変化はデフォルトと反復を通じて広がり続ける可能性があります：
- ツールが特定の用語をデフォルトとして採用する
- 教材がその用語を最初に教える
- スタイルガイドが同様のパターンを補強する
時間が経てば、これが事実上の標準をつくりだすことになります。誰かに命じられたからではなく、新しい開発者にとってもっとも馴染みのある選択肢になるからです。
ただし同時に、ばらつきは残り続けるでしょう。ネットワーク、データベース、ハードウェアといった分野ごとに、それぞれの要件に応じた異なる慣例に落ち着く可能性があります。
安定性と進化のあいだの緊張
繰り返し現れる制約は、変化と互換性のバランスをとる必要性です。
今後も問われ続けるであろう問いがあります：
- 用語の変更は移行コストに見合うのか
- レガシーシステムはどう扱うべきか
- どこで例外を認めるべきか
長寿命のシステムが蓄積されていく限り、この緊張は解消しないでしょう。多くの場合、結果は統一ではなく妥協になるはずです。
コア用語を超えた広がり
これまでもっとも目に見えてきた変化は、特定の用語やドキュメント上の慣行に焦点を当てたものでした。今後は、システムの記述や設計のあり方そのものに、より広く関心が向かう可能性があります。
たとえば一部の研究・デザイン分野では、厳密に人間中心の視点を超えることへの関心が高まっています。環境、生態系、あるいは人間以外のアクターと相互作用するシステムを論じる際に、「人間以上の（more-than-human）」や「マルチスピーシーズ（multi-species）」デザインといった概念を用いる動きです。
こうした言語がメインストリームのソフトウェアエンジニアリングにどの程度入り込むかは、まだ不透明です。今のところ、実践の中心よりも周縁に位置しています。しかし、言語をめぐる議論のスコープが時間とともに広がりうることを示してはいます。
生命を使う技術から、生命とともに設計する技術へ – 「マルチスピーシーズ」という視点
https://innovatopia.jp/multi-species/multi-species-news/87226/
続く議論、最終的な解決ではなく
このトピックについてもっとも予測しやすいのは、おそらく、議論が続くということでしょう。
- 継続性と馴染みを優先し続ける開発者もいる
- 明確さ、アクセシビリティ、インクルーシブネスを重視する開発者もいる
- コミュニティによって、異なるバランスに落ち着く
その意味で、用語が安定した終着点に達する見込みは低いでしょう。用語は、それを使うコミュニティとともに変わり続けるはずです。
動き続けるインターフェースとしての言語
この不確実性を理解するひとつの方法は、言語そのものを一種のインターフェースとして捉えることです。人とシステムを、そして人と人をつなぐもの。
あらゆるインターフェースと同様に、言語を形づくるのは：
- 誰がそれを使うか
- どれだけ広く共有されているか
- どのような制約を満たさなければならないか
これらの条件が変われば、インターフェースもまた変わります。
したがって、この先にあるのは固定された到達点ではなく、進行中のプロセスです。技術的な要請、社会的な期待、そして実務上の制約が引き続き作用し合い、ときに互いを補強し、ときに異なる方向へ引っ張り合う——そうしたプロセスです。
【関連リンク】
- Inclusive Naming Initiative:
https://inclusivenaming.org/about/ - Towards Inclusive Language in Code – Cisco Engineering Blog:
https://blogs.cisco.com/developer/inclusivelanguage01 - NISTIR 8366 — Inclusive Language in Standards (2025年に取り下げられた):
https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf - [Terminology] Re: Withdrawal of NISTIR 8366:
https://mailarchive.ietf.org/arch/msg/terminology/rNrDt65P7TZ1rY9DtXeTeYKME1w/ - IEEE 3400-2025: IEEE Standard for Use of Inclusive Language in Technical Terminology and Communications:
https://standards.ieee.org/ieee/3400/11579/
【編集部後記】
この議論がひとつ明らかにしていることがあるとすれば、テクノロジーにおける用語はもはや純粋に内輪の問題ではない、ということです。かつて比較的閉じたコミュニティの中を流通していた言葉が、今ではデフォルトで国を、言語を、文化を越えて移動します。そうした条件のもとでは、言語は単なる習慣ではなくなります。協働が実際に機能する仕組みの一部になるのです。
この観点に立てば、近年の用語の変化は、ときに見えるほど些細なものでもなければ、ときに描かれるほど強圧的なものでもありません。少なくとも部分的には、共有言語をソフトウェア、システムやプロトコルが今日において構築されるスケールに合わせて調整しようとする試みです。不完全で、不均一で、ときにぎこちない試みではあるものの。
より無視しがたいのは、この変化がいかに不均一に解釈されているかという点です。
一部の議論——とりわけ日本では——反応はしばしば喪失の枠組みで語られます。言葉が奪われる、表現が抑制される、馴染みのある慣例が問い直される。その懸念は傾聴に値します。特に、変更が十分な説明なく導入される場合や、実際のコストを伴う場合にはなおさらです。
しかし同時に、「表現の自由」の持ち出し方にある種の選択性・恣意性があることも、見過ごしにくいところです。言論の自由への訴えは、特定の用語——とりわけ挑発的なものや変化に抗うものと見なされる用語——の継続使用を擁護する際にもっとも強く現れる傾向があります。一方で、同じ論理が別の方向（例えば、マイノリティの自由や政治的な自由）に向けられることは、はるかに少ないのです。すなわち、既存の言語そのものが参加を制約していないか、不必要な障壁を生んでいないか、一部の貢献者が関わりにくいと感じる原因になっていないか、という問いです。
言語が協働のインフラの一部であるならば、表現の自由は馴染みのある言葉を保持する自由にだけ還元されるわけにはいきません。より多くの人が会話に参加できる条件にも、何かしら関わっているはずです。
これは、提案されるすべての変更が正当であるとか、新しい用語がすべてより明確で優れているとかいうことを意味するものではありません。表層的にとどまる変更もあるでしょう。定着しない変更もあるでしょう。新たな混乱を生む変更もあるでしょう。言いたいのは、変化の方向が常に正しいということではなく、それを評価する基準が、現状よりも広くあるべきかもしれない、ということです。
グローバルに分散したコミュニティによってソフトウェアやシステム、プロトコルが作り続けられる限り、問いは残り続けるでしょう。どの言葉が許容されるかという問いだけではありません。どのような言語が、大規模な協働を持続可能にするのか、という問いです。
その問いに唯一の答えはありません。しかし、これは制限の話にすぎないとか、進歩の話にすぎないとか、そうした前提から始めるよりは、生産的な出発点になるかもしれません。
