チームとは (The Discipline of Teams)
2007.09.01
今日紹介するのは、Harvard Business Reviewの記事の中でも特に評価の高い、Katzenbach & Smith による「The Discipline of Teams(このリンクをたどれば全テキストが原文で読める。日本語で詳しく読みたい人は右に紹介した「好業績チームの知恵」を参照)」。彼らは「単なる人の集まりはチームと呼ぶべきではない。メンバーそれぞれの力を合計した以上の力が出せる人の集まりだけをチームと呼ぶべきだ」と主張し、チームを以下のように定義する。
a small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutualy accountable"performance goals"とか、"accountable"などの重要でありながら日本語にものすごく訳しにくい言葉が入っているので、分かりやすくするために思いっきり意訳すると、
共通の目的と、目的達成のためのいくつかの達成すべきゴールとを共有し、かつそれぞれがチームに対してどんな役割と責任を果たして行くかについて共通の認識を持ち、お互いを補完する能力を持った少人数の集まりとなる。
ここで大切なのはチームの目的(=存在理由)が(たとえ最初はそれが上司から与えられたものであったとしても)メンバー全員でしっかりと共有された、彼ら自らが望むものであること。「なんでこんなことをやらなければならないか分からないけど、上司から言われたからしかたなくやっている」のではモチベーションも上がらないし、「全員の力を合わせた以上の力を出すこと」など不可能である。
そして次に大切なのは、その目的に向けたいくつかの明確なゴール設定をし、それを達成することにメンバー全員が全精力を費やすことを約束すること。目的がいくらしっかりしていても、自分たちが着実に目的に向けて駒を進めていることを実感できるゴールをこまめに設定しなければ前には進めない。そうやって設定したゴールを一つづつ着実に達成して行くことで成功が実感でき、モチベーションが上がる。
そしてもう一つ大切なことは、それぞれのメンバーがチームのためにどんな役割と責任を果たして行くかに関して十分に共通の認識を持つこと。それぞれのプロジェクトで誰がリーダーシップをとるのか、それぞれの得意分野は何か、誰が何を担当するのか、などを常に明確にして働けば、不要なミーティングの数も減らせるし、仕事の効率が圧倒的に上がる。
自分のマイクロソフト時代の経験を思い出してみると、たしかに成功したプロジェクト(Windows 95, IE 3.0/4.0)の場合は、目的がものすごく明確だったし(それぞれ、Windows 3.1とコンパチブルな32-bit OSを作る、Netscapeを抜く)、こまめにマイルストーンを設定して着実に駒を進めていたし、役割分担もものすごく明確でほとんどミーティングなどしていなかった。逆に失敗したプロジェクト(Cairo, Netdocs)の場合は、目的そのものが途中で揺らいでしまったし、アーキテクトが何人もいて誰がリーダーシップを取るのかが不明だったため、ミーティングばっかりして、肝心のもの作りがおろそかになってしまっていた。
Comments