新着Pick
968Picks
Pick に失敗しました

人気 Picker
このMatrix型のSpotify Modelは機能させることがとても難しかったというSpotify内部の人の話もあるので、合わせて読みたいですね。

https://www.jeremiahlee.com/posts/failed-squad-goals/

色んな派生の組織モデルはありますが、競争環境がデジタル化し、激化する中、「顧客起点で変化にスピーディに対応する」アジャイル型組織の重要性が増すのは間違いない大きな流れだと思います。
スピーディーな開発手法として定着した感のある「アジャイル開発」。しかし組織が大きくなっていくと、アジャイルの良さを活かすのは難しくなります。Spotifyはそうしたトレードオフを乗り越え、独自の開発チームを組成していることが本書では示されています。新しい物を生み出せるチームとは?に関するヒントがあふれています。
アジャイルを単にスピードで捉えるのではない、ということがよくわかりました。

Squad という小単位で、状況に合わせて迅速に対応する。それがアジャイルの本質ですね。

Rescue Squad をイメージするとわかりやすい。事故現場や火事場は状況がさまざまです。予測がつかない状況に合わせて最適な戦略を立てて迅速に行動し、事態を収束させる。

このアクションがユニコーンのDNAになっているのでしょう。
『組織の規模が大きくなっても、スタートアップのようにプロダクト開発をし続けるにはどうすればいいのか』

これは永遠の問い。事業(営業)と開発が敵対関係にならないよう、同じ目標に向かって走れるように事業部制/子会社毎をとってきたけれど、その先の姿として参考になる。
アジャイルが導入されて結構な月日が経ちますが、イマイチ成果があがりません。記事にある通り、開発手法の習得よりも組織の在り方をアジャイルにフィットさせることが重要。
考えると当然で、年度計画はプロダクトベースで予算積み上げするので、他がプロジェクト完結型で一部アジャイルでは意味が薄い。
最近になってサブスク型にシフトし、KPIがARRで評価されるようになってからようやくアジャイルの本領が発揮され始めた気がします。
当たり前と言えば当たり前ですが
スクワッド!
スクラムという考え方が出てきたと思ったら、スクワッド・・・

素人には違いがよく分かりません。

私が直観的に感じるのは、各チームが独立して機能するように進めるためには、ウォーターフォール以上にシステムの構造、アーキテクチャー設計と言っていいのではないかと思うが・・・、を確実にできるかどうかに成功がかかっているような気がします。しかし、今一番不足しているのが、そのような人材ではないだろうか。アーキテクチャー設計のレベルが低いままアジャイルで開発するほど恐ろしいものはないと感じるのですが・・・
マトリックス型組織を前提としたSquad構造は弊社も採用してますが、トライブという名前のニュアンスがあまり好きではないので最近別の名前に決めました。
後は開発だけじゃなくてマーケティングやオペレーションなど、他のファンクションもSquadにアサインしてます。その方がそのチームで決めれることが増えるので。

秘密というか合理的に考えていくとこういう形になるという話という気がしてます。
疎結合が開発スピードと運用の容易性につながると言われ20年以上。できないなら組織を変えるとそれがアーキテクチャに反映する、とも読める「ソフトウェアの構造として、アプリケーションのさまざまな部分を独立したパーツへと分解できれば、担当するスクワッドが並行して作業できるようになります」
凄い面白い。

『経営陣に与えられるのは、タスクや予算ではなく、ミッションと仕事をやり遂げるのに必要な人員。そこから何をどう開発し、どんな課題を解決するかは、スクワッドそれぞれが決めなければなりません。』
この通りやれるかは別だし、完璧に同じにする必要はないが、とても参考になる。
またチームが"ギルド"で動くという点も、柔軟であり興味深い。
アジャイルの先というより、エンジニア組織のひとつの形なイメージです。
プロダクトの性質によって必ずしもスクワッドが良いとは限らないでしょう。
ただ知らずに選ばないのと知って選ばないのは全く違うので、本書を読んで理解を深めてみます。
この連載について
まるで預言者(プロフェット)のように、新しい時代のうねりをいち早く紹介するNewsPicksのインタビュー集。本質を見抜く視点を毎週つむいでゆくことで、ちょっと先の未来を覗こう。
Premiumを無料で体験
登録・ログイン