インクルーシブなコードを目指して

Indeed のインクルージョン施策は、従業員間の支援グループや推進イベントに留まりません。背景、経験、思想のダイバーシティが従業員の能力向上や成長を引き出し、より効果的な意思決定を可能にし、パワフルなイノベーションを生み出します。Indeed ではインクルージョンを推進するため事業のあらゆる階層と部門で心理的に安全な環境づくりを目指しており、その一環としてインクルーシブではない用語を社内のコードベースから無くしていくことにしました。

事業の成功にダイバーシティとインクルージョンは欠かせません。従業員のインクルージョン支援グループ「Women at Indeed」アムステルダム支部のリーダーたち。 (左から): Edwin Moses、Trudy Danso-Osei、Freek van Schaik、Renske van der Linden、Valerie Sampimon 

技術用語のインクルージョンへの対応

どのような言葉にも、コノテーション (元の意味以外に暗示される意味) により表現の幅が広がりますが、技術用語も例外ではありません。本来の意味以外のには、広く知られ、意味が理解されているものもありますが、文脈によって異なったり、個人の実体験の違いによって理解に差がある場合もあります。また長年にわたって用語に蓄積されたコノテーションとその語源との関係がほとんどなくなってしまう場合も少なくありません。

コンピューターサイエンスやソフトウェアエンジニアリングでは、便利で使い勝手がよく、意味をよくとらえた用語が数多く使われていますが、一部の人々に対して、その言葉の言外に含まれるネガティブで排他的な意味合いを無視して使用するように強いている場合もあります。

「master (マスター、主人)」と「slave (スレーブ、奴隷)」がその代表例でしょう。そこから「slave は master の制御に従って動作する従属的プロセスである」というコノテーションとして悪気なく解釈して使っているエンジニアもいますが、多くの人、特に有色人種にとっては、それは恐ろしい奴隷制度のイメージと直結した用語です。このコノテーションは、米国の奴隷制度のように一国の歴史にだけ存在するわけではありません。現代でも世界中で2,100～4,500万人の人々が現代の奴隷制の被害にあっていると推計されており、master と slave は過去の歴史というだけでなく、現代の世界的な人道危機をも表す用語です。

この他にもネガティブなコノテーションを持つ用語はたくさんあります。「blacklist (ブラックリスト)」のように色と価値判断を関連付けた用語、「tribal knowledge (部族の知識)」のように文化を搾取し蔑むような性質のある言葉がその一例でしょう。障がい者に対する差別用語にあたる「lame (レイム、足が不自由)」や「blind (ブラインド、盲目)」が誤った文脈で使用されると、障がいを持つ人にネガティブな影響をもたらしかねません。社会にはそういった特徴に基づいた偏見や先入観との絶え間ない戦いがあります。

実際に疎外された経験のある立場でなければ、挙げられた例のいくつかに驚くかもしれません。それでももし、同僚から、自分を排除したり傷つけたりする言葉が周りで飛び交っている状況だと言われたなら、当事者の立場に立って新しい用語を探すべきです。

話し合いをはじめる

Indeed では、インクルージョンと帰属意識をコアバリューの一部として2019年に正式に導入していますが、それ以前から、社内のエンジニアは問題のある用語を私たちのテクノロジーから取り除く活動を始めていました。

まずは排他的な用語を特定し、批判的な観点から見るため、社内の Wiki やブログ、専用のコンテンツハブでの議論を始めました。エンジニアなら誰でも Inclusive Terminology の Wiki ページに参加して意見を出せるようにし、集められた意見をもとに、従業員が用語についての責任ある決定ができるように、簡易版のクイックリファレンスガイドを作成しました。

エンジニアチームはコードに新しい言葉の導入方法を決めました。次にベストプラクティスやプロセスを共有しました。社内では、今でも話し合いを続けています。

ケーススタディ: Git プロジェクトで「master」を「primary」にリネームする

Git プロジェクトの master ブランチのリネームは片手間にできる作業ではありません。履歴が長いプロジェクトならなおさらです。先日、Indeed の Design Systems というチームが、この作業をチームのプロジェクトとして完了しました。作業工程は以下の通りです。

1. master ブランチのクローンを作成し、そのクローンに「primary」という名前を付ける。
2. GitLab のデフォルトブランチを「master」から「primary」にアップデートする。
3. master ブランチをロックダウンする。記録の目的で残しますが、今後使用することはできません。
4. 作成した primary ブランチに master ブランチの設定を適用する。

このシナリオでは、いくつか問題が発生する可能性があります。たとえば上記作業で primary ブランチを作成する前に、別のユーザーが master ブランチから新規のブランチを分岐させてしまうことが考えられます。また primary と master は同じ履歴を共有するため、ユーザーはその機能を primary にマージすることが理論的に可能です。そういった問題のリスクを緩和するため、リネーム作業中はコードフリーズを実施しました。さらにメインのプロジェクトのリネームを行う前に、比較的小規模のプロジェクトで作業工程をテストしています。

具体的な成果

この作業をトラッキングするにあたり、Indeed ではソフトウェア開発のトラッキングツールとして Atlassian の Jira を活用しました。フィルターとソートができるよう、インクルージョンの対象用語を含む Jira のチケットにラベルを追加することで、排他的な用語が存在する領域や、その用語を取り除く現在進行中の作業と進捗を俯瞰することを可能にしました。これまで113件中97件をクローズし、現在も作業を続けています。

「inclusive-terminology」のラベルがついた Jira のステータス別件数

実現に至るまでの課題

この作業の過程において、エンジニア間で活発な議論が行われました。Indeed としては、この用語変更を、批判的であったり屈辱を与えるようなプロセスにだけはしないことを念頭に置き、トップダウンで強制するのではなく、草の根で進めて行くことにしました。これにより全員が敬意を持って用語変更の議論ができるようになり、その過程で互いに学び合うことにもつながりました。リーダーシップ側は必要に応じて支援したり方向性を示し、積極的に対話に関わっています。

議論の中で挙がった議題の中に、作業のコストと水準がありました。プロダクトの用語変更は徹底的に実施すると長期のプロジェクトになり、エンジニアの作業時間もかかります。実際に現時点でコードベースから「slave」という用語についてあと5,000件以上のインスタンスを削除しなければなりませんが、Indeed は、この作業をやり遂げていきます。この取り組みによって、排他的用語の削除にかかった時間と労力を上回る、心理的安全性がもたらされるでしょう。

未来に向けて

言語は使う人間の必要性に合わせて絶えず進化しており、使っていくうちに時代遅れにもなるでしょう。そういった意味で、コードベースの用語変更は1回限りの作業ではなく、継続していく活動であると Indeed は考えています。

私たちは今後も置換すべき用語を記録し、適切な代替用語を提案していきます。社内では新規のコードでそのような不適切な用語を使わないようにし、ベンダー各社にも自社プロダクトでの使用を避けるように協力をお願いしています。また、コードベースの変更に際しては、手順を守り、細心の注意を払って既存の用語の特定と置換を実施しています。

やらなければならないことはまだあります。Indeed では、常に排他的な用語とそうした言葉が示唆する事柄に対して意識を高めており、従業員間でこの話題について敬意を持って対話に取り組んでいます。皆で協力し、あらゆる人にとっての心理的安全性が確保され、インクルーシブで歓迎されている気持ちになれる職場づくりを目指しています。そして一連の活動を周知していくことで、Indeed がインクルージョンのモデル企業となり、テクノロジー業界全体の改善にもつながることを願っています。