【プロジェクト】物理名であれ論理名であれ、英語名であれ日本語名であれ、意味が通る一意に決まる名前こそ至高
はじめに
対象
- Webアプリの設計に携わるITエンジニア向け。
- 命名規則・用語統一の重要性に気付いているが、上手く説明できない開発者向け。
用語は統一しようという話
ときに猫を表す単語はどのくらい存在するでしょうか。
- 猫・ねこ・ネコ
- Cat, Gatto, Katze
- くろ・しろ・みけ・たま
- にゃんにゃん・イッパイアッテナ
- Felis silvestris catus
- ...
まだまだ出てくるかもしれません。実際、世の中を見回してみると、一つの物事に対して複数の名前が付いていることが多いこと多いこと。それが言語の味といえばそうですが、ことシステム開発に関していえば、用語は一つに統一するべきです。
| 論理名 | 物理名 |
|---|---|
| 猫 | cat (cats) |
| 犬 | dog (dogs) |
何を簡単なことをと思うかもしれません。しかし製品によっては、プロジェクトの参加メンバー内ですら呼称が異なるもの、UI側だけが全く別のラベルのものなど、論理名ですらバラバラなことがあるのです。一体、どうしてこんなことに。
用語揺れの発生メカニズム
用語揺れが起きる要因はいくつかありますが、代表的なものを並べます。
データベースの物理名だけが古い
データベースのテーブル名とカラム名を変更するの面倒臭い病です。実際、動いているサービスのデータベースに変更を与えたくないので、渋々嫌々お客様に見える部分だけ名称を変更するということはあります。プログラム側だけが古い英語のまま残ってしまうムーブです。
これはデータベースに留まりません。例えばURLだと30xリダイレクトその他諸々の手続きを踏むのも大変なので、結果古いまま据え置きということになります。ストレージのパスやリポジトリ名なども該当します。
変更したときの影響が見えないブラックボックス化したプロジェクトでは、これは珍しいことではありません。しかしRailsのように命名規則が厳密なフレームワークで部分的に規則から外れるなど、なかなか香ばしいコードになるのは間違いありません。
部署ごとの言葉遣いが異なる
酷いときだとお客様にヒアリングしたときから違う用語の場合があります。JIS規格・RFC・法律用語としての正式名称を使用していないこともありますし、ユーザーからヒアリングした内容が伝言ゲームされて全く別の単語になって開発側に伝わることもあります。
よくtoBアプリで見るのはcompanyです。これは企業でしょうか、それとも会社でしょうか。そもそも企業と会社は何が違うのでしょう。
会社の具体例は株式会社や有限会社などで、括りとしてはずっと狭い用語です。企業には公社やNPO法人、個人事業主なども含まれます。詳しくは『企業 会社 違い』で検索すれば出てくるので、そちらを参照ください。そして英語にもFirm, Enterpriseなど種類があるので以下略。
とにかくこんな単語一つとってみても、使い方を分かっていないことに気付かされるでしょう。
そして誰も彼もが辞書も引かずに、自分の知っている身近な単語で、仕様の中の同じ物事を呼称し始めるのですから、使う単語がバラバラにならない方が無理があります。
不便な名称だと略称や造語を使い始める
日本人は略語が大好きです。長い作品名は直ぐに略すし、英語のAbbrも平気で使うし。生ビールジョッキでって頼めばいいのに、生中って自然に略しちゃう民族です。
しかも利便性が良いので、一概に責めることもできない。多くの居酒屋には瓶ビール・グラスビール・生ビールジョッキがあって、更に種類銘柄まで選べる。ビールだけでは通じないけど、生中であれば直ぐに通じる。こういった利便性は否定できないでしょう。
プロジェクトを長いこと運営していると、そういった略語や造語のような言い回しは自然発生します。関係者間で非公式に使うこと自体は問題ありません。問題は会議や仕様書などの公式の場で、それらの非公式な呼び名が使われることです。呼び方がどんどん増えていきます。
終いには略語が独り立ちして、全然別の意味に変質してしまうこともあります。元々の意味と仕様が薄れてしまい、設計会議で生き字引な方に用語の定義を確認する有り様です。
プロジェクトにおける用語統一の実践
用語の揺れが放置されると、誤解・混乱・余計な確認が日常茶飯事になります。ここからはどうすればそうした用語のバラつきを抑え、一貫性を持たせられるかを探っていきます。
プロジェクト公式の用語集を定義する
プロジェクトWikiに用語集を作成します。あいうえおからABCまで一通り見出しを作成し、索引や見出しマップからアクセス可能なようにします。ページ内検索に任せるか、ページが分かれる場合は用語集だけ絞って検索できるシステムが望ましいです。
綺麗に書こうとすると更新頻度に差し支えるので、装飾などは60%程度の多少雑な完成度で満足するようにしましょう。このWikiの目的は用語の意味を定義して活用することであって、完璧な辞書を作って満足することではないからです。必要があれば随時更新します。
複数の呼び名がある場合は、公式でこれという論理名・物理名を選出して見出しとします。また歴史的経緯がある場合は、用語説明の後に追記しておくと検索性が上がってよいです。
本質を見抜き一貫性のある名称を付ける
そもそもなぜ造語が乱立し、プロジェクトの途中でリネームしたくなるのか。それはひとえに本質とは異なる名称を付けてしまったという責任が大きいです。分かりにくい名前だから別の名前で呼びたくなるんです。
確かにプロジェクトの途中でビジネス要件が変わり、意味そのものが変化してしまうように見える用語もあるにはあるのですが、全く別の用語になるというよりは包含関係に変化がある方が自然で多いです。会社だけでなく法人全般を対象にするようになった、とか。
この場合は特に支障がなければ、最初から企業という呼び方に統一しておくと安心かもしれません。スコープが明確なら会社でも良いです。ただ後から企業にするのは、先述のURLやデータベースの件も含めると少々面倒だと思いますので、よく考えた上で。
長い名前に略語ができるのは避けようがないので、前項の用語集で差分を吸収するようにした方がまとまると思います。
改名しないか・見えない部分も合わせて修正する
とても悲しい事実ですが、システムのことを考えれば、それでもデータベースやURLは変えないほうが無難という結論に至ります。改名はシステム側もですが、ユーザーマニュアルや運用への影響がでかいので、それだけで大工事なんですよね。
なので下手に名称を変更するよりは、潔く変えないままいく方が混乱が少なかったりします。論理名と物理名がちぐはぐになると、開発者の脳のリソースを都度割かれますし、タイポに似たような名前違いでエラーで落ちるとか、やってられませんから。
どうしても変えるという強い意志を持ったら、ユーザーや運用から見えない部分も合わせて対応する覚悟を持つことです。リファクタリングでこつこつ進めてもよし、予算を取って一気にやるもよし。
いずれにせよ製品の寿命とは相談した方がいいかもしれません。改名したけど翌年サービス終了しますというのはもったいないので、今後数年は稼働するシステムが現実的ですかね。
おわりに
今、無性に今川焼きが食べたいです。
Discussion