【紹介】『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』
はじめに
私はソフトウェアエンジニアとしてプロダクトの開発をしています。開発を進めるなかプロジェクトの完了とともにプロジェクトチームが新体制へ移行、同時にアジャイルプラクティスなどのチーム文化のナレッジがチームに留まらないことに課題を感じていました。参加したプロジェクトメンバーに知見が共有されることよいことですが！
texta.fmの「11. Favorite Technology Survey」でthoughtworks社が提供しているTechnology Radar Volume 27 を紹介していて、眺めていた時にチームの認知負荷として本書「チームトポロジー」が紹介されていました。
チームの相互作用は、ビジネスの俊敏性とスピードのために組織を再設計する際の重要な概念です。... 私たちのアドバイスは、チームがどのように設計され、どのように相互作用するかについて意図的になることです。組織の設計とチームの相互作用は時間の経過とともに進化すると考えているため、チームの認知負荷を測定して追跡することが特に重要であると考えています。これは、チームがサービスの構築、テスト、および保守をどの程度容易または困難に感じているかを示します。チーム トポロジの作成者によるアイデアに基づくチームの認知負荷を評価するために、テンプレートを使用してきました。
アーキテクチャの設計はキャッチアップしてきたけれど、組織（チーム）の設計はカタを知らないなと思い、なにか学べればと読みました！
PART Ⅰ デリバリーの手段としてのチーム
組織設計によってどんな課題があったのか。どのような組織設計の戦略を取り入れることで改善できるのかを説明しています。
- 全員が他のすべての人とコミュニケーションするように求めるのは、混乱のもとになること
- チームの認知負荷の許容量に合わせて、責任を限定すること
が刺さりました。プロダクトを開発するときは、ソフトウェアアーキテクチャとチーム設計を同時に設計する。両者は互いに影響しあうため。
PART Ⅱ フローを機能させるチームトポロジー
DevOpsトポロジーやチームタイプ、インタラクションを説明しています。
他者のしているチーム構成を、そのまま持ち込んでもうまくいかないよという説明や、チームの責任、境界について明確にすることでオーナーシップを持てるようにする。「隠れモノリスと結合」の項目でパターンのリストが参考になります。
PART Ⅲ イノベーションと高速なデリバリーのためにチームインタラクションを進化させる
チームタイプやインタラクションの具体例や導入方法を説明しています。
- チームはストリームに合わせて配置する
- 運用ロールをチームに取込、フィードバックをインプットする
チームをセンサーと捉えるのは有用だと感じました。
おわりに
チームへ目的と責任を明確にすることで、適切なアクションが取れるようになる。チームのパターンについても具体例を持って説明している。（サービスの価値を考慮した）組織設計について学べる書籍です。
個人的にはメンバー・チームの認知負荷についてどのように対応していくのかというテーマが刺激になりました。チームの認知負荷を下げるためにドメインでチームを分割したり、技術的にとがっていたらコンプリケイテッド・サブシステムに切り出す。チームへのコミュニケーションも状況によってインタラクションを変えるなど。『プログラマー脳』を読んでいた影響かもしれません。
インフラストラクチャ―・アプリケーションのデプロイの境界についても頭を悩ませていたのですが、ストリーム（組織の特性とプロダクトのドメイン）に合わせてエンド2エンドで独立して行うことができるといいよねという風に解釈し腹落ちしました。
ドメインやアジャイルプラクティス、CICDの話がちょいちょい出てきます。情報持っていると繋がることが多いかもです。
