はじめまして島田です。お見知りおきを。
>>>＃OOA/OOD屋とOOP屋が設計に関する議論をすると，平行線を辿るものでしょう．
>>>
>>>
>>それは両者が共通のゴールを目指していないからでしょう．
>>
>>
>
>しかし問題なのは,OOA／OOD屋が作る設計というのが，
>「お世辞にも綺麗な設計ではない」
>ということなのですよ．
>もちろん，そのまま作ると実装もスパゲティ化します．
>
>それに，はたしてOOA/OOD屋にゴールという発想があるかどうか．
>＃OOA/OOD屋のゴールって
>＃「設計者が楽すること（その分実装者が苦労すること）」
>＃じゃないかと思うことさえある．
>
>
私の理解・知識不足かもしれませんがOOA／OOD を切り離すべきだと考えています。
私にはむしろOOA屋、OOD／OOP屋を分けることで、多少の改善がうまれるのでは
ないでしょうか。
（それでもギャップは生まれるでしょうけどね・・・・・・・・・・・・）
私はOOAは全くではないにしろ実装を意識すべきではないと考えます。
私にとってのOOAは分析を行う工程なわけですから、何かを理解するために分析
（OOA）を行うと理解しています。
分析する目的は分析以降で行うシステムの実装時に顧客にとって必要ないもの
や、顧客の考えを
誤解したために生まれる開発者と顧客とのギャップを生めるものです。
そのためOOAでは、あまり実装を意識しないで作業を行うといわれているのだと
思います。
この工程に適した人物像は以下が考えられます。
・顧客要求したのドメインに詳しい人物
・高いコミュニケーション能力がある（システムの知識が無い人物との対話能力）
・高度な分析能力がある（未知の分野でも誤解のないように認識し理解する）
・ＯＯＤ／ＯＯＰ屋に分析結果をわかりやすく伝える能力がある
・アナリシスパターを理解している
一方OOD／OOPではは、OOAで分析した顧客が認識している概念を理解するだけで
満足するわけにはいかないため、
OOAが残した成果にたいして実装を意識した成果を加えてやればよいと思います。
当然のようにOOD／OOPはシステム実装のスペシャリストであるわけですから、
OOA屋が残してくれた
成果を忠実に実装していけばよいと思います。
理想的な人物像としては以下が考えられます。
・コーディングが出来る（オブジェクト指向対応言語があればのぞましい）
・保守性、拡張性、再利用性ｅｔｃ・・・・ その場に応じて抽象度を高めたり
できる
・ＧＯＦのデザインパターンを理解している
OOA → OODの引継ぎの際にシームレスに移行できるように
ＯＯＡ工程途中からＯＯＤ屋と一緒になって徐々に実装の概念も加えてやること
が必要になりますね。
実装が得意な実装屋（ＯＯＤ／ＯＯＰ屋）が顧客のイメージをわかりやすく具体
化できる能力をもっているとは
かぎりません。さらに実装屋が不得意な分野を得意とする分析屋（ＯＯＡ屋）が
実装ができるとはかぎりません。
お互いが力をあわせて顧客を満足させる目的にたちむかっていけばいいのではな
いでしょうか。
そのために、ＯＯＡ屋、ＯＯＤ／ＯＯＰ屋の知識のギャップを埋めるために
共通の知識としてオブジェクト指向（言語じゃないですよ）の概念やＵＭＬなど
のモデリング言語が必要になってくると思います。
長々と書いてますが・・・・・・・
結局各分野に精通した人たちが組んで仲良くしてればうまくいくけど、
勉強もせずにオブジェクト指向を理解してると言う人やオブジェクト指向言語を
使って満足してる人が多い
この業界じゃ中々うまくはいかないんですよねぇ・・・・・・・