30人が参加するプロジェクトで桁違いのパフォーマンスを発揮するためのチームデザイン - Cybozu Inside Out

こんにちは。シニアスクラムマスター（初めて名乗った！）の天野 @ama_ch です。開発本部に所属するアジャイルコーチとして、組織内を横断的に支援しています。最近は、 kintone フロントエンドリアーキテクチャ（フロリア）プロジェクトの支援に注力しています。

フロリアプロジェクトの概要はこちらの記事をご覧ください。

blog.cybozu.io

現在、フロリアには約30人のメンバーが参加して日々活動しています。チームの規模が大きくなると、コミュニケーションが難しくなり、効果的なチームワークを発揮するのがどんどん難しくなっていきます。フロリアでは、昨年後半頃からだいぶチームの規模が膨らんできたため、今年からチームを再編し4チーム体制に切り替えました。

今回は、フロリアが数十人規模でもチームワークを発揮するために、チームの設計や運用で意識しているポイントを紹介します。

目指している状態

最初に、目指しているチームの姿を紹介します。

フロリアプロジェクトでは、チームの設計段階から深く関わらせてもらうことで、圧倒的に高いパフォーマンスレベルのチームを作ることを目標にしています。

そのお気持ちを Slack に書いたところ、ピン留めされて定期的に参照されるようになり、今では「いつもの」と呼ばれています。

フロリアは根本的にパフォーマンスの桁が違うレベルのチームにしたいと思っています。今までのチーム比で5〜10倍とかそういうレベルです。 — 圧倒的なパフォーマンスのチームにしたいお気持ち表明

一般的に、プロジェクトの人数が増えるとパフォーマンスは低下します。フロリアでは、多人数による非効率を抑え、高いパフォーマンスとメンバーの満足感を両立できるチームを目指しています。

現在のチーム体制

フロリアプロジェクト全体で4チームが活動しています。チームごとにゴールを持ち、ゴール達成のために必要な職能メンバーが含まれるようクロスファンクショナルチームにしています。

職能はエンジニア、品質保証、デザイナ、セキュリティ、ライターなど様々ですが、全チームに全職能メンバーがいる訳ではなく、チームごとにゴール達成のために必要な職能メンバーを揃えています。

それぞれのチームが独立したスクラムチームになっており、1チームの人数は5〜9人程度です。安定した小さいチームを基本単位にすることを重視しています。全体は Scrum@Scale をベースにしたプロセスで統合することで、プロジェクト全体で方向性を揃えています。

現在のチームについて、役割、作成物、イベントの観点から詳細を紹介します。

チームが自律的に活動するための役割分担

各チームにプロダクトオーナー（PO）とスクラムマスター（SM）がいます。

フロリアでは、それぞれのチームが独立してオーナーシップを持って自律的に活動することを重視しているため、チームの方向性を決める PO と、チームワークを効果的に発揮できるよう支援する SM という2つの役割は、自律的なチームには必須の機能だと考えました。

基本的にはどのメンバーも PO/SM 経験はありませんでしたが、希望を聞いた上で挑戦してもらっています。多くのメンバーはエンジニアと PO/SM を兼務しています。役割をアサインするだけでは PO/SM として効果的に振る舞うのは難しいため、継続的な支援も必要です。支援は自分が担当し、後述する全体イベントや個別現場で適宜支援しています。

各チームの役割のほかに、プロジェクト全体でチーフプロダクトオーナー（CPO）をプロジェクトリーダーである @koba04 が担当しています。自分はスクラムオブスクラムマスター（SoSM）として、全体のプロセスを見ています。

ゴールを達成するためのチームの作成物

プロダクトバックログ、スプリントバックログはそれぞれのチームで独自に作成・運用しています。

チームの独立性を高く保つため、バックログ管理ツール等もあえて統一せず、各チームで自由に選定しています。特定のチームに依存しない仕事を管理するために、全チーム共有のバックログ（Shared Backlog）もあります。

作成物に対するコミットメント（確約）として、プロダクトゴール（1〜3ヶ月の目標）とスプリントゴール（1週間の目標）がありますが、これらのゴールも各チームで設定しています。ただし、各チームで自由にゴールを設定するといっても、フロリアは複数チームから構成されるプロジェクトなので、プロジェクト全体で方向性は揃えたいです。そこで、 CPO がプロジェクト全体のプロダクトゴールを設定し、それを踏まえて各チームの PO がゴールを設定しています。

ツリー構造で表現すると、下記のようなゴール構造になります。

プロジェクト全体のプロダクトゴール
- チーム A のプロダクトゴール
  - チーム A のスプリントゴール
- チーム B のプロダクトゴール
  - チーム B のスプリントゴール
- チーム C のプロダクトゴール
  - チーム C のスプリントゴール
- チーム D のプロダクトゴール
  - チーム D のスプリントゴール

現在取り組んでいる仕事に対して、「なぜこれをやっているんだっけ？」と疑問に思ったときに、上位に辿っていけるようにしています。上位のゴールがあることで優先順位が明確になり、上位のゴール達成のために他のチームを助けるといったコラボレーションも発生します。

チームを横断したイベントの設計と運用

フロリア全体では、下記のようなチーム横断の全体イベントを毎週運用しています。全体イベントは SoSM の自分が進行を担当しています。

イベント名	目的	参加者
スケールドリファインメント	各チームの方向性を揃え、優先順位を検討	CPO ＋各チームの PO
スプリントレビュー	スプリント成果の検査と適応	全員
スケールドレトロスペクティブ	学びの共有とチーム横断の問題解決	SoSM ＋各チームの SM

全体イベントは他にも、スケールドデイリースクラムや全体でのプランニングなども最初はありましたが、運用しながら最低限必要なものを残し、今はこのような形になっています。

Scrum@Scale でいうところのプロダクトオーナーサイクルとスクラムマスターサイクルのイベントがそれぞれ残った形ですね。それぞれの場が、 PO と SM に対する最低限の支援提供の場として機能しています。

全員が参加するイベントはスプリントレビューのみとし、それ以外のイベントは効果的に議論できる人数を維持するために代表者制にしています。

上記の全体イベントの他に、各チームでスクラムイベントを実施しています。チームによって働き方が異なるため、イベントのタイミングは統一していません。各チームの SM が中心になり、それぞれで検討・実施しています。

チームを信頼して任せる

SoSM として、全体のプロセスに責任を負う一方で、各チームの個別の現場には極力口を挟まないようにしています。特に、バックログの管理方法やイベントの進め方といった、「スクラムの実装方法」は聞かれない限りお任せしています。

「こうするといいよ」とやり方を教えることもできますが、そうすると自分の知っているひとつの方法が「正解」になってしまい、その後の発展が難しくなってしまいます。チームの試行錯誤を見守ることで、自分が考えてもいなかった創意工夫に出会うことができます。チームを尊重し、信頼して任せることで、自分も日々新しいことを学ばせてもらっています。

極力チームに任せつつも、プロジェクト全体として効果的にチームワークが発揮できるよう、 SoSM として意識しているところもあります。

全体のプロセスがうまく回っているかどうかは、全体イベントでのやり取りの内容や、日々のチームのコミュニケーションや成果物を観察して回って確認しています。気になる事象を発見した時は、インペディメント（チームを妨げる障害）として管理します。インペディメントには優先順位をつけ、上位の問題を解決するためにチームの活動に参加させてもらうこともあります。