二十世紀のほとんどの期間、支配的な組織形態は、調整に費用がかかり情報が乏しい世界に向けて構築されていました。意思決定する者と実行する者を明確に分ける機能別階層は、その世界に対する効率的な答えでした。指示を下へ、報告を上へ動かす費用を最小化したのです。しかし、その前提はいつの間にか溶け去りました。今や調整は安価となり、情報は豊富にあり、制約の要は情報伝達の費用から学習の速度へと移りました。既知の計画を実行するために設計された組織は、どの計画が正しいのかを発見することには適しておらず、そして発見こそが今や仕事の大部分を占めています。

進行しつつある変化は、組織の単位がプロジェクトからチームへと移ることです。プロジェクトは定義上一時的なものです。固定されたスコープの周りに人を集め、成果物を納め、そして解散し、蓄積された理解を持ち去ってしまいます。これは、システムを仕様化して構築し、運用は他者に引き渡す初期の企業ITには適していました。しかしデジタルプロダクトには適していません。デジタルプロダクトは決して完成することがなく、継続的に感知し、調整し、防御し続けなければならない生きた資産だからです。プロダクトを理解している人々が出荷の瞬間に散り散りになれば、組織はプロダクトを変更しなければならないたびに、その理解を再発見するために繰り返し代償を払うことになります。

これが今重要なのは、誤った構造に対する罰則がいっそう厳しくなったからです。恒久的なクロスファンクショナルチームを軸に組織された競合他社は、プロジェクト型のライバルが四半期を要するところをわずか数日でプロダクトを変更し、その差は複利で拡大します。加えて重要なのは、この失敗が組織図の上には見えないことです。箱は近代的に見えても、仕事の流れは依然として直列で、引き継ぎが多く、フィードバックに飢えたままでありうるのです。取締役会は、潤沢な資金を得たデジタル施策がなぜ遅々として進まないのかをますます問うようになっていますが、正直な答えは人材やツールの不足であることはめったにありません。組織が、しばしば意図せずして、遅く動くように設計されているということなのです。

この分野では三つの考え方がほとんどの働きを担っており、それらは互いに噛み合っています。第一はConwayの法則です。システムを設計する組織は、その組織のコミュニケーション構造を反映した構造を持つ設計を生み出す、というものです。これはスローガンではなく、制約についての観察です。チームは会話を持てるところでしかインターフェイスを合意できません。会話が難しいところでは、それに合わせてインターフェイスも硬直します。ソフトウェアのアーキテクチャと組織のアーキテクチャは、意味のある時間軸で見れば、二つの角度から見た同一のアーキテクチャなのです。

第二はConwayの法則の逆手取り、いわゆる逆Conway戦略です。構造とアーキテクチャが収束するのであれば、一方を用いてもう一方を意図的に形づくることができます。望むシステムを描いて組織がそれを実現してくれることを願うのではなく、望むチームの境界を描くことで、目標とするアーキテクチャが最も抵抗の少ない道となるようにするのです。疎結合なサービスを望む企業は、疎結合なチームを構築し、各チームが一つのサービスを端から端まで所有します。組織は、技術設計の最初にして最も重大な一片として扱われ、一行のコードも書かれる前に定められます。

第三の考え方は、原子単位としての恒久的なクロスファンクショナルチームです。そのようなチームは、事業の一断面をアイデアから稼働中のサービスまで運ぶために必要な幅広いスキル、すなわちプロダクト、デザイン、エンジニアリング、そしてますますサービスが生き延びるために必要となる運用能力とデータ能力を備えています。チームは機能ではなく成果を所有し、そして持続します。チームトポロジーはこれに有用な語彙を与えます。ストリームアラインドチームは価値の流れを担い、プラットフォームチームは内部の能力をプロダクトとして提供することで彼らの認知負荷を軽減し、イネイブリングチームは一定期間だけ専門知識を広めてから退き、コンプリケイテッドサブシステムチームはゼネラリストには手に余る深さを引き受けます。設計の課題は、これらの類型を組み合わせて、素早く動くストリームアラインドチームが小さく、自律的で、滞りなく動けるようにすることです。

これら三つの考え方から一つの第一原理が導かれ、私たちはそれを堅持します。まず価値の流れを設計し、次に各ストリームを所有するチームを設計し、次にそれらの間のコミュニケーション経路を設計し、そのうえで初めて技術を設計する、というものです。構造は仕事を注ぎ込む容れ物ではありません。構造は仕事の第一原因であり、後続のあらゆる選択はその形を受け継ぐのです。

プロダクトとして扱われるプラットフォーム。近年最も重要な変化は、内部プラットフォームを、稼働率やチケット数で測られるコストセンターから、それを利用するチームの生産性で測られるプロダクトへと捉え直したことです。プロダクト志向を持つプラットフォームチームには、強制すべき権限ではなく、惹きつけるべき利用者がいます。正しいことを容易なことにする舗装された道を公開し、利用を強いるのではなく獲得します。これは中央IT部門と開発チームの伝統的な関係を逆転させ、大企業における待ち行列の最も一般的な源を取り除きます。

設計指標としての認知負荷。実務者は、チームが背負う精神的負担を、コストやスループットと並ぶ一級の制約として扱い始めました。プロダクト、インフラ、データパイプライン、セキュリティ態勢、インシデント対応のすべてを所有するよう求められたストリームアラインドチームは、そのすべてを不十分にしかこなせません。その答えは引き継ぎを増やすことではなく、プラットフォームと明確な境界によって負荷を下げ、チームの担当範囲が実際に頭の中に収まる範囲に収まるようにすることです。境界がそれには複雑すぎる主題を横切る場合には、コンプリケイテッドサブシステムチームがストリームチームに代わってその深さを吸収します。

チーム単位のフロー指標。組織はますます、個人やプロジェクトの単位ではなくチームの単位でデリバリーを測るようになっており、少数の指標を用います。すなわち、チームがどれほど頻繁に安全に出荷できるか、変更が本番に届くまでにどれだけかかるか、変更がどれほど頻繁に失敗するか、そしてサービスがどれほど速く復旧するかです。これらは財務報告が覆い隠す構造的な摩擦を明らかにし、そして決定的に重要なことに、個人の生産性指標とは異なり、操作されにくい性質を持っています。局所的な活動ではなく全体の健全性に対してチームに報いるからです。

階層よりネットワーク。指揮命令系統は残りますが、それはもはや仕事が流れる主要な構造ではありません。価値は、明確に定義されたインターフェイスと共有プラットフォームで結ばれた恒久的なチームのネットワークを横断して動き、一方で階層は、それが真に得意とすること、すなわち人材の育成、標準の管理、投資の配分へと退きます。二つの構造は共存しており、それらを混同して階層に日々の仕事を差配させることを期待するのは、頻繁で高くつく誤りであり、ネットワークが解消するはずだった待ち行列をひそかに再び持ち込んでしまうのです。

価値の流れに沿って引かれる境界。組織設計における最も重要な決定は、どこで切るかということです。私たちはチームの境界を、技術レイヤーや職能の専門領域の周りではなく、顧客や事業が認識できる価値の断面の周りに引きます。オンボーディングを所有するチームはオンボーディングを改善できますが、データベース層を所有するチームは他者からの依頼に応えることしかできません。適切に境界づけられたコンテキストのように、ドメインに沿った境界は、疎結合なソフトウェアと、自らの仕事を成し遂げるために他者と交渉する必要のめったにないチームの両方を生み出す傾向があります。

長く生きるチーム、移り変わる仕事。私たちは、施策ごとに新しいチームを編成するのではなく、チームを安定させ、仕事のほうをチームへと流します。安定こそが、チームがドメインの暗黙知を蓄積し、素早さを生む信頼を築き、所有するものの長期的な健全性に責任を負うことを可能にします。予算配分もこの論理に従います。資金は恒久的なチームとその使命に配分されるのであって、しばしばインクが乾く前に陳腐化している事業計画に対してプロジェクトごとに拠出されるのではありません。

情報のある場所へ押し出される意思決定権限。速さは、明確なガードレールの内側で、仕事に最も近い人々に決定させることから生まれます。私たちは、チームが単独で下してよい決定、協議を要する決定、そして真に留保される決定を明示し、その対応表を小さく読み取りやすく保ちます。境界のない自律は混沌であり、自律のない境界は、私たちが取り除こうとした待ち行列そのものです。設計の課題は、チームが許可を求めずに動ける、最小限の制約の集合を描くことです。

親密さより先にインターフェイスを。チームは、絶えざる調整を通じてではなく、APIであれサービス合意であれよく理解された契約であれ、明確で安定したインターフェイスを通じて相互作用すべきです。仕事を成し遂げるために毎日会わなければならない二つのチームは、証拠に照らせば、誤った場所に描かれた一つのチームであるか、あるいは欠けているプラットフォーム能力の兆候です。私たちは、繰り返されるチーム横断の会議のすべてを、耐え忍ぶべき組織生活の事実としてではなく、診断すべき症状として扱います。

名前を貼り替えただけのサイロ。ある部門がプロダクトチームと改称され、そのメンバーは職能上の指揮命令系統も、目標も、上司もそのままに、名札以外何一つ変わりません。コミュニケーションの構造が手つかずである以上、Conwayの法則により、仕事の構造も手つかずのままです。これが最も一般的な失敗なのは、実行するのが最も安上がりで、進歩と取り違えるのが最も容易だからであり、そして誰もがもう変化は起きたと主張できるようにすることで、組織を本当の変化に対して免疫化してしまうのです。

整合なき自律。共有された方向感覚も共通の標準もないままにチームが自由にされ、組織は相容れない局所最適の寄せ集めへと断片化します。各チームは速いのに、全体は遅い。何一つ噛み合わず、あらゆる統合が交渉になるからです。自律は整合を背景として与えられる裁量であって、整合の代替ではなく、両者は共に設計されなければならず、さもなければその自由は断片化へと腐っていきます。

指図するプラットフォーム。プラットフォームを構築せよと命じられた中央チームが、必須のプラットフォームを構築してその使用を強制し、解消するはずだった待ち行列と反発を再び生み出します。プラットフォームは、代替手段よりも真に容易であることによって利用を獲得します。それを課さなければならなくなった瞬間、技術的にどれほど優れていようとプロダクトとしては失敗しており、開発チームはそれを迂回して、対処しようとした問題よりも悪い事態を招くのです。

構造と矛盾するインセンティブ。組織はチームワークを求めながら個人の英雄的活躍に報い、長期的な所有を求めながらプロジェクトの遂行で昇進させ、チームに協働を求めながら同じ予算をめぐって互いに順位づけします。人はインテンションではなくインセンティブを読み取るのであり、インセンティブと交戦している構造は、毎回インセンティブに敗れます。だからこそ私たちは報酬制度を設計の一部とみなし、後から誰か他の人が片づける事柄とはみなさないのです。

早すぎるプラットフォームの構築。ある能力が、それが実際にどうあるべきかを明らかにするのに十分なチームが利用するより前に、プラットフォームへと一般化されてしまいます。その結果は、まだ存在しないチームのニーズについての一つのチームの推測によって形づくられた高価な抽象であり、現実の需要が試すより前に石化してしまいます。プラットフォームは、複数のストリームを横断してすでに実証されたパターンから抽出するのが最も良く、それらに先立って設計するものではありません。早すぎる構築は因果を逆転させます。抽象に合わせて仕事を曲げるよう開発チームに求めることになり、それはまさにプラットフォームが解消するはずの押しつけと待ち行列そのものです。実践においては難しいことですが、規律とは、共有された必要の形が符号化するに値するほど明確になるまで、意図的な重複の期間を許容することにあります。

私たちは組織図からではなく、価値の流れから出発します。いかなる構造を提案するより前に、現状の組織において仕事が意図から稼働中のサービスへと実際にどう動くのか、どこで滞留し、どこで引き継がれ、どこで一つの機能から次の機能へと理解が失われるのかを描き出します。抽象的なモデルではなくその地図こそが、現在の構造が仕事のどこと戦っているのかを教えてくれます。それなしに再編するのは暗闇で家具を並べ替えるようなものであり、それこそがほとんどの組織再編が消耗を強いながら同時に無意味であることに成功してしまう理由です。

私たちは逆Conway戦略を意図的に用います。目標とする運用モデルが合意されたなら、事業が必要とするアーキテクチャが、組織の流れに逆らって課されるものではなく、チームの引き方の自然な帰結となるように、チームの境界を設計します。私たちは概して漸進的に進み、一度に一つの価値ストリームを作り直し、そのパターンを実証し、命令ではなく証拠によってそれを外へと広げていきます。目に見えて速く出荷し、自らの成果を所有する一つの恒久的なチームは、将来像についてのいかなるスライドよりも説得力があります。

私たちは意思決定権限と責任を明示し、それを書き記します。各恒久的チームについて、何を所有するのか、どの成果に責任を負うのか、単独で下してよい決定はどれか、そして守るべき少数の標準は何かを合意します。これに、認知負荷を下げるプラットフォーム作業を組み合わせます。なぜなら、チームがあらゆる根底にある関心事をひそかに自ら背負っていないときにこそ、自律は初めて本物になるからです。そして私たちはインセンティブと能力を設計の一部として扱い、後回しにはしません。構造は、それを支える報酬制度とスキルと同じだけしか持ちこたえないため、私たちは人材の育成を最初からモデルに組み込みます。

その全体を通じて、私たちはあなたのチームを迂回するのではなく、共に働きます。恒久的なチームを速くする知識は暗黙的で局所的なものであり、外から取り付けることも、文書で引き渡すこともできません。私たちの役割は、推論とパターンと規律をもたらすことであり、そして文脈の変化に応じて自らを設計し直せる組織を後に残すことです。文脈は必ず変化するのですから。

組織設計は、デジタルの野心が最も頻繁に座礁するところです。指揮命令系統、予算、個人の立場に触れるがゆえに、誰の気分も害さず何も動かさない表面的な変更へと皆を誘惑するからです。私たちの仕事を際立たせるのは、組織図で立ち止まることの拒絶です。私たちは構造、意思決定権限、インセンティブ、能力を単一のシステムとして扱い、それらを共に設計します。なぜなら、他を無視した一要素への変更は、残りの要素によってひそかに帳消しにされてしまうからです。私たちは仕事の流れを実際に変えるバージョンを主張し、提案された再編が芝居であるときにははっきりとそう言い、そして新しい形が現実の圧力の下で持ちこたえるのを見届けるまで留まります。

違いはスコープにもあります。この分野の助言の多くは、組織設計を理想的な組織図を描くこととして扱い、構造がまるで、生きて営まれなければならない働く関係の集合ではなく一片の文書であるかのように引き渡します。私たちは、描くことなど最も些細なことだと考えます。より困難で価値ある仕事は、箱が合意された後に始まります。誰が何を真に決めるのかを定め、報酬制度が構造と同じ方向に引くように整え、チームの自律を名目上ではなく本物にするプラットフォーム能力を築き、そして暗黙知によって恒久的なチームを速くする人々を育てる、といった仕事です。図なら誰でも供給できます。規律は、続く一年の中に、すなわち設計が現実の組織の摩擦と出会い、証拠が入ってくるにつれて、堅持されるか、あるいは判断をもって調整されなければならないときの中にあります。

加えて、仕事が前提としてよいことを変える実務上の帰結があります。あるエンゲージメントが、まだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platformは、エージェンティック・エンジニアリングによって、ほぼあらゆる機能を素早く受け入れられるように構築されています。必要なものを平易な言葉で記述すれば素早く生成されますが、それは常に確固たるアーキテクチャ原則の内側で、厳格な品質保証のもとで行われるため、速さが一貫性、セキュリティ、統制を犠牲にすることは決してありません。その効果は、単に便利であるにとどまらず戦略的です。内製か購入かの境界線を動かし、選択肢を安価に保ち、戦略が棚にあったものに合わせて曲がるのではなく、アーキテクチャが戦略に従うことを可能にします。

この仕事の尺度は、より整った図ではなく、より速く、より安定した価値の流れであり、自らの形を変えるのに私たちをもはや必要としない組織です。私たちが目指すのは、自らの成果を所有する恒久的なチーム、良い決定を安価にする明確な境界、その利用を獲得するプラットフォーム、そして文脈が変わったときにそれらの境界を再び引き直す自信を、あなたのもとに残すことです。私たちが取り付けうるいかなる単一の構造にもまして、その自己再設計の能力こそが、デジタルな運用モデルが最終的に必要とするものなのです。