Spotify Engineering Cultureの整理 ver.4 -Communication between squads-
アジャイルコーチであるHenrik Knibergさんの解説をyoutubeにしたSpotify Engineering Culture (by Henrik Kniberg)に感銘を受けて、自分の中での整理も込めて、トピック毎にまとめてみようと思います。
第4弾の今回は、SpotifyのSquads間のコミュニケーションについてです。
“Spotifyはどんな感じなの？”という質問に対しては、“（所属する）Squadによるよ！”というのがほとんどの回答のようです。基準はほとんどなく、前回の記事で紹介したAlignment and Autonomyの文化に基づいて、各SquadがSquadsがスクラム開発していたり、していなかったりとそれぞれで決めているようです。
つまり、標準化（Standardization）よりも相互交流(Cross-pollination)に重きを置いていることを示します。どのツールを利用するかもSquadで判断しますし、他のSquadとコミュニケーションが必要であれば、情報交換を行ない、こういったコミュニケーションがデファクト・スタンダードになっているようです。こういった非公式のコミュニケーションが、組織の一貫性と柔軟性のバランスを取っています。
システムのアーキテクチャーは100以上のコンポーネントに分かれており、独立して開発やデプロイが行われています。全てのコンポーネントはそれぞれが、プレイリスト管理や検索、モニタリングなど一つのニーズ実現に絞られています。さらに、それぞれのコンポーネントは一つのSquadに担当され、一つのSquadが複数のコンポーネントをカバーしております。
また、SpotifyではInternal Open-source modelを採用しております。そのため、各Squadは各コンポーネントのソースコードを「所有」するのではなく、「共有」するようなイメージになります。例えば、下図ではコンポーネントBはSquad2の担当です。Squad1がBに変更を加えたい時は、Squad2に依頼します。しかし、Squad2にその時間がなかったり、優先順位が低く対応できない時は、Squad1自らがコンポーネントBの修正を加え、Squad2にレビューしてもらいます。ここで大事なことは、待つ必要はないということで、「誰でもコードを触ってよく、コードレビューをしてもらう」ことです。これはコード品質の改善になりますし、さらに各知識の浸透に繋がり、開発者間の摩擦も減ります。例えば、デザインガイドラインやコード基準などです。
次回は、Spotifyでの動機付けについての理解を深めていきます。
Spotify Engineering Cultureについての目次になります。目次を参考に必要なところを探すのに役立てればと思います。
ver.1 「Agile > Scrum」
ver.2 「Autonomous Squads」
ver.3 「Alignment and Autonomy」
ver.4 「Communication between squads」
ver.5「Motivate employees」
