2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 が発売になります。 本書のレビューに参加させていただき、翻訳者の皆様から一足先に書籍をいただきました。 レビュー時は「なかなか難しいな…」と思っていましたが、翻訳者の皆様の努力とカラー装丁の効果か、読みやすい本に仕上がっております。
チームトポロジーとはどんな本か
翻訳者の一人であるryuzeeさん始め、多くの方が既にまとめてくださっているのでそちらを参照するのが良いかと思います。
チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。
- 新刊『チームトポロジー』発売のお知らせ | Ryuzee.com
- Team Topologiesを読んだ | Taichi Nakashima
- 「ちいとぽ」こと『Team Topologies』の翻訳（12月1日発売）を読んだ - こまぶろ
- Team Topologies(by Manuel Pais)のキーポイント
自分の言葉で話すと「ソフトウェア開発体制」の定石を扱った本かなと思います。パターンランゲージとかが近いのかもしれません。 チームトポロジーの知見を踏まえつつ、状況に応じた開発体制のあり方を議論し見直していく。うまくいく状態を見いだせてから組織図に反映していく。本書とはそんな付き合い方が良いのではないかなと思います。
"ソフトウェア開発はこうしたらうまくいくんじゃないかな?"という経験や理論が体系化されている
「フロー(デリバリー、バリューストリームとか)を最大化する組織を目指す」「チームを基本単位として長く存続させる」「コミュニケーションパスを整理する」といった、ソフトウェア開発をうまくやるための知識が幅広く紹介・解説されており、関連する書籍や一次情報へのポインタもまとめられています。「サービスが成長し、人も増えて来て組織のあり方を見直したい」というのは"あるある"のよく聞く悩みですが、本書はそんな悩める人が手に取り読み、共通の知識・用語を使って議論を始める土台とするのにちょうど良いと思います。
自分は開発部門のマネージャーとしてチーム編成を見直すことが時々ありますが、チームにどんなコミュニケーションを取ることを期待しているか説明することができていなかったなと本書を読んで感じました。本書で説明されている3つのインタラクションモードは誤解なく伝えることができそうで、業務でも取り入れようと考えています。
逆コンウェイ戦略という用語の難しさ
本書のベースにはコンウェイの法則と逆コンウェイ戦略があります。
先に引用したryuzeeさんの説明も「チーム構造と組織構造を進化させて」とあるので、変えていくこと前提だと思うのですが、「目指すソフトウェアアーキテクチャの正解があって、それに合うように開発体制を作るんだ」と考えている人が一定割合いるんじゃないかなと感じることがあります。本書はそんなこと書いてないんですが、斜め読みして誤解する人が増えると嫌だなーとか用語が出てくるたびに頭をよぎります。
"ドメインの知識はあっても望ましいサービス責務が見えていない"は割とあるケースだと思っています。 ストリームアラインドチームのコラボレーションを促し、チームの責務を意図的に広く・曖昧にして議論を促すと良いのかなーとか考えたりするんですけど、逆コンウェイ戦略かと言われると違う気がしています。「脱コンウェイ戦略」とかなのかな?
ハブやコミュニティをどう表現するか
組織のスケーリングを扱った書籍だとコミュニケーションのハブとなる人材や、ノウハウマネージャーを置いたりして、コミュニケーションパスを短くするアイデアがよく紹介されます。Spotifyモデルのギルドのように職能や目的別のコミュニティを作るというやり方もありますが、これらはチームトポロジーではどう表現するとよいのでしょう。
仮想的なイネーブリングチームがあって、他チームをファシリテートで導いている気もするし、チームの一部メンバーがコラボレーションしているとも言える気がします。
ソフトウェア開発以外の組織体制はどうしていくといいんだろう?
サービスはソフトウェア開発だけで成立しないので、営業や企画など他部門を交えてフローを最大化していく必要があり、開発組織と合わせて進化させていく必要があると思います。チームトポロジーの考え方は使えるような気がするんですが、本書はソフトウェア開発に絞った話なんですよね。
チームトポロジーの狙いはあくまで明快なパターンの提供だとすると、もう少し具体化したルールを定義することで「アジャイルはソフトウェア開発にしか適用できないが、スクラムはソフトウェア開発以外にもで起用できる」ような状態にできるような・・・できないような・・・
他社の事例も聞きたい
読んで終わりにするのではなく、自社の状況を図示して整理し、共通の用語を使って議論できることにチームトポロジーの価値があると思っています。自社の開発体制を描いたものが手元にありますので、見てみたい方・議論したい方・ツッコミしたい方、お声がけください。
Meety or Meetyのグループディスカッションを考えたのですが、クローズよりはオープンな勉強会とかの方が良いのかなと思ったり。何社か集まってできるといいな。
