Team Topologies の最初の一歩

Team Topologies は、ソフトウェア組織をチームとチーム間の関係から設計する考え方です。組織図をきれいに描くことではなく、認知負荷を下げ、価値の流れをよくすることが目的です。

いきなりチームタイプを当てはめる前に、まず見るべきものがあります。

価値の流れを見る

最初に確認するのは、顧客価値がどこで止まっているかです。アイデアが生まれてから顧客に届くまでに、どのチームを通るのか。どこで待ちが発生するのか。どの判断に時間がかかるのか。

組織課題は、人の能力不足として語られがちです。しかし実際には、依存関係が多すぎる、権限が分散している、必要な知識が別チームに閉じている、といった構造の問題であることが多いのです。

チームの認知負荷を見る

ひとつのチームが抱えられる複雑さには限界があります。ドメイン知識、技術スタック、運用、セキュリティ、問い合わせ対応、社内調整をすべて同時に背負えば、チームは学習よりも処理に追われます。

認知負荷が高いチームでは、次のような症状が出ます。

  • 小さな変更でも調査に時間がかかる
  • 障害対応が特定の人に集中する
  • 新メンバーがなかなか自走できない
  • 優先順位が常に割り込まれる
  • 改善したいが手をつける余裕がない

この状態で「もっとアジャイルに」と言っても、うまくいきません。

チーム間の関係を明示する

Team Topologies では、チーム間の関係を Collaboration、X-as-a-Service、Facilitating のように分けて考えます。重要なのは、関係を暗黙にしないことです。

あるチームが別チームに常に相談しなければ進められないなら、それは一時的な協働なのか、継続的なサービス利用なのか、能力移転の支援なのかをはっきりさせます。関係が曖昧なままだと、依頼、待ち、遠慮、割り込みが増えていきます。

最初の一歩

大きな組織再編から始める必要はありません。まずはひとつの価値の流れを選び、関わるチーム、待ち時間、依存関係、認知負荷を書き出します。

そのうえで、次の問いを置きます。

  • この価値の流れを速くするには、どの依存を減らすべきか
  • どのチームの認知負荷が高すぎるか
  • 一時的な協働でよいものと、サービス化すべきものは何か
  • チームにどの権限があれば、自律的に進められるか

Team Topologies は、チーム名を分類するためのものではありません。価値を流しやすい組織構造を継続的に設計するための道具です。