スクラムチーム

実装が終わっても、別の部署によるテストや運用準備を待つために、利用者へ届けられないことがあります。
開発者を集めてチームと呼ぶだけでは、成果を使える状態にするための仕事が抜けるかもしれません。
スクラムチーム（Scrum Team）は、目指す将来の状態であるプロダクトゴールを共有し、価値があり有用な成果をスプリントごとに作る責任を持つチームです。

三つの責任を一つのチームで担う

スクラムチームは、一人のプロダクトオーナー、一人のスクラムマスター、開発者で構成されます。
プロダクトオーナーはプロダクトの価値の最大化、スクラムマスターはチームの有効性に責任を持ち、開発者は使える成果を作るために計画し、品質を確保します。
これらは、スクラムで果たす責任の区別です。

この区別は、プロダクトオーナーやスクラムマスターが開発者の上司だという意味ではありません。
スクラムチームの内部に、指示する側と実行する側という階層は置きません。
チーム全体で成果への責任を持ちながら、それぞれの責任に従って判断します。

なお、スクラムでいう「開発者」は、プログラマーに限定されません。
たとえば、デザインやテストなどの専門性を使って成果を作る人も含まれます。
所属部署や社内の肩書だけで、スクラム上の責任が決まるわけではありません。

必要な技能をチームとして備える

スクラムチームには、スプリントごとに価値を作るための技能を、チーム全体で備えることが求められます。
これを機能横断的と呼びます。
全員がすべての作業を一人でできるという意味ではなく、専門性を組み合わせて、完成までの仕事を進められるということです。

たとえば、請求書をダウンロードする機能を作るなら、画面の実装だけでなく、金額の確認、権限の検証、運用上の準備も必要になります。
誰か一人が全部を担う必要はありません。
ただし、テストを毎回チーム外の順番待ちにすると、チームだけでは完成まで進められません。
組織は、必要な技能を持つ人の参加や技能の共有を通じて、こうした依存を減らせるか検討します。

自己管理を支える判断範囲

スクラムチームは、誰が何を、いつ、どのように行うかを内部で決める自己管理のチームでもあります。
そのためには、目指す状態に加えて、予算や品質基準などの制約と、チームで決められる範囲を共有する必要があります。
目標も判断範囲も示さずに「自由に進めて」と任せるだけでは、チームは選択を評価できません。

たとえば作業が詰まったとき、開発者は担当を越えてレビューを手伝ったり、作業の順番を変えたりします。
着手済みの仕事が各人の手元に積み上がっているなら、個人の担当件数より、チームとして何を完成させるかを話し合います。
共通のスプリントゴールが、その選択の基準になります。

人数より完成までの流れを確かめる

スクラムガイドは、通常10人以下をチームの目安としています。
ただし、人数だけを合わせても、必要な技能や判断権限が欠けていれば、使える成果は作れません。
チームを編成するときは、完成の定義を満たすまでに必要な仕事を並べ、どこで待ちが発生するかを確かめます。

同じプロダクトを複数のスクラムチームで扱う場合は、プロダクトゴール、プロダクトバックログ、プロダクトオーナーを共有します。
チームごとに異なる方向を目指すことによる、仕事の食い違いを避けるためです。

参考資料