スクラムの拡張による組織づくりでチームのコミュニケーションについて考える

スクラムの拡張による組織づくりを読みました。

本書はスクラムをスケールさせるフレームワークの1つ Scrum@Scale について書かれた本です。Scrum@Scale を知りたい、導入したい人にはうってつけの本でしょう。また、Scrum@Scaleガイドで概要が分かっても導入方法や具体例が知りたい方にもおすすめです。そうでなくても、規模が大きい開発に携わっている方々にも役立つヒントが見つかると思います。

参考：Scrum@Scaleガイド - Scrum Inc. Japan #TeamworkMakesTheDreamWork

第1章：スクラムのスケーリングと大規模の難しさ
第2章：スクラムのおさらい
第3章：とあるチームのScrum@Scaleでの1スプリント
第4章：スクラムマスターサイクルとプロダクトオーナーサイクル
第5章：Scrum@Scaleを形成する12のコンポーネント
第6章：現場へどのように導入していくか
第7章：Scrum@Scaleで運用される現場 ──チャットサービスの開発現場の場合

Scrum@Scale は素直にスクラムをスケールしていると感じた

まず、スクラムは10人以下のチームで1人のプロダクトオーナー(PO)、1人のスクラムマスター(SM)、複数人の開発者で構成されています。Scrum@Scaleは複数のスクラムチームで構成されているのが特徴で、その複数のスクラムチームを同期させるためにチームを取りまとめるチーム(スクラムオブスクラム(SoS))が定義されています。

同じスクラムをスケールさせるLeSSは1人のPO、2～8の開発チーム、1～3の開発チームに対して1人のSMで開発します。POやSMの構成が異なりますね。

じゃあ、具体的にどうやって同期しているのか？どういうチーム分割が良いのか？具体例は何かないのか？ということが学べるのが本書です。

どうやってチームが連携し問題を解決するのかが具体的に分かる

「第3章：とあるチームのScrum@Scaleでの1スプリント」では具体的な例を使ってスケールドデイリースクラムのイベントでチームの問題が複数のチームと連携して解決していく様が学べます。チームをまとめるチーム(SoS)があり、SoSをまとめるチーム(SoSoS)があり、チームの問題はSoS→SoSoSへとエスカレーションされて解決されていきます。ストーリー形式で説明されているのでイメージしやすい。

本章で感じたことはスクラムやScrum@Scaleの価値基準「公開、勇気、集中、尊敬、確約」が軸だということです。本章の具体例では問題点を共有する「公開や勇気」が使われていますし、その問題を他のチームも自分の問題だと捉え、解決に向けて努力する「尊敬、確約」が使われていると感じました。

共通の関心事同士でコミュニケーションを設計する

今回一番参考になった個所は「第4章：スクラムマスターサイクルとプロダクトオーナーサイクル」の「SoSは共通の関心事どうしで作る」です。本章はScrum@Scaleの特徴について学べるのですが、スクラムチーム同士のチーム(SoSやSoSoS)の作り方について解説がありました。その中で以下の記述がありました。

チームどうしのコミュニケーションが必要なのは、同じ関心事を扱っている場合です。つまり、チームが複数あったとしても、それぞれのチームが扱っている関心事が異なるのであれば、それほど強い同期は必要ありません。

こちらは、現在考えていることとも関連していて一番響いた部分です。複数人で開発しているとミーティングは必要になってきます。情報を共有したり、課題を解決するために話し合うことが必要です。しかし、ミーティングばかりでは開発する時間が減っていき課題になります。「どういった単位でミーティングを設計すればいいのだろう？」という問いの答えは「関心事で区切る」ですね。

ミーティングの中でも取り扱い議題が多様である議題はAさんとBさんとよく話す、別の議題はAさんとCさんがよく話す、となったときミーティングは分割することができるかもですね。共有のための議題もあるので一概に話す/話さないでわけることはできませんが、検討するヒントになりそうです。

安心して読める

具体的な中身というより、全体的な構成なのですが、各章の先頭にこの章でわかることがまとめられているので、自分なりに準備して読み進めることができます。また、良いなぁーと思ったのは「第3章：とあるチームのScrum@Scaleでの1スプリント」です。本章はScrum@Scaleの解説の章よりも前に構成されています。そのため以下のような説明がされていました。