Platform Engineeringを実現する上で重要な組織論「チームトポロジー」とは？

第3回　チーム間の人間臭い営みこそが組織変革に重要

　ここまでの連載で、第1回「開発者の認知負荷が高まっていること」、第2回「実現技術よりも開発者に向けたプラットフォームの価値を重要視すること」が語られてきました。第3回から徐々にPlatform Engineeringを実現するためのより具体的な方法論に入っていきます。今回は組織論である「チームトポロジー」とPlatform Engineeringの関係を見ていきます。

チームトポロジーとは？

　「チームトポロジー（Team Topologies）」の考え方が書籍として発表・発行されたのは2019年です（日本語版は2021年）。トポロジーは日本人にはなじみが薄い言葉ですが、ネットワークトポロジーがネットワーク構成図を表しているように、チームの組織図とご理解いただければわかりやすいかと思います。著者はMatthew SkeltonとManuel Paisの2名です。

　チームトポロジーを極めてシンプルにまとめると、「サービスの安定を保ちながらリリース頻度を高め顧客価値を最大化していく」ための開発組織の設計方法論です。具体的な方法として大きくは「①4つのチームの役割分担」「②3つの連携方法」「③組織構造進化の方法」がまとめられています。ここでは概要のみを紹介します。

①4つのチームの役割分担

• ストリームアラインドチーム：中心となるサービス開発チーム
• プラットフォームチーム：インフラ／ツール／知識等をセルフサービスで提供する
• コンプリケイテッド・サブシステムチーム：主に難易度の高い開発パーツを切り出す
• イネーブリングチーム：スキルや考え方を補完する有識者としてコーチ・並走する

“Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.”

②3つの連携方法

• コラボレーション：両チームが密接に連携
• X-as-a-Service：最小限の連携で、サービスとして他チームに機能提供する連携
• ファシリテーション：特定の課題に対して支援したりされたりする連携

“Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.”

③組織構造進化の方法

• 組織的センシングという方法を用いた気付きをきっかけに継続的に組織構造を進化させる

“Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.”

　単純な役割分担だけでなく、「連携方法を複数定義したこと」「組織の進化の概念を取り入れたこと」がチームトポロジーの新しさだと感じています。今回の記事ではPlatform Engineeringに関わる部分として、ストリームアラインドチーム（以下SAT）およびプラットフォームチーム（以下PT）を中心に解説します。