何か大きなことを成し遂げようとする時に、大勢で取り組むというのはごく当たり前のことのように思えるが、 チームを作り方、働き方によって成果は大きく変わってくる。
生産性の高いチームと、そうでないチームの差は、１００倍以上とも言われている。 複数人で共同作業を行おうとした場合、人数は多ければ多いほど有利だと思っている人は多いが、実際には人数が多いというのは不利である。人数が多くなってくると個々人がそれぞれ他のメンバーとコミュニケーションを取る数が増えてしまい、効率的なコミュニケーションが行えなくなってくる。すると、全員で一つのことを成し遂げようとした場合、どのように行うのかという意思統一を行うのに、より多くの時間がかかってしまう。何か指示を与える場合でも、全体に行き渡るのに時間がかかり、こうした意思伝達に大きなコストがかかることになる。
目指すべきは出来る限り厳選した少数精鋭の部隊であって、誰が誰か分からないほどの大人数で編成した大軍隊ではない。俊敏に意思決定を行い、それぞれがその場その場で考え判断をし、迅速に問題に対処していく最小メンバーで作られたチームである。一人で仕事をする場合とチームで仕事をする場合とではその成果は大きく異なり、５人のメンバーでチームを組んだ場合、５人それぞれの能力を足し合わせた総和を超えた成果を出せるチームが望ましい。
こうした、チームで戦う基本的な原則に誰もが同意するにも関わらず、チームで成果を出すということを教わる機会がない。私はチームで成果を出すことを支援するコーチングを行ってきたが、 それは何も野球というチームスポーツをやってきたから自然に身についたわけではない。私がチームで働くことを学んだのは24歳で入社したソフトウェア会社であった。
今でこそ私は「アジャイル」という言葉を使って仕事を説明しているが、 当時はそのような言葉は使っていなかった。
一つのプロダクトに５０人近くの人間がひしめき合って開発を行っていた。その中に１チーム５人程度のサブシステム単位でのチームが作られ、それぞれのサブシステム間で互いにコミュニケーションを取って同期を取りながら開発を行っていた。そしてほとんどのユーザーは複数のプロダクトを購入するので、それぞれのプロダクト間での連携も必要だった。各チームはそれぞれで意思決定を行う権限を与えられており、チームメンバーも基本的には自らの判断でユーザーからの要求を想定し、設計を行い、コードを書いて実装し、テストする。要件定義だけを行うメンバーや、設計だけを行うメンバーというのはいない。それぞれのメンバーが全ての工程を行う。全員がすべての工程を理解しているので、意思決定は速い。そして自らが実装するので、技術的な面を無視した実装不可能な要求や、整合性が取れないような設計を行うことはなかった。
入社1年目も10年目の社員もそれぞれが自由に意見を言い合い、合理的な判断が行えるように 、誰もが遠慮せず深い議論を行っていた。だからといって決して会議が長いわけではなく、必要な分だけを必要なメンバーだけでさっと集まって議論し、結論が出たらすぐにデスクに戻って作業に取り掛かっていた。チームメンバーの中での得意不得意があるのは当然だが、それぞれの得意領域で能力を発揮し合うことがチームの成果につながることを理解しており、とてもアクの濃い個性を持ったメンバーばかりだった。
業務時間中も雑談を交えながら談笑したりと、白熱した議論をするからといって決してギスギスした雰囲気ではなかった。論理的に考えることを求められるので、結論に至るまでのプロセスが後から参照しても明確であった。各メンバーに大きな裁量が与えられ、それぞれが自分たちの責任を果たすべくONE TEAMとして、そしてプロフェッショナルとして、自分たちの仕事にプライドを持って日々戦っていた。
ソフトウェア開発の現場では、顧客の言う事は絶対だという変な風潮があるが、その当時の会社では全くそんなことはなかった。顧客からの要望を跳ね返すこともあるし、こちらからユーザーの想定を超えた価値の高い機能を提案し実装することも多かった。ユーザーと開発者に主従関係はなく、あくまでも対等であった。だからこそ開発者たちは、自分たちの作るものがユーザーにとって価値をもたらさないのであればユーザーが離れていってしまうことを理解し、「何が何でもいいものを作ってやる」という覚悟があった。こちら側の落ち度でユーザーを怒らせることもあったし、感謝されることもあった。そうした時はチームで慰め合い励まし合い、喜びを分かち合った。
チームメンバーはみな若く、 ２０代半ばから３０代半ばぐらいのメンバーが最も多かった。ベテランと呼ばれるメンバーでも５０歳を超えたメンバーはほぼおらず、４０歳を超えていれば長老級の風格があった。スピード感があり毎日強いプレッシャーを受けながら仕事をしていたが、短期間で自分を含めたチームメンバーたちが成長していくのを実感できた。 この頃の体験が私の中での「優れたチーム」の基準になっている。
もしあなたが今一人で仕事をしているようであれば、チームを組んだ方がいい。会社員であればチームで仕事を任されることがあると思うが、果たしてあなたのチームと呼ばれるものは、うまく機能しているだろうか。
もしあなたがフリーランスで携わっているプロジェクトの中にチームがあるとした場合、あなたは本当にチームの一員だろうか。
あなたがもしまだ大学生で、何か強い使命感を帯びたようなチームというものを未だに経験したことがなく、チームで戦うということがイマイチイメージが湧かないと思うのであれば、価値観を基準にチームを作るのではなく、能力を基準にチームを作ってみよう。大学生のうちは価値観が近い者同士で集まり、集団を形成していく。仕事で成果を出すためには価値観が一致していることよりも能力の水準が一致している方が重要である。
あなたから見てこの人の能力は優れていると思う人に声をかけよう。自分と価値観が近いから声をかけやすいという理由で人を選ばないように注意しよう。
人をいたずらに増やすのをがまんしよう。人を増やしていくと、細部がわからなくなっていき、そして未熟なマネージャーは、マイクロマネジメントをしたい欲求に勝てなくなり、過干渉をしだしてしまう。生産性が落ちていく原因を「自分が管理しきれていないからだ」とさらに過干渉を加速させることになり、そしてさらに悪化させていくのである。もはや悪循環である。
全てを詳細に把握しようとするマネージャーが、チーム全体のコミュニケーションのボトルネックになっていることが問題なのである。
ではマネージャーは何をマネジメントすればいいのか。
それはチームメンバー同士のコミュニケーションパスのマネジメントである。
初めの頃というのは、メンバーそれぞれで未経験の領域もあるだろう。
チームとして有機的に機能するようになってくると、あなたひとりの成果をはるかに超えた成果を、チームが生み出すようになるだろう。
