中村＠豆蔵です．
＃特に合木さんに対してではないのですが…
> 『メタファーがあって、人によってその解釈が「まちまちなままプロジェクトが進む」
> とメリットよりもデメリットのほうが大きくなる』 （つまり発散しっぱなしの状態が続く）
>
> ということを言われていると理解しました。僕もその通りと思います。
>
> 言い換えると、「解釈を統一していく過程が重要」ということであろうと思います。....(A)
>
> というのも、議論をする時にも、まずここの考えや意見、アイデアなどを募り発散させて
> そのあと収束させていく過程の中で、より良いアイデアが相乗効果的に出てくると思います。
> メタファーはそういった考えや意見を発散をさせある方向に収束させるためのツールになる
> と僕は理解しています。
>
> つまり、どういったメタファーをそのプロジェクトの初期にもってくるかが重要にな
> るということであると思います。うまく行かなければ再度メタファーを与えることも
> 必要となるでしょう。
>
> したがって、こういった「発散から収束という過程を踏むよ」(Aと同意）という事が事
> 前に合意されていることが重要になると考えます。
この一連の議論を見ていると，metaphorに対して，ある程度の不変性を仮定している
ように感じました．
まず，解釈が統一できないmetaphorは良くないmetaphorであって，metaphorを決定する
段階でもめるようなら選択すべきではないと思います．
また，最初に合意できていたmetaphorが，開発システムに対する理解が進んでいく
うちに合わないと感じてきた場合は，変更すべきものです．
＃metaphorもembrace changeの例外ではないということですね．(^^)/
metaphorはシステムに対するアウトラインを表す概念要素で，アーキテクチャと
対比するとそのアウトラインがむしろアーキテクチャに近いもので，metaphorは
そのアーキテクチャのコンセプト(まあそのままですが)という認識ではないで
しょうか．
＃アーキテクチャジャンプが起きるときはmetaphorの変更も必要でしょうね，
＃きっと．
また，真似でもない限り，どうやっても，システムのアーキテクチャを他のもので
正確に表すのは不可能です．
しかし，その概念であれば，まったく違ったフィールドのものでも，ぴったりと
いくことがありえます．
＃既成概念を覆すような画期的なシステムの場合は，どうしようもないかも．
＃中村もmetaphorについてはもやもやした感じがかなり強かったのですが，
＃Wakeの"XP explored"を読んで「いくらか」解消されました．
＃まだ読んでいない方は一読してはいかがでしょうか．
-----
NAKAMURA Tadashi