チームの作り方を調べると、いろいろな「型」が出てきます。名前を並べると同じ分類に見えますが、専門性についての言葉もあれば、誰が判断するかについての言葉もあります。ここでは出典ごとの意味を確認して、どんな仕事に使えそうかを考えてみます。
この記事のポイント
チームの名前を選ぶ前に、担当する仕事、判断する人、困ったときの支援方法を確認します。複数の考え方を組み合わせるときは、それぞれ何を指す言葉なのかを共有しておきます。
まずは言葉の違いを表で整理する
次の表は、組織の構造や開発手法に出てくる言葉を、私なりに並べて比べたものです。一つの理論に沿った正式な分類ではありません。同じチームが複数の特徴に当てはまることもあります。
| 呼び方 | 主に見る特徴 | QAで考えられる用途 |
|---|---|---|
| 職能型 | 同じ専門性で集まる | QAの育成や標準の整備 |
| クロスファンクショナル型 | 必要な異なるスキルを備える | プロダクトの継続的な開発 |
| プロジェクト型 | 期限のある目的へ集まる | 移行や特定の業務改善 |
| 自己管理型 | 仕事の分担や進め方を内部で決める | 共通目標に向けた日々の調整 |
| Squadの事例 | 領域の長期的なミッションを持つ | 少人数での継続的な領域担当 |
| Platform | 他チームの仕事を支える内部プロダクト | 共通のテスト実行基盤 |
| Enabling | 他チームの能力獲得や障害の解消を支援する | テスト設計の伴走支援 |
| 実践共同体 | 共通の領域で交流し、実践を学ぶ | チームを越えたQAの知識共有 |
クロスファンクショナルと自己管理は両立する
Scrum Guideでは、Scrum Teamは価値を生むために必要なスキルを備え、誰が何をいつどのように行うかを内部で決めると説明されています。前者はクロスファンクショナル、後者は自己管理という特徴です。
この二つは、どちらか一方を選ぶものではありません。異なる専門性を持つメンバーが、共通の目標に向けて仕事の進め方を自分たちで決めることもできます。自己管理を「各自が自由に仕事を進めること」と受け取らないよう、目的と責任も一緒に確認します。
PlatformとEnablingは何を支援するのか
Team Topologiesでは、PlatformとEnablingは別のチーム類型です。Platformは価値の提供を促す内部プロダクトを提供し、Enablingはほかのチームの障害や不足する能力に働きかけます。
QAに当てはめるなら、共通のテスト環境を提供し続ける仕事と、ほかのチームがテスト設計をできるよう一定期間手伝う仕事の違い、と考えられそうです。これは私による適用例です。どちらも「支援」ですが、何を提供し、誰が使い、いつ支援を終えるのかを分けて整理します。
Squadの事例と実践共同体を読むときの注意
Squadを紹介する2012年の『Scaling Agile @ Spotify』は、当時の働き方を記録した資料です。長期的なミッションを持つチームの例として読めますが、そのまま現在の組織や万能のモデルを示すものとして扱わないようにします。
Wenger-Traynerが説明する実践共同体では、共通の領域、交流する人々、共有する実践が重要な要素です。同じ役職の人を集めればできるものではなく、経験や道具を持ち寄って、仕事のやり方を学ぶ場として考えます。
担当・判断・相談先を具体的に決める
日々のプロダクト開発、専門知識を学ぶ活動、期限のある改善では、必要な協力の仕方も変わります。継続して担当するのは誰か、知識を共有する場所はどこか、困ったら誰に相談するかまで決めておきます。
別の記事で使っている「パウ・パトロール型」も、状況に合わせて得意なことを持ち寄るチームを説明するための比喩です。正式な分類として加える意図はありません。実際の役割や責任、判断の手順を話し合うときの例えとして使っています。