プロダクトに名前をつける時に気をつけたいこと


私は今まで、数々のアプリケーションやライブラリをつくって GitHub / RubyGems 等で公開してきました。ここで毎回注意しているのが__プロダクトの名前の付け方__です。この記事では、自分が何に気をつけて名付けをしているのかを紹介します。

# ユニークな名前にする
ユニークな名前にする、つまり__既に公開されているものとなるべく名前が被らないようにすべき__です。ユニークな名前にすることでググラビリティ（検索した時のヒットしやすさ）を高めることができますし、エゴサーチもしやすくなります。

## 同じ名前のプロダクトがすでに存在しないかチェックする
自分はよさ気な名前が思いついたら、まず Google 検索と GitHub の一番上にある検索ボックスに突っ込みます。同じ名前のリポジトリがすでにあるかどうかを調べるためです。ハイフンとかを含めるなら名前をダブルクォートで囲むのが良いでしょう。

![dtan4__Daisuke_Fujita_.png](https://qiita-image-store.s3.amazonaws.com/0/17508/2a10c204-b501-b0aa-9952-19c81f56b774.png)

![Search_·__terraforming_.png](https://qiita-image-store.s3.amazonaws.com/0/17508/69409fea-c27e-e4f5-20a0-ab6a671a06ad.png)

幸運にもリポジトリが一件もヒットしない場合は、その名前を採用します。もしヒットした場合でも、数が少ない & 全然開発されていなかったり (Initial commit だけみたいな)、Star が全然ついてない場合は採用することがあります。自分のほうが有名になってやるぞ！という勢いです。

プロダクトを RubyGems や npm などのパッケージ管理システムに上げる場合は、そこでも名前を検索する必要があります。ここで被っているとさすがに登録できないので…

* * *

DeNA が作っている [JSX](https://jsx.github.io/) と React.js の JSX や、プログラミング言語 Go と Thoughtworks が出してる [GoCD](https://www.thoughtworks.com/go/) とか、正直どうしてぶつかった感があります…

## 辞書に載っているような単語はなるべく避ける
英語の普通名詞や固有名詞はなるべく避けた方がいいです。よほどそのプロダクトが（それこそ Ruby とか Go みたいに）ヒットしない限り、その名前単体で Google 検索して引っかかることは相当厳しいでしょう。

とはいえ、適当にタイプした母音のないような単語は好ましくありません。発音しにくい & 覚えにくいというのはマイナスです。単語をそのまま使わず、少しもじったり組み合わせたりするとよいでしょう。フレーズを作って、単語の頭文字をつなげ合わせるのもよいです。Linux (Linux Is Not UniX) のような[再帰的頭字語](https://ja.wikipedia.org/wiki/%E5%86%8D%E5%B8%B0%E7%9A%84%E9%A0%AD%E5%AD%97%E8%AA%9E)を作れるとカッコいいです。

あるいは、英語以外の単語・フレーズで考えるとユニーク性は増します。[Google 翻訳](https://translate.google.co.jp/?hl=ja)の左欄に日本語なり英語の単語を入れて、右欄の言語を変えまくってよさそうな表記を探したりします。

![Google_翻訳.png](https://qiita-image-store.s3.amazonaws.com/0/17508/ff153e11-4747-73d6-07ba-2059ac694df3.png)

ラテン語とかエスペラントとかはそうそう被らないでしょう（README に説明を書くべきだとは思いますが）。日本語のローマ字表記や中国語のピンインも意外と穴場だったりします。

# キーボードでタイプしやすい名前にする
:warning: 世の中 Dvorak 配列とか AZERTY 配列とかありますが、自分は大多数を占める QWERTY 配列における打ちやすさを考えています。 :warning: 

特にコマンドラインアプリケーションを作る場合は、そのアプリケーションの名前をしょっちゅうターミナルに入力することになります。こうなると、名前のタイプのしやすさが重要になってきます。よさげな名前を思いついたら実際にタイプしてみて、自分が打ちにくいと思ったら別の名前を考えましょう。

タイプのしやすさとは？と言われるとぶっちゃけ感覚としか言えないのですが…例えば `qaza` みたいな一方の手/指に偏るような名前は打ちにくいです。

あと、最近はシェルの補完が利くとはいえ、やはり__短い名前__のほうが良いです。覚えやすいし、タイプもしやすいので。

# そのプロダクトが何をするのか、というのを間接的でも含める
プロダクトの__性質__や__何をするものなのか__というのを元に名前を考えるようにしています。GitHub 上の description やリポジトリの README を見に行かなくとも、名前を見ただけでこのプロダクトが何をするのか、というのをわかってもらえるのが理想です。

そういう単語を見つけるときは、和英辞典の他に類語辞典をよく使います。

- [英和辞典・和英辞典 - Weblio辞書](http://ejje.weblio.jp/)
- [英語類語 - Weblio辞書](http://ejje.weblio.jp/english-thesaurus/)

そのプロダクトがある特定のプロダクト (HashiCorp 系とか) や外部サービス (AWS とか) のヘルパとなる場合は、それらの名前をもじってつけることが多いです。また、API クライアントみたいに同じ役割を担うプロダクトが言語ごとに存在しうる場合は、言語名のプレフィクス・サフィックスを付けるのもよく見ます。Java だと末尾に `4j` とつくようなアレです。

# さいごに
以上の内容を踏まえながら、自分がこれまでに作ってきたプロダクトの一部を紹介します。

- [ec2c](https://github.com/dtan4/ec2c)
    - シンプルな EC2 コマンドラインツール
- [Ramesh](https://github.com/dtan4/ramesh)
    - [東京アメッシュ](http://tokyo-ame.jwa.or.jp/)の Ruby クライアント
- [sintaku](https://github.com/dtan4/sintaku) （__神託__）
    - EC2 スポットインスタンスの Termination Notice、つまり神 (= AWS) のお告げを外部からチェックする
    - `h` 抜くほうが打ちやすかったので、あえて `si` にした
- [Spotdog](https://github.com/dtan4/spotdog)
    - EC2 スポットインスタンスの価格履歴を Datadog に送信する
- [Spotrack](https://github.com/dtan4/spotrack)
    - EC2 スポットインスタンスの入札/落札状況を監視する
- [Teppan](https://github.com/dtan4/teppan) （__鉄板__）
    - テンプレートに環境変数を埋め込んで出力するコマンドラインツール
- [Terraforming](https://github.com/dtan4/terraforming)
    - 既存リソースから [Terraform](https://www.terraform.io) のコードを生成する

このように、辞書に載ってない & プロダクトの中身を表すような名前を自分で考えてつけるようにしています。唯一英語の一般名詞を使っている Terraforming ですが、現在自分のプロダクトで一番スターが付いてるにも関わらずそこそこ使われる一般名詞なので Twitter エゴサーチが機能しないという欠点があります。

エンジニアとしてはプロダクトの表面よりも中身で勝負や！という気持ちがあるかもしれませんが、プロダクトを広める上では名前はとても重要です。いい感じの名前をつけて、より多くの人に認知してもらえるようにしましょう :octocat: