Scaling Agile @ Spotify を読み直す(その1)

https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf

1 comment | 0 points | by Jshiike 約4年前


Jshiike 約4年前 | ▲upvoteする | link

1年前、同僚のエンジニアがSpotifyのこのペーパーにまとめられている開発体制を絶賛してたのですが、当時はちょっとピンとこなかった記憶があります。流行の概念を取り込んだうえに、マトリックス組織を更に複雑にしたような構成が、実務上うまくワークするのかどうかよくわからなかったからです。その後の自分の経験をへて、腹おちする仕組みなのかどうかを確認するために、改めてこのペーパーをまとめ直してみます。



昨年このレポートが書かれた時点で、開発部隊は3都市30チームの構成


Squad


開発の基本的な組織単位。スクラムチームに似た概念で、ミニスタートアップのような位置づけ。同じ場所で仕事をし、開発、テストから本番アップまで担うスキルがある。


自立した組織として運営され、スクラムスプリントのスタイルをとるチーム、カンバンのスタイルをとるチームなど様々。


各Squadは「Androidクライアントの開発」「課金機能の導入」など長期のタスクをもつ。


MVP (minimum viable product) & KPIの分析によるA/Bテストなど、Lean Startupの進め方がが推奨されている。


10%の時間がHack Dayにあてられる


Squadは正式なリーダーはいないがProduct Ownerがいる。POはタスクの優先付けをするが、メンバがどう仕事をするかには関わらない。PO同士でsyncして会社としてのロードマップの確認をする。


Agile Coachは仕事の進め方の改善のために、振返り、スプリント計画ミーティング、1対1のかたちでSquadに関わる。


四半期ごとのレビューをする。


Tribe


Tribeは複数のSquadを開発の分野(音楽プレーヤー、バックエンドインフラなど)により束ねた組織で、Dunbar’s numberに基づき100名以内で構成される。同じTribeは同じ場所で業務にあたり、Tribeリードは各Squadの職場環境を担保する。hack-dayの披露、取り組んでいる案件のデモなどをする気軽な集まりを定期的にもつ。


Squad dependencies


Squadは自治権をもって仕事をすることが期待されてるが、実務上はSquad間の依存関係はでてします。各Squadの依存関係は洗い出され、業務をスローダウンさせる要因になってないか確認し、適宜優先順位の変更、組織変更、システムアーキテクトの変更などにより依存関係の解消をはかっている。複数のSquadの依存関係が続くプロジェクトの場合は、日次のミーティングで依存関係解消の進捗を確認する。


Opsチームは別途いるが、SquadからOpsに引継いで本番リリースするスタイルでなく、OpsはSquadのために本番アップの道筋をつけてあげる役割。コードのリリース作業自体はSquadがやる。作業プロセスの詳細なドキュメント化ではなく、face-to-faceの共同作業で進める。




Scaling Agile @ Spotify を読み直す(その2)



#spotify #人事 #組織 #開発スタイル

Back