Spotifyモデルをちゃんと読んでみた (Scaling Agile @ Spotify)
今まで本などで読んだ気になっていたSpotifyモデルをちゃんと読んでみた。
すごいことが書いてあった！
なんでも原典は読んだほうがいいと改めて実感。
原文はこちら。PDFなのでサムネイルが出てきません。
和訳はこちらで参照できます。(2022/1/31 リンク切れによりリンク修正)
Spotifyモデル
有名なのはこの図。リンク先PDFより。
この図についてはよく大規模アジャイルの教科書的に使われます。解説があちらこちらにあると思いますので割愛。Scaled Agile (SAFe) も大きくこれを参考にしています。
これもすごいですが、もっとすごいのはアーキテクトの立ち位置と役割。
ずっと気になってた個人的課題
スクラムでは「フィーチャーチームがいい」「開発からリリースまで全ての機能が一つのチームに存在する」と言われていましたが、それってアーキテクトの役割ってどうなの? と思ってました。
過去非常に小さなチームで実装と技術的負債の最小化とセキュリティの担保と実装担当およびアーキテクチャ担当の属人化対策と全て自分でやっていた時のことです。正直無理だと思いました。
実装のことを考えると顧客の要望を最大限実装してあげたいし、でも実装のために使用する技術は新しいチームメンバーを手配したときに育成可能な範囲で留めておきたいし、セキュリティは担保したいし、となると結局何も決まりません。
どうしていたかというと、実装のことを考える日と潜在的リスクを考える日と、出した考察をまとめて決断する日に分けてました。
悩む件があったときに3日間かかるので、正直時間がかかる。これってどうしたらいいんだろう?
アーキテクトの役割
というところで以前から既存のフレームワークいろいろ調べていたんですが、なかなかヒントが見つかりませんでした。
レガシー開発のフォーメーションは正直納得感があります。海外のチームとのやり取りの方が国内の開発チームのやりとりより多かったのですが、大雑把に
- ビジネスアナリスト: 要件の収集と定義
- アーキテクト: 技術的リスクの担当 (セキュリティや技術的負債対策など)
- プログラマー: コーディング
これは納得感がある。
日本のプロジェクトチームだとアーキテクトとプロジェクトマネージャー、あるいはアーキテクトとプロジェクトリードが一緒になっていたりする。これは人により、兼任している役割のどっちかの色合いが強かったり、全部能力的にはできるけれども役割が多すぎて時間をとっていただくのに一週間待ちとかになったりする。
Large Scale Agile (LeSS) や創発的設計もとてもいいのですが、いまいちピンとこない。
それにどれもこれもエンタープライズアーキテクトとの同期はどうしたらいいんでしょう。
という中で納得感が一番あったのはScaled Agile (SAFe) だったんです。
これはさすがに100人を超えるようなリリーストレインもサポートするようなフレームワークだけあって、アーキテクトが役割としておいてありますし、プラクティスが定着していないことを検知して是正する仕組みもあります。
Spotify モデルのチームとアーキテクト
SpotifyモデルではSquadが開発チームの単位で、スクラムを使っていればスクラムチームです。このSquadは、例えば支払いシステムをつくるなどの長期目標をそれぞれ持っています。
Squadはフィーチャーチームであるため、どのシステムやサブシステムに対しても開発をします。
Tribeは近しい領域のSquadが集まったグループ。人の育成はこのTribeのなかで同じ役割を持っている人たちで会社組織的なマネージャーがいて、このマネージャーが担当します。
このSquadやTribeのグルーピングとは関係なく、システムオーナーという役割があり、担当システムの技術的負債などにはこのシステムオーナーが責任を持ちます。この方は通常はSquadのメンバーなど、開発チームとしての通常業務がありますが、どこかのSquadが機能を追加したいと思い、対象のシステムへの実装に不安があるときはこのシステムオーナーが相談に乗ります。
またシステムオーナーは通常の業務の合間に一定期間に一度「システムオーナーの日」を持っており、技術的負債対応やスケーラビリティやリリースプロセスなどシステム固有の検討や作業ができる日を確保しています。
その他に全体のアーキテクチャにまつわるチーフアーキテクトがおり、システムをまたがったアーキテクチャ全体に責任を持ちます。例えば新しいシステムを作るかどうかなど。
Spotify モデルは上級者編に見える
非常によく練られたモデルですが、真似ようとしてうまくいかないことも多いそうです。
このモデルをそのまま組織に当てはめて、「明日からできるでしょ」と言ってもできないはずです。そもそもこのモデル個々がプロダクトや会社のビジネスに対して最適な選択ができるような知見を持っており、チームやそれぞれの役割がお互いをエキスパートとして信頼しているという前提で成り立っていると思うのですよね。
したがってこのモデルに移行するなら移行プロセスをどう設計するかはきちんと考えないといけなさそうです。
ここを理想の地と考えて、最初のスタート地点や組織設計の考え方、設計パターンとアンチパターンなどは Team Topology という本がとてもわかりやすい。読み終わったら別途まとめます。
ちなみにSpotifyモデルはアジャイル開発のフレームワークではない
Spotifyはアジャイルチームを複数に束ねてスケールするためのフレームワークですが、アジャイル開発そのもののフレームワークではありません。以下Squadの説明より。
They are a self-organizing team and decide their own way of working – some use Scrum sprints,some use Kanban, some use a mix of these approaches.
とあるように、アジャイル開発のフレームワークはSquadで選定します。ですのでSpotifyモデルはそれらを取りまとめるためのフレームワークですね。したがってSpotifyモデルを採用するときはきちんと開発のフレームワークが定着するかどうかを観測することと、Spotifyモデルが定着するかどうかの観測が必要です。
この記事が気に入ったらサポートをしてみませんか？