西川＠中野です。
ありきたりですが、人間の問題なのでその場での最適解に近づける
事しか出来ないのではないでしょうか。
>あるシステムを0から設計、完成させるとして、複数のプロジェク
>トが係わるとします。
私の場合はプロジェクトを”一つのゴールを目指すチームの活動”
ととらえています。なので、あるシステムの完成をゴールとすれば
複数のプロジェクトがあるシステムに関る・・・のくだりが理解で
きないです。主プロジェクトに含まれるサブプロジェクト、と言う
ことでしょうか？
>その際、そのプロジェクト全体が、「さあ、良いものを作るぞ!」
>と意気ごみ、全ての方がとても優秀で、各々のプロジェクトはそれ
>ぞれに(XPで、とは限らずとも)うつくしい実装、正しいインタフェー
>スを提供することが出来、最終的にとても良いシステムになる。
>と言うのは、(個人的な思いでしか無いかもしれませんが)とても難
>しいことであると感じております。
美しい設計と実装で、完璧に機能をもったシステムを作り上げると
言うことでしょうか？ それはとても難しいです。
>と考えたとき、最終的なシステムがお客様の手にわたることをふま
>えれば、ひとつでもプロジェクトが破綻していた場合、そのシステ
>ムに係わるプロジェクトは(学ぶことはど多いけれど)失敗である、
>と私は考えています。
パラレルに問題を分割して、解決しているので当然スレッドのどれ
かが失敗したら問題全体としては失敗ですね。
>1.そもそもプロジェクトの切り方がまちがっている。
サブプロジェクトに分割することも、並列度を高めることも間違っ
ていないと思います。
>2.係わる全てのプロジェクト間で密なコミュニケーションをするこ
> とにより回避できる問題である。
ここで、何が問題とされているかが私にはピンときません。
プロジェクトを分割して、要員が並列に動いているけれどやっぱり
うまく行っている感触がない、と言うことが問題でしょうか？
だとしたらゴールが遠くに設定されすぎているか、ゴールの定義が
曖昧なので達成感が得られていないのかな、と思います。
人間の集合体なので100％の満足は求めず全員が80％満足できれば
いいのかなと私は考えます。
>3.自プロジェクトにおいて他プロジェクトとのインタフェースさえ
> 綺麗に切れており、かつ自プロジェクト担当部分の設計及び実装
> が正しくなっていさえすればシステムの成否は関係ない。
ある意味正しいのかもしれませんが、それで満足できますか？
そんな部品のような位置づけで。
コンポーネントはそれ（＝疎結合）でいいとおもいますが、プロジ
ェクトは密結合であるべきだと思います。それが密なコミュニケーシ
ョンかと。
>4.どうがんばっても改善しないようであれば、その他プロジェクト
> は切る。(自プロジェクト側で工数が許す限り作業する、もしく
> は別の部隊をassign出来るかどうか：時間的にも技術的にも、を
> 再度検討する/してもらう。)
何を改善したいのでしょう？
他のサブプロジェクトチームの成果物の質に満足できていない？
それならばプロジェクト全体の問題として話し合うべきです。
>理由により、そのプロジェクトに係わる人ならだれでも、プロジェ
>クト間の隙間を埋められるような良い方法は、無いものでしょうか？
それこそ銀の弾丸はないです。
開発しているのは無機質なロジックの協調であるソフトウェアですが、
開発プロセス自体は有機な思考の協調ソフトウェアです。曖昧な問題に
柔軟に対応できる反面、誰でも出来る方法論というのはないでしょう。
>o 新人が全く別プロジェクトのしかし係わりはあるプロジェクトの、
> 頑固でちょっと年季の入った人間(私のような。(^^;)に対しても、
> 気楽に設計の間違いなどを指摘、論理的な議論が出来る場をつく
> りあげるには、誰が、どうがんばったら良いのでしょう？
どこにでもある問題ですね。
気に入った女の子に対するアプローチといっしょではないでしょうか
（女性だったらごめんなさい、私は男性なので）。
「もてる男の秘訣」って記事をいくら読んでももてません。実際に干
渉して、相手を理解して、話をする、しかないでしょう。
-----------------------------------------
西川真五＠興和（株） IT本部 営業部 １課
e-mail: s-nisikw@....jp
-----------------------------------------