SRE兼スクラムマスターのブログ

チーム開発が好きなエンジニアブログです。検証した技術やチームの取り組みを書いていきます。

「ONE TEAM」を目指したが、コラボレーションは簡単じゃない

はじめに

2019年にラグビーワールドカップで「ONE TEAM」という言葉が流行り、ラグビーだけでなく仕事場でも「ONE TEAM」という言葉を使ってチーム作りしている現場もあると思います。 私の現場も「ONE TEAM」というキーワードが出てきてみんな賛同して目指すことになりました。しかし、いざ目指してみるとチーム間でコラボレーションするのがすごく大変だったので解消するためにやったことを残しておきます。

「ONE TEAM」を目指してどうなっていたのか?

「ONE TEAM」を目指そうと話が出たときは、プロジェクト全員が乗り気でかつ自分たちなら達成できると考えていたと思います。しかし、「ONE TEAM」というのはノープランで目指すべきものではないです。

ここではノープランで「ONE TEAM」を目指した結果

  • チーム間で上下関係ができた
  • サイロ化した

の2つの事象が発生しました。

チーム間で上下関係ができた

私たちのプロジェクトはクロスファンクショナルなチームもいれば専門性の高いチームも存在しています。 そんな中、スクラム開発しているチームのスプリントレビュー時に、専門性の高いチームのメンバーが参加すると、 ときどきちゃぶ台返しのような事態も発生します。

サイロ化した

「チーム間で上下関係ができた」ことも原因の1つになると思うのですが、こうして各チームでのサイロ化が急速に進みました。 このころになると、「設計時に困ったら呼んでください」といっても、あまり呼ばれなくなったりとチーム間の交流は少なくなりました。

なぜ「ONE TEAM」にならないのか?

「上下関係ができる」、「サイロ化が進む」で「ONE TEAM」を目指す前は良いペースで進んでいたプロジェクトが徐々に失速しました。 そこでなぜ失敗したかをふりかえっていきます。

なぜ上下関係ができたか

まずはなぜ上下関係ができたかを考えてみます。 個人的には上下関係ができたのはスプリントレビュー時のちゃぶ台返しや「設計時に困ったら呼んでください」などの「困ったら呼んでください」といった発言なのかなぁっと思います。ちゃぶ台を返した時点で建設的なレビュー者ではなく、チームにとってはちゃぶ台を返したメンバーがフェーズゲート(承認者)のように見えていたと思います。そこで、なぜちゃぶ台を返すかをヒアリングしたところ、チームによって達成すべきミッションが異なるからということが分かりました。達成するミッションが異なるので各チームでプロダクトに対する優先順位も異なるのでリリースできる・できないの判断基準が異なったのです。

これ以外にも細かい部分では「困ったら呼んでください」という声かけも「呼んでください」という表現は呼ぶ側と呼ばれる側で心理的に対等にならないとも感じました。

なぜサイロ化したのか

サイロ化したのは「上下関係ができた」ことも原因の1つだと考えていますが、チーム間でコラボレーションする方法を知らなかったことが根本原因だと感じています。プロジェクトでチームが増えてこれまでと同じやり方でうまくいかないのは明白なのに、コラボレーションする仕組みを作ることをしなかったのが問題だと思います。

取り組んだこと

なぜ失敗したかをふりかえり

  • ミッションの違いによる問題
  • 上下関係を感じてしまう心理的な問題

の2つの観点で問題があると考え、これらの問題を解決するための仕組みを作りました。

ミッションの違いによる問題を解決するために

ちゃぶ台返しが良く発生していたのはSREチームとスクラムチームでした。 そこでシステムのSLO(Service-level objective)*1を策定しました。 SLOという明確な基準値を設けることにより各チーム間で基準値内の場合はお互いの自由を許容するというルールにしました。

上下関係を感じてしまう心理的な問題

ミッションの問題と違って明確な数値を設定できるものではないのでコミュニケーションの機会を増やすようにしました。 具体的には

  • 各チームのタスクボードを共有する時間を作る
  • 合同でlearning sessionを実施する
  • 心理的安全性を実現するためにスキルを習得する

の3つに取り組んでいます。

まとめ

ノープランやスキルない「ONE TEAM」は実現しない ミッションが異なるチームでコラボレーションするには?

  • 共通言語を作る
    • 自分たちの場合はSLOを作成する

心理的な問題を解消するには?

  • スキルを身につける
  • コミュニケーションの機会を増やす
    • 合同でlearning sessionを実施する
    • 各チームのタスクボードを共有する時間を作る

すぐ取り組めるものから、エンジニアリングが必要なものもありますが、私たちのプロジェクトは仕組みを導入してから以前よりも雰囲気が良くなりました。 チーム間でギクシャクしているなと感じることがあったら、ぜひ立ち止まってふりかえってみてください。その時のアクションプランの参考になれば幸いです。

参考

スキルやサイロ化について学習したときの書籍の一部です。 ここでは紹介しませんが、ファシリテーション系の書籍で得た知識も大変役に立ちました。SLOについてはもともと知っており、SRE本に詳しく書かれています。

amzn.to

amzn.to

*1:サービルレベル目標(service level objective)であり、SLIで計測されるサービスレベルのターゲット値、あるいはターゲットの範囲を指します。