中村＠豆蔵です．
＃議論がよく見えていなかったような気もしますが，一応．
> > まず，解釈が統一できないmetaphorは良くないmetaphorであって，metaphorを決定する
> > 段階でもめるようなら選択すべきではないと思います．
>
> 「metaphorを決定する段階でもめる」という所を
>
> 『「システムを作る前において」metaphorを決定する段階で「メンバがそれを拒むことで」もめる』
基本的には単に「拒む」のではなく，他のmetaphorが良いというような反対をする，
つまり，いくつかの選択肢が出てくることをいっています．
他に何もないようであれば，そのmetaphorがその段階のメンバの理解では一番良い
ということになると思います．
＃ただ拒否するのはチームとして成功を目指していくというXPの精神に反すると
＃思います．その場合は，metaphor云々以前のチーム結成にかかわる問題でしょう．
＃もちろん，そのmetaphorを使用するぐらいなら，ないほうが良いという意見は
＃ありえますが，その場合は，そういう合意がなされていくべきでしょう．
> まず、ここで、今まで僕が述べてきたことを整理してみたいと思います。
>
> 最初に、メタファーを次の二つに分けて考えています。
>
> 1) システムの【作り】としてのアーキテクチャーをどのようなものにするかを検討するた
> めに用いるメタファー
> - XPで言って入るメタファー
> - アーキテクチャーに近いもの
>
> 2) どういったモノ（システム）を作るかを検討する上でのアイデアを作り出すためのメタファー
> - 書籍「知識創造企業」でいっているメタファー
> - グランドコンセプト
2)のほうは開発前のことを言っているのでしょうか．
XPはもともと開発方法論なので，それ以前(開発対象が未定)の段階でXPを適応しよう
としているであれば，中村は今のところ意見はもっていません．
＃漠然とですが，アイデアを出す段階ではmetaphorはないほうが良い感じがします．
＃アイデアの制限をしてしまうと思うので．
＃もちろん，企業では作成できるものが限られていますから，制限が暗黙的に
＃存在していますが．
なので，以下はXPでのmetaphorに対する中村の考え(理解)です．
> そして、1)2)のメタファーに共通する考えとして、次のように考えています。
>
> t1) メタファーを導入する目的は、作ろうとしているモノを明確にしていくために起爆剤で
> である。メタファーを導入することで、意見や考えを発散させて収束させる活動の中で
> 具体的なものに近づいていく。
起爆剤かどうかはわかりませんが，システムの方向性を発散させないための具体的な
ものだと思います．
この『具体的なものに近づいていく』がmetaphorについていっているのであれば，
同意しかねます．metaphorは具体化する必要はないと思っています．
＃正しいmetaphorに変えていくというのはありえますが．
> t2) メタファーが具体的であればあるほど、最初の発散させ混沌とした状態を作りだす起爆
> 剤とはなりえず、相乗効果を発揮しあったアイデアがでる可能性は低くなる。
> しかし、発散し難いメタファーが使われたならば、プロジェクトはスムーズに進む可能
> 性はある。けれども、今までにないような製品を作り出すことは難しい。
ちょっと，順序が変に思います．作りたいものがまずあって，それを表すメンバの
共有概念がmetaphorだと思うのですが．つまり，metaphorによって開発対象が変わる
ようであれば，そのmetaphorは不適切なものと考えるべきではないでしょうか．
> t3) メタファーが抽象的であったり曖昧であるほど、最初の発散混沌とした状態を作り出す
> 起爆剤となりえ、相乗効果を発揮しあったアイデアがでる可能性が高まる。
> しかし、収束不可能なメタファーが使われたならば、プロジェクトは座礁しえる。
> けれども、今までにないような製品を作り出せる可能性がある。
発散しないためにmetaphorがあると認識しています．
顧客や開発者の開発システムに対する曖昧な点をある程度定めるためにmetaphorを
使用するのではないでしょうか．
なので，なくてもあっても良いようなmetaphorは意味がないと判断すべきだと
思います．
> メタファーにどの程度「曖昧なもの」を選ぶかどうかは、新規性あるものを作りたいかどうかで
> 変わる。新規性があるものであれば、頭の中を揺さぶり議論が高まる曖昧さを含んだものが
> 望まれる。
>
> ＃ 「曖昧なもの」という表現は、いまいちです。よいのが浮かびませんでした。f^^;
これも，metaphorを何を作るかに使おうとしている感じがします．
> そして、これは、1)と2)の二つのメタファーにそれぞれ言えると考えます。
> つまり、今までにないアーキテクチャーを作り出したいのであれば、「（抽象さを含む）曖
> 昧さ」が大切になると考えますし、今までにない製品を作りたい場合も2)の視点から同様と
> 考えます。
アーキテクチャを縛るmetaphorを導入するかどうかは最終的には顧客の判断だと
思います．縛る場合はアーキテクチャの領域まで希望があるということですから．
そうでない場合は，アーキテクチャを縛るようなmetaphorは個々のケースのよるの
ではないでしょうか．
-----
NAKAMURA Tadashi