アジャイルは7人に2人多いか少ないかくらいの大きさのチームについて話題にするが、一方で全体チームという考え方も推奨する。全体チームとは案件を遂行するための十分な技術をチーム全体に持たせるという考え方だ。つまり、中核となる開発技術とは別に、必ずやらなければならないテストの技術、データベースに関する技術、ユーザインターフェイスに関する技術もチームが持つという考え方だ。しかし、多くの組織がチームの大きさや効率的なチームの構成についての問題に頭を悩ませている。
Scott Ambler氏は、プロジェクトのニーズによっては小さなアジャイルチームも大きなアジャイルチームもあり得ると考えている。小さなチームの場合は一般的には、メンバはスクラムの役割が与えられる。例えば、スクラムマスターや開発チーム、プロダクトオーナーといった役割だ。また、チームをサポートするメンバがいる場合もある。このメンバは、DBAのような技術的な領域の専門家や、ドメインの専門家、またはテスト担当者などで構成される。一方、大きなチームには'チーム内チーム'の手法が必要だ。氏が言うには、
大きなチームを複数の小さなチームに編成するのが典型的な戦略です。そしてシステムの設計を中心に編成するのが最も効率的です。各サブシステムをひとつ以上のチームに割り当てることによって、各チームがひとつのアジャイルチームとして働き、動作するソフトウエアを適切なタイミングで提供する責任を持つようになります。この戦略は1960年代にこの戦略を紹介したMelvin Conway氏の名を取ってConwayの法則と言います。また、リーン開発のガバナンス戦略のひとつでもあります。
Steve Miller氏の考えでは、スクラムの役割がチームにあるとしても、それだけでは品質の保証と文書化までをも十分に管理するのは非現実的だ。氏らはこの問題を改善するためにチームに新たな役割を2つ追加した。ひとつはソフトウエア品質エンジニアでひとつのスプリントの品質に対して責任を持つ。もうひとつは文書化スペシャリストでユーザガイドや管理ガイド、各種トレーニング資料の作成を行う。
同様にスクラム開発チームの大きさについての議論に答えてMichael F. Dwyer氏は次のようにコメントしている。
Ron Jeffries氏の言葉はたくさん引用されていますが、私は氏の有名な言葉を拝借して"2が十二分に大きければ2 + 2 = 5になる"と言いたいです。チームの大きさは小さければ1人ですし、大きければ500人にもなるでしょう。この数はチームとその関係者をどのように定義するか依存します。
このように、プロジェクトのニーズに応じてチームの大きさや構成を調整すること自体については一般的な共通理解がある。しかし、チームが最適な構成になっているかどうかについてはどのように検証したらいいのだろう。
Mike Cohn氏の提案は次の9つの質問に答えることだ。これらの質問には十分に構成されたチームにするためのアドバイスが含まれている。肯定的な返答ができるかどうかでチームの構成の具合を探ることができる。質問は下記の通りだ。
- 長所を伸ばし、弱点を補強し、メンバのモチベーションを保つようなチームの構造になっているか。チームのあるメンバの弱点はその他のメンバの強みによって目立たなくなります。
- ふたつのチームで働かなければならないメンバの数を最小に押さえているか(メンバが3つのチームに属さないようにしているか)。多くのプロジェクトに携わったり、複数の作業を同時並行で進めたりするのは有害です。
- メンバが一緒にいる時間が最大化するようなチームの構造になっているか。チームの一員であるという気持ちを維持できるようにチームを設計することのほうが、チームの一体感を生み出すために長い期間を費やすよりも優れた方法です。
- コンポーネントチームは限定的かつ適切に使っているか。チームは機能チームであるべきです。機能チームはエンドツーエンドの機能を実装することに基づいて編成されます。
- チームの食事は2枚のピザで賄えるか。優れた構成のチームの人数はほとんどの場合、7人プラスマイナス2人です。
- チーム内の意思伝達の経路の数は最小に抑えられているか。アプリケーションに小規模な変更を加えたとき、チーム内部のコミュニケーションが増加するならチームの構造を再考したほうがいいでしょう。
- あまりコミュニケーションを取りたがらないメンバが積極的に意思伝達をすることを奨励するようなチームの構造になっているか。チームの設計が効率的なら、本来ならコミュニケーションを活発にするべきなのに我が道を進んでしまうメンバやチームも、積極的にコミュニケーションを行うようになります。
- 説明責任について明確に理解できるようにチームが設計されているか。チームは、オーナシップを共有し恊働して成功に向かうという考え方を強制する構造になっているべきです。
- チームのメンバが自身の属するチーム自体の設計に対して何か提案をしたか。チームのメンバは自分がチームを作っているということを自覚するべきです。
これらの質問に答えてみよう。あなたは効率的なチームを持っていると思うか。アジャイルの提言をどのように受け入れれば効率的なチームを作ることができたのだろうか。