SalesNow 開発部の @sa9sha9 です。本記事では SalesNow が実践するチームトポロジーについて紹介します。
チームトポロジーとは
昨今、界隈でよく耳にする「チームトポロジー」ですが、弊社でもその概念を取り入れたエンジニア組織を組成しています。
チームトポロジーを一言で表すと、「複雑化する "解くべき課題"を解きやすくするため に、チームの形を最適に保つ抽象概念の言語化メソドロジー」であると筆者は理解しています。
共通認識化された抽象概念は説明に用いやすいので、非常にありがたいです。
言語化したチームトポロジーをメンバーに共有し、共通認識のもと課題に取り組むことで最大の効果を発揮することでしょう。
言語化することは認知の獲得（再現性）と認知負荷の軽減をもたらすので、弊社ではバリューとして文化的に推奨しています。
https://speakerdeck.com/salesnow/culture-deck?slide=32
４つのチームタイプと３つのインタラクションモード
チームトポロジーに聞き馴染みのない方は次の「４つチームタイプ」と「３つのインタラクションモード」の概念を理解するとよいでしょう。
少し前のチームトポロジーの原著や邦訳本とはインタラクションモードの図形が若干異なる（特に XaaS）ので、ご留意ください。
https://teamtopologies.com/key-concepts-content/team-interaction-modeling-with-team-topologies
４つのチームの形
これは、チームに期待される責務と役割の境界を表す概念です。
| チームの形 | 説明 |
|---|---|
| ストリームアラインドチーム （Sa） | "解くべき課題" （=ストリーム） に沿って設置されるチーム。いわゆるプロダクト開発チーム。 |
| イネーブリングチーム （En） | 他のチームの能力の向上を促すチーム。他のチームにバフを与える役割。 |
| コンプリケイティッドサブシステムチーム （Cs） | Saチームが抱える認知負荷を軽減するための専門家チーム |
| プラットフォームチーム （Pf） | 基盤を提供するチーム |
３つのインタラクションモード
これは、チーム間の相互作用を表す概念です。
| インタラクションモード | 説明 |
|---|---|
| コラボレーション | 密にコミュニケーションし連携する形 |
| XaaS | 自チームの役割をサービスとして提供する連携の形 |
| ファシリテーション | 他チームに知見を提供し支援する連携の形 |
チームトポロジーに関してもっと詳しく知りたい方は サイト や 書籍 をご参照ください。
SalesNowのプロダクト開発組織の昔と今
これまで SalesNow では何度かの組織再編を繰り返してきましたが、かつてのチームの形としてはざっくり次のようになります。
- 黄色のアプリチームがプロダクトを司るストリームアラインドチーム
- 青色のデータチーム・インフラチームが基盤を司るプラットフォームチーム
昔のSalesNowのチームトポロジー
昔の形のいいところと課題感
MVP のプロダクトをリリースしてしばらくは、積み上がった機能要望をいかに高速に開発していくかという段階であったため、基本的にはチーム間のコミュニケーションを最小限に留め、個々に独立したチームとなっていました。
ミーティングなどの同期的な時間を最小化しているため、開発する時間が単純にそれだけ増えますし、独立しているため自チーム内でフットワーク軽く動けるので高速に開発が進み、このフェーズにおいてはかなりワークしたと考えています。
ただし分業を敷くといっても、データチームとインフラチームは基盤チームとしてコラボレーション厚くしたり、インフラチームとアプリチームはアプリで実現したい実装をインフラ観点で知見を与えたりなどの必要な協業は存在しました。
また、当時の組織背景として業務委託比率が高めのチームだったことも分業が適していたことの一端であったと考えています。
課題感
しかしながら、プロダクトの成長や組織背景の変化に伴って課題感も現れました。
- １つのアプリチームで SaaS・メディアの２つのプロダクトを開発していたが、複雑化するにつれて開発効率が悪くなってきた
- データ基盤が複雑化するにつれて、アプリチームとの連携齟齬が生まれ始めた
- インフラチームとアプリチーム間での連携のリードタイムが伸び始めた
認知負荷の軽減とより密なコミュニケーション、コラボレーションの活性化が求められ始めたのです。
進化したチームトポロジー
そのような課題感を経てつくられたチームトポロジーが次の形です。
今のSalesNowのチームトポロジー
まず、アプリチームの人員を２チームに分けてそれぞれ専属のメンバーとしてアサインし直し、チームを２つにくっきりと分けることで認知負荷や開発にあたってのスイッチングコストを軽減しました。これによりそれぞれのプロダクトドメイン領域内での動き回りやすくなりました。
また、アプリチームとデータチームとインフラチームの合同のミーティングの場を増やし、コラボレーションを厚くしました。
単純な作業時間は同期的な時間を確保する分目減りしますが、コレボレーションの効果として、フロー効率を意識した全体最適な優先順位の合意形成や知見の共有がスムーズになりトータルの開発効率が向上しました。
技術顧問を巻き込んだイネーブリングチームも発足し、足元の課題感の解消や中長期的な施策についてディスカッションする場を設けて開発生産性の向上を促しました。
今の形の課題感
元々の課題感は一定解消されましたが、まだまだ改善の余地があります。
- アプリケーションの認知負荷が高くなってしまっている部分をサブシステムとして切り出し、専門のチームを組成する（＝コンプリケイテッドサブシステムチーム）
- 開発組織の規模が拡大した場合、今のコラボレーションの厚さだと逆にフットワークが重くなる（と思う）
この辺りについてはチームの形を変えたり分けたりすることが重要ですが、チームの中核を担うメンバーが不在の中で無理やりチームを分けても形骸化するだけなのでまだ着手していません。（あえて先に概念だけ切り分けてポジションの明確化をするのもアリかなとは思います）
最後に
あらためて、チームトポロジーという抽象概念を用いて言語化することで、各チームの役割を認知しやすくなったと感じています。
一方で、チームの境界がくっきりと規定されてしまうと役割が明確化される反面、その線を踏み越えて越境する動きがしにくくなってしまう場面もあるかもしれません。
そこは別途、文化としてどういった動きが推奨されるのかを各組織がバリューを持って定義し、フォローするのがよいと筆者は考えます。
引き続き、SalesNow では最適なチームトポロジーを模索し、チームの生産性を最大化させる取り組みを続けていきます。
もしチームトポロジーを取り入れたいと考えている組織があれば、次の公式テンプレートなどを活用してみてください。
Discussion