@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「チームトポロジー」を読んだ

チームのあり方のパターンがまとめられていた。
内容としてはデリバリを効果的に行うための開発チームや組織をどのように作るべきかについてまとめられている。
チームが最大限に成果を出すためのチームの人数やその責任の範囲のデザインの仕方、基本的な4つのチームタイプ、そのチーム間のコミュニケーションパターンについて説明されている。さらにはこれらをどう変化させていくかについても説明されている。これらが理論だけではなくいくつかのケーススタディと一緒に説明されている。

本書ではコンウェイの法則、逆コンウェイの法則を原則としてチームの設計が説明されている。実際に働いてみてコンウェイの法則は当てはまるなと思うことが多い。

チームに対して過度な認知負荷や余計なコミュニケーションを増やすことが余計な仕事を増やしているということは納得感がある*1。長く安定しているチームがプロダクトを開発、メンテナンスしていくことでサービスも安定するのだろう。サービスもチームも安定することでようやくサービスの将来について考えたり新しいことに手が出せるのだろうと思う。認知負荷が上がりすぎてないかを検知できるような仕組みを考える必要がありそう。

また、どのチームタイプになるかだけではなく他のチームタイプと関わる際のコミュニケーションパターンについても説明されている。チーム間のコミュニケーションパターンによってはサービスの作りにも影響は出るだろう。しっかりと組んでしまうと密結合なシステムになってしまうことが多いだろうし、うまい距離でやりとりをしている場合にはAPIを通してサービスを使うような疎結合なシステムになるかもしれない。
このあたりを考えてコミュニケーションパターンを考える必要があるが、本書ではこれらの変化のさせ方についても説明されている。

今の仕事をしている時にこの仕事は自分の部署でやるんだろうか?それとも隣の部署がやるんだろうかと考えることが多かったのだがこれもそもそものグループ分けの際にどこがなんの仕事をするか決めてチーム作成をしていないからなんだろうなと思った*2。ぜひグループを考える人達にも本書を読んでみて欲しいなと思った。

また認知負荷以外にもチームの成熟度や技術力などについても監視できる仕組みを取り入れていきたい。隣のグループが開発生産性についてはメトリクスを取っていたのでまずはそのあたりを取り入れてみるところからかな。

まとめ

  • 自分のチームをどのトポロジーに当てはめるか考えてみたい
  • 自分のチームをほかのチームが扱う際に困らないようにチームAPIを設計してみたい
  • 偉い人に自分たちのチームに求めているものが何か聞いてみたいと思った

*1:適当なコミュニケーションは必要だと思っている

*2:考えているのかもしれないけど僕には分かっていない