最適化した開発チームは3〜10人で美しく回る:開発チームを改善するためのスクラムTips(5)(1/2 ページ)
「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。
今回の内容
●課題:課題:
- チーム運営を改善する
●スクラムのプラクティススクラムのプラクティス
- チームのベスト人数は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人別のチームに入れ、一度に多くのチームを教育させようとするかもしれません。しかし、これではチームの状況が違うため、成功したチームでの経験を生かしきれません。それよりは、チームを維持し、新しい課題をチームに与えていく方が効率的です。
Copyright © ITmedia, Inc. All Rights Reserved.