読者です 読者をやめる 読者になる 読者になる

セカイノカタチ

世界のカタチを探求するブログ。関数型言語に興味があり、HaskellやScalaを勉強中。最近はカメラの話題も多め

マーブルワーズ

システム開発時のネーミングついて

システム開発 山の民 プログラミング

※ 筆者の特性上、話題の対象が業務システム開発に偏っていることを予めご承知おき下さい

システムのネーミングですが、困りますよね。

長年業務システム開発で、DB設計などに携わった身として、少しだけコツをお話したいと思います。

前提

まず、前提としてシステム開発する際に、我々がネイティブに使っている日本語を元に英語の命名をする場面を想定しています。

対象は、業務システムで金融とか小売とか流通とか、そういう感じのシステムを想定しています。

命名者は、日本語話者で、英語はそんなに得意でないことを想定しています(自分のことです)。

勘違い

自分が、駆け出しの頃、以下の様な思い込みをしていたのですが、後に間違いだったことに気づきます。

日本語→英語の対応付けが可能である

日本語→英語の変換ですが、両者の言語特性の違いから、一対一の対応付けは困難です(不可能と言ってもいいぐらいです)。

英語の意味に対応する、日本語が複数あったり、日本語の意味に対する英語が複数あったりして、多対多の関係になります。

それに、英語の特徴だと思うのですが、一つの単語の守備範囲がアバウトで色んな意味があり、複数連ねて熟語にして初めて正確な意味を指すようになるようです。

丁度、日本語の漢字一文字に対して英語の単語が対応するような感覚です。

英語の話者は、恐らく話題の主語に合せて暗黙的に意味を絞る事で、平易な単語を使っての会話を成立させているのだと思います。

同じ単語が、前後の文脈によって、全く違う(こともないんだけど連想ゲームみたいな感じになっている)意味を帯びてきます。

システム設計で頻出する単語で言うと、OrderとかAccountとか、Applicationとかはヤバイです。

つまり、几帳面に英訳していくと、冗長な連語になりやすいと言う事です。

一つの辞書があれば、全てのシステムで自動的に命名可能である

ということで、全てのシステムで共通的に使用できる辞書を作成するというのは不可能です。

可能ですが、冗長すぎて役に立たない物になると思います。

それよりも、システムの特性に合わせて辞書を別々に用意したほうが、効率的になります。

命名のコツ

それで、命名のコツですが、システムの特性に合わせて、良い単語を優先的に良く使う重要な意味に紐付けるということです。

ハフマン符号化のような、アルゴリズムを働かせる事になります。

例えば、先の単語で言ったら、Orderという単語を「受注」と決めてしまうわけです。「accepting order」とか「order receipt」なんて熟語は使用しませんし、「順序」という意味では、Orderは使わないということです。

Accountも経理や金融システムであれば「口座」に割り当てられるでしょうが、それ以外のシステムではだいたい「ユーザーアカウント」という意味で使います。

弾かれてしまった方の意味でも単語を使いたい場合は、「bank account」などの形で冗長にします。

こうして、単語を割り当てていくと、全体として重要なところに良い単語があたっていて、枝葉の部分には、冗長な単語が割り当てられているが、使用頻度が少ないので我慢できる感じになります。

運用

割り当てた単語の運用ですが、エクセルで辞書を作るか、高価なリポジトリツールを導入するか、その他の手段を取るかはその時の状況次第ですが、対象システム内で、同じ意味の日本語には、同じ単語(や熟語)を割り当てることを徹底する必要があります。

例外が、2,3%を超えるとシステムの運用に大きな負債を抱えることになります。

そのため、基本的にはDB設計を優先的に行い、業務的な単語の割当を急ぎます。

DBベースの辞書が完成すると、業務に必要な単語は大体割当が決まるので、プログラムもそれに合わせて命名してもらいます。

この時に、プログラムやSQLの予約後が入っていると問題を起こしやすいので、そういった単語はそもそも命名時点で外しておきます。

classとか、importとか(これは輸入システムでは苦しいので大して問題にならないケースが多いし使用します(^^;)、commentとかがこれに当たります。

辞書があれば、日本語→英語は単純変換できるのですが、この時のコツは辞書を予め日本語の文字数が多い順にソートしておくことです。

つまり、下記のようなケースがあるからです。

|日本語|英語| |先行受注|early bird| |受注|order|

これは極端にするために適当につけていますが、日本語の熟語によって、それが重要ならば別の単語を付けるケースがたまにあるからです。

そんな時も、長→短の順に当てれば、問題なく動作します。

困ったこと

システム設計していると「そもそも概念に名前がついていないこと」が、たまに発生します。

例えば、ホットペッパーのような店舗を扱うシステムで、個々の支店は、shopとかつければ良いのですが、それらの集合体の総称はどういう名前をつけたら良いのでしょうか?

shop?ブランド?company?どれもしっくりこないし、ブランドは和製英語じゃん!?

・・・となって悩んだ挙句、「web site」として逃げました(その時のシステムは、店舗の集合体毎にWeb siteを持つ形式だったのでこれでも通じた)。

というような、事態も時折起こります。

また、社内発注が発生して、上流部門では「発注」でも下流部門では「受注」と呼んでいるようなケースも多々あります。この場合も、部門ごとにバラバラになっている単語を意味に合わせて、社内で統一していく必要があります。この辺は、完全にシステム開発から外れて社内政治の世界に突入するわけですが。(^^;

大切なのは、多少不自然でも誰かが勘とセンスで名付けをして、その名付けをみんなが我慢して使うということです。

なるべく違和感の無い命名が理想ですが、それがかなわない場合でも「悪法でも法」の精神で、命名を遵守することで、表現のブレによる困難なバグに遭遇する機会がぐっと減ります。

一言で言えなかった

結構長くなってしまった。

僕は、「システム開発は名付け8割」だと思っています。

特にSEの仕事は、システムに関連するあらゆる事象に名前を付け終わったら、大体終わりです。

それだけ、奥が深く、重要で疎かにできない要素です。

文章にするのが難しく、煩雑でダメな文章を書いてしまいまいしたが、雰囲気だけでも伝われば幸いです。