【第27回】良いチーム、悪いチーム

情報システムの開発プロジェクトでは、複数の会社（開発ベンダ）からエンジニアが参画し、それぞれ役割分担するような「混成チーム」が多くみられます。

たとえば、基幹システムと通販システムと物流システムがそれぞれ別の会社の製品で、それらシステム間の連携機能を構築するような開発プロジェクトなど。

そんな時、「うまくいくチーム」と「うまくいかないチーム」って、結構はっきり分かれます。

残念ながら、「うまくいかないチーム」の方が多いのではないでしょうか？

（個人の感想です）

放っておくと大抵うまくいかないのです。「混成チーム」って。

なんというか、歯車がかみ合わない感じで。

その理由は、わりと明確です。

「自社のメリットを最優先に考える」のが会社員の当然の習性だからです。

「自分の責任範囲内で最大限の努力をする」のがＩＴエンジニアの職務だからです。

「うまくいくチーム」にするためには、まずこの基本思想の変革が必要なのですね。

「自社だけでなく、プロジェクト全体のメリットを最大限に広げる発想をする」

「自分たちの責任範囲の少し外側にも首を突っ込み、お互いにカバーしあう（場合によっては、厄介ごとを自ら引き受ける）」

言うのは簡単ですが、なかなかできることではありません。

でも、これまで私が関わってきたプロジェクトのいくつかで、この発想でとても良いチームがあったことは確かです。

そこには、優秀で信望ある「リーダー」や「マネージャー」がいました。

その人が徹底的に「セクショナリズム」を排除し、「プロジェクトの目的」を一切ブレることなく伝え続けたのです。

誰が「その人」になるべきか。

最も望ましいのは顧客側のプロジェクト責任者。

次は、顧客側に立って開発ベンダに平等にものを言える「優秀な」コンサルタント（カギカッコ付き注意）が参画すること。

たまに、混成チームの中に1人、全メンバーから一目置かれるタイプの「キーパーソン」がいて、その役割を担うこともあります。

そうそう。

もし、あなたが今まさにそのような状態なら。

いい機会です。

一肌脱いでみるのはいかがですか？