「あのファイル、どこいった!?」生産性向上に効く、エンジニアのためのネーミングスキル講座


「ネーミングによって、仕事の質や生産性が大きく変わってしまう」

こう聞いたら、エンジニアの皆さんはどう感じるでしょうか? 「ネーミング」はマーケティングや販売促進の仕事で、自分には関係ないと思っている方にとっては、目からウロコな情報かもしれません。

ネーミングセンスのないエンジニアは生き残れない

もちろん、エンジニアが消費者向けの商品のネーミングをしたり、ロゴを作ったりすることはありません。エンジニアがネーミングを行う機会は、例えば仕事で使うファイルやプログラムの関数名、部品名などを付けるときです。これらの名前は、響きが良かったり、魅力的であったりする必要はありません。できるだけ短い語数で、正しく伝わることだけが重要です。

もし、ソフトウェアのプログラミングで、関数名のネーミングに問題あるときのことを考えてみましょう。関数の用途が正しく他人(1週間後の自分も他人と考えましょう)に伝えられず、それを探すのに時間がかかったり、最悪の場合は使い方を間違えてしまいバグの原因にもなったりもします。

ですので、大規模なシステム開発の案件では、コーディング規約(プログラムの書き方のルール)の中に関数の名前の付け方のルールを設けることが多いです。このように、プログラムの関数名では重要視されているネーミングの技術ですが、これをほかのものにも展開すると仕事の生産性が上がることうけあいです。

ここからエンジニアがネーミングする上で、重要なポイントを考察してみたいと思います。

ネーミングに重要な要素

1.一貫性

ネーミングは一貫性が重要

同じ要素は同じ単語で表現することが重要です。意味もなく、異音同義の言葉にすることは厳禁です。また、名付けのルールを決めたら例外を作ってはいけません。

例えば、「XXX」というファイルがあったとして、その前のバージョンのファイルを「XXX_old」と名付けたとします。この後、「YYY」というファイルの前のバージョンを「YYY_before」としてしまうと、ほかの人が「before」と「old」で意図的に区別しているのではないかと悩んだり、ファイルを探す際に見落としたりするかもしれません。チームで共有する場合は、メンバーにもルールを周知させましょう。

2.文字面で識別が容易なこと

例えば、定量的と定性的、英語だと「quantitative」と「qualitative」。両極端の言葉なのに、パッと見て見分けがつくでしょうか?

これを調査報告書のファイルに使ったとすると、「quantitative_research」と「 qualitative_research」になります。これでは混乱してしまいますね。ほかの名前を検討しましょう。

3.短いこと。「Simple is best」

同じ内容を伝えるのであれば、短ければ短い方が良いです。Simple is bestは大原則です。混乱が起きない範囲で略語なども有効です。

例: Feedback→FB、April→APR、archive→ARCHなど

なお「混乱が起きない範囲で」という条件には気を付けてください。いくら短くなっても、混乱を招く略語では本末転倒です。略語はチームのメンバーとしっかり共有しておきましょう。

4.相対的な言葉は使わない

例えば、「普通の処理」と名付けた処理があったとします。確かにそのときは「普通」かもしれませんが、状況が変わるとほかの処理が「普通」になるかもしれません。

「特定」「特殊」「指定」「一般」「通常」「現状」「原因」「結果」「目的」「基準」といった相対的な言葉は、なるべく使うのを避けましょう。

5.検索性が高いこと

作成した日時を入れる、作成者を入れるなど、検索するときのことを意識した名付けが重要です。なお、ファイル名の場合、日時は先頭に入れてください。後に付けるのはダメです。理由はファイルをソートしたときに、日時順に並んでくれるからです(例: 20150908_XXXXXX)。

逆にファイルのバージョンは、後ろ付けた方が便利です(例: XXXXX_Ver02)。

ネーミングのチェック方法

次に、付けた名前が適切かどうかをチェックする方法を紹介します。最初のうちは毎回チェックを入れることで、徐々にネーミングのコツをつかんでくるはずです。

  • ファイル名だけを見て内容を推測すること
    例えば、ある機能を「異常検知遮断機能」と名付けたとします。すると、この内容は二通りの意味に受け取れる可能性があります。「異常検知」機能を遮断するようにも、「異常」を検知して「遮断」するようにも受け取れます。名前を付けたときに、必ずこのチェックを行うようにするだけで、品質の向上に大きく役立つでしょう。
  • 他人に見てもらうこと
    1人で考えているとどうしても自分特有の思い込みがあります(つまりベテランの方が危険です)。それを避けるためには、第三者の視点で問題がないか評価してもらうのが一番です。
  • 一度声に出して読んでみること
    音にすると今まで見えなかったものが見えてくる(聞こえてくる)ことがあります。もし、微妙な違和感を覚えたら、そのときは、論理的に説明できなくても、何か問題を抱えていることが多いのです。

エンジニアのネーミングのためのチェックリスト

 

最後に

大手半導体メーカーで半導体エンジニアをしていた私がネーミングの重要性に気付いたのは、社会人になったばかりのころ、ある部門のファイルサーバのディレクトリ構造を見たときでした。そこではディレクトリやファイル名に 「01_」 などと番号を振っていて、検索性を高くしていました。

今となっては当たり前のテクニックだと思うのですが、当時の未熟な私にとってはその便利さは驚きでした。ネーミングを考えるという少しの時間の投資で、仕事の生産性を大きく向上させることができるので、ぜひ実践してみてください。

なお、特にプログラムを書くエンジニアの方には、下記の本がおすすめです。一読すれば自分の仕事を改善するきっかけになることでしょう。

ネーミングの掟と極意(エンジニア道場) 開米 瑞浩著 / 翔泳社