『チームトポロジー ― 価値あるソフトウェアをすばやく届ける適応型組織設計』を読みました。ソフトウェアのアーキテクチャは組織構造によって規定されるという「コンウェイの法則」がありますが、それを逆手に取った「逆コンウェイの法則」によって、理想的なアーキテクチャになるようにチーム構成を作ろうという話です。

本書によると、チーム構成は以下の４種類のチームタイプと３つのインタラクションモードに基づいて設計されます。

• チームタイプ
  • Stream-aligned team
  • Enabling team
  • Complicated Subsystem team
  • Platform team
• インタラクションモード
  • Collaboration
  • X-as-a-Service
  • Facilitating

組織をこれらのチームタイプやインタクションモードに従わせることで、チームに求められる振る舞いが明確になり、コミュニケーションコストや認知負荷を抑えられます。またチームタイプやインタラクションモードは固定されたものではなく、ソフトウェアやチームの進化、認知負荷の上昇に合わせて動的に変化させていく必要があります。

チームタイプを定型化するのはわりと一般的な話だと思いますが、それとは別でインタラクションモードを定型化するのはなるほどと思いました。今まで無意識のうちにインタラクションモードはチームタイプに本質的に組み込まれたものだと思いこんでいました。

逆コンウェイの法則に従うと、アーキテクチャを設計することはすなわちチーム構成を設計することになります。よってアーキテクチャを設計する人（アーキテクト）は組織設計に対する権限も持っていなければいけません。アーキテクトはプロジェクトの境界を見つけ、それに沿った組織・チームを設計することが求められます。また逆に組織設計に対する権限を持っている人（マネージャ）はアーキテクチャに対する強い影響力を持っていることを自覚しなくてはいけません。

このあたりの話はアーキテクトという役割についての解像度をググっと引き上げてくれて面白かったです。アーキテクトの職務とエンジニアリングマネージャの職務が交差するという事実は「IC と EM の間を振り子のように行ったり来たりするキャリアパス」の有用性や「EM なら技術に明るくあって欲しい」という期待を補強する知見だと思いました。

また本書では「コミュニケーションやコラボレーションは多ければ良いものではなく、認知負荷を抑えるために適切に設計すべき」とも言っています。これは納得できる一方で、人事評価システムによっては他チームとのコラボレーションへの積極的な貢献を求められることも多く、その辺の期待値設計が難しそうだなぁ、という気持ちになりました。積極的なコラボレーションは期待しつつもあくまで現行のチームトポロジーに沿った形でお願いしていくべきか、自由にコラボレーションを始めてもらって必要に応じてチームトポロジーを刷新していくべきか。「チームトポロジーは動的に進化させていくもの」というポリシーを踏まえると、現行のチームトポロジーに固執する前者のやり方ではなく、実態に合わせて柔軟に変えていく後者のやり方が正しいのかもしれません。

いずれにせよチームトポロジーはチーム設計のための共通言語としてとても有用だと思いました。チーム設計をする人はもちろん、設計には携わらないけれどチームの一員として実際に働くメンバーの人にも是非読んでみて欲しいです。チームとして求められている振る舞いが分かって面白いと思います。