最適化した開発チームは3〜10人で美しく回る：開発チームを改善するためのスクラムTips（5）（1/2 ページ）

「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。

[かわぐちやすのぶ（@kawaguti），＠IT]

今回の内容

●課題：課題：

• チーム運営を改善する

●スクラムのプラクティススクラムのプラクティス

• チームのベスト人数は3〜10人

---

　あなたが所属する「チーム」はどんなチームですか？

　チームのスタイルは千差万別です。メンバーがそれぞれ独立して仕事するチームもあれば、全員の作業状態を共有しているチームもあります。

　良いチーム運営をするために、スクラムのプラクティスは有効です。スクラムの核心は、「コミュニケーションコストをなるべく上げず、有機的なチームを作ること」にあるからです。

チームミーティングの「人大杉」問題

　毎週のチームミーティングで話す「内容」を思い出してください。

• 今週行ったことの報告
• 問題の共有
• 同僚からアドバイスをもらう

　多少の差はあれ、だいたいこのようなことを話しているかと思います。

　「時間」はどうでしょうか？ 参加人数が多いミーティングでは、全員の話を聞くだけで相当の時間がかかります。時間を圧縮するために、チームリーダーは工夫をこらすでしょう。表者だけが発言するケース、ひどい場合だと「一方的な伝達事項のみ」……なんてこともあります。

　マネージャがどれだけミーティングを効率的に運営しても、「人大杉」問題は解決されません。

適切なチームは3〜10名で回る

　スクラムでは、「適切なチームの人数は、3〜10人」という認識です（長く4〜10人でしたが、2011年に最低人数が3人と改められました（詳細は記事末のコラム参照）。

　これはルールというより、世界中の人たちの経験則に基づいたベストプラクティスです。10名を超える場合は、チームを分割して適切な人数を保つ方が効率的だといわれています。

　例えば5名なら、日々のミーティング（朝会/デイリースクラム）で、1人につき2分ずつ報告しても、10分で終わります。他のメンバーが行っていることを知り、問題になっていることを確認し、チームの置かれた状況を把握するために、人数は少ない方がやりやすいのです。

参考：第1回「『ほう・れん・そう』を15分の朝会に置き換える」

当事者意識を刺激する

　チームの人数は、メンバーの当事者意識に大きく作用します。

　人が多いと、「課題を自分から解決しなくても、誰かがきっと解決してくれる」と考える確率が高くなります。すべてのメンバーが「次に解決するのは自分かもしれない」という意識を持たなければ、他のメンバーの問題解決から学び取ろうという意識が生まれません。

　小さなチームではいつ自分の番が回ってくるか分かりませんから、常に準備が必要になります。その結果、チームの知識は常に「同期された状態」を保つようになります。

人数が少なすぎても問題が起こる

　反対に、チームの人数が少なすぎても問題を抱えます。最大の問題は、チームの課題を解決するアイデアの多様性が欠如することです。

多様性を確保する

　解決すべき課題に対して、開発者、デザイナー、インフラ、さまざまな知見を総動員してアイデアを出すことになりますが、この時に最も影響を与えるのは「スキルや経験の多様性」です。

　チームに多少なりともその解決策を知っている人がいれば、Webで調べたり、知っていそうな人に聞きに行けます。しかし、知らないことは調べることすらできません。チームは多様性を持っている方が、効率的なのです。

　また、人が入れ替わる際のコストも、人数が少ない方が高くつきます。4人のチームから1人交代する場合、十分に成熟したチームであれば、残りの3人が1人分の仕事をバックアップしながら、新しいメンバーに徐々に知識共有しけるでしょう。チームの文化が急に崩壊することもありません。しかし、2人のチームで1人が抜けることは、即座にチームの崩壊を意味します。

“できるチーム”の分解はしちゃだめ

　チームで培って来た文化の実体は、各メンバーの“頭の中”にあり、かつチームが置かれてきた状況に強く依存します。

　新しいやり方で結果を出したチームがあると、経営者はそれを社内全体に波及させたいと望むでしょう。例えば、チームのメンバーを1人1人別のチームに入れ、一度に多くのチームを教育させようとするかもしれません。しかし、これではチームの状況が違うため、成功したチームでの経験を生かしきれません。それよりは、チームを維持し、新しい課題をチームに与えていく方が効率的です。