こんにちは、ウォンテッドリー VPoE室の髙橋です。

この記事は、Wantedly Advent Calendar 2023 の25日目の投稿です。前回の記事は​「高頻度で安全なリリースを支える「クラスタ」という抽象」でした。

はじめに

ウォンテッドリーに興味を持っていただいた方からよく聞かれる質問の一つに、

ウォンテッドリーは「Spotifyモデルと呼ばれる組織構造をアレンジして利用している」と聞きましたが、具体的にどのような組織構成なのでしょうか？

というものがあります。

ウォンテッドリーの組織構成については、以前に別の記事でご紹介しています。

こちらの記事でも説明されているように、外部の方には「ウォンテッドリーの組織構成は Spotify のモデルを参考にしている」と説明することが多いのですが、なぜそのような組織構造を採用しているのか、またSpotifyモデルとは何が違うのか、どうアレンジしているのか、についての説明については明確なものはありませんでした。

そこで本記事では、ウォンテッドリーの組織構造におけるSpotifyモデルの適用と、アレンジ観点からの取り組みついてご紹介いたします。

「Spotifyモデル」とは

我々が生きているこの時代は前例のない速度で技術革新が進んでおり、常に変化し続ける市場に迅速に適応する必要があります。ウォンテッドリーもその例外ではなく、柔軟かつ効率的にソフトウェア開発を進めるために、いわゆるアジャイル開発と呼ばれている開発手法を取り入れています。

Spotifyモデルとは、アジャイル開発を組織構造に組み込むためのアプローチとなります。

このモデルは、スウェーデンの音楽ストリーミングサービスを提供するSpotify社が提唱したもので、特に技術や製品開発の分野において、イノベーションと生産性の向上に効果を発揮するものです。

Spotifyモデルの組織構造

Spotifyモデルの特徴は、主に「Squad」「Tribe」「Chapter」および「Guild」という４つの構成要素にあります。

1. Squad: Squadは基本的に小規模な開発チームで、それぞれが特定の機能やプロジェクトに取り組みます。各Squadは自己組織化され、独立して意思決定を行います。

2. Tribe: 複数のSquadが関連する機能に取り組む場合、これらはTribeとして一緒にまとめられます。Tribeは、協力とコミュニケーションを促進し、Squad間のシナジーを生み出します。

3. Chapters: 同じ専門スキルを持つ人々が集まり、スキル開発や知識共有を行うためのグループです。Chapterは、Squadを横断して機能します。

4. Guild: Guildは、組織全体における共通の興味や専門分野を共有する社員の非公式なグループです。これにより、組織全体での知識共有と連携が促進されます。

下記はSpotifyモデルを説明する際に良く引用される図です。

画像引用：Scaling Agile @ Spotify

Spotifyモデルの目指すもの

Spotifyモデルの特徴は、チームを小さく保ち、その自律性を重んじていることにあります。チームは自己組織化（self-organizing）されており「ひとつの会社のように働く」ことを期待されています。

ここで重要なのは、Spotifyモデル自体はアジャイル開発そのもののフレームワークではないということです。たとえばSquadにおいては、スクラムやカンバン方式など、チームが自律的にフレームワークを採用することが可能であり、この自律性が非常に高い生産性・アウトプットに繋げられる、という考え方を持っています。

ウォンテッドリーがSpotifyモデルを採用する理由

アジャイル開発は、ソフトウェア開発において柔軟で効率的なアプローチを取る方法論です。アジャイル開発についての詳細な説明は割愛しますが、先ほど説明した通り、ここで取り上げているSpotifyモデルとはアジャイル開発の原則を組織構造に組み込んだものと言えます。

ウォンテッドリーでも、プロダクト開発にはアジャイル開発の手法を取り入れてます。さらに、ウォンテッドリーの価値観（VALUES）は、アジャイルの原則と照らし合わせた設計になっています。

アジャイルの４つの基本原則とウォンテッドリーの価値観は、下に示すように親和性が強いことが読み取れます。

「プロセスやツールよりも個人と対話を」⇒ One Team

アジャイルはチーム間のコラボレーションとコミュニケーションを奨励します。ウォンテッドリーの組織文化においては、これがチームワークと相互協力の精神を醸成し、効率的な作業環境を促進します。

「包括的なドキュメントよりも動くソフトウェアを」⇒ Code Wins Arguments

アジャイルは包括的なドキュメンテーションよりも、実際に機能するソフトウェアの提供を重視します。これは、顧客に迅速に価値を提供することを目的としています。

「契約交渉よりも顧客との協調を」⇒ User Obsession

アジャイル開発は顧客のフィードバックとニーズに焦点を当てます。このアプローチは、エンジニア組織文化においても顧客中心の思考を促進し、顧客満足度の向上に寄与します。

「計画に従うことよりも変化への対応を」⇒ Move Fast

アジャイルは変化に対する迅速な対応を重視します。これにより、エンジニア組織文化では柔軟性と適応性が強化され、市場の変化や顧客のニーズへの対応が迅速に行われます。

上記より、ウォンテッドリーがSpotifyモデルを採用する理由はウォンテッドリーの価値観を組織構造に組み込むためであると言えます。ウォンテッドリーが、迅速かつ効果的な方法で市場の要求に応え、持続的な成長を遂げるための組織構造、これが我々がSpotifyモデルを採用する理由です。

Spotifyモデルからのアレンジ部分

Spotifyモデルの最大の利点は柔軟性と適応性です。チームを迅速に動かし、イノベーションを促進するために、Squadは小規模で自己組織化され、開発で必要とされるスキルをが各Squadは持つことを前提としています。また自己組織によりメンバーは自分たちの仕事により大きな所有感を持つことができ、メンバーのモチベーション向上とエンゲージメントの獲得にも寄与します。

しかし、Spotifyモデルにおける様々な文書で言及されているように、Spotify自身もSpotifyモデルをそのまま利用し続けることはできなかったと言われています。Spotifyモデルにおける課題において、ウォンテッドリーではSpotifyモデルをアレンジすることでその対策を行っています。

Branchの設置

ウォンテッドリーには、各Chapterをまとめ上げるBranchという組織単位が存在します。Branch は職種で大きく分類し編成したチームで、複数のChapter が集まって編成されています。ウォンテッドリーは現在 Dev Branch、Biz Branch、Corp Branchの３つのBranchを設置しており、これらの職種単位をまとめることで、下記４つの観点からSpotifyモデルの潜在的な課題に対応しています。

専門性の強化

ウォンテッドリーではChapter単位では細分化されすぎる専門性を、Branch単位で構造化しています。このBranch単位で制度設計や育成の推進などを進めることで、より迅速で効率的な組織運営が可能です。

目標と責任の明確化

プロダクトにおける目標と責任はTribe / Squadが持ち、組織や仕組みにおける目標と責任をBranch / Chapter を持つように、明確にしています。これにより、各部門ごとの成果測定と評価が容易になり、効果的な目標達成戦略を策定できるようになっています。

リソース配分の最適化

リソース（人材、予算、時間など）の管理をChapter毎に行うのは現実的ではありません。BranchとしてChapterをまとめることで、これらリソースの配分をより効率的に行うことができます。例えば採用機能などはBranch毎にリソースを割り当てており、全体的な生産性の向上に繋がっています。

コミュニケーションの効率化

例えば、Squadにおけるリソース調整を行うとする場合、各ChapterのLeadにそれぞれエスカレーションする必要があり、非効率となります。これをBranch Leaderに直接エスカレーションすることでコミュニケーションの効率化を図り、より迅速な意思決定を行うことができます。

基盤Squadの分離

ウォンテッドリーの開発組織においては、ソフトウェア基盤の構築・改善、意思決定のための情報収集分析、組織開発などプロダクト開発をより推進するための 基盤 Squad を分離して設置しています。これは、全てのプロダクト開発に共通して影響する機能チーム（Infra Squad）や全てのSquadに対して共通的に支援する技術支援チーム（DX Squad）を ChapterではなくSquadとすることで、Squadの機能的な分断にとらわれず中長期的な投資や改善を可能とするためです。

Squad / Chapter横断でのマネージャーの配置

企業がスケールし、Squadが増えてくると、チーム間のコラボレーションのためのコミュニケーションパスは増大します。また組織の効率化のために基盤Squadを分離したとき、機能Squadと基盤Squadの間で依存関係が生まれます。これらの課題を解決するために、各Squad間のアライメントとコラボレーションのプロトコルの共通化のために、Squad / Chapterを横断的に・積極的に統制するマネージャーを配置して、チーム間のコラボレーションを効果的に行えるようにしています。これは、SpotifyモデルにおけるAlienceの設置をマネージャーの機能が代替しているとも言えます。

おわりに：組織の変化に対応し続ける

この記事では、ウォンテッドリーの組織構成についてSpotifyモデルの解説と合わせて整理しました。

Spotifyモデルはアジャイル開発の実践に対して優れた仕組みを提供しますが、その根底には、高品質かつユーザに価値のあるソフトウェアを迅速に提供するための組織文化が必要です。

ウォンテッドリーが大切にしているプロダクトに対する強いこだわりは、組織の変化によって揺らぐものではありません。この不変の価値観によって、私達は将来に起こり得る組織の変化にも柔軟に対応し、自ら組織を再設計し、進化させることができると確信しています。

ウォンテッドリーは引き続き「究極の適材適所により、シゴトでココロオドルひとをふやす」というミッションを実現し、社会に実装するための取り組みを進めていきます。

ウォンテッドリーの組織構造については他の記事も御覧ください

• Squad? Branch? 一見変わって見えるウォンテッドリーの組織構成をご紹介！
• Design System Guild を立ち上げました
• 開発チームの構造 - Wantedly Engineering Handbook
• SquadとOKR - 開発チームが無駄なく高い成果を出すために大事にしていること

参考資料

• アジャイルソフトウェア開発宣言
• アジャイル宣言の背後にある原則
• アジャイルソフトウェア開発宣言の読みとき方：独立行政法人 情報処理推進機構
• Spotify engineering culture (pert 1, part 2)
• Scaling Agile @ Spotify
• Spotify’s Failed #SquadGoals
• アジャイル拡張のためのSpotifyモデル | Atlassian
• 書籍：チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 （マシュー・スケルトン, マニュエル・パイス他）
• 書籍：ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方（Jonathan Rasmusson他）