なでしこJAPANの快挙すごかったですね！

みなさんは設計やプログラミングの際に、DB名やクラス/変数名の"名前"のつけ方をどうされていらっしゃるでしょうか？自分は初期段階からこだわってしまって、肝心の作業の時間を削りがちな事が多いです（苦笑）

しかし「名は体を表す」という言葉にもある通り、名前に明確な意思を込める事で成果物の見通しが良くなったり、他の方との意思疎通を取りやすくなったりとメリットもあるかと思います。今回は今までの自分の経験の中で、どういった考え方で名前付けをしているかをまとめてみました。

■一貫性を持たせる
設計書に"プレゼント機能"とあるのであれば、“Present"の英単語を基本として名前付けしていきます。“Gift"などより適切な単語にしたくなる事もありますが、設計書やチーム内での統一見解と一致させる方が意味のミスマッチが無くなり有利です。
（設計工程の初期段階であれば、ギフトの呼称に変えていく…という戦略もアリかもしれません）

■平易な英単語を使用する
例えば、「お客様に"おわびのアイテム"を付与する」という機能を実装する場合、“おわび→償い"という連想から"reparation"と名付けしたいところですが、よくよく英単語の意味を調べると国家賠償とか賠償金とか仰々しい意味が連なっています。

ここであまり意味の強い英単語を使用してしまうと、その言葉に設計が縛られてしまい、他の機能を追加したりすると本来の意味からかけ離れていきメンテナンス性が損なわれる可能性があります。

個人的には中学レベルやCMや流行曲(!?)で耳にしたことのある同類の単語にしたり、またそれ以外の機能を持たせられる"のりしろ"的な単語にする方がいいかと思います。但し、あまりにも広義な意味に取られかねない単語は機能の一極集中を招いてしまうので、この辺はさじ加減が難しいです…。
（ちなみに自分は"sorry"を選択しました。他プロジェクトでは"reparation"だったので一貫性ルールに反していますが…最近の話ですｗ）

■類語を調べる
平易な英単語が見つからない場合は、その機能を表す別の言葉を検索します。ただ、前述の通りあまりにも本来の意味からかけ離れてしまうと混乱の元となるため、単語の選択には注意が必要です。また、ここに来て名づけができないという事は、そもそも設計の粒度に問題がある可能性も疑い始めた方がいいかと思います。

※Chromeの"検索エンジンの編集"にショートカット登録しておくと便利です

■他オープンソース製品から調べる
類語を調べるのと並行して、同じ機能を実装していそうな他のオープンソース製品を参考にします。最近はソースコード検索が充実してきたので、Google検索と合わせればどちらの単語がより多く使われているか多数決を取ったりする事も可能です。

■各種命名規則に合致するか調べる
この辺になると変数名などの粒度になってきますが、大規模なオープンソースプロジェクトでは"命名規則"がルールとして用意されています。また、CakePHPなどのフレームワークでは名前付けに一定のルールがあったりするので、それらを参考にする事で自分の名付けに問題がないか検証する事ができます。

なんかこの手の話はバッドノウハウというか自分の浅学を晒しているだけの気もしてきましたが、本質的にはボキャブラリーが増えたとしても役に立つケースはあるかと思いますし、“名付け親"としてコードに愛着が湧いて品質がアップする…かもしれません（笑）