こんにちは。シニアスクラムマスターの天野 @ama_ch です。
サイボウズの開発組織において、今後の成長を加速させるためには、組織の基本単位をスクラムチームのような自律的な小さなチームにしてスケールさせることが非常に大切だと考えています。サイボウズは比較的スクラムが普及している組織ではありますが、組織内のすべてのチームがスクラムを採用しているわけではありません。
フレームワークとしてスクラムを採用するかどうかはチームの自由です。しかし、健全なチーム環境を整えることはすべてのチームにとって重要です。チームやチームワークに関する情報は巷に多く存在しますが、我々のようにすでにある程度の規模で活動しているプロダクト開発組織で、チーム環境を整えるために実践的に使える情報がないことが悩みでした。
そこで、これまでのチームに関する学びと実践を踏まえ、サイボウズの開発組織の文脈において、スクラムを実践しているチームでもそうでないチームでも参考にすることができる「開発チーム作成ガイド」を作りました。こちらを本記事で一般公開します。
組織の枠を超え、健全なチームが増える一助になれば幸いです。
開発チーム作成ガイド
はじめに
レガシーなアーキテクチャからの脱却を図るため、サイボウズの開発組織では各所でチーム分割の議論が進んでいます。世間では、チームトポロジーやユニコーン企業のひみつ（Spotifyモデル）などが話題になり、チームを主体とした組織づくりが現代的なソフトウェア企業には必須になってきています。このようなアジリティの高い組織を作るには、まず機能する「チーム」を作る必要があります。機能するチームが組織の最小単位になります。
このドキュメントでは、機能するチームはどのようなものか、どうやって作るかの一例を基本の型として示し、開発組織のみなさんがパフォーマンスの高いチームを作れるようになることを目指します。
本ガイドでは、スクラムと同じ用語が登場しますが、スクラムチーム以外でも使えるものになっています。
3行まとめ
- 5-9人のクロスファンクショナル（職能横断）チームを作る
- チームの方向性を決める役割（プロダクトオーナー）とチームを健全に保つ役割（スクラムマスター）に責任を負う人を置く
- チーム内で意思決定と仕事が完結するよう必要な権限・リソースを確保する
もう少し詳しいまとめは 機能するチームの基本の型 へ
優れたチームの効果
優れたチームは、一般的に、タスクに関する成果（顧客満足、予算と納期の順守、高い品質etc）と人に関する成果（このチームで働き続けたい、成長できる、幸せだetc）を両立します。重要なのは、これらを両立させるという点です。
タスクに関する成果を重視しすぎると、燃え尽きや低いモチベーション、高い離職率などの問題が発生します。人に関する成果を重視しすぎると、仲良しのぬるま湯のようなチームになったり、顧客を無視して技術的な課題を探究してばかりのチームになってしまったりします。
優れたチームの効果（タスクの成果と人の成果の両立）は、チーム活動の結果として得られるものです。優れたチームの効果を得るまでには、入力（チームの設計）、プロセス（チームワーク）、出力（チームの効果）の過程が存在します。
入力（チームの設計）を整えないままプロセス（チームワーク）を頑張っても、得られる出力（チームの効果）は大きくなりません。素晴らしいチームワークを発揮し、優れたチームの効果を得るためには、チームワークの前提となるチームの設計を整える必要があります。
効果的に機能するチームの特徴
効果的に機能するチームは、仕事の進め方にいくつかの特徴があります。
- 自律的
- 外部からの指示によらず、チーム自身が目標を設定して活動する
- 自己管理（自己組織化）
- 目標達成のために行う日々の活動をメンバーが自分たちで考えて決める
- 相互依存性
- メンバー同士で互いに協力し密接にコミュニケーションを取りながら業務を遂行する
- 独立性
- チーム外への依存は最小限で、チーム内で意思決定から業務遂行まで完結できる
広義のチームと自己管理型チーム
一般的に、チームは「共通の目標を達成するために役割分担して協力する集団」のように説明されることが多いです。これを広義のチームと呼びます。この定義にもとづくと、サイボウズのような1,000人単位の組織もチームと言えます。
一方、前項のような特徴を持ち、高いチームワークとパフォーマンスを発揮するチームを実現するには、より多くの条件を考慮して設計する必要があります。広義のチームと区別できるようにするため、本ガイドで実現を目指すチームは自己管理型チーム (self-managing team) とします。
本ガイドで用いる「チーム」という単語は、すべて自己管理型チームを意味しています。
チームの設計で特に考慮すべき条件
いくつかの書籍・論文の情報とこれまでの現場での実践を踏まえ、サイボウズの開発組織でチームを設計する時に特に考慮すべき条件をまとめます。
人員規模
チームの人員規模は、5-9人が適正サイズです。
ダンバー数や2ピザルールなど関連する情報は多くありますが、7±2名という数字がよく使われます。5名が最適という研究結果もあります。概ね小さい方が日常のコミュニケーションや会議を円滑に進めやすく、チームワークを発揮しやすい傾向があります。5人未満でも機能しますが、3人未満になると、必要なスキルが不足する・相互作用が少なくなるなどの問題が発生しやすくなります。
チームを適正サイズに維持することは極めて重要です。チームの規模が10人以上になると、十分な意思疎通ができない・メンバー同士の信頼関係を構築できない・ミーティングが時間通りに終わらないなど、チーム運営上致命的な問題が発生します。
目的
チームが自律的に活動するためには、「このチームは何のために存在しているのか？」という存在目的（パーパス）が必要です。チームは目的を達成するために日々活動します。チームの目的は、チームにとってしかるべき人物が決める必要があります。チーム内のメンバーであることもあれば、チーム外の上司であることもあります。
例えば、フロリア（kintone フロントエンドリアーキテクチャプロジェクト）ではプロジェクトリーダーのkoba04さんから「フロントエンドに Autonomy をもたらす」という目指す姿（目的）が掲げられています。
責任と権限
チームの目的を実現するための活動がチームの業務になります。そのためにチームの職務を設計し、必要な権限・リソースを確保します。職務設計では、チームが提供する価値のエンドツーエンドのフロー全体を扱うようにします。フロー全体に責任と権限を持つことで、顧客からのフィードバックをもとにパフォーマンスを最適化できるようになり、チームのモチベーションも高まります。
例えばプロダクト開発チームであれば、次のような権限が必要です。
- プロダクトの方向性を決める
- 利用するツールを自分たちで選べる
- 任意のタイミングでデプロイできる
- インフラを自分たちで触れる
- ユーザーの声を直接聞くことができる
- 利用状況を分析できる
技術的な事情などによりすぐに実現するのは難しいものもありますが、原則としてチームの目的達成に必要なものはすべて自分たちで触れるようにします。
適切に業務を設計し権限を確保することで、チームはオーナーシップを発揮して責任を果たせるようになります。
スキルの多様性
チームの目的を達成するには、日々複雑な問題に向き合わなければいけません。チームは、複雑な問題を解決するためのスキルを統合する装置と見なすことができます。複雑な問題に対処できる多様な専門性を確保するために、複数の職能からなるクロスファンクショナルチームを形成します。
メンバーの多様性については、職能の他に属性・経験・心理的特徴といった観点からも捉えられますが、チームのパフォーマンスに影響があるのは、属性の多様性よりも職能の多様性であることが明らかになっています。
安定性
頻繁にコミュニケーションするチーム活動の性質上、チームとして安定した成果を出すためには、メンバーを安定させることが重要です。できる限りメンバーの入れ替えは避け、安定したチームはなるべく解散しないようにします。
ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ by アラン・ケリー 『Project Myopia』
チームの成果を安定させるためには、基本的には専任でチームの活動に参加することを推奨します。専任が難しい場合は、チームとして成果を出すために必要なレベルのコミットメントについて合意するようにします。兼務が増え、コミットメントのレベルが下がるほど、チームのパフォーマンスは下がりやすくなります。
また、誰がチームメンバーで誰がそうでないのかというチームの境界を明確にすることも重要です。境界が曖昧なチームは、意思決定が遅くなり、低いパフォーマンスにつながります。
役割分担
自律的なチームは、バラバラなメンバーの集合体というよりも、ひとつの生き物のように振る舞います。そのためには、チームとして一貫して意思決定できること・レジリエンス（困難な状況から回復する力）を備えることが必要です。
チームにこれらの機能を持たせるために、チームの方向性を決める役割（プロダクトオーナー）とチームを健全に保つ役割（スクラムマスター）を分担します。
プロダクトオーナーは、チームに一貫した方向性をもたらします。チームが目指すゴールを示し、活動の優先順位を判断し、成果を最大化するために何をするか(What)に責任を負います。
スクラムマスターは、チームを健全な状態に保ちます。コーチとしてチームを支え励まし、継続的な改善をサポートすることで、チームがより良い方法で仕事を進められるようにすること(How)に責任を負います。
プロダクトオーナー/スクラムマスターを置いただけでは効果的に振る舞うことは難しいため、継続的にコーチングを受けることも重要です。
機能するチームの基本の型
チーム設計時に考慮すべき条件を満たすチーム設計として、下記を基本型として提示します。
- 5-9名の複数職能からなるクロスファンクショナルチーム
- チームには存在する目的がある
- 目的達成のために必要なすべての業務を遂行する権限がある
- メンバーの入れ替えは最小限で安定している
- 誰がチームメンバーで誰がそうでないかの境界が明確
- チームの方向性を決める役割（プロダクトオーナー）とチームを健全に保つ役割（スクラムマスター）の責任者がいる
- メンバーは必要十分なレベルのコミットメントをしている
サイボウズの開発組織ではスクラムを採用しているチームが多いため、プロダクトオーナーとスクラムマスターの役割をチームの機能として抽象化し、スクラムでないチームにも適用可能にしています。プロダクトオーナーとスクラムマスターがそれぞれリーダーシップを発揮することで、優れたチームの効果を得やすくなることを意図しています。
これらの条件を整えれば必ずしも優れたチームになるわけではありませんが、成功する可能性を高めることはできます。条件を整えるためにできる手段を尽くすことが、リーダーやマネージャーの責任です。
整えた上でうまくいかない場合は、適切なコーチングを受けることで改善できるかも知れません。ぜひアジャイルコーチチームを頼ってください。
よくある質問
- 必ず条件を整えないとダメ？
条件を整えても成功を約束できるものではないので、必ずしも全部の条件を整える必要はありません。すべての条件が整っていなくてもうまく機能するチームもあり得ます。特に役割分担については、プロダクトオーナーとスクラムマスターで分担する以外の形はいくつも考えられます。ですが、その他の条件はほぼ満たしていないと、現実的に成功する可能性は著しく低くなると考えています。
- POってPMとは違うの？
本ガイドでのプロダクトオーナー（PO）は、チームの「外部からの指示によらず自律的に動く」という機能を実現するための役割です。プロダクトマネージャー（PM）は一般的に存在する職能で、製品の企画や仮説検証を行うプロダクトマネジメントの専門家になります。
チームの意思決定役としてのPOは、必ずしもプロダクトマネジメントの専門家である必要はないため、POはPMとは異なります。POはチームに1名必ず存在しますが、PMは1人で複数のチームを担当することもあります。
- POはプロダクトに1人では？
その通りです。プロダクトという単位で見た時に、1人の人物がPOとして振る舞うことは重要です。サイボウズの規模では、プロダクトチームは複数のチームの集合体になります。プロダクト全体の意思決定を担うPOがいるのと同時に、各チームが自律的に活動するためにチームPOが存在する、というフラクタルな意思決定構造にすることで、全体の方向性を揃えることと各チームの自律性を高めることを両立できます。
- チームに所属しないで働いてるんだけど？
組織はチームだけでできているわけではないので、必要に応じてそのような動き方もあり得ると思います。今の働き方に疑問がなければ、そのまま継続で問題ありません。もしやりづらさがあったり問題が顕在化しているようなら、チームに入ってチームの仕事にすることを検討してみても良いかも知れません。
- 単一職能のエキスパートチームはダメなの？
ダメではないです。チームの目的次第では、エキスパートチームが向いていることもあります。非常に専門性の高い問題を解決するチーム、他のチームを支援することが目的になるチームなどが例として挙げられます。チームトポロジーでいうところの、イネイブリングチームやコンプリケイテッド・サブシステムチームの多くはこれに該当します。
- 入社や異動で定期的にメンバーが変わります
チームを安定させるためにメンバーの頻繁な入れ替えは避けるべきですが、環境にあわせてチームも変化します。新しいメンバーの入社・キャリアの挑戦のための異動などの「自然な代謝」は問題ありません。むしろメンバーが何年もまったく変わらない方が、サイロ化・社会的手抜きなどの問題が起こりやすいです。
目安としては、半年に1名くらいの変化は自然な代謝の範囲と考えて良いと思います。毎月メンバーが入れ替わるレベルになると、明らかに安定性を欠いています。
- チームにPO/SMをやりたい人がいません
基本姿勢としては、強制してやってもらう役割ではないと考えています。
経験がなくてできるか不安ということであれば、ぜひお近くのスクラムマスター/アジャイルコーチにご相談ください。一緒に考えます。持ち回りでやってみて一度経験してみるのも良いかも知れません。
純粋にやりたくない・モチベーションが湧かない場合は、チームの成り立ちや置かれている状況に何か問題があるのかも知れません。力になれるか分かりませんが、一度お話を聞かせてください。
- 条件を整えられる気がしない
条件を整えるための相対的な難易度は、現場によってかなりばらつきがあります。新たに立ち上げるチームでは比較的簡単に整えられますが、これまで長く活動していたチームで後から条件を整えるのは非常に難しいです。無理せずできるところから整えていきましょう。
条件を整えるにはチームの形や仕事のやり方を大きく変える必要があるので、条件を整えることはリーダー・マネージャーの重要な責任だと考えています。実行はアジャイルコーチ・スクラムマスターも推進していくので、ぜひ気軽にご相談ください。できる限りの支援を尽くします。
