開発チームの人数とふるまいイメージ

チームの自律性

お仕事でソフトウェアを開発するプログラマーチームに対して、僕が持っているイメージを整理しました。

人数
2	リードとサブ	コンビ
3	リードとサブ x 2	コンビとサポート	チーム
4	リードとサブ x 3	チームとサポート	チーム
5	マネージャーとメンバー x 4	チームとサポート	コミュニティ

この表は、右に行くほどチームが自律性高くふるまうことをあらわします。

自律性が高い方が良いとは限りません。 自律性が低いと5人以上のチームでは、チームマネジメントを専任する人が必要になると思います。 それをマネージャーとメンバーと表現しています。 プログラマーの中にはチームマネジメントを専任したくない方が一定数います。 もしも、プログラマーからチームリーダーになり、チームマネジメント専任になりたくない場合、チーム人数が少ないうちから自律性を高めておくのがオススメです。

チームの人数が増えてから自律性を高めるには時間が掛かります。 チームメンバー同士が対話する機会を設け練習を繰り返す必要があります。 週1回程度の話し合いの機会を半年～一年くらい続けると、自律性が高まるように思います。

チームの自律性を重視するときに注意事項があります。 2人チームがリードとサブになるかコンビになるかは、性格の相性に強く依存します。 2チームでは、自律性をあまり重視しない方が無難です。

一方、3～4人では自律性を重視すると良いと思います。 リードとサブ x n の状態で人数が増えると、リーダとチームメンバーのコミュニケーションが増え、チームメンバー同士のコミュニケーションが増えません。 リーダーがコミュニケーションにつかうコストが増え、チームメンバー同士のコミュニケーションを増やす施策が打てなくなります。 チームの人数が増えるとチームのパフォーマンスは一度下がります。 チームのパフォーマンスを上げるために、リーダとチームメンバーのコミュニケーションに時間を使いたくなると思います。 一度パフォーマンスが上がってからチームの自律性を高めようとしても、チームの自律性を高めるには再びパフォーマンスを一時的に下げる必要があります。 怖くてできません。 「パフォーマンスが上がっているし、自分が我慢すれば良い」と思いがちです。 人間は「自分が我慢すればよい」誘惑に抵抗するのに、ものすごいパワーが要ります。

コミュニティ

上の表をみると、5人チームにコミュニティという謎の状態があります。 チームとコミュニティの違い、会社・組織をどう捉えるか | Social Change! に出てきているコミュニティをイメージしています。 なぜ、チームではなくコミュニティなのかというと、5人以上になると、ミッションに対して100％動いていないメンバーがでてきます。 4人のチームはめちゃくちゃ上手く行っていると4人分の成果がでます。 5人のチームはめちゃくちゃ上手く行っても4.5人分の成果です。

スキルの差からではなく、タスクの投入量が上手くコントロールできなくなるために起きます。 手の空くメンバーは特定の人物ではありません。時々によって手が空くメンバーは変わります。 タスクを上手く用意すれば5人分の成果がでるようになるかというと、僕の経験則では、なりません。

チームにミッション以外のことに取り組む余裕が生まれた状態と捉えるとよいです。 ミッションとは別の緊急ではないが重要なタスクを用意しておいて、チームメンバーに取り組ませるとよいでしょう。 これはチームの余裕です。 4人までのチームでは緊急ではないが重要なタスクは正式なタスクにしたり、リーダーが空き時間でこっそりやったりという工夫が必要です。 5人以上のチームがコミュニティになると、チームメンバーが自主的に緊急ではないが重要なタスクに取り組めるようになります。

また、もともと4.5人分の成果しか出ないので、メンバーの離脱や加入が容易になります。 一人離脱しても12.5パーセントしか下がらないのでインパクトが弱いです。 一人加入にしても1人分の成果は期待されないので、新メンバーの負担が低いです。 このメンバーの出入りが容易な状態が、チームではなく場でありコミュニティです。

チームの自律性を高めるコツ

チームの自律性を高めるコツは、チームメンバーに縄張りを作らせないことです。 人間は縄張り意識を持つと、その作業を他人にされるのが苦痛に感じます。 また、縄張り外の仕事するのがおっくうになります。

縄張りをつくらせないためには、リーダーはチームメンバーの扱いを変えてはいけません。 チームメンバーのスキル、年齢、性別、得意なことが違っても扱いを変えません。 経歴20年のベテランと新卒半年の新人の扱いを同じくします。 スキルが足りない部分のサポートは必要です。 スキルが足りている作業は平等に割り振ります。

チームメンバーによって実行速度の遅い速いの差はありますが、クリティカルパスに乗っていない作業は早さを気にする必要はありません。 また時間が掛かっても成果を出せた体験は、個人の成長に繋がります。 さらにクリティカルパスに乗っていない作業は早さを気にする必要が無いは頭で理解しても、なかなかその通りにふるまえません。 何度も実際に体験する必要があります。

平等に割り振らずに、ベテランにばかり難しい作業を振ると「この領域はおれの仕事」と縄張りを作りはじめます。 ベテランほど陥りやすいので、意図的にコントロールする必要があります。 コントロールせずに放置しておくと、よほどの人格者でないとブリリアントジャーク化します。 すでにブリリアントジャーク化していてコントロールできず、 短期的な成果よりチームの成長が重要な場面では、チームから外れてもらうことを考えてもいいかもしれません。

継続して開発していると、前回機能Aを担当した人に今回も機能Aをお願いしたくなります。 よほど急ぎでない限り担当はグルグル変えるようにしましょう。 繰り返しですが、クリティカルパスに乗っていない作業は早さを気にする必要はありません。 プロジェクトの進行が早くならないのに、縄張り作りを強化するのは、なにも得しませんよね。