巷で話題のチームトポロジーを読んでいる。読みながら感じたことが多いのでそれを雑に残しておきたい。まだ半分くらいしか読んでないので、その2に続くかもしれないし、続かないかもしれない。

読もうと思ったきっかけは、開発組織のあり方やチームの編成を議論するための前提知識のように感じることが増えてきたためだ。なんとなく聞いたことはあるが、具体的なことは何もわからなかったので、そろそろ読んでみようと思った。

チームの自律性

Chapter 2で、アプリケーションチーム（以下、本書に倣いストリームアラインドチーム）にデータベースに関するスキルが乏しく、データベース管理チームに依存するようになると、データベースを共有するアーキテクチャになってしまう、という話があり、納得感があった。異なるアプリケーションがデータベースを共有してしまうと、アプリケーション間で依存関係が生まれ、独立して開発を進めることが困難になり、生産性が落ちるため、アンチパターンと言われていたはず。

そういった自体を回避するため、ストリームアラインドチームには開発、デリバリー、そしてその後の運用に至るまで幅広くスキルが求められる。さもなくば、チーム間に依存関係が生まれ、それがコンウェイの法則によってアーキテクチャ上の依存関係につながってしまう。本書では、そういったチーム内で開発が完結することを自律性と呼んでいる（と理解した）。

自律性とモチベーション

本書ではダニエル・ピンクを援用して内発的動機づけには自律性が重要であると書いてある。そして、それは複数のチーム間の調整によって失われていくと書いてある。

自らの実感として、これは本当にそうで、自分たちの手に負えない要件を扱うときや、関係者が多すぎてコミュニケーションパスがカオスになっているときに、強い無力感に陥ってモチベーションが無になる。モチベーションがどうこうという話は本書の主題ではないと思うが、自分としては強く共感できた。

イネイブリングチーム

ストリームアラインドチームのスキル不足を解消するために、イネイブリングチームがあると理解した。

ありがちなのは、アプリケーションを開発するチームにはAWS上にリソースを作成し管理するスキルがないため、別のチームからインフラエンジニアの工数を借りてきて、一部のタスクを依頼するみたいな状況は過去に何度も見てきた。こういった動きはそのチーム自体にインフラを管理するスキルがない状況を根本的に解決するわけではないから、自律的に運用を進めるのが困難になり、アーキテクチャ上のひずみにつながるかもしれない。

対してイネイブリングチームとしての動きは、チームにそういったスキルを獲得するための支援をすることにあり、場合によってはペアプログラミングしたり、詳細なガイドラインを書いたり、コードレビューを引き受けたりする、といった動きになるのだろう。これにより、チームが自分たちで運用するためのスキルを獲得し、自律的に開発できるようになるのだろうと理解した。