LIVESENSE ENGINEER BLOG

リブセンスエンジニアの活動や注目していることを発信しています

名前重要なIT業界の技術名 その複雑さに立ち向かう

はじめに

少し前のことになりますが、転職ドラフトではサービス内で使われる技術名の表記を統一しました。

リリースノートの8/29「技術名の表記ゆれを統合しました」にある通り、サービス内でバラツキがあった、プログラミング言語、各種ミドルウェア、OSS、クラウドサービスなどの、いわゆる技術名(6000個ほどもあった)を、社内のエンジニアで手分けして調査し、適切と思われるものに変換するためのデータをゴリゴリ作りました。

この記事では、近年大きく発展し、それとともに多様になったIT関連の技術における名前、「技術名」の難しさについてお話します。

転職ドラフトでの技術名の使われ方

転職ドラフトは、企業がユーザーを年収額を提示した形で指名するという転職サービスです。

ユーザーには、職務経歴書にあたるレジュメをしっかり書いていただき、更にサービス側の審査を経て、毎月開催しているドラフトに参加できます。 そして、企業の採用担当者の方々は、600名近いユーザーから誰を指名するか絞り込む必要があります。

この絞り込みには、様々な希望条件やユーザーの過去の経歴、フリーワードなどを用いることができますが、全検索の約46%に検索条件として技術名が使われています。

また、その検索の条件を保存しておく機能もあるのですが、その中では半数以上で技術名が使われています。

このように技術名は非常に重要なのですが、入力する際は以下のように自由記述が可能です。 これは、幅広い背景を持つユーザーに対応するためでもあるのですが、タイポが入る余地が生じてしまいます。

Typoしてみました

そういった事情もあり、同じプログラミング言語やフレームワーク、クラウドサービスでありながら、別名で登録されてしまい、絞り込みの際に除外されてしまっていた可能性は多々あったかと思います。 ただし、OR検索も可能になっておりまして、検索する際に同名と思われる技術名を複数選択するなど、個々に対策をしてくださっていた場合もあったようです。

今回変換テーブルのデータを整備したことで、入力時にサジェストされる技術名が整うとともに、過去に発生したものと同じ間違いは自動的に修正されるようになりました。これによって、今後誤入力は大幅に減ると思われます。

なぜ技術名の表記がゆれるのか

タイポ以外でも以下のような理由で、同じ技術を示す名前でも別の言葉になってしまっていたようです。

頭字語の多さ

HTML が HyperText Markup Language の略であるように、各単語の頭文字をとって作られた言葉が多いことは、日々みなさん実感していると思います。 頭字語 - Wikipedia

プログラマは言葉遊びが大好きな人が一定存在しており、PHPなどの再帰的頭字語もあります。

例えば、ALBは頭字語のままで良いのか、Application Load Balancerと略さずに書くべきなのか、迷うところではあります。

読み方の難しさ

基本的に英語圏の言葉が多いIT関連用語ですが、国境を超えて技術が普及することも多いので、読み方も様々になってしまっています。

tex(てふ?てっく?)、nginx(先頭がngだから……何?)、GUI(じーゆーあい?ぐい?)、AMI(あみって読めるらしい)など、事例を上げ始めればキリがありません。 普段は文字として発音せずに読んでいますが、会話となると相手と読み方が違って、〇〇のこと?というように聞き返したり、心の中で「ああそう読むんだ、気をつけよう」となることは、みなさんあるあるじゃないかなと思います。 正しく読み方を覚えていてもいなくても、文字と上手く関連付けられないとスペルを間違えてしまうことは多いかと思います。

たくさんあるクラウド

ITのインフラがクラウド化したことで、様々なベンダーがIaaSやPaaSのサービスを作りました。 その際の命名として XXX Cloud や Cloud XXX となることが非常に多く、こちらも頭字語の問題とあわさって、被る可能性を高めます。 このXXXの部分に、Storage、Networkなどのより一般的な単語が入ってくると、いくつかのベンダーが同名と言えるサービスを提供しているので、その際は適切な場所にベンダー名を付与するなどの必要がありました。

統合方針

前述のリリースノートにも書きましたが、この混乱を鎮めるため、以下のような方針で統合することしました。大まかには公式に従うです。

ベンダーの公式の表記に従う

転職ドラフトでもインフラとしてAWSを利用していますが、各サービスで「Amazon XXX」と「AWS XXX」で分かれております。 入力時も混乱することが多く、AWSのほうが多少優勢でしたが、実は命名に方針があるようで、以下の記事は大変参考になりました。

dev.classmethod.jp

こういったように、各サービスの公式のウェブサイトなどを確認し、その中の表記にあわせるようにしました。

オープンソースも公式ウェブサイトの表記を尊重する

大抵のオープンソースのライブラリやフレームワークは、公式のウェブサイトがあることが多く、その表記に従うのが最も良いと考えました。

例えば、Protocol Buffersは、GitHubのリポジトリ名だと「protobuf」であったりするので、そこはリポジトリ名ではなく公式のウェブサイトの表記にあわせるようにしました。

その他細かい大文字・小文字の違いや単語間の空白、複数形などについて、わかる限り公式に合わせる

先程の「Protocol Buffers」は、protobuf以外に以下のようなバリエーションがありましたが、先頭は大文字、単語間に空白を入れる、Bufferは複数形に、といったように統一しました。

protocol buffers
ProtocolBuffer
ProtocolBuffers

誤字・タイポは修正(でも本当に間違ってるの?)

Wondows(o→i)、Pyhon(tが足りない)、Pretter(iが足りない)、Pupeteer(途中のpは2つ)など、細かい誤字と思われるものは直しました。

ただし、言葉遊びとして少しひねった名前(RuboCopなど)もそこそこあるのがWeb系の技術あるあるなので、実は正しいことの確認が意外と大変でした。

最近はRubyならぬRuvyもあるそう(キーも隣だし、打ち間違いかな?と思ってしまいそう)で、本当に正しいかどうか字面だけで判断するの難しいですね。

shopify.engineering

また、調査中、間違ったと思われる単語で検索してみると、結構なページが出てくるので、間違えやすいんだなぁと何度も思いました。

結論

人は間違えるものですが、そこをサービスとしてカバーし、公式の表記を尊重することが大事です。 特にIT業界では、様々な場面で名前重要とよく言われます。

今後もみなさんの転職を成功させるために、こういった地道な仕事にも取り組んでいく次第でありますので、転職ドラフトをどうぞよろしくお願いします。

修正前の様子(Rail と Rails と Ruby onRails は Ruby on Rails になりました)

job-draft.jp