中村さん、
こんにちは、合木です。（ちょっと今日はメールしすぎです。これで今日は仕事に集中します）
On Fri, 07 Sep 2001 15:51:47 +0900
NAKAMURA Tadashi-san wrote:
> 中村＠豆蔵です．
<賛成反対がわかりませんでしたので大きく削除 m(__)m />
：
> まず，解釈が統一できないmetaphorは良くないmetaphorであって，metaphorを決定する
> 段階でもめるようなら選択すべきではないと思います．
「metaphorを決定する段階でもめる」という所を
『「システムを作る前において」metaphorを決定する段階で「メンバがそれを拒むことで」もめる』
という風に補足することが正しかった場合、ある程度賛成です。
しかし、その補足が正しかった場合に、いくらか意見があります。
＃ 補足が正しくなかった場合は、補足した文章についての意見とご理解ください。m(__)m
その理由と意見を以下に述べます。
まず、ここで、今まで僕が述べてきたことを整理してみたいと思います。
最初に、メタファーを次の二つに分けて考えています。
1) システムの【作り】としてのアーキテクチャーをどのようなものにするかを検討するた
めに用いるメタファー
- XPで言って入るメタファー
- アーキテクチャーに近いもの
2) どういったモノ（システム）を作るかを検討する上でのアイデアを作り出すためのメタファー
- 書籍「知識創造企業」でいっているメタファー
- グランドコンセプト
そして、1)2)のメタファーに共通する考えとして、次のように考えています。
t1) メタファーを導入する目的は、作ろうとしているモノを明確にしていくために起爆剤で
である。メタファーを導入することで、意見や考えを発散させて収束させる活動の中で
具体的なものに近づいていく。
t2) メタファーが具体的であればあるほど、最初の発散させ混沌とした状態を作りだす起爆
剤とはなりえず、相乗効果を発揮しあったアイデアがでる可能性は低くなる。
しかし、発散し難いメタファーが使われたならば、プロジェクトはスムーズに進む可能
性はある。けれども、今までにないような製品を作り出すことは難しい。
t3) メタファーが抽象的であったり曖昧であるほど、最初の発散混沌とした状態を作り出す
起爆剤となりえ、相乗効果を発揮しあったアイデアがでる可能性が高まる。
しかし、収束不可能なメタファーが使われたならば、プロジェクトは座礁しえる。
けれども、今までにないような製品を作り出せる可能性がある。
そして、この前提で、次のように考えます。
＊ ＊ ＊
メタファーにどの程度「曖昧なもの」を選ぶかどうかは、新規性あるものを作りたいかどうかで
変わる。新規性があるものであれば、頭の中を揺さぶり議論が高まる曖昧さを含んだものが
望まれる。
＃ 「曖昧なもの」という表現は、いまいちです。よいのが浮かびませんでした。f^^;
＊ ＊ ＊
したがって、「metaphorを決定する段階でもめる」場合に、そのメタファーの選択を止める
かどうかは、そのプロジェクトの目的によると考えます。つまり、新規性が高いものが望ま
れるならば「もめる」ことこそが必要なことになりえるという主張です。
そして、これは、1)と2)の二つのメタファーにそれぞれ言えると考えます。
つまり、今までにないアーキテクチャーを作り出したいのであれば、「（抽象さを含む）曖
昧さ」が大切になると考えますし、今までにない製品を作りたい場合も2)の視点から同様と
考えます。
例えば、すでに存在する製品とまったく同じものを作りたい場合は、その製品そのもののが
メタファーとなってもよいでしょう。例えば、ワープロを作りたい場合、どういったワープ
ロを作るかという場合のメタファーは、「MS Word」というのがそのメタファーとなるでしょう。
この場合は、1)の視点で殆ど議論の必要はなく、模倣することに全力が注がれるでしょう。
反対に、「MS Word」に勝てるようなワープロを作る場合に、とても抽象的なメタファーとし
ては、「日の丸ソフト」というのもそのメタファーとなるでしょう。そして、この場合は、
2)の視点から「日の丸ソフト」とは何であるかというそもそも論の議論からスタートするこ
とが必要となるでしょう。
こういう風に考えています。
> また，最初に合意できていたmetaphorが，開発システムに対する理解が進んでいく
> うちに合わないと感じてきた場合は，変更すべきものです．
> ＃metaphorもembrace changeの例外ではないということですね．(^^)/
はい。これ以下は、同意です。
--
Shigeru Gougi
E-mail :ANC04864@....jp