Team Topologiesの感想

updated at: 2024/11/25 9:19:36(JST)
twitter

71qyA3Hi47L.SL1418.jpg

感想

  • エンジニア組織設計の指針が得られる。これまで経験則的・抽象的に正しそうと思っていたことが明確に言語化されている。たとえば組織設計において、「フロントエンド・バックエンド」といったチームを廃止し職能横断型チームに転換したこと、また、設計した「組織横断型の生産性向上チーム」はまさにイネイブリングチームだったこと、などである。
    • 感覚的に捉えていたことが言語化されるというのは、システム設計の本であるAPoSDでも同じ感覚があった。システム設計はAPoSD、組織設計はチームトポロジーを軸にこれから考えていくことになると思う。
  • 今いる会社は受託開発を行っていて、ひとつのプロダクトを長期に渡って成長させていくモデルではない。プロダクト開発と決定的に違うのが、①小規模チームが多数立ち上がることと、②複数プロジェクトの並行は避けられない点である。というのは、受託開発は当然ながら顧客のスケジュールありきで進むため、そのためプロジェクトAが終わったタイミングでプロジェクトBが始まるなんていう、都合の良いことはないのである。したがって、エンジニアの稼働に空白が生じないためには、複数の、スケジュールが異なるプロジェクトを並行・兼任する必要がある。なので「チームトポロジー」をそのまま当てはめることは難しく、アレンジが必要である。
  • 全員が全員この本を読むべきということはないけども、業務のアサインや組織設計にはこういう背景があるということに想いを馳せてもらえたら、マネージャーの判断が理解しやすくなるのではないだろうか。あとなんでもかんでも「コラボ」するのが良い、というわけではないとか。
© Spatialty.io All rights reserved.