チームの自律性を重んじるだけでは組織がうまく回らない / 「Spotify’s Failed #SquadGoals」を読み解く

「Spotifyは "Spotifyモデル" を使っていないし、あなたも使うべきではない」という一文からはじまる文書「Spotify’s Failed #SquadGoals」が公開されたのは、2020年4月だ。Spotifyモデルを紹介する書籍『ユニコーン企業のひみつ』の日本語版発売が2021年4月。そこから1年も前の出来事である。

今となっては古い話題ではあるが、Spotifyモデルが失敗したとされる原因について改めて掘り下げようと思い、「Failed #SquadGoals」をあらためて読み直してみた。その内容を本稿に整理する。

もちろん、Spotifyモデルを批判する意図は微塵もなく、失敗したと断定する気もない。純粋に、当該文書に記された失敗理由の数々が、多くの組織にとっても考慮すべき示唆を含んでいると感じただけだ。言い換えれば、一般化できる知見が豊富に含まれているのではないか、ということである。

だからこそ、ここから学べることは大いにある。特に、大規模アジャイルでソフトウェアプロダクトを開発する組織を設計する際の洞察を養ううえで役立つだろう。

なお、私自身はSpotifyモデルを試した経験はない。知識として知っているだけだ。文書に書かれていることの真偽を確認したわけでもない。その後の最新情報も追ってはいない。実際、Spotify組織は、その後もどんどん変化していったと言う。きっと、本当に問題を抱えていたとしても、解決していったのだろう。

参考にした主な文献

本稿で主に参考にした文献は次のとおりだ。私が有するSpotifyモデルに関する知識はこれらがすべてと言ってよい。

Spotify’s Failed #SquadGoals

www.jeremiahlee.com

Spotifyモデルの失敗についてまとめたドキュメント。Jeremiah Leeによって書かれ、2020年4月に公開された。

Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds

（PDF）https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Spotifyモデルを解説したホワイトペーパー。Henrik KnibergとAnders Ivarssonによって書かれ、2012年10月に公開された。

ユニコーン企業のひみつ ― Spotifyで学んだソフトウェアづくりと働き

www.oreilly.co.jp

Spotifyモデルを解説した書籍。Jonathan Rasmusson 著、島田浩二・角谷信太郎 翻訳でオライリー・ジャパンから2021年4月に出版。

大規模アジャイルを機能させるためのアイデアが詰まった一冊で、おすすめの書籍。noteに書いた感想文はこちら。

note.com

---

なお、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』も、本稿と扱うテーマが近いため適宜参照し、引用した。ただし、同書の中ではSpotifyモデルへの言及は注釈が一件ある程度であり、内容の中心ではない。 gihyo.jp

最小限の用語集

まず、本稿を読み進めるうえで必要最小限のSpotifyモデル用語を説明する。Spotifyの組織構造を「スクワッド」と「チャプター」によるマトリクス組織と捉えると、用語を理解しやすい。

スクワッド

• エンジニアだけでなくデザイナーやテスターも含む、職能横断の自己組織化チーム
• チームとしてフルスタックで、フロントエンド（FE）／バックエンド（BE）の開発やデプロイまで行える体制
• スクラムチームに近い
• 本稿では多くの箇所で、あえて「チーム」と表記

プロダクトオーナー

• ビジネス価値と技術的側面の両方を踏まえて作業の優先順位を決める役割
• 各スクワッドに専任で配属
• スクラムにおけるプロダクトオーナーに近い

チャプター

• 専門性を軸に、スクワッドを横断して形成される人の集まり
• ライン組織上の部門や部署に相当
• 例：Web開発チャプター、バックエンドチャプター、テストチャプターなど

チャプターリード

• 各チャプターのラインマネージャー
• 採用・評価・給与・キャリア開発などを担う
• いずれかのスクワッドにも所属

失敗の本質となる二つの問題点と「コンピテンシー」という言葉

Jeremiah Leeの文書をもとに、問題点を次の二つに分類した。

1. 過度な自律性に対してチームがコンピテンシー不足
2. 組織構造的にコンピテンシーリーダーが不在

以降の節では、Spotifyの組織に限らず一般化を意識しつつ、これらを考察する。したがって、原文で述べられていない点についても、必要に応じて具体化・抽象化しながら考えを深めていく。

「コンピテンシー（competency）」という言葉に馴染みがないかもしれないが、複数の参考文献でも用いられているため、あえて使用した。

コンピテンシーとは、特定の業務領域で高い能力や成果を発揮する人に共通して見られる特徴を指す。そこには知識やスキルだけでなく、態度や行動様式も含まれる。たとえば、論理的思考力、顧客志向、チームワーク、主体性、リーダーシップなどが挙げられる。

重要なのは、コンピテンシーが単なる能力や資質ではなく、具体的な行動として定義される点である。たとえば論理的思考力であれば、「複雑な課題を分解し、筋道立てて説明する」といった観察可能な行動で表される。

一方、「コンピテンス（competence）」という言葉を使う場合、コンピテンシーを発揮するための基礎的な能力自体を指している。

なお、上記の二つの問題点以外にも「3. 自縛を招いた独自の語彙」が存在するのだが、多くの組織には当てはまらず、一般化しづらいため本稿では割愛する。興味があれば、Jeremiah Leeの文書内の「Mythology is difficult to change」を読むとよいだろう。

問題1. 過度な自律性に対してチームがコンピテンシー不足

ここで求められる自律性とは、アジャイルの価値や原則、プラクティスに根ざした意思決定や行動を指す。

この自律性は個人ではなくチームに最適化された「チーム思考」に基づくものである。そして、チーム思考という言葉が指す「チーム」の範囲も、所属するスクワッド単体に留まらず、組織全体、会社全体をチームとしてとらえる。それこそが、自己組織化と言えるだろう。

しかし実際には、多くのメンバーの行動が、そのようなコンピテンシーを欠いていた。

それに気付かないまま、チームの自律性を重視するあまり、すべてをチームに委ねたらどうなるだろうか。仕事のやり方への標準化は「Howに対する強制であり、自律性に反する」と考えられたのだろう。

その結果として生じるのは、「車輪の再発明」「規模の経済の喪失」「流動性の喪失」「帰属意識の希薄化」だ。

車輪の再発明

新しく編成されたチームは、ゼロから自分たちの “仕事のやり方（Way of Working）” を作り上げることになる。参照できるテンプレートはなく、アジャイルプラクティスに関する知識や経験も乏しい。その結果、チームが本質を理解しないままアジャイルを実践し、大抵は「ウォーターフォールではない何か」にとどまる。

何が正解かわからないまま実践し、つまずきながら課題を改善していくことになるだろう。それ自体は悪くない。

しかし、これでは効率が悪い。既存のアジャイルプラクティスを用いれば解決できることまで、知らないがゆえに各チームがやり方を再発明してしまうからだ。

規模の経済の喪失

プロセス改善の観点から言えば、複数チームでソフトウェアプロダクトを開発する組織は、通常は規模の経済の恩恵を受けられる。

あるチームが得たローカルな知識を組織全体に共有し、グローバルな知識へと発展させられるからだ。それは組織内のプラクティスとなる。各チームはそのプラクティスを自チームに取り込んでプロセスを改善できる。

しかし、チームごとに “仕事のやり方” が大きく異なっていれば、他チームのプラクティスを適用しにくくなる。たとえ似た問題を抱えていても、コンテキストが違えば解決のためのプラクティスも異なるからだ。

だから、結局はそれぞれのチームで解決方法を見つけ出すしかなくなる。それがまた、チームごとに「車輪の再発明」を加速させる。

これでは規模の経済の恩恵を享受できない。

流動性の喪失

チームごとに “仕事のやり方” がまったく異なるなら、チーム間でのメンバー異動の難易度は上がる。

異動したメンバーにとっては、新しいチームのプロセスもツールも今までとは違うものとなる。もしかしたら、技術スタックだって違うかもしれない。その学習コストが高い。

そのうえ、チームオリジナルのやり方だから、わからないことがあっても、ウェブ上に情報がないこともある。そういう時はチーム内のドキュメントに頼りたいところだ。けれど、それも整備されているとは限らない。暗黙知も多いだろう。

最後の頼みの綱は、チームの仲間に聞くことだけだ。しかし、彼らが忙しそうなら、質問をためらってしまう。

新規メンバーの受け入れ自体に拒否感を示すチームもあるだろう。「学習や教育に時間を割く余裕はない」と判断するかもしれない。

結果的に組織から流動性が失われ、チームが固定化する。硬直した組織内では、属人化が横行しやすい。コードだって属人化する。さらに、チーム全体がコンフォートゾーンに浸かりやすく、業績基準も低くなる。

出典: エイミー・C・エドモンドソン 著／野津智子 訳／村瀬俊朗 解説『恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす』英治出版, 2021年, 第1章 表1.1を参考に筆者が作成

これらは、『チームの力で組織を動かす』の中でも述べている。

　属人化は、メンバーそれぞれに得意分野ができはじめることから生じます。同じチームで長く仕事を続ける中で、みんな、いずれかの分野が得意になっていきます。得意になれば、その分野の仕事は人から頼られるようになるし、自ら引き受けるようになります。得意な人がやった方が短期間で仕事が完了するし、アウトプットの品質も高くなるから当然です。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 3-3-2

　属人化の魔の手はコードにも及びます。
　大抵は、特定の領域のコードの理解容易性の低下という形であらわれます。その領域の変更はいつも同じ人が担当するから、当人だけがコードを理解すればよく、他人が理解しやすいようにコードを書く動機がないのです。そうしてコメントもなく、適切なドキュメントもないコードができあがります。
　理解容易性が低ければ、変更容易性も低くなります。コードを書いた本人以外には、どのような設計になっているのかをコードから読み取ることが難しくなるのです。別のメンバーがそこに変更を加えたくても手出しできません。そうすると、また当人が変更するしかなくなります。こうしてコードの属人化は深刻化の一途を辿ります。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 3-3-3

　私たちは、チームや組織をラーニングゾーンや高パフォーマンスゾーンに置きたいのです。
　しかしながら、チームを長く安定させ続けていると、コンフォートゾーンに陥りやすくなります。外部環境も内部環境も常に変動し続ける中で、新しいことを学び、チャレンジしなければ、優れたプロダクトをユーザーに提供することなどできません。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 5-5-4

また、人の異動に伴う知識の移動も失われる。それがまた、車輪の再発明へとつながる。

帰属意識の希薄化

チームごとの差異が大きくなると、各チームで独自の文化が育っていく。すると、メンバーからすれば他のチームがまるで別会社のように映り、関心を持ちにくくなる。

これでは、自チームへの帰属意識は高まっても、組織全体、会社全体への帰属意識は薄れる。

この状態は、全体最適な意思決定を阻害する要因にもなる。

部分最適な意思決定

「自律性」の意味を取り違えると、チームの意思決定は部分最適に陥る。組織全体や会社全体の視点で状況を捉えられず、自チームの仕事を優先してしまう。しかし、部分最適の総和は、全体最適とはならない。

チーム間での仕事の依存関係は、この問題を顕在化させる。

たとえば、チームAが受け持つ機能開発において、所有するコードaだけでなく、他チームBが所有するコードbを変更しなければならないときだ。どちらがコードbを変更するにせよ、チームAにとってはチームBの協力が必要となる。このように、複数チームに分かれたプロダクト開発には、チームを横断しなければ実現できない仕事も多い。

このような場合、もしチームBが自分たちの仕事ばかりを優先すれば、チームAの開発は停滞してしまう。

対策1. Minimum Viable "Agility" の標準化

自律性という名のもとに “仕事のやり方” をすべてチームに委ねるのではなく、組織として標準化すべき範囲を定めることが重要だ。共通のプロセスやツール、ルール、ガイドラインを定義する。それが「最小限の実行可能なアジリティ（minimum viable agility）」である。Jeremiah Lee の文書では、この言葉をLean Agile Scotland 2017でのJoakim Sundén（Spotifyのアジャイルコーチ）の発言から引用していた。

Every time you have a new team, or a team splits, they kind of have to reinvent the wheel in how they should be working.
Maybe, just maybe, we should do it that we have this "Minimum viable agility" and that's what you start with.
Feel free to opt out, but people shouldn't have to opt-in all the time.

新しいチームができるたびに、あるいはチームが分かれるたびに、自分たちがどう働くべきかを、ある意味で、車輪を再発明しなければならない。
もしかすると、もしかするとだが、「最小限の実行可能なアジリティ」を持つようにすべきなのかもしれない。そして、それを出発点とする。
オプトアウトすることは自由だ。常にオプトインすることを求めるべきではない。

（引用: Joakim Sundén「You can do better than the Spotify Model」Lean Agile Scotland 2017, 2017年10月, 26:50-27:09 ※日本語訳は筆者によるもの）

標準に含めるプロセスやツールも、既存のものを活用する。たとえば開発プロセスならスクラムを採用するといった具合だ。その他にもTDDやgit-flow, GitHub Flowなどを組み合わせられる。

こうして定めた標準は、すべてを必須にせず、オプトアウトを認めたり、複数から選択できる形にするのが望ましい。チームの環境や成熟度によって、最適な選択肢や組み合わせは異なるからである。

このように標準を設けることで、車輪の再発明を防ぎ、知識の流通による規模の経済を享受し、人の流動性を高め、さらに組織や会社への帰属意識を醸成できる。

対策2. チーム間連携方法の標準化

チーム間連携の方法や意思決定についても、標準化しておくとよい。

たとえば、チーム横断でのコード変更に関するガイドラインを設ける。先述の「チームAが受け持つ機能開発において、所有するコードaだけでなく、他チームBが所有するコードbを変更しなければならないとき」をどう扱うかである。

コードbはどちらのチームが変更するのか、外部品質・内部品質は誰が責任を負うのか。そういったポリシーを決めることも標準化のひとつだ。『チームの力で組織を動かす』では、これを「コードのオーナーシップ制」としてガイドラインを定義している。

ソフトウェアプロダクトを構成するコードは、その領域ごとにオーナーたるチームを設定し、品質責任の所在を明確にします。そのうえで、チーム内では「コードの共同所有」とし、他チームに対しては「弱いコードの所有」をポリシーとします。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 6-2

次のスライドは、書籍紹介イベントで使った登壇資料のものだ。

対策3. 何が全体最適であるかの明示

チーム間連携の手法だけを定義しても、チームが全体最適な意思決定ができなければうまく機能しない。組織全体として何を優先すべきかが曖昧であれば、チーム間での優先順位付けに統一性が欠けるからだ。先の例で言えば、チームAからの連携依頼をチームBが安易に断ってしまう恐れがある。

だからこそ、組織全体のミッションを明確にする必要がある。どこに向かっているのか、全員が共通の認識を持つことが重要だ。それに照らして、各チームが自らの意思決定を最適化、つまり「アラインメント」を施せるようにする。

さらに、ミッション（目的）を実現するための目標を設定する。目標を達成しても必ずしも目的を果たしたことにはならない。だが、目標と実績のギャップは、チームが自身の意思決定の妥当性を分析・検証するための指針となる。

加えて、目標に対する評価方法を定めることで、チームが何をすべきかがより明確になるだろう。

対策4. アカウンタビリティの所在の明示

また、自律性に見合う形で、チームにアカウンタビリティを持たせる。チームとしての意思決定に対し、その結果に責任を持ち、そうする（そうした）理由を関係者に説明できなければならない。

指示されて動くチームなら、レスポンシビリティのみでよい。言われた仕事をきちんと遂行する責任を負い、アカウンタビリティは指示側が受け持つ。

しかし、自律性を持って動くチームには指示者がいない。自分たちで決める。したがって、レスポンシビリティだけでなく、アカウンタビリティも必要となる。

ただし、「アカウンタビリティを持て」と言うだけでは単なる精神論だ。何らかの仕組みを用意する必要がある。

まず、誰が何に対してどの責任を持つのか、その所在を明確にする。ここが曖昧だと、チームやマネージャーが権限を誤用・濫用しかねない。明確化の手法としては、RACI（レイシー）マトリクスが向いているだろう。

次の表は、スクラムにおけるスプリントプランニングのRACIマトリクスの例だ。

出典: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 3-8-4 を参考に筆者が作成

• R：Responsible（実行責任者）: 実際にタスクを実行する役割
• A：Accountable（説明責任者）: タスクの結果に責任を持ち関係者に説明する役割
• C：Consulted（相談先）: タスクに関連して情報やアドバイスを提供する役割
• I：Informed（報告先）: タスクの進捗について報告を受ける役割

次に、実行と結果を可視化する。RACIマトリクスでResponsibleやAccountableに割り当てた活動は、Informedへ報告（可視化）する。

注意すべき点は、チームの失敗を “責任追及” ではなく “学習の機会” として捉えることだ。誰（どのチーム）が失敗したかではなく、なぜ失敗したのかを分析し、改善につなげることが重要だ。

理由は次のとおり。引用文では個人の失敗について述べているが、チームの失敗にも同様に当てはまる。

　もし、ミスを犯した人を責め、個人に責任を負わせようとする組織なら、失敗から学ぶこともできず、改善のチャンスを失います。また、現場の改善提案を無視したり、否定・抑圧するマネジメントが横行しているなら、誰も提案などしなくなるでしょう。
　こういった「人を信頼しない組織」では、誰もが口を閉ざすようになります。自分の失敗を隠し、問題に気づいても見ぬふりするようになるかもしれません。これではフィードバックを得ることも、そこから学ぶこともできなくなってしまいます。（中略）
　失敗した当人たちがリスクを負わずに失敗について語り、分析ができる。改善のためのアイデアを誰もが提案できる。そんな文化を持つからこそ、学習する組織たり得ます。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年8月, 1-3-4

問題2: 組織構造的にコンピテンシーリーダーが不在

チームが問題1のようにコンピテンシー不足であるにもかかわらず、組織がチームの自律性に頼りすぎると、組織全体がカオスに陥る。

従来の組織では、マネージャーがリーダーシップを発揮すべき場面である。コンピテンシーリーダーとして、彼らがメンバーに欠けた点を補う役割を担うのだ。

しかし、マネージャーらはその期待に応えることができなかった。従来組織のマネージャーに相当する「チャプターリード」が、スクワッドの活動から距離を置いた存在だったからである。

さらに、マトリクス型組織の構造的問題もあり、マネージャーが能力を十分に発揮できる体制は整っていなかった。スクワッドメンバーごとに所属チャプターが異なり、その数だけチャプターリードがいる。この複数マネージャー体制自体が問題となっていたのだ。

その結果として生じるのは、「トレードオフ不全」「相談先の重複と分散」である。

トレードオフ不全

長期的な視点に立てばスピードと品質は対立しないが、短期的にはトレードオフの関係にある。ここで言う品質とは、外部品質も含むが、特に内部品質を指す。内部品質を高めれば、プロダクトオーナーにとって将来のオプション（選択肢）が増える。しかし、そのレベルの品質を実現するには時間を要するかもしれない。

トレードオフとは、どちらか一方を完全に犠牲にすることではなく、対象となる項目それぞれにどれだけ力を注ぐかを調整することを意味する。

そのバランスを見極められるのは、対象領域を熟知した専門家だけである。そして、ソフトウェアプロダクト開発において、その多くはエンジニアリングの専門性である。

ただし、チーム内に複数のエンジニアがいれば、意見が割れて結論が出ないこともある。プロダクトオーナーがエンジニアでなければ、その意見をまとめるのも難しい。

このような場合にリーダーシップを発揮するのがエンジニアリングマネージャーだ。彼らは、マトリクス型組織の中で、チャプターリードとして配置されている。

しかし、チャプターリードはチームのソフトウェアデリバリーに関与せず、責任も負っていなかった。彼らの役割はキャリア開発と給与の査定に限定されていた。これは、おそらくチームの自律性を重視しすぎた結果の責任配置だったと考えられる。

そのため、プロダクトオーナーはエンジニアリングマネージャーに頼ることができず、適切ではないかもしれない判断を下すことになる。

相談先の重複と分散

たとえチャプターリードがソフトウェアデリバリーに責任を負っていたとしても、そこには問題が生じかねない。

理由は、一つのチームに対してチャプターリードが複数存在することにある。たとえば、チーム内のFEエンジニアが所属するチャプターのリード、BEエンジニアが所属するチャプターのリードといった具合に、専門性ごとにチャプターが区切られているからだ。

まず、プロダクトオーナーにとって相談相手が複数存在すること自体がコストとなる。誰に相談すべきか迷うこともあれば、全員を集めて協議するには大きな手間がかかる。

さらに、複数のチャプターリードがいれば、彼らの間で意見が割れることもある。その場合、対立を調停するために、さらに上位レイヤーへエスカレーションせざるを得ない。

これでは迅速な意思決定は難しい。

対策1. エンジニアリングチームを拡張したプロダクトチーム

この問題の原因は、ライン組織の切り方にある。すなわち、組織設計によって生じた構造が引き起こしている。

スクワッドと呼ばれるプロダクトチームはフルスタックである。ウェブ開発エンジニアもバックエンドエンジニアも含む。エンドツーエンドでのプロダクト開発を可能にするためだ。

一方、チャプターと呼ばれるライン組織は技術的専門性ごとに編成される。たとえば、ウェブ開発チャプターやバックエンドチャプターなどである。

必然的に、スクワッドには複数のチャプターからメンバーが集められる。

このような構造を採った理由は、技術的専門性の深化、リソースプール機能の確保、の二点にあると考えられる。

まず、スクワッドのような機能横断型組織は「知の探索」には適しているが、「知の深化」には相対的に弱い。新しいアイデアや技術を模索するのには向くが、技術を磨き上げ効率化・精緻化するのには向きにくいということだ。

そこでチャプターを機能別組織にすることで、「知の深化」を補おうとしたのだろう。

もう一つは、スクワッドの再編成を容易にする狙いである。チャプターを機能別組織としておけば、新たなスクワッドを組成したり、スクワッド間でメンバーを異動させたりする際に、チャプター間を異動する必要がない。こうして柔軟な組織運用を実現したかったのだろう。

しかし、前者の「知の深化」については、別枠の「ギルド」で担保し得た。ギルドは関心領域に基づき、スクワッド横断で形成される枠組みで、たとえばiOSギルドやAndroidギルドなどがある。

後者については、実際にはチャプターの入れ替えはそれほど頻繁ではなかったという。ソフトウェアプロダクト開発は、小規模で、かつ安定した体制で進める活動であり、プロジェクト体制のように頻繁にチームを組み替えるものではないからだ。

これらを踏まえると、この組織構造のメリットは大きくは見いだしにくい。

さらに、チャプターリードは、自律する（はずの）スクワッドの活動から遠ざけられていたため、スクワッドのソフトウェアデリバリーに十分関与できなかった。

もう少し深掘りすると、チャプターリードがメンバーの評価を正しく行えたかは疑問である。メンバーはそれぞれ別のスクワッドに配置され、チャプターリードの目の届かない場所で活動している。日々の活躍をつぶさに観察できない状況で、本当に正しく公平な評価ができたのだろうか。

結論として、機能横断型のプロダクトチームは、ライン組織上のエンジニアリングチームを拡張する形で形成するのがよいと考える。プロダクトチーム内で最も人数が多い職種であるエンジニアを基盤に据え、そこに企画者やデザイナーを加えて編成する。

もちろん、ライン組織上のエンジニアリングチームは、あらかじめソフトウェア開発・運用面でフルスタックで構成する。FE開発もBE開発もでき、運用もできる体制だ。

こうすることで、エンジニアリングマネージャーは、被評価者である全メンバーの活動をつぶさに観察できる。自らもプロダクトチームの一員としてメンバーとともに働けるからだ。

加えて、プロダクトチーム内の唯一のエンジニアリングマネージャーとして、プロダクトオーナーの片腕になれる。プロダクトチームをスタートアップ企業に準えるなら、プロダクトオーナーはCEO、エンジニアリングマネージャーはCTOである。チームがうまくいかない時の対処も主導できる。

余談だが、ホワイトペーパーでは、エンジニアリングマネージャーとプロダクトオーナーのこの関係性を「教授と起業家（professor and entrepreneur）」モデルと呼んでいた。メアリー&トム・ポッペンディークに由来するとされるが、一次ソースが見つけられなかった。これはおそらく、ポッペンディーク夫妻の著書『リーンソフトウェア開発と組織改革』を下敷きにしているのではないか。同書では「コンピテンシーリーダー（高能力・高業績リーダー）」と「製品チャンピオン」という用語で対比が示されている。

最後に

文書の中でJeremiah Leeは、自律性にはアカウンタビリティ（accountability）とアラインメント（alignment）が必要だと述べている。

ここで言うアラインメントとは、チームの活動を組織全体・会社全体の方向性と一致させることを指す。チームの自律性が「やりたいことを何でもできる」という意味に誤解されることを防ぐためのものだ。

アジャイルを実践するからといって、むやみにチームの自律性だけを重んじれば失敗する。そこでの優先順位付けにはアラインメントが施され、その意思決定にはアカウンタビリティが伴わなければならない。

Jeremiah Leeの文書は、その点に警鐘を鳴らしている。

最後にお知らせだが、2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。Spotifyモデルについてはほぼ触れてはいないが、本ブログに興味を持っていただけた方なら、楽しんで読んでいただけると思う。

gihyo.jp