前回に続き、チームワークについて考える。目的をしっかりとシェアし、互いの強みを生かし弱みを補い合う関係が大事である。営業部門を筆頭に、検査部門、管理部門や、ライン部門など社内関連部署とも密接に連携しなければならない。
 |
システム開発のように大量の設計者が参画する開発現場にあっては、各設計者が勝手ばらばらに設計したのでは、なかなかまとまらない。リーダーの明確な方針の下、リーダーの指示に従って開発を進めなければならない。
しかし、開発現場は高度な知的職場でもあるため、上からの指示に従っていればよいというほど単純ではない。各設計者も言われたとおりに設計するのと、自分の考えで設計するのとでは、やりがいや達成感がまるで異なってくる。やりがいがあれば当然、設計の質も上がるし、設計の効率も上がる。
チーム・メンバーが新人中心だったり、外注者中心だったりする場合は、リーダーの統制的な指導がより求められるだろう。だが、ある程度のレベルが期待できる設計者集団なら、上からの指示よりも、みんなで考え、議論して方針を決めていくアプローチを取り、みんなが自由にかつ真剣に考えるチーム作りを目指すべきであろう。
 |
チームのモラールを維持向上させるためには、ちょっとした行事を考えることも大事である。
1971年ごろ、旧国鉄の緑の窓口システム「マルス105開発プロジェクト」の立ち上げ時、総指揮者の尾関雅則氏は、全国から集まった国鉄のスタッフに日立製作所のスタッフを加えた混成プロジェクトを編成。その際に、「チームの歌と旗」を募集し、チームワーク作りに苦心されていた（本誌1998年7月 20日号に関連記事）。
また大規模システムの場合には、各メンバーが何をやっているのかさえ知らない場合も出てくる。ある段階で全員を集め、各人の担当内容を発表する行事を設定するのもチームワーク作りの一案である。発表会を通じてお互いの連携強化が期待できる。
飲み会やスポーツ大会などもよく見られる例である。プロジェクトごとに、チームワークを高めるために何らかの行事を設定することが望ましい。
 |
プロジェクトが、1つの部や課の人員だけで構成される場合は、ラインとプロジェクトが同じになるが、大規模プロジェクトでは1つのライン組織だけでは、人数、技術力ともに不足するので、必要な技術を扱う専門組織や研究部門を含む他のラインから人材を供給することも必要になる。
このとき、各ラインから派遣されたメンバーにとって、ラインとプロジェクトの方向が一致していればよいが、必ずしも一致しないのが現実である。派遣されたメンバーが困らぬように、プロジェクトのリーダーやマネジャーは、各メンバーの“里”（出身部署）であるラインのマネジャーと定期的に連絡会議を開くとともに、時には懇親会の企画も必要だろう。進捗会議などにはラインのマネジャーにも参加してもらい、連携を深めるべきだ。
 |
一定規模を持つ組織では、品質保証部とか検査部と呼ばれる部隊がある。通常は、プロジェクトとは独立に存在し、顧客に対して会社としての最後の責任を持つ。プロジェクト内に臨時に設置したテスト部隊とは異なり、高品質なシステムを提供できるよう、品質保証のプロ集団であることが強みだ。品質の最後の砦が検査部なのだから、プロジェクト・メンバーは検査部のメンバーとの連携を強化すべきである。
検査部に問題点を指摘されたり、不良を摘出されたりすることを嫌がる設計者もいるが、「検査される」といった被害者意識を捨て、むしろ「検査してもらう」「バグを見つけてくれてありがたい」と感謝するくらいに前向きな気持ちを設計者は持つべきである。
