こまぶろ

技術のこととか仕事のこととか。

「ちいとぽ」こと『Team Topologies』の翻訳(12月1日発売)を読んだ

邦訳が待望されていた『Team Topologies』(邦題は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』。以下、「ちいとぽ」)ですが、発売日(12月1日)を前にして翻訳レビュワーを務められた角谷さんからご恵投いただいた(ありがとうございますありがとうございます)ので、とりあえず一気に読みました。

Kindle版も出る予定とのことです。

内容については、すでにiki-ikiTwitterで色々話を角谷さんから聞いていて、ある程度前提があったのですが、実際に読んでみて印象に残ったことや感じたことを2点ほど記します。

一読した感想を先に記しておくと、この本は、自分一人で読んで、自分の組織について「あのチームは『ちいとぽ』でいうとこういう風に再定義できて、そうなると・・・」と考えてみるのも面白いですし、同僚と一緒に読んで「現状だとうまくいっていないところがあるだろうか?」と話してみるのも有意義だろうなと思いました。フルカラーで、視覚的にも楽しいです。そして、翻訳もとても読みやすかったです!

詳しい紹介が欲しい人は原書を読んで書かれた以下の記事がおすすめです。

deeeet.com

訳者の一人である吉羽さんの記事もご覧ください。

www.ryuzee.com

翻訳書籍とは別ルートで「ちいとぽ」に興味を持った方によるよいまとめ記事も公開されていました。

zenn.dev

「内容を三行で・・・」という人は以下もご活用ください。

scrapbox.io

組織・チームの「継続的な設計」

「ちいとぽ」といえば「4つのチームタイプと3つのインタラクションモード」です。こういうのをみると、「はいはい、またSpotifyモデルみたいな話でしょ?」となってしまいがちで、実際にこの書籍の中でもSpotifyモデルの話は何度か登場するのですが、「ちいとぽ」の優れているところは、これらを動的なものとして、書籍中の表現を使えば「継続的な設計」をするものとして位置付けているところだと思います。

できる限り効果的なチームにするには、ただ偶発的もしくは行きあたりばったりでチームを編成するのではなく、継続的にチームを設計する必要がある。このように継続的な設計によるチーム構造のことをチームトポロジーと呼ぶ。これは、それぞれのチームの責任範囲を明確にしながら、組織内にチームを意図的に「配置」することを意味する。(p.72-73)

「ちいとぽ」による組織改編の結果のスナップショットは(まさにSpotifyモデルがそうであったように)常に動的な過程の中の一断面に過ぎないと考える必要があります。

書籍では、スナップショットを説明するための静的な概念の紹介は一部のみで、重点は組織構造をどのように変化に対して適応させていくか、という方面にあります。第1章のタイトルは「組織図の問題」ですし、冒頭で既に以下のようにインタラクションモードは状況に応じて変化させていくものであるという言明があります。

技術やプロダクトの探索段階では、成功のために、チームの境界がオーバーラップしたコラボレーションの多い環境が必要だ。だが、探索が終わって技術やプロダクトができあがったあとも同じ構造を維持すると、無駄な労力と誤解を生んでしまう。(p.10)

あらゆる状態に適した組織構造というものはあり得ず、状況の変化に応じて形を変えていく必要があるというのは当たり前といえば当たり前なのですが、この書籍がその適応のさせ方に明快なガイドラインを与えてくれていることの価値は大きいように感じました。

豊富な参考文献と納得度の高い経験に基づいた議論

「ちいとぽ」を一読して印象に残るのは、豊富な参考文献を用いた議論の整理や裏付けと、時折挿入される経験にもどついた議論の納得度の高さです。

巻末に参考文献表が掲載されているのですが、細かい字で丸々12ページに渡って文献が列挙されています。これらの文献が文中のいいところで引用・紹介されていて、理解の助けになったり、「そういえば積んでるなその本・・・」となったりします。書籍の本筋とは別のところでも得るものが多いというのは、個人的には読む甲斐のある書籍の1つの特徴だなと思っています。

一方で、著者のこれまでの経験に基づいた記述も納得度の高いものです。たとえば、51ページではチームに割り当てるドメインの複雑度と数についての経験則が紹介されています。ここでいう複雑度は「シンプル」「煩雑」「複雑」の3つに分類されていて、「第2の経験則」として「1つのチームに、シンプルなドメイン2~3つ」がちょうどいい、という話がされています。これ自体もなるほどと思わされる記述ですし、最後に付け加えられている「しかし、仕事がルーティン化することで、チームメンバーのモチベーションが下がるリスクもある」という但し書きも、「お、そうだな……」と思わされます。

全体を通して、理論的根拠と経験の裏付けの両方に支えられた優れたガイドラインになっていると感じました。

おわりに & おまけ

というわけで、「ちいとぽ」を読んだよ、面白かったよ!というお話でした。

「ちいとぽ」を読んで、チームをトポっていきましょう!

おまけ:関連資料

IDDDの著者のバーノンのポッドキャストに著者2人がゲストで出てました。

open.spotify.com

「DDDとTeam Topologiesでプロダクト・レッド・オーガニゼーションですよ」だそうです。


www.youtube.com

プロダクト・レッド・オーガニゼーションについては、横道さんが訳された以下の書籍をご覧ください(僕は積んでます)。

公式のGitHub Orgもあります。

github.com

国内の事例も。

engineering.mercari.com

第4章でも言及されている「DevOpsトポロジー」について。

kakakakakku.hatenablog.com

おまけ:印象に残った参考書籍

前述のように「ちいとぽ」の中では様々な文献が紹介されているのですが、印象に残ったいくつかについて少しコメントをしておきます。

『LeanとDevOpsの科学』はしばしば引用されていました。ちょうど3年前にざっと読んだままなので、改めて読み直してみようかなと思いました。

ky-yk-d.hatenablog.com

『モチベーション3.0』も引用されていました(13ページや104ページ)。「ちいとぽ」13ページで言及されている「8人の精鋭からなるチーム」の話は読んでいるだけで辛いものがありますね。こちらもだいぶ前から積んでいるのでこれを機に読んでみようかと思います。

最後に、ナオミ・スタンフォード『Guide to Organisation Design: Creating high-performing and adaptable enterprises』です。9ページなど何度か言及されているこの書籍ですが、おもしろそうでした。Amazonだと2つページがあるのですが、Kindle版のある方のページのリンクを貼っておきます。