こまぶろ

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

Technical leadership and glue work / Being Glue を読んで

Tanya Reilly による「Technical leadership and glue work」という講演(および、その文字起こしによるブログ「Being Glue」)があります。(以下、講演に特に言及する場合を除き、「記事」として言及します)。


www.youtube.com

noidea.dog

Manager ではなく Individual Contributor としてのキャリア

筆者の Tanya Reilly は、元GoogleのStaff Systems Engineerで、現在はSquarespaceでPrincipal Software Engineerを務めています。これらの職名からもわかるように、彼女はマネージャーではなくエンジニアとして昇進を続けながら活躍してきた人です。

エンジニアリングマネージャーについての書籍は、翻訳が出ている『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』(原題:The Manager's Path)や『フェイスブック流 最強の上司』(原題:The Making of a Manager)の他にも、『An Elegant Puzzle: Systems of Engineering Management (English Edition)』などの書籍がありますが、IC(Individual Contributor)の上位職のための書籍としては『Staff Engineer: Leadership beyond the management track (English Edition)』があるくらいで、まだ整備されていないという状況があります(これは、ICの上位職の責務が企業により非常に異なっているという事情もあるようです)。

Tanya Reilly は、このICの上位職のための書籍を目下準備中(発売予定は2022年10月。Oreillyのサブスクで Early Release 版の第1章まで読めます)なのですが、冒頭の記事も近接した問題系についてのものです( Tanya Reilly が書籍で挙げているサンプルのキャリアラダーでは、この記事で言及される Senior Engineer の上で Staff Enginner と Manager とに分岐するのですが)。

learning.oreilly.com

(2024/3/5追記、すでに『The Staff Engineer's Path』として発売されています。)

Glue Work とその危険性

この記事の主題である「Glue Work」とは、他のメンバーがブロックされているのを助けたり、設計ドキュメントをレビューしたり、新しいメンバーのオンボーディングをしたりという、一見すると「技術的」ではないと思われるような仕事です。著者によると、これらの仕事は「技術的なリーダーシップ」の一部であり、シニア開発者には求められるものである一方で、シニアになる前にこれらの仕事をしすぎることはキャリアをダメにしてしまう危険性があるとされています。なぜなら、これらの仕事をしすぎると、コーディングなどのより「技術的」な仕事に時間を割くことができず、「シニア」への昇進で求められるような「技術的」スキルを磨く機会を失ってしまうからです。

記事の中では、1人の女性エンジニア(ここでわざわざ「女性」というのには意味があり、記事の後半で女性が男性よりも多くこの種の昇進に結びつかない仕事を頼まれる/する傾向があるという話が紹介されています)のストーリーを用いて説明がなされますが、この話を「自分のことだ!」と思う人は少なくないようです。自分も、割合この種の仕事をしがち(好んでやっているし、自分だけがしているわけでもないので不満はないのですが)なので、読んでいて「あーわかる〜」となる部分が多くありました。

自分は何をすべきで、何をすべきじゃないんだろう

記事の紹介はここまでで、ここからは自分の話なのですが、自分は結構な割合の労働時間を Glue Work に時間を割いている時期が今まで多かったです。コーディングが嫌いなわけではないし、技術に興味がないわけでもないのですが、どちらかというとコーディング以外の形でプロジェクトやチームに貢献するという機会の方を選択してきたように思います。

そうしてきたのは(後ろ向きな理由もなかったわけではないですが)、それが一番自分がその時点で貢献できるからであったり、それが一番面白いと思ったからであったりするのですが、改めて立ち止まってみると、自分のキャリアにとっては好ましくない部分もあったのかなと思いました(よかったと思う部分も多々あります)。たとえば、会社の身の回りのエンジニアに比べて、手が動くまでが遅いというのは、エンジニアとしての自分の大きな欠点だなと思っているところなのですが、 これが改善されてきていないのは自分のこれまでの選択の産物に他ならないと思います。

プログラミング経験ゼロからこの業界に入ってそろそろ5年になりますが、ちょうど自分が業界に入ったあとに「エンジニアリングマネージャー」というトピックが日本でもポピュラーになり、「将来はEMとかそっち方面かなー」とずっと思ってきたので、コーディングなど「技術的」な仕事に多くの時間を割くということをそこまで重んじてこなかったという側面もあります(現場の開発者としての経験はEMにも重要だと考えて、現場に近い仕事を転職の時に選ぶことはしましたが)。

Glue Work についての記事は、自分のキャリアについて特定の方向の示唆を与えるものでもないのですが、改めて自分のキャリアというものを考えてみたときに、どういう仕事を日々選択してやるのかというところも重要になってくるな、というのを改めて思わされました。自分のキャリアの観点とは別に、チームの状況という観点からも、これまでと同じ動き方をしていくことがベストではないのではないかというのが最近思い始めていることなので、改めて自分の働き方、動き方について、チームのメンバーやマネージャー、あるいは社外の人たちと話し合ってみたいなと思いました。

e34.fm

iki-iki のご紹介:いきいき Advent Calendar 2021

本記事は「いきいき Advent Calendar 2021」の18日目の記事です。

t.co

昨年の半ばごろから、 iki-iki という活動(?)に参加しています。この記事ではこのiki-ikiを紹介します。

scrapbox.io

iki-iki ってなに

iki-iki とは、以下のようなものです。

ここはいきいきマニフェスト(仮) に心を動かされた人びとの活動の場です。

WelcomeVisitors - iki-iki

iki-iki では、Discordで雑談したり、Scrapboxを育てたりしています。 Scrapbox内の記事としては、 @kakutani が書いた『ユニコーン企業のひみつ』あとがきや、QRCチームトポロジーの記事を見たことがある人がいるかもしれません。

scrapbox.io

scrapbox.io

iki-iki の歴史

iki-iki の歴史は、@kkd の書いた以下の記事に触発された @kakutaniが「ノリで」Discordサーバを作ったところから始まっています。

note.com

f:id:ky_yk_d:20211206214328p:plain

しかし、お二人が「いきいき」と言い出したのは最近ではなく、どうやら2008年ごろに遡れるようです。 @kkd が2008年夏に「沢田マンション」を訪れて、そこから「いきいき」というフレーズが盛り上がっていったようです。 @kkd 自身は、アレグザンダーの「無名の質」や「生命構造」にも強く影響を受けていると書いています。

giantech.jp

scrapbox.io

2009年時点で既にWikiWikiWebと「いきいき」とを結びつける発言を @kakutani がしていて、10年以上経って実際にWiki(実装としてのScrapbox)が立ち上がったというわけです。

iki-iki では執筆者を募集しています

以上、iki-ikiの紹介でした。

iki-iki の執筆を一緒にやってくれる人をいつでも募集しています。 以下のページを参考に中の人にお声がけください!

scrapbox.io

『Release It!』の次に読みたい(読むとは言ってない)英語の技術書

最近、英語の勉強を改めてしていて、その一環として少しずつ読んでいた『Release It!』の2版を一周しました。

英語の本を読むのは続けていきたいと思っているのですが、日本語の本ほどのスピードではまだ全然読めないので、「これ!」という少数の本を読んでいく方針で当面は進めようと思っています(せっかくオライリーのサブスクを契約しているので、たくさんの本を拾い読みするというのもアリなのですが)。

そこで、次に読む本を考えていくにあたって、せっかくなので候補に挙がっている書籍をリストアップしておきます。

「これは翻訳の予定があるよ」というものはこっそり教えてください(無茶言うな)

Dynamic Reteaming

『チームトポロジー』でしばしば言及されていた本。

オライリーのサブスクでオーディオブックを少しずつ聴いている限りでは、事例が結構厚めな印象を持っている。固有名詞の入っているところばかり耳に残っているだけという説もありますが・・・

I. What Is Dynamic Reteaming?
1. The Evolution Of Teams
2. Understanding Teams
3. The Power Of Team Assignment
4. Reduce Risk And Encourage Sustainability
II. Dynamic Reteaming Patterns
5. One-By-One Pattern
6. Grow-And-Split Pattern
7. Isolation Pattern
8. Merging Pattern
9. Switching Pattern
10. Anti-Patterns
III. Tactics For Mastering Dynamic Reteaming
11. Adapt Your Organization For Dynamic Reteaming
12. Plan Your Dynamic Reteaming Initiative
13. After Dynamic Reteaming: Transitions And Team Calibrations
14. Reflect And Determine How To Shift
IV. Conclusion

永瀬美穂さんが翻訳してくれるのに期待している 👀

オライリーサブスクでも読める。

Dynamic Reteaming, 2nd Edition [Book]

Learning Domain-Driven Design

2021年11月に出たばかりのドメイン駆動設計に関する本。

オライリーサブスクで読める↓のレポートがよくまとまっていると評判なので、この書籍も期待できそう。目次を見た感じも良さそう。

www.oreilly.com

I. Strategic Design
1. Analyzing Business Domains
2. Discovering Domain Knowledge
3. Managing Domain Complexity
4. Integrating Bounded Contexts
II. Tactical Design
5. Implementing Simple Business Logic
6. Tackling Complex Business Logic
7. Modeling The Dimension Of Time
8. Architectural Patterns
9. Communication Patterns
III. Applying Domain-Driven Design In Practice
10. Design Heuristics
11. Evolving Design Decisions
12. EventStorming
13. Domain-Driven Design In The Real World
IV. Relationships To Other Methodologies And Patterns
14. Microservices
15. Event-Driven Architecture
16. Data Mesh

オライリーサブスクでも読める。

Learning Domain-Driven Design [Book]

Building Microservices

『マイクロサービスアーキテクチャ』の第二版。既に翻訳が進んでいそうな気がする。初版に比べてかなり分厚くなっているので大変そうですが・・・

オライリーサブスクでも読める。

Building Microservices, 2nd Edition [Book]

Software Architecture: The Hard Parts

kawasimaさんが読んでいるのを見て面白そうだなと思っている本。

1. What Happens When There Are No “Best Practices”?
I. Pulling Things Apart
2. Discerning Coupling In Software Architecture
3. Architectural Modularity
4. Architectural Decomposition
5. Component-Based Decomposition Patterns
6. Pulling Apart Operational Data
7. Service Granularity
II. Putting Things Back Together
8. Reuse Patterns
9. Data Ownership And Distributed Transactions
10. Distributed Data Access
11. Managing Distributed Workflows
12. Transactional Sagas
13. Contracts
14. Managing Analytical Data
15. Build Your Own Trade-Off Analysis

ほぼ同じ執筆陣のこちらの方を先に読んだ方が良い説もある。

2022/08/19 追記:翻訳が出ています。

www.oreilly.co.jp

Chapter 1: Introduction
Chapter 2: Architectural Thinking
Chapter 3: Modularity
Chapter 4: Architecture Characteristics Defined
Chapter 5: Identifying Architecture Characteristics
Chapter 6: Measuring and Governing Architecture Characteristics
Chapter 7: Scope of Architecture Characteristics
Chapter 8: Component-Based Thinking
Chapter 9: Architecture Styles
Chapter 10: Layered Architecture Style
Chapter 11: Pipeline Architecture
Chapter 12: Microkernel Architecture
Chapter 13: Service-Based Architecture
Chapter 14: Event-Driven Architecture Style
Chapter 15: Space-Based Architecture
Chapter 16: Orchestration-Driven Service-Oriented Architecture
Chapter 17: Microservices Architecture
Chapter 18: Choosing the Appropriate Architecture Style
Chapter 19: Architecture Decisions
Chapter 20: Analyzing Architecture Risk
Chapter 21: Diagramming and Presenting Architecture
Chapter 22: Making Teams Effective
Chapter 23: Negotiation and Leadership Skills
Chapter 24: Developing a Career Path

いずれもオライリーサブスクでも読める。

Software Architecture: The Hard Parts [Book]

Fundamentals of Software Architecture [Book]

Strategic Monoliths and Microservices

『実践ドメイン駆動設計』の Vaughn Vernon の最新刊。

イベント駆動やCQRSなど技術的な側面と、ビジネスの側面との両面にバランスよく触れられていそうな印象。

Part I: Transformational Strategic Learning through Experimentation
Chapter 1: Business Goals and Digital Transformation
Chapter 2: Essential Strategic Learning Tools
Chapter 3: Events-First Experimentation and Discovery
Part II: Driving Business Innovation
Chapter 4: Reaching Domain-Driven Results
Chapter 5: Contextual Expertise
Chapter 6: Mapping, Failing, and Succeeding—Choose Two
Chapter 7: Modeling Domain Concepts
Part III: Events-First Architecture
Chapter 8: Foundation Architecture
Chapter 9: Message- and Event-Driven Architectures
Part IV: The Two Paths for Purposeful Architecture
Chapter 10: Building Monoliths Like You Mean It
Chapter 11: Monolith to Microservices Like a Boss
Chapter 12: Require Balance, Demand Strategy

オライリーサブスクでも読める。

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture [Book]

Modern Software Engineering: Doing What Works to Build Better Software Faster

『継続的デリバリー』の David Farley の新刊。彼の YouTube はときどき見ている。


www.youtube.com

Part I What Is Software Engineering?
1 Introduction
2 What Is Engineering?
3 Fundamentals of an Engineering Approach
Part II Optimize For Learning
4 Working Iteratively
5 Feedback
6 Incrementalism
7 Empiricism
8 Being Experimental
Part III Optimize For Managing Complexity
9 Modularity
10 Cohesion
11 Separation of Concerns
12 Information Hiding and Abstraction
13 Managing Coupling
Part IV Tools To Support Engineering In Software
14 The Tools of an Engineering Discipline
15 The Modern Software Engineer

オライリーサブスクでも読める。

Modern Software Engineering: Doing What Works to Build Better Software Faster [Book]

Building Secure and Reliable Systems

Amazonの「一緒に購入されている本」で見つけたもの。

Google の SRE本シリーズの第三弾。

目次を見た感じ、テーマが多いので個々の掘り下げはそこまでなのかな?という気がするけど、『Release It!』と近い感じで一読しておいて損はなさそう。

I. Introductory Material
1. The Intersection Of Security And Reliability
2. Understanding Adversaries
II. Designing Systems
3. Case Study: Safe Proxies
4. Design Tradeoffs
5. Design For Least Privilege
6. Design For Understandability
7. Design For A Changing Landscape
8. Design For Resilience
9. Design For Recovery
10. Mitigating Denial-Of-Service Attacks
III. Implementing Systems
11. Case Study: Designing, Implementing, And Maintaining A Publicly Trusted CA
12. Writing Code
13. Testing Code
14. Deploying Code
15. Investigating Systems
IV. Maintaining Systems
16. Disaster Planning
17. Crisis Management
18. Recovery And Aftermath
V. Organization And Culture
19. Case Study: Chrome Security Team
20. Understanding Roles And Responsibilities
21. Building A Culture Of Security And Reliability

オライリーサブスクでも読める。

Building Secure and Reliable Systems [Book]

おまけ: Brutal Refactoring

『レガシーコード改善ガイド』の Michael Feathers の幻の新刊(?)。

発売予定が示されてから発売が遅れに遅れ、今月発売予定になっているのだが、著者のTwitterなどでも全く情報が出てきておらず、本当に出るのかいまだに謎でした。

しかし、↓のインタビューの記録を読むと、これはどうも出版はされないようです。『レガシーコード改善ガイド』にはお世話になっているので楽しみだったのですが・・・

www.infoq.com

It feels like a whack-a-mole type thing because that is not a real book. I gave a workshop on that in Chicago. I forgot how many years ago, but somebody has put that up as a page on Amazon and I need to go and figure out where to go and get that taken down.

アーキテクチャデシジョンレコード(ADR)を組織構造の変更にも適用する

ソフトウェアアーキテクチャに関するプラクティスとして、アーキテクチャデシジョンレコード(Architecture Decision Records, ADR)というものがあります。この記事は、それを組織構造に適用してみるとどうなるだろうと考えてみるものです。100%妄想ですので、予めご了承ください。

(↓妄想が湧いたときのツイート)

2021/11/30 追記: 数日前に、同じくADRを組織の領域に適用する話が出ていました。

dev.classmethod.jp

ADRとは?

今回の題材である(本家の)ADRとは、以下のようなものです。

テキストベースの軽量なテンプレートを使用して、アーキテクチャ上の設計判断を記録する。(中略)設計判断を記録していくことで、それらを共有し分析することが容易になる。意思決定の履歴を残すことで、現在のアーキテクチャについてのコンテキストを、その過程と結びつけて提供できる。

(『Design It! ―プログラマーのためのアーキテクティング入門』p.302)

ADR - iki-iki

アーキテクチャに関する設計判断は、プロジェクトの最初に一回だけなされるというものではありません。設計判断(およびそれに基づくアーキテクチャの変更)は、コンテキストの変化にも対応しながら、継続的に行われていくものです。ADRは、これらの判断を毎回簡潔に記録していくことで、将来の開発者のアーキテクチャに対する理解や判断を助けてくれます。

なぜADRを組織に適用しようと思ったのか?

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』は、チーム編成は継続的に設計していくべきものであると主張しています。

探索や実行といった、プロダクトや技術のライフサイクルにおける各フェーズをサポートするには、チーム同士のやりとりは時間を追うごとに進化する必要がある。

(『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』p.xi)

※『チームトポロジー』については以下の記事をご覧ください

ky-yk-d.hatenablog.com

この書籍では、組織内のコミュニケーション(チーム同士のやりとり)の構造がソフトウェアの開発にとって極めて重要であり、開発の中で実現したい事柄に応じてこれを変更していくことが必要であると指摘されています。この言説に従うならば、チーム編成の変更は、偶発的なものではなく、継続的に行われていくものということになります。

また、この主張の背景には、組織のコミュニケーション構造とそれが生み出すシステムの設計との相関を指摘した「コンウェイの法則」(および、その応用としての「逆コンウェイ作戦」)があります。

以上のことから、継続的に行われるソフトウェアの設計に関する判断を記録していくプラクティスが有効なのだとすれば、ソフトウェアの設計と密接に関わっている組織構造(チーム編成)に関する判断(これも継続的に行われる)を記録していくことにも意味があるかもしれない、というのが今回の着想です。

記録するとよさそうなこと

Michael Nygard による本家ADRのテンプレートは、以下の通りです。同じものをベースにして、補足をしてみます。

  • タイトル(Title)
  • コンテキスト(Context)
  • 内容(Decision)
  • ステータス(Status)
  • 影響(Consequences)

※各項目の訳語は『Design It!』に準拠しました

「コンテキスト」の項目では、本家ADRでは、技術やスキルといったソフトウェアに「近い」内容に限らず、ビジネスの状況などのアーキテクチャに影響を与える要因を記述することが推奨されています。組織構造についての判断についても、ほぼ同様の内容を記述することができるはずです。システムに対する変更の判断が技術以外の要因の影響を受けるのと同様に、組織に対する変更の判断も技術やビジネスなどの要因の影響を当然に受けるからです。

「影響」の項目では、本家ADRでは、判断がシステム、ステークホルダー、チームの状況をどう変えるか(そして変えたか)を記述することが推奨されています。ここも同様の内容を書くことができるでしょう。特に、ネガティブな変化についても記述せよという本家の指摘は、組織に対してこのプラクティスを適用にするときにも重要になると思われます。組織の変更はポジティブな結果を期待して行われるものですが、そこにトレードオフやリスクがあることを(判断する側はもちろん、その他のメンバーも)知っていることは大切です。

何が嬉しい(嬉しそう)なのか?

実践してみたわけではないのですが、本家ADRについて挙げられているメリットや、過去の自身の経験などを踏まえて想像(妄想)してみます。

  • 組織構造に対して変更を加えるというのは、一定のポジションにならないと経験しづらいものですが、判断を記録の形式に落とし込むことで、マネージャー以外のメンバーもその判断について理解することができます。
  • メンバーは、自身が所属するチームの役割だけでなく、他のチームの役割や、それとの関わり方についての「設計思想」も知ることができます。
  • 現時点での組織構造についての歴史的経緯がわかるようになります。歴史的経緯がわかると、今後の方向性について共通認識を持ったり、過去の過ちから学んだりできます。

注意(したほうがよさそうな)点

  • 本家ADRに比べて、GitHubなどのコードに近いところで保存しておくメリットは乏しいように思われます
  • 本家ADRでは、ADRを(GitHubなどを使って)ピアレビューできることもメリットに挙げられていますが、組織の変更について同様の民主化が完全に可能なのかは不明です
  • 最も粒度の小さい変更としての個人の異動については、理由を全て公表することができない場合もありうるでしょうから、そもそも残さないほうが良いようにも思われます

おわりに

以上、組織構造版ADRというプラクティスを考えてみたよというお話でした。

もし、「実践してみたよ!」という方や、「既に似たようなプラクティスをやっているよ!」という方、あるいは「それにはそもそも名前がついていてだな・・・」という方がいらっしゃったら、記事へのコメントないし @koma_koma_dまでぜひご連絡ください(興味本位)。

「ちいとぽ」こと『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版のある方のページのリンクを貼っておきます。