Shawn Axsom (エンジニアリング担当ディレクター) と Jean-Laurent de Morlhon (エンジニアリング担当副社長) とともに、Docker がチーム トポロジの信条を適用して、社内のエンジニアリング チームをより適切に編成し、サービスを提供する方法を学びます。
新しいアプローチの採用
Docker では、開発者に夢中になっており、2019 年からエンジニアリング チームを再編成して、さらに拡張できるようにしています。 この取り組みは継続中ですが、 これまでのところ成功しています. 開発者中心の北極星に従うことで、60人の従業員を抱える会社以来、あらゆる面で成長してきました。 このビジョンには、Dockerユーザーだけでなく、社内エンジニアも含まれます。
したがって、私たちは、サイロ化された製品ベースのチームからストリームに沿ったイネーブリングチームに移行し、現在はチームトポロジに基づくプラットフォームチームに移行するなど、私たちの独自性を損なうことなく、文化と組織構造を刷新しました。
Docker のエンジニアリングの旅について、Team Topologies の共著者である Matthew Skelton との詳細な会話を録音し、進捗状況について話し合いました ドッカーコン2022で.以下では、当社の変革と、Docker を合理化されたコラボレーション可能な職場にする方法について詳しく説明しています。
文化の再構築
2019年11月のリストラにより、働き方を変えることができました。 私たちはコアミッションを倍増させ、リーンプロセスを開発し、 ドッカーの美徳:開発者の執着、謙虚さ、考慮された行動への偏見、およびオープンなコラボレーション。
また、当社のエンジニアリングチームは、社内プロセスに関する多くのフィードバックを共有しました。 彼らは、チームがより効果的に協力し、より迅速に出荷し、各製品のコードベースに伴う急な学習曲線を平坦化する方法を強調しました。 私たちは、Docker のチームを再形成する際に、このことを心に留めました。
まず、オープンなコミュニケーションについて説明しましょう。 スタッフの同期を確立し、頻繁な全社会議 (タウンホールのバージョン) で情報をオープンに共有し、スプリントサイクルを全社的なデモと同期させました。 それ以来、エンジニアリングチームを同じページに保つことがはるかに簡単になりました。 さらに、これは新しいサポート構造を形成するのに役立ち、チームメンバーが壁に囲まれているのではなく、コミュニケーションをとることを奨励しました。
次に、製品管理プロセスを刷新しました。 四半期ごとの計画から、全社的なプロジェクトやイニシアチブをスプリントごとに追跡する「ローリングロードマップ」に移行しました。 また、優先順位をよりリアルタイムで適応させることができました。 戦略ドキュメントと OKR は全員を永続的な方向に導き、ロードマップは変化するニーズを反映するために四半期ごとに進化してきました。
しかし、私たちはいくつかの初期の所有権の課題に直面しました。 製品や機能に関するサイロ化に遭遇し、ドメインの知識はチームではなく個人に任されていました。 当社のプロダクトマネージャーは割り当てられておらず、優先順位をめぐって競争していました。 その結果、チームトポロジの方法論に従うときに、真のストリームに沿ったチームが持つべきまとまりのある焦点が欠けていました。 間違いなく改善の余地がありました。
高成長に向けた製品開発チームの再編
2019 年 11 月以降、チーム構造を複数のステップで変革しました。
- 確立された製品バインド チーム (チーム トポロジを採用する前)
- ストリームに沿ったチームと実現可能なチームを中心に再構築
- ストリームに沿ったチームを分割し、プラットフォームチームを形成することでスケーリング
このプロセスが最終的にどのように行われたかを評価しましょう。
製品に縛られたチームの確立
チームトポロジのプラクティスを採用する前は、個々の製品を中心に大規模なサイロ化でチームを編成していました。
パロアルトとサンフランシスコベイエリアの開発チームは引き続きDocker Hubを維持しましたが、それ以外の場合は、英国のケンブリッジオフィスとフランスのパリオフィスで製品開発を分割しました。 Docker Hub に新たに重点を置くことで、 しました Docker Hub EU チームを紹介します。 しかし、製品の境界を越えた結束やコラボレーションがほとんどない均質な開発グループは残っていました。
最初の再構築は完璧にはほど遠いものでした。 製品に重点を置いたチームは、規模を拡大するにつれてさらに細分化する必要がありました。 問題を。チーム トポロジは、Conway の法則がアーキテクチャ、ビジネスの俊敏性、およびエンド ユーザーに与える影響を強調しています。 チームを地理的に分離するだけで、論理的なフラクチャプレーンの選択を回避しました—チームトポロジの推奨事項の重要な信条 適切な河川境界の検索.
ザ 逆コンウェイ操作 認知的負荷を軽減し、依存関係を最小限に抑え、製品の方向性に一致する方法でチームとアーキテクチャを調整する必要があります。 私たちの最初の試みは、認知的負荷を下げることができませんでした。 Docker Hub US チームは、Docker Hub のすべての部分を平等に理解する必要がありました。 製品管理のサーフェス領域も、機能セットのサポートを分割するのではなく、Docker Hub にまたがっていました。 チームの依存関係と複雑さの両方が高かったため、製品間の統合は最小限に抑えられました。
可能な場合はチームに専任のプロダクトマネージャーを任命するなど、段階的な変更を加えましたが、次回の規模を拡大するには、革新的な変更が必要でした。
ストリームに沿ったチームと実現チームを中心とした再構築
最初のチーム トポロジ ビルドは 2020 年 4 月にロールアウトされました。 この新しい構造では、ストリームに沿ったチームとイネーブリング チームが強調されました。
フラクチャプレーンは、会社の戦略に適合する水平方向の製品ニーズとタイムゾーンによって決定されました。 製品チームは引き続き特定の製品とスキルセットに焦点を当てましたが、境界はもはや不連続ではありませんでした。
私たちは、組み込みのプロダクトマネージャーとUXデザイナーでStreamに沿った各チームを形成しました。
このフェーズでは、プラットフォームチームを廃止することにしました。 プラットフォームチームは強固な基盤を構築するのに賢明でしたが、リソースは限られていました。 私たちは、顧客のニーズが第一であり、収益化がプラットフォームチームの成長を促進するための新しい人員への再投資に役立つことを知っていました。 最終的に、チームは時間の 30% 以上をオフザボードのアイテムに費やし、バグのスプリント作業を取り入れ、アーキテクチャを改善し、技術的負債を減らす余裕を与えました。
これらのチームは、次の目標を持って作成されました。
- 「各チームは 自主的な.彼らは明確な目標とスキルセットを持っており、自分で決定を下す権限を与えられています。 これらは、ローリングロードマップで共有される顧客の問題とビジネス目標を通じて調整されます。 Streamと連携した各チームには、専任のプロダクトマネージャーとデザイナー、および独自のクロスファンクショナルスキルを持つエンジニアがいます。 これは非常に珍しいことですが、チームを真に自律的にするために私たちにとって重要です。」 すべてのチームは、他の Stream と連携するチームとほとんど同期せずに機能を出荷できる必要があります。 私たちは優れたエンジニアを採用し、彼らを管理するのではなく、彼らの最高の仕事からブロックを解除することを目指しています。 ストリームに沿ったチームは、遅延や障害となる依存関係を最小限に抑えます。
- 「すべてのエンジニアは 顧客対応.私たちは、お客様のために価値を創造することとの強いつながりを維持する必要があります。 インフラストラクチャ&データチーム以外に、内部消費者のみを持つプラットフォームチームは避けます。」
- 「私たちは各チームの現在の 認知的負荷 を下げることを目指しているので、実行するコードの各部分を所有しています。」
Streamと連携したチームに焦点を当てたのは、Dockerの歴史を悩ませている主な懸念事項である収益化戦略に対処することを目的としていました。 また、開発者へのこだわりの美徳も維持したかったのです。 言い換えれば、私たちはお金を払う価値のあるユーザー向け機能を出荷する必要がありました。 以前は 再びスケーリングを心配しています。
また、製品開発プロセスをサポートするコアコンピテンシーを備えた不可欠なイネーブリングチームを作成しましたが、収益化に取り組んだため、これらのチームは人員が不足していました。 これからたくさんのポイントがありました。
ストリームに沿ったチームを実装する際に学んだ教訓
最初の Stream の実装は、主な目的である認知負荷で成功しました。
Docker Hubの米国チームは、Hubのインフラストラクチャとサービスのすべてに責任を負わなくなりました。 エンジニアのオンボーディングがはるかに簡単で、チームのサービスのより包括的なビューを開発することを期待できました。 ありがたいことに、エンジニアリングと製品のために個別の知識サイロが崩壊しました。 チームスコープを小さくすることで、チームの責任のサブセクションの表面領域全体で複数のエンジニアが焦点を重ねることができるようになりました。
最後に、焦点が狭くなったため、特定の製品の懸念事項をより深く掘り下げることで、製品組織に新たな重点が置かれました。
ただし、チームの境界は重要です。 チームのスコープ設定は、プロジェクトのスコープ設定に似ています。 理想的には、チームスコープも管理しやすく、バランスのとれた作業を可能にしながら、あいまいさを排除し、見落としを防ぐことです。
新しいチームを展開する際に、目標、機能、サービスの所有権を念頭に置いてミッションステートメントを作成しました。
確かに、戦略とロードマップをすぐに確立することは賢明だったでしょう。 しかし、一貫性のあるロードマップの作成が遅いチームもあれば、Accounts & Growth のように、スケジュールが厳しいプロジェクトが豊富にあるチームもあります。
また、時間の制約や再スキルにも取り組みました。 当初の構造に起因するものではありませんが、締め切りのプレッシャーと労働力の不足により、製品サイロ化されたチームに戻す必要が生じることがよくありました。 たとえば、アカウント&グロースはSSOプロジェクトだけを処理することもできましたが、積極的な目標を達成するために他のチームからデスクトップリソースを借りました。 私たちは、自律性によって将来の効率を解き放つのではなく、お客様のニーズに最善を尽くしたいと考えていました。
ストリームに沿ったチームの分割とプラットフォームチームの形成によるスケーリング
いよいよ規模拡大の時が来ました。 ARRが4倍に成長したことを考えると、製品に再投資し、より強力なロードマップで開発者に返済することができました。 ただし、これには最新のチームトポロジ手法にいくつかの調整が必要でした。
膨大な数のプロジェクトが引き続き選択されたチームに上陸しました。 これらのチーム内で新しいフラクチャープレーンを特定する必要がありました。
驚異的な成長が見られた今、インフラストラクチャと開発者の生産性のニーズに確実に対処する必要がありました。 これにより、回復力のあるインフラストラクチャを構築し、高速を維持することができました。
新しいストリームに沿ったチームは、主に既存のチームから分岐しました。 たとえば、アカウント&成長チームをアカウント、ビジネス、請求、カスタマーイネーブルメントチームに分割しました。 以前の再編から教訓を学びましたが、スケーリングは複雑さと課題をもたらし、チームの相互作用とニーズを予測不可能にします。 私たちは、変化するニーズや状況に適応するために、人員にバッファーを確保しました。
プラットフォームチームを導入することで、オープンコラボレーションに関する意思決定と実践を再考しました。 また、彼らの分野横断的な懸念に関する賛同を再考しました。 私たちは、実践コミュニティにサービスを提供するためのより民主的なアプローチを備えたプラットフォームチームを設立しました。
また、セキュリティ、データ、UX リサーチのニーズに対応するための専用のイネーブリング チームも導入しました。 これらは、最初は製品と設計の組み込みリソースと同様に動作しますが、ニーズが一元化されたときにチームを管理する新しい方法を探ります。
ドッカーチームに参加する
エンジニアとして、チームトポロジを使用すると、開発目標に取り組むことができます。 他の開発者、顧客、アカウント管理との連携、Docker Desktop Extensions エコシステムと SDK の構築、世界最大のライブラリやコンテナ イメージのコミュニティでのツールの作成など、製品関連の懸念を却下し、情熱を真に追求することができます。 複数の帽子をかぶって(必要に応じて)、Dockerの多くのエキサイティングなイニシアチブに直接影響を与えることができます。
私たちはあなたがすることを望んでいます Docker に参加して、次の成長段階に入ります。 アイデアを共有するだけでなく、主要な製品全体に実装することをお勧めします。 また、キックオフされる多くの新しいプロジェクトにさらされます。 最近受け取った多額の資金.
現在、11チームが採用しています 求人ページ、今年後半にはさらに多くの機会が訪れます。
これらには、Webおよびデスクトップ開発、データエンジニアリング、およびエンジニアリング管理におけるエンジニアリングの役割が含まれます。 また、オープンな技術プロジェクト管理、製品管理、および設計の役割もあります。
Docker での作業について詳しく知りたいですか?私たちをご覧ください 採用情報ページ 表示する 現在の求人、私たちの利点について読み、いくつかのクールな特典を調べてください—ホエールネスデイズを含む、健康的なワークライフバランスを促進する方法の1つにすぎません.