「Team Topologies」から学ぶチーム構造(第一部)

「Team Topologies」を読んでみた

炎上中のチームに人を増やしてもすぐには戦力にならないこと、また、デリバリ期限までに必要なインクリメントを作ることで精一杯で開発プロセスを洗練させることに投資することもままならない状況を経験したことから、何がその状況を生み出すのか考えてみた。
結果、以下の原因があるのではないかと推測。

• チームの前提

  • モノリスなアプリケーションで提供しているサービスを開発、保守していくチームが2チーム
  • このチームに長く在籍していて潤沢に開発知識を有しているメンバーは3人程度
  • 独自フレームワークを使用しており、他のWebアプリケーションに比べると参入障壁が高い(通信の仕組みなど覚えることが多い)
  • スクラムを採用しており、開発Tは要求から機能を定義し、品質を担保し、デリバリするところまでを全て担う

• 考えうる原因

  • チームに新しく人を入れたとしても、そのアプリケーションが動く仕組み、どうユーザに使われているのか、どういうプロセスでデリバリしているのかをキャッチアップするために大量の知識と経験が必要になる

この原因を生み出している原因について、アーキテクチャとチームの構造の観点からプラクティスがないかを模索していたところ、 Team Topologies が目に入ったので読んでみた。

まずは第一部まで読了したので、そこまでの内容のメモと、考察を記載する。

序文

• 内容サマリ: Team Topologiesはチーム構造を最適化することで、ビジネス価値を高めようと苦労している、または、チーム構造によりビジネス価値を高めることができると気付いていない組織を支援することを目的としている。チームが継続的に価値を届け、自律的に動き、かつ、自分たちを継続的に改善させるための組織構造の設計を提供する。また、このアプローチをとらないからと言ってチームが必ず失敗するわけではない。

• 考察: 正直、原理・原則ではなくある程度実装された組織構造やパターンを発見する目的だったので、もしかしたら割と原理・原則の話？と思ったけど、読み進めていくうちに割と実装されている内容を語っているなーと思って読み進めた。

第一部

ここではコンウェイの法則と、その法則から生じる制約をどう利用するかという点に論点をフォーカスするらしい
個人的に重要だと思った点とどう自分のいるチームに還元できるかについて記載していく

チームの説明責任をデザインする

• 昨今ではアプリケーションを開発する企業は安全性とスピードのどちらか一方を重視するということができなくなった。それはアプリケーションが人々の生活に多大なインパクトを与える存在になったから。アプリケーションをデリバリするということは社会的な営みであるという側面を持つ、そして、社会的な営みが昨今程、多くの人たちにインパクトを与えることは想像できなかった。
• アプリケーションをデリバリするチームの説明責任をデザインすることで、高品質で社会にインパクトのあるプロダクトを作ることができるようになる。
• 考察: 説明責任をデザインするという焦点の当て方が勉強になる。結局チームをいくつかに分ける際に、そのチームごとの目的が明確にあるが、それを全体最適を考えた上で、各チームが果たすべき責任を定義するというところまで深く考えれてなかったかも。

組織構造とコミュニケーションパスのずれ

• 大抵PJのキックオフで体制図のようなものがつくられ、それぞれのチームが定義されるが、それぞれのチームの行う最適化はそれぞれのチーム内での最適化にしかつながらない。価値提供のフローの全体を観察したときに、ボトルネックは依然として残ったままになっている。
• アーキテクチャと体制図のギャップがある場合、チーム間でのコミュニケーションが頻繁に必要になってくる。つまり、他のチームの情報やシステムについて知らないといけなくなり、認知負荷が高くなる
• 考察: コンウェイの法則の話につながってきた。これが第一部の問題提起。ここから、チームの抱える認知負荷の話や、組織構造がアーキテクチャに与える影響について語られる。

コンウェイの法則による影響を学ぶ必要がある

• サーバ担当チームが4つ、UI担当チームが4つ、DB担当チームが1つといった組織構造でアプリケーションを構築した場合、サーバコンポーネントは4つ、UIコンポーネントは4つ、すべてのコンポーネントが接続にくるDBが一つといった構造のアプリケーションが出来上がる。これにより、他チームの要望で増やしたテーブルのカラムが原因で、他チームのコンポーネントに不具合が発生する、という事態につながる。
• この原則を逆手にとれば、UI, サーバ, DBすべてを担うチームが４つ存在する状態でアプリケーションを構築すれば、それぞれのサブシステム毎に変更の影響を抑えることができるアーキテクチャを作ることができる
• このようにチーム構造を決定する責任を負う人は、その決定がアーキテクチャに与える影響を加味したうえで決定できる人間でなければならない。
• 考察: コンウェイの法則を逆に利用した戦略という文脈で語られていた。これは知識としては知っているけど、実践したことがない。実践しようとすると、開発プロセスを変更したり、疎結合なインターフェースを保つ仕組みを考え、維持したりと、デメリットの方が大きいのでは？という風に考えが傾いてしまう。少なくとも、マイクロサービスにしたから、みたいな漠然とした目的でやると開発するのがつらくなるだけになる。。

チームの認知負荷

• 一つのチームが複数のチームと頻繁にコミュニケーションをとらないといけない、また、他のチームのシステムについて知る必要があるというのはどちらもチームの認知負荷を上げることになる
• チーム間のコミュニケーションは活発な方が良いと思われがちだが、必要最低限にすることを推奨する。逆に頻繁にチーム間で情報を共有する必要があるのは1チームの認知負荷が高まっており、各チームの保守するコンポーネントの結合度が高いことを表す兆候のため、注意する必要がある
• 考察: チーム間のコミュニケーションは多いほうが良いと思っていた。 The New New Development Game でも語られるように一つの価値提供ユニットについて全員で取りかかって情報を個人ではなくチームに蓄えるようにすることが高品質とアジリティにつながると思ってた。ただ、この本が対象にしているのは単一チームの話じゃなくて、複数チームのコミュニケーションの話だから、自分が拡大解釈していただけだったなと、新しい発見。あと、本で書かれていた team of teams 読んでみたい。

チームに適用される認知負荷を制限する

• 認知負荷には種類がある

  1. 仕事をするための基本的な認知
     • javaでクラスやメソッドを作るにはどうしたらよいの？など
  2. 仕事をするうえで本質的ではないが必要になる認知
     • テスト環境にモジュールをデプロイする手順はどうすればよいの？など
  3. ハイクオリティなプロダクトを生み出すための認知
     • どういう内部構造にすると、今後の変更が楽になるか？など

• 一つのチームに適用される上記の認知負荷を下げないと、チームは自分たちのプロセスを洗練させる認知のスペースがなくなってしまい、デリバリ期限に間に合うようにタスクをこなすことを目標としてしまう。1の認知についてはトレーニングや知識の共有で少なくしていく必要があり、2の認知については自動化により、これも少なくする必要がある。そして、3に関する認知を脳内メモリに展開できるスペースを確保することが重要だが、基本的にチーム構造を考える際にこの認知負荷は論点にならないし、コストとして計上されることもない。

第一部を読んで考えたこと

自分が考えていたチームに新しい人が入ってもすぐには戦力にできないことの原因の一端でもあることについて書かれていた。
認知負荷の種類についてもカテゴライズしたことはなかったけど、確かにこういう視点でチームの認知負荷のどこを下げて、どこの認知をするためのスペースを空けるのか戦略が必要だと感じた。
ここまでを読んで感じているのは、「アーキテクチャが複数のチームで開発するのに向いていない」ではなく、「複数のチームがそれぞれの責務で開発をしていない」から、アーキテクチャはそうなってしまっているということ。
また、「アーキテクチャが複数のチームで開発するのに向いていない」を動かせない前提にしてしまうと、このアプリケーションを保守開発するチームは複数のドメインの3種類の認知負荷をメモリに展開したままになるため、ひたすらに認知負荷の2を少なくするということに注力するしかない。
認知負荷の2を減らすだけでチームをスケールすることが可能になっていくのかというと自信がない。まずは痛みの少ない範囲でドメインを切り出し、そのドメインに対する説明責任を負ったチームを組成し、モノリスアプリケーションを分割することをやらないと、コンウェイの法則がある以上自然には認知負荷は減らないことがわかった。