はじめに
この記事では、特に技術的な複雑さを持つサブシステムに焦点を当てて、自分がチームトポロジーのフレームワークに則り、 Complicated Subsystem team を立ち上げた際のノウハウと、その試行錯誤の過程について紹介します。
チームトポロジーの説明とその必要性
チームトポロジーは、効率的なソフトウェア開発と運用を支援するために、チームの構造とコミュニケーションのパターンを設計するアプローチです。この概念は、チームが直面する複雑性を管理し、技術的負債の増加を防ぎ、プロジェクトの認知負荷を軽減するのに役立ちます。
チームトポロジーに関して理解するためには「チームトポロジー」という本が非常に参考になります。また、メルカリのエンジニアリングチームがチームトポロジーをどのように適用しているかについても、メルカリエンジニアリングブログで詳しく紹介されています。
自分の会社のコアロジック部分に関わる部分が、多くの技術的負債と高い認知負荷を抱える課題に直面したため、専門的な知識を必要とするチームである Compliated Subsytem team をチームトポロジーのフレームワークに則って適用することで、これらの課題に効果的に対処することが期待されていました。
チームトポロジーに則れば、Complicated Subsystem team の定義は次のようになります
コンプリケイテッド・サブシステムチームは、システムの中でスペシャリストの知識が必要となるパーツを開発、保守する責任を持つ。（中略）このチームの目的は、複雑なサブシステムを含んだり利用するシステムの担当となるストリームアラインドチームの認知負荷を減らすことにある。
Complicated Subsystem team立ち上げの試行錯誤
Complicated Subsystem teamの立ち上げは、Stream Aligned team（主要ビジネスラインに沿って組織されたチーム）との密接なコラボレーションとコミュニケーションから始まりました。当初から、チームを綺麗に分割し、それぞれの領域を分業することはできません。その代わりに各チームのステークスホルダーが連携し、コアロジックの理解を共有することやタスクの担当範囲を明確化することに重点を置きました。
システムがパッケージやコードレベルで完全には分離されていなかったため、コミュニケーションコストを惜しまずにかけることが重要であると考えました。もちろんシステムとしての分離も進めつつ、このアプローチによってチーム間での認識の齟齬を避け、よりスムーズに業務を進めることができるようになりました。
理想と現実の乖離とその対応
Complicated Subsystem team の立ち上げにおいて、現実は理想から遠く離れていました。最初の大きな課題は、理想的なサブシステムの構想と、既存のシステムの泥団子状態との間の乖離をどう埋めるかでした。ここではドメイン駆動設計（DDD）の手法から力を借りました。プロセスとしては次のような手順で進めました
- それぞれのチームが担当するドメインをコンテキストマップに落とし込む (コンテキストマッピングによる戦略的ドメイン駆動設計 - InfoQ)
- コンテキストマップとそれに対応するシステムの現状を理解する
- 理想的なコンテキストマップと現状のシステムの乖離をリファクタリングで段階的に埋めていく
このアプローチは、サブシステム間の境界を明確にし、各チームの目線を合わせる助けになりました。
チーム運用の課題と解決策
運用の進行中には、サブシステムとして振る舞いながらも、コアドメインとしての認識を維持し、価値を主張することが重要でした。チームがサブシステムとしての役割に留まらず、企業全体の戦略的な資産としての位置を確立するためには、プロジェクト優先度の管理と主張が欠かせません。
Stream Aligned team のプロジェクトマネージャー と1 on 1 を定期的に実施してサブシステム側の開発アイテムについて相談を行ったり、横断的なプロジェクト優先度相談ミーティングに参加してサブシステム側から開発アイテムの提案などを行うなどしました。
こういった地道な営みが完璧ではないにしろ、開発アイテムが決定されづらい状況を克服し、チーム内外でのコラボレーションを改善していたと思います。
まとめ
Complicated Subsystem teamの立ち上げと運用を通じて、チームトポロジーの適用の重要性、初期段階でのコミュニケーション戦略、そしてコアドメインとしての位置付けと価値の主張に力を入れることが、複雑なシステムの管理において非常に重要だと感じました。この記事が、同様の課題に取り組む方々にとって参考になれば幸いです！
