アジャイルガイド · アジャイルの役割とチーム
アジャイルのチーム構成：種類、役割、選び方
アジャイルのチーム構造とは、小規模なクロスファンクショナルチームがエンドツーエンドで価値を提供できるように、人、スキル、責任を編成する方法です。一般的な構造には、フィーチャーチーム、コンポーネントチーム、ジェネラリストとスペシャリストの組み合わせ、プラットフォームチームがあり、組織が拡大するにつれて、より大きな単位にまとめられることがよくあります。
要点
- アジャイルチームは小規模で、クロスファンクショナルで、自己管理型で、長期的に存続します。
- フィーチャーチームは引き継ぎを減らし、コンポーネントチームとプラットフォームチームは専門性の深さと共有サービスを提供します。
- 価値の流れを中心に構造を設計し、依存関係を最小限にしましょう。
- 構造は定期的に見直しつつ、チームは安定させましょう。
チームをアジャイルにするもの
- クロスファンクショナル： チームは、バックログアイテムを完成した成果に変えるのに必要なすべてのスキルを持っています。
- 小規模で安定している： 通常は約10人以下です。2020年版スクラムガイドでは、スクラムチームは通常10人以下とされています。
- 自己管理型： チームが自分たちの仕事の進め方を決めます。
- 長期的に存続する： チームは多くのプロジェクトにわたって一緒に働き続け、学び改善していきます。
- 一度に1つのゴールやプロダクトに集中する。
参考： アジャイルチームとは で基本を確認できます。
一般的なアジャイルのチーム構造
| 構造 | 仕組み | 強み | 注意点 |
|---|---|---|---|
| フィーチャーチーム | すべてのレイヤーにわたる完全な顧客向け機能を担当する | エンドツーエンドの迅速なデリバリー、少ない引き継ぎ | 幅広いスキルが必要。共有コードには優れたプラクティスが必要 |
| コンポーネントチーム | 決済や検索など、システムの一部を担当する | 深い専門性、一貫したアーキテクチャ | フィーチャーに複数のチームが必要で、依存関係が増える |
| ジェネラリストチーム | メンバーが多くの種類のタスクに対応できる | 柔軟でボトルネックを避けられる | 深い専門性に欠けることがある |
| スペシャリストチーム | メンバーがそれぞれ異なるスキルを持つ | 各分野で高い品質 | 1つのスキルに負荷が集中するとボトルネックになる |
| ハイブリッド（T型）チーム | メンバーが1つの深いスキルと、より幅広い副次的なスキルを持つ | 深さと柔軟性のバランスを取る | 構築に時間と支援が必要 |
| プラットフォームチーム | 共有のツールとサービスを他のチームに提供する | 重複した労力を減らす | 他のチームを顧客として扱う必要がある |
アジャイルチームの役割
| 役割 | 焦点 |
|---|---|
| プロダクトオーナー | 価値を最大化する。バックログを所有し順序付ける。参考： スクラムのプロダクトオーナー |
| スクラムマスターまたはアジャイルコーチ | チームの有効性と障害の除去。参考： スクラムマスターの役割 |
| 開発者またはチームメンバー | 作業を構築、テスト、提供する。エンジニア、デザイナー、アナリスト、テスター、ライターなどを含むことがある |
| ステークホルダー | 特にレビューでインプットとフィードバックを提供する |
| アジャイルのプロジェクトマネージャー（一部の組織） | チーム間の調整、予算、報告。参考： アジャイル・プロジェクトマネージャー |
チーム構造の設計方法
- バリューストリームから始める： 依頼から顧客に届くまでの作業の流れを可視化します。参考： バリューストリームマッピング.
- チームの種類を選ぶ： カスタマージャーニーやプロダクトに沿ったフィーチャーチームを優先し、専門性や規模が求める場合にのみコンポーネントチームやプラットフォームチームを追加します。
- チームの規模を決める： 5～9人程度を目安にし、それより大きなグループは分割します。
- スキルの不足を補う： 引き継ぎなしで作業を完了するのに必要なスキルを洗い出し、採用、研修、ペアリングで不足を補います。
- 依存関係を最小限にする： あるチームが別のチームを常に待っているなら、境界を調整します。
- チーム間の調整方法を定める： 次のようなプラクティスを使います： スクラム・オブ・スクラム や共同の計画。
- 定期的に見直す： 数か月ごとにフロー、依存関係、士気を確認し、適応させます。
例：コンポーネントチームからフィーチャーチームへ
あるオンライン小売業者には、各6人の4つのコンポーネントチーム（Webフロントエンド、モバイル、チェックアウトサービス、データベース）がありました。典型的な機能には4チームすべてが必要なため、アイテムは待ち行列で滞り、簡単な変更でも6週間かかっていました。同社はカスタマージャーニー（閲覧、購入、アカウント）に沿った3つのフィーチャーチームに再編し、それぞれにフロントエンド、モバイル、バックエンド、テストのスキルを持たせ、さらに共有インフラのための6人の小さなプラットフォームチームを1つ置きました。引き継ぎが減ったことで、現在ではほとんどの機能が1つのチームで1～2スプリント以内に完了しています。
大規模での構造
- チームのチーム： 1つのプロダクトに取り組む複数のチームがバックログを共有して調整します。参考： 大規模スクラム（LeSS）.
- アジャイルリリーストレイン： SAFeでは、通常5～12のチームが一緒に計画し提供します。参考： アジャイルリリーストレイン.
- スクワッド、トライブ、チャプター、ギルド： Spotifyによって広まったモデルです。参考： スクワッド、トライブ、チャプター、ギルド.
このトピックの無料テンプレート
よくある質問
最適なアジャイルのチーム構造は何ですか？
唯一の最適な構造はありません。ほとんどのプロダクト開発にはフィーチャーチームが適しており、専門的な深さや共有サービスが必要な場合にはプラットフォームチームやコンポーネントチームを置きます。
アジャイルのチームの規模はどのくらいにすべきですか？
小規模で、通常は約10人以下です。それより大きなグループは、通常は複数のチームに分割すべきです。
クロスファンクショナルなアジャイルのチーム構造とは？
他のチームに頼らずに完成した成果を提供するのに必要なすべてのスキルを持つチーム。
アジャイルのチーム構造として、フィーチャーチームとコンポーネントチームのどちらが優れていますか？
フィーチャーチームはシステム全体にわたって完全な顧客向け機能を提供し、コンポーネントチームはシステムの一部を担当します。
アジャイルのチーム構造におけるT型のチームメンバーとは？
1つの分野に深い専門性を持ち、他のいくつかの分野にも実務的な知識を持つ人で、チームが作業を分担しやすくなります。
アジャイルのチーム構造にプロジェクトマネージャーは必要ですか？
スクラムの中では不要です。スクラムにはプロジェクトマネージャーの役割がありません。チーム間の調整のためにプロジェクトマネージャーを置く組織もあります。参考： アジャイル・プロジェクトマネージャー.
アジャイルのチーム構造では誰がリードしますか？
アジャイルチームは自己管理型です。プロダクトオーナーが優先順位を決め、スクラムマスターが有効性を支え、チームが仕事の進め方を決めます。
アジャイルのチーム構造におけるプラットフォームチームとは？
他のチームがより速く提供できるよう、共有のツールやサービスを構築・運用するチームです。
アジャイルのチームは同じ場所に集まるべきですか？
同じ場所にいるとコミュニケーションには有利ですが、優れたツールと合意した勤務時間があれば、リモートやハイブリッドでもうまく機能するチームは多くあります。
アジャイルのチーム構造はどのくらいの頻度で変えるべきですか？
チームは安定していることで力を発揮するため、頻繁な組み替えは避けましょう。数か月ごとに構造を見直し、依存関係やゴールが変わったときに変更します。
アジャイルのチーム構造では複数のチームをどう調整しますか？
共有のバックログ、合同の計画、定期的なチーム横断のミーティング、スケーリングフレームワークを通じて調整します。参考： スケールド・アジャイル・フレームワーク.