d.sunnyone.org
sunnyone.org

ページ

2013-07-28

「仕組み」の名前の考え方

名前に関する記事のタイトルがいまいちなのはさすがによくないので、タイトルを直した(2013/7/29)
---

最近ちょっと近くで話題になっていた「名前」の考えていきかたについて整理してみた。

ブランド名のように、独自性を持たせることを目的とするのではなく、後で呼びやすく混乱しないための名前付け。主に「それ」を知る人間同士がその物を識別するために使うための名前のガイドライン。「わかりやすい」「混乱しにくい」名前をつけるにはどう考えていけばいいか、というお話。

自分の立ち位置的に、ソフトウェア設計の視点が強くなってしまうが、仕組みを作る立場であれば似たような話になると思う。

経験がたまれば、更新するかも。

1) 文をそのまま使う

「これは何ですか?(何をするものですか?何をすることですか?)」と聞かれたと想定して、それで出てきた説明文をそのまま呼び名にすることを検討する。「何ですか?」の回答そのものなので、意図が伝わりやすい。長くなりがちだが、明快な説明ができる人間の命名であれば、短いことを上回るメリットがあることが多い。

確認ポイント

使う頻度は高くないか?
使う頻度が少ない(例えば、個別の機能のいちモジュール名だったり、年一回の事務処理の細かい手順のひとつだったり)のであれば、意図が伝わりやすいことのメリットが大きい。 しかし、毎日呼び合うような名前だと、短い名前をつけることを検討したあと、決定したほうがよい。 なぜかというと、ただ呼びやすいだけのあまり考えられていない(混乱しやすい・わかりにくい)名前で呼ばれてしまいやすくなるから。
一部の単語だけピックアップして呼び続けられたりしないか?ピックアップされても混乱はないか?
ピックアップしても区別できないから、本当に汎用な言葉がピックアップされることは少ない。例えば「顧客情報データ」を「データ」と略して呼び続けることは少ない。 しかし、文脈を共有すると選んで呼びやすくなってしまう語がある。例えば「クライアント」とか。 混乱がなければそれでもいいのだけど、混乱することがすでに想定できるのであれば、別の名前をつけてあげるのがよい。
そこから頭字語・略語はできるか?
これでつけてみた名前で、頭文字を取ったらいい感じに呼べる名前だったとか、略したら呼びやすかったりしたら、最初から略はこうです、という形で 明示しておくと混乱がない。一方で、その略語が他と同じ場合、かえって混乱を招くので、そもそも略していない状態でも他の呼び名を検討する。

2) 同じジャンルの意図することそのものの単語を使う

1) のそのまま使うパターンにマッチせず、意図した内容が既に一般的な名前として決まっている場合(「一般的に決まった名前」は以後、「定義された名前」とする)は、それを使うことを検討する。ずばりそのものということなので、ほとんどの場合良いが、安易に使うと大混乱を招くケースがある。

確認ポイント

元の語と明白に異なる意図を持っていないか?
新しくつける名前側が従で、定義された名前のほうが先に来ているようなケースでは、それが前提である以上、異なる意図は存在しにくいので、この名前付けパターンは良い選択である。 例えば、定義された名前が何かの規格で、その規格に乗ることこそ意図されたような場合であれば、それを名前につけるのは、受け取る側の意識付けの意味としても、非常に有効である。 しかし、定義された名前が従の場合、注意が必要である。「これこれはAで、あれそれはB…これってXYZって名前ついてるじゃん!」というケース。 こういった場合、一部の重要な部分が異なる場合がある。例えば、「定義された名前ではそれそれはCなんだけど、自分が考えるのはそれそれはDなんだよね…」といった感じ。 このようなことが名前付けの段階で明らかに分かっている場合は、その名前は使うべきではないことが多い。 なぜかというと、聞いた側は、名前が既に定義されているが故、その定義側の意図のほうを名前に感じてしまうから。 「俺のXYZはそうじゃないんだ!」といっても、最初はいいかもしれないが、よっぽどの強さがないと、元の語の意図を書き換えるのは難しいので、どんどんその意図は薄れて行ってしまう。
元の語に付加したい強い意図は持っていないか?意図を狭めたくはないか?
定義された名前は確かにずばりなんだけれど、もっと範囲を狭めておきたいという意図がある場合は、言葉を付加するなり、別の名前付けをするなりを検討すべき。 そうしておけば、広すぎて何を言っているかわからないという事態を避けられる。

3) 別ジャンルの意図することと関係のある単語を使う

文そのものでも、既存の言葉もない場合は、別ジャンルの近そうな言葉がないかを考える。メタファー/こじつけの世界。
一回目は聞いてもわからないが、わからない故、確認が必要となる。ゆえに、混乱を招きにくい。比喩になっているので、一回認識してしまえば、覚えやすい。

確認ポイント

選んだ言葉から受ける意図が、他の一面と衝突しないか?
単語の持つ意味は一面ではないことがあるので、ある面を見て比喩を選んでも、別の面で衝突している可能性がある。 例えば、固いイメージを与えたいからといって「フライパン」と名付けたとしても、冷たいという意図を併せ持つものだったりすると、「フライパン」の持つ熱せられそうなイメージと衝突するので、混乱を招く。
元のジャンルでその言葉は別の意味を持っていたりしないか?
比喩として使われていたりなどで、すでに使われていないか。強い意図を持ってジャンルの壁を越えてきているので、うっかりこの ケースで意図がバッティングすると、大混乱を招く。

4) 別ジャンルの全く関係ない単語を使う

3)に近いが、名前付けに意図がないので、さらにぱっと見/ぱっと聞きでわかりにくくなるが、混乱も小さくなる。
数が必要な場合に選ぶとよい。

5) 新単語を作る

どうしても困る場合は、新しい言葉を作ってしまうのもひとつ(文を略語化するのもこのパターンの一つなんだけど)。

決めた後の確認

似たような意図の語がすでに用意されていないか?それとの違いは何か?
最初にやるべきだけど、名前をつけることで明確になることもあるので、再度確認する。
似たような単語が既に使われていないか?
別の意図なのに、同じあるいは同じような用語が使われていないか確認する。

2013-07-12

Azure WebRole開発で使われるIIS Expressの設定(applicationHost.config)を変更する

Azure WebRole開発で(設定で選択した場合)利用されるIIS Expressの設定を変更する方法がちょっとトリッキーなので記録しておく(Azure SDK 2.0向け…Azureはどんどん変わるので)。このブログでAzureが登場するのは初めてかも。

結論

c:\Program Files\IIS Express\AppServer\applicationHost.configを変更する。

うまくいかなかったら、下に書いた方法で調べるといいかも。

詳細

Web Roleのアプリケーションを開発する際は、開発環境でIIS Expressを使うかIISを使うかをクラウドサービスプロジェクトの設定で選べる。
この設定でIIS Expressを使用するを選んだ場合、IIS Expressが利用される。AzureのIISの設定は、 startup taskでappcmd.exeを叩く(いつもお世話になっているブチザッキさんのブログ)とか、Microsoft.Web.Administartion(NuGet)を使ってC#から変更するといった方法が使えるのだけど、IIS Expressの場合はIISではないので、この方法では設定が反映されない。

IIS Expressの設定ファイルはDocuments\IIS Express\config\applicationHost.config をいじれという情報がWebにある(例えばいつもお世話になっているブチザッキさんのブログ)ので、「これだ!」と思って変更するものの、反映されない。

そこで、Process Explorerでiisexpress.exeのコマンドラインを調べてみると、applicationHost.configの場所が明示的に指定されていることがわかった。

指定されているのがどう見ても一時的なパスなので、もしかして埋め込まれてたりして変えられないのかなーと思ってProcess Monitorで見たら、WaHostBootstrapper.exeがc:\Program Files\IIS Express\AppServer\applicationHost.config を読んで、上記の一時的なパスに書き込んでいることがわかったので、元のファイルを書き換えてみると無事反映された。


めでたしめでたし。
(自分の環境で、「IIS Web サーバーを使用する」で動くようにしろという話ではあるが)