Post
JA EN

自由にしていい層と、固めないといけない層 ─ 技術選定を各自に任せて成功している企業を探した結果

Posted
By
43 min read
自由にしていい層と、固めないといけない層 ─ 技術選定を各自に任せて成功している企業を探した結果
  • 想定読者： チームの自律と技術の統一のどちらに寄せるか迷っているCTO・VPoE・EM・テックリード
  • 前提知識： チーム開発の実務経験。姉妹記事（末尾にリンク）を読んでいなくても単独で成立する
  • 所要時間： 通読 約15分／要点把握 約5分

概要

技術選定を各チームの裁量に委ねた組織で何が壊れるかを2本の記事で書いた。書き終えてから、当然の反問が残った。逆に、自由奔放にやって成功している企業はないのか。

あるはずだ、と思って探した。Amazon、Netflix、Spotify、Valve。「チームが好きな技術を選べる」と紹介されがちな会社を、一次資料まで降りて確認した。網羅的な調査ではなく、よく引用される4社を確認した範囲の話だと先に断っておく。

結論から言うと、本当に自由なまま成功している例は見つからなかった。見つかったのは、もっと具体的で使える構造だ。成功している企業は例外なく、どの層を自由にして、どの層を絶対に固めるかを意図的に分けている。Amazon は実装層を完全に自由にした代わりに、チーム間のインターフェースを「違反したら解雇」という水準で固定した。Netflix は標準を義務化しない代わりに、人材密度とコンテキスト供給に恒常的なコストを払っている。

層を分けなかった組織の記録も見つかった。Spotify だ。元社員が2020年に公開した振り返りには、チームごとに働き方がばらばらになり、人が squad 間を移動しにくくなったと書かれている1。そして同じ2020年に、Spotify 自身が「断片化した開発者ツールのエコシステム」を認めて Golden Path の記事を出している2。話がつながる。

本記事は、4社の実際を確認したうえで、自由にしていい層と固めないといけない層を4つに分けて整理する。そのうえで、自由が成立する条件を3つに絞る。「うちは自律を大事にしているから標準化はしない」という判断が、その3条件を満たしているかどうかを点検できるようにするのが目的だ。

Amazon：実装の自由を、境界の厳格さで買っている

「Amazon ではチームが好きな技術を選べる」という話の出どころは、2011年に Steve Yegge が書いた文章だ。Google 在籍時に社内向けのつもりで書き、誤って公開されてしまったもので、Amazon に6年半いた彼が、2002年ごろに Bezos が出したという指示を記憶から書き起こしている3。

先に断っておくと、これは Amazon の公式文書ではない。Yegge 自身が時期を「2002年ごろだと思う、前後1年」と書いている。断定調で引用されがちだが、あくまで一人の元社員の回想だ。

そのうえで、内容を見ると、よく引かれる部分は実は4番目だけである。

それがどの技術を使うかは問題ではない。HTTP でも Corba でも Pubsub でも独自プロトコルでも構わない3

問題は、その前の3項目が何を言っているかだ。

すべてのチームは、今後、自分たちのデータと機能をサービスインターフェース経由で公開する。 チームは、このインターフェースを通じて相互に通信しなければならない。 それ以外のプロセス間通信は一切認めない。直接リンク禁止、他チームのデータストアの直読み禁止、共有メモリモデル禁止、バックドアは一切なし3

さらに「すべてのサービスインターフェースは、例外なく、外部に公開できる前提で最初から設計すること」が続き、6項目目が「これをやらない者は解雇する」だ（7項目目は「よい一日を！」というジョークだが、6項目目については Yegge が「これは本物だった」とわざわざ書いている）3。

つまり、技術選定の自由は、インターフェースの絶対的な固定とセットで渡されている。実装層を解放するために、境界層を極端に固めた。しかも「外部公開可能な設計」まで要求することで、内部向けの手抜きインターフェースが作れないようにしている。

対価はもうひとつある。Amazon CTO の Werner Vogels は2006年の ACM Queue のインタビューで、各サービスにはチームが紐づき、そのチームが機能の定義からアーキテクチャ、実装、運用まで完全に責任を負うと述べ、こう続けた。

You build it, you run it. これは開発者を、自分のソフトウェアの日々の運用に接触させる。同時に、顧客との日々の接触にも連れ出す4

好きな技術を選べる。そのかわり、選んだものを自分で24時間運用する。選択の自由と運用責任が同じ人に渡っていることが、無責任な技術選定への歯止めになっている。「面白そうだから使ってみたい」が通るのは、深夜に起こされるのが自分だと分かっているときだけだ。

Netflix：自由は前提ではなく、投資の帰結

Netflix が公式に支える「paved road（舗装路）」を採用義務にしていないことは、姉妹記事でも触れた5。ここで見たいのはその先、なぜ義務化しなくても回るのかという条件のほうだ。

ひとつは、舗装路が何を含んでいるかにある。Netflix が full cycle developer の記事で列挙しているのは、デプロイ・監視・アラート・障害対応といった運用まわりのツール群だ5。開発者が自分のサービスを24時間持つ以上、運用と可観測性の道具が揃っていなければ成立しない。実装の選択が自由でも、ここは中央が用意している。

もうひとつ、公式のカルチャー文書に成立条件が明記されている。

まず、マネージャーの側に義務がある。「すべてを自分で制御しようとするのではなく、良い判断を下すために必要なコンテキストと明確さをチームに与える」のがマネージャーの仕事だと定義されている。そして引用されるときに落とされがちな一文がすぐ後に続く。

context not control を、放任（hands-off management）と混同してはならない6

もうひとつ、人材の前提がある。この仕組みが機能するには「並外れて責任感のある人（unusually responsible person）」が要る、と公式が書いている。自己動機づけと自己認識と自己規律があり、指示を待たない人だ6。休暇規定は「休暇を取れ」の一文、経費規定は「Netflix の最善の利益にかなうように行動せよ」の一文しかない。ルールを最小化できるのは、ルールがなくても壊れない人だけを残しているからだ。

つまり Netflix の自由は出発点ではない。そういう人材だけを集めて維持し続けるコストと、マネージャーがコンテキストを供給し続けるコストを払った結果として、後から成立している。順序を取り違えて自由だけを配ると、残るのは放任だけになる。

Spotify：層を分けなかった組織の記録

ここがいちばん示唆的だった。自律に振り切った組織の代表として語られてきた Spotify について、当事者による失敗の記録が公開されている。

元社員の Jeremiah Lee が2020年に書いた「Spotify’s Failed #SquadGoals」の要点はこうだ1。

「autonomy requires alignment（自律には整合が要る）」。ところが Spotify では、alignment と accountability に関するドキュメントが完成せず、autonomy の部分だけが世に出た。世界中がコピーした「Spotifyモデル」は、実態の記述ではなく願望だった。共著者と複数のアジャイルコーチが、何年も「真似するな」と言い続けていたという。

帰結について、元アジャイルコーチの言葉が引用されている。

新しいチームができるたびに、働き方を車輪の再発明しないといけない（Joakim Sundén, 2011-2017在籍）1

働き方に一貫性がないと、人が動きにくくなる。（中略）そのまま強化され続けて、ある時点で気づくと、もう同じ会社で働いている状態ではなくなっている（Jason Yip）1

Lee が書いているのは、チーム横断のコラボレーションに共通のプロセスが定義されなかったことだ。すべてのチームが独自の働き方を持つことを許した結果、協働するたびにチームごとの流儀に合わせる必要が生じた1。

ここは正確に分けておきたい。Lee の記事が扱っているのは働き方（ways of working）の不統一であって、技術スタックの分散そのものではない。技術側の断片化を認めているのは Spotify 自身のほうだ。

その Spotify が、同じ2020年に Golden Path の記事を公開している。断片化した開発者ツールのエコシステムを彼らは rumour-driven development（噂駆動開発） と呼び、意見を持った・サポートされた経路を整備したと書いた2。

自由奔放の代表格として引用され続けたその組織モデルが、当事者によって失敗と総括され、会社自体は舗装路を作る側に移っていた。Spotify は事業としては成功しているので、失敗したのはモデルのほうだ。引用元が更新されていないだけだった、というのがこの話の身も蓋もない結論になる。

Valve：フラットの実態と、研究からの限定

上司のいないフラット組織として有名な Valve についても確認した。

Journal of Organization Design の Point of View 欄に、Matthew McCaffrey による4ページの論評が載っている。Foss と Klein の著書『Why Managers Matter』(2022) を扱ったもので、実証研究ではない。McCaffrey が「説得力がある」として支持し要約している Foss・Klein の主張は、3点にまとめられる7。

  • bossless / flat な組織は、比較的確実で安定した条件下では機能することがあるが、より動的で時間制約の厳しい状況では、イノベーション・スケール・存続に苦しむのが典型
  • マネジメント階層は、調整と協力の問題を解き、従業員が判断を下すための枠組みを提供するという経済的機能を果たしている
  • Valve は、形式的な階層を非公式な階層に置き換えた例として挙げられ、形式的マネジメントの欠如が生む creative inertia に苦しんだとされる

留保が二重にかかる点に注意したい。これは論評であって実証研究ではなく、さらに論争の一方の側（マネジメント擁護側）の主張だ。加えて Valve は非上場で内部データが乏しい。この評価をそのまま確定的なものとして扱うべきではない。押さえておきたいのは、「フラットにすれば速くなる」という話が、少なくとも学術側で自明の前提として扱われてはいないことだけだ。

なお Valve は、以降の層の議論には出てこない。技術選定の層ではなく、階層そのものを消した例だからだ。層の切り分け以前の話として、参照範囲を分けて置いておく。

見えてくる構造：4つの層

4社を並べると、自由と統制の対立ではなく、層の切り分けの話だったことが見えてくる。

flowchart TB
    subgraph FIX["固める（組織の結合点）"]
        L1["層1<br>チーム間のインターフェース"]
        L2["層2<br>運用と可観測性の最低線"]
    end
    subgraph FREE["自由にできる（チームの内側）"]
        L3["層3<br>実装 言語・FW・ライブラリ"]
        L4["層4<br>チーム内のプロセス"]
    end

上下は段階ではなく、固める側と自由にする側の並びを表している。

層扱い理由事例
1. チーム間のインターフェース固めるここが緩むと、他チームの変更が自分を壊す。組織の結合度そのものAmazon の API mandate3、Zalando の API First8
2. 運用と可観測性の最低線固めるログ・トレース・メトリクス・デプロイが揃っていないと、障害時に他チームが助けに入れないMonzo の雛形（既定でログとトレース有効）9、Netflix の運用ツール群5
3. 実装（言語・FW・ライブラリ）自由にできるただし無条件ではない。成立条件は次節で扱うAmazon「どの技術でも構わない」3
4. チーム内のプロセス自由にすべきここを統制しても得るものがなく、自律性だけ失うNetflix の最小ルール6、Moe らの研究10

多くの組織が間違えるのは、この順番を逆にすることだ。層4（チーム内のやり方）を統制しようとして、層1・2（境界と運用）を放置する。標準化の議論がこじれるのは、たいていここが入れ替わっているせいだと思う。

なお、持ち帰れるのは層の切り分けという構造のほうだ。4社はいずれも巨大企業で、Amazon が層1に課した水準や Netflix が払っている人材コストを、数十〜数百人規模でそのまま再現できるわけではない。

「技術選定を各自の裁量に委ねた組織で、静かに壊れていくもの」で書いた「揃えるべきは経路であって、人の裁量ではない」という言い方は、層の言葉に翻訳するとこうなる。経路は層1と層2。裁量は層3と層4。

自由が成立する3条件

層3を実際に自由にしていいかは、次の3つで判定できる。

条件1：層1と層2が先に固まっている

Amazon が実装を自由にできたのは、その前にインターフェースを「違反したら解雇」の水準で固定していたからだ3。逆に、境界が緩いまま実装だけ自由にすると、他チームの技術選定が自分の障害対応に直撃する状態になる。

自組織の判定は簡単だ。他チームのデータストアを直接読んでいる箇所があるか。 あるなら層1は固まっていない。その状態で層3を自由にするのは、順序が逆になっている。

条件2：選択の自由と運用責任が同じチームにある

「You build it, you run it」4。選んだ人が運用しないなら、選択は他人にコストを押し付ける行為になる。運用を別チームが引き受ける構造で技術選定だけ自由にすると、選ぶ側にコストが返ってこないので、際限なく増える。

日本の組織では、開発と運用が分かれている、あるいは運用が協力会社に出ている構成が珍しくない。その場合、層3の自由は前提を欠いている。

条件3：人材密度と、コンテキスト供給の担い手がいる

Netflix が明言している「並外れて責任感のある人」と「コンテキストを供給し続けるマネージャー」6。この2つがないところで自由を配ると、放任になる。公式文書が「context not control を放任と混同するな」とわざわざ書いているのは、混同されるからだろう。

そして Spotify が示したのは、この供給が途切れたときに何が起きるかだ。alignment のドキュメントが完成しないまま autonomy だけが配られ、チームごとに働き方を再発明する状態になった1。

この3つは、単純なAND条件ではない。欠けた条件は、残りの条件をより強く固めることでしか埋められない、という関係にある。

Amazon がわかりやすい例だ。Netflix のような人材密度の話は、Yegge の回想にも Vogels のインタビューにも出てこない。条件3を満たしているかどうかは、少なくとも本記事が確認した資料からは判定できない。そのかわり Amazon は、条件1を「違反したら解雇」という極端な水準まで持ち上げている（この解雇の一文自体が回想に基づく記述だという点は、先に触れたとおりだ）。条件が1つ弱いなら、別の条件を極端にする。そういう埋め合わせの構造になっている。

逆に言えば、3つとも中途半端な組織に層3の自由はない。そして数十〜数百人規模で、どれか1つでも極端に固められている組織はあまり多くない。「うちは自律を重視しているから標準化しない」という判断は、多くの場合、この検討を経ていない。

なお姉妹記事「「標準がない」組織で、何から着手し、どう提案を通すか」にも3条件（速い／記録／変えられる）が出てくるが、別のものだ。あちらは経路の側（層1・2）を機能させる条件、本記事のこれは裁量の側（層3）を許してよいかの条件にあたる。補完関係にある。

よくある誤読

「Netflix は自由だから、うちも自由でいい」

Netflix の自由は結果であって前提ではない。人材密度への継続投資と、マネージャーのコンテキスト供給義務がセットになっている。そして舗装路自体は存在していて、速いから使われている5。自由の部分だけを輸入すると、舗装路のない Netflix になる。

「Spotifyモデルでやろう」

そのモデルは記述ではなく願望で、当事者が公開の場で失敗だったと書いている1。共著者と複数のアジャイルコーチが、真似するなと言い続けてきた。2026年時点で「Spotifyモデル」を根拠に自律を主張するのは、更新されていない引用に頼っていることになる。

「Amazon はチームが好きな技術を選べる」

選べる。ただし、他チームとの通信手段は一切選べない3。しかも選んだものを自分で運用する4。この2つを外して自由の部分だけ持ち帰ると、Amazon の設計とは別のものになる。

「標準化すると自律性が下がる」

層による。層4を統制すれば下がるが、層1と層2を固めることは、むしろ層3の自由を可能にする。Moe らが大規模アジャイルの2ケースを比較した研究では、マネージャーを構成員から外し、全チーム・プロダクトオーナー・専門家からなるコミュニティが意思決定する方式のほうが、チームがアーキテクチャや要件、組織の方向性にまで影響を及ぼせていた10（この研究は「「標準がない」組織で、何から着手し、どう提案を通すか」でも扱った）。誰が決めるかを変えれば、決めること自体は自律性を減らさない。

まとめ

「自由奔放にして成功している企業」を探して、見つからなかった。見つかったのは、自由にする層と固める層を意図的に分けている企業と、分けなかった結果を公開している企業だった。

Amazon は実装層を完全に自由にする代わりに、チーム間インターフェースを（回想によれば）違反即解雇の水準で固定し、選択の自由に運用責任を貼り付けた。Netflix は標準を義務化しない代わりに、人材密度とコンテキスト供給に恒常的なコストを払い、公式に「放任と混同するな」と書いている。Spotify は層を分けずに autonomy だけを配り、チームごとに働き方を再発明する状態になって、後から Golden Path を作った。フラット組織一般については、組織論の側から「安定した条件下では機能することがあるが、動的な状況ではイノベーション・スケール・存続に苦しむ」という指摘があり、Valve はそこで形式的階層を非公式な階層に置き換えた例として挙げられている。

整理すると4層になる。チーム間のインターフェースと、運用・可観測性の最低線は固める。実装と、チーム内のプロセスは自由にできる。多くの組織はこれを逆にやっている。チーム内のやり方に口を出しながら、境界と運用を放置する。

層3の自由が成立する条件は3つ。層1と層2が先に固まっていること。選択の自由と運用責任が同じチームにあること。人材密度とコンテキスト供給の担い手がいること。単純なAND条件ではなく、欠けた条件は残りをより強く固めることでしか埋められない。3つとも中途半端なら、それは自由ではなく放任になる。

自律か統制かという二択で議論している限り、この整理には到達しない。問いを「どの層の話をしているのか」に置き換えたほうが、話が早い。

技術がバラバラな組織で何が壊れるのかは「技術選定を各自の裁量に委ねた組織で、静かに壊れていくもの」で、何から着手しどう社内を通すかは「「標準がない」組織で、何から着手し、どう提案を通すか」で扱っています。本記事はその2本に対する反問（自由側の事例はないのか）から出発しています。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

  1. Spotify’s Failed #SquadGoals - Jeremiah Lee (2020). 【信頼性: 中】元 Spotify 社員による内部からの振り返り。個人の見解であり、社内の複数関係者の証言を引用しているが、Spotify の公式見解ではない ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6 ↩︎7

  2. How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem - Spotify Engineering (2020). 【信頼性: 中〜高】自社事例の一次情報 ↩︎ ↩︎2

  3. Stevey’s Google Platforms Rant - Steve Yegge (2011). 【信頼性: 要検証】Amazon の公式文書ではなく、元社員（在籍6年半）の記憶による paraphrase。著者自身が時期を「2002年ごろ、前後1年」と記している。広く引用されているが、原文書は公開されていない。社内限定のつもりが誤って公開された経緯は gist 本文にはなく、当時の報道（Forbes / TechCrunch, 2011）による ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6 ↩︎7 ↩︎8

  4. A Conversation with Werner Vogels - Werner Vogels（聞き手 Jim Gray）/ ACM Queue (2006). 【信頼性: 中〜高】Amazon CTO への一次インタビュー。「You build it, you run it」の初出 ↩︎ ↩︎2 ↩︎3

  5. Full Cycle Developers at Netflix — Operate What You Build - Netflix Technology Blog (2018). 【信頼性: 中〜高】自社事例の一次情報 ↩︎ ↩︎2 ↩︎3 ↩︎4

  6. Netflix Culture - Netflix. 【信頼性: 中〜高】自社の公式カルチャー文書。採用向けの文書であり、実態との乖離は外部からは検証できない ↩︎ ↩︎2 ↩︎3 ↩︎4

  7. Who’s the boss? The persistence of entrepreneurial hierarchy in flat organizations - Matthew McCaffrey / Journal of Organization Design 12:37-40（2022年11月オンライン公開、2023年掲載）. 【信頼性: 中】査読論文ではなく Point of View 欄の論評（全4ページ）。Foss & Klein『Why Managers Matter』(2022) への論評であり、本文で挙げた3点は McCaffrey が同書の主張を要約・支持した部分。Valve に関する記述も一次調査ではなく公開情報に基づく ↩︎

  8. Zalando RESTful API and Event Guidelines - Zalando. 【信頼性: 中〜高】公開されている実運用中の社内標準。効果の定量データはなし ↩︎

  9. How Monzo’s Opinionated Platform and Tools Support their Developer Experience - Container Solutions / Suhail Patel (Monzo) へのインタビュー. 【信頼性: 中】当事者の証言。第三者による検証ではない ↩︎

  10. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development - Moe, Šmite, Paasivaara, Lassenius / Empirical Software Engineering 26, 101 (2021). 【信頼性: 高】査読済み。ただし2社の事例研究であり、一般化には注意 ↩︎ ↩︎2

マネジメント・組織
技術標準化 組織設計 チーム設計 Platform Engineering 組織変革
This post is licensed under CC BY 4.0 by the author.