エンジニア組織の文化の話は自分は関心のある領域で、どの章も面白く読んだのですが、中でも印象的だったのは第4章の「公正のためのエンジニアリング」です。分量としては多くないのですが、Google が（過去の失敗も踏まえつつ）どのようにダイバーシティなどの課題に取り組んでいるのかなどが書かれていて、面白く読みました。日本の企業では Google ほどこの論点についての課題感は強くなりづらいと思いますが、この書籍で丸々一章がこのテーマのために割かれたのは意味のあることだと思います。
スタイルガイド、コードレビュー、ドキュメンテーション、テスト、廃止について取り上げています。Google のテストについては、『テストから見えてくるグーグルのソフトウェア開発』（未読です）という本があるほか、 Google Testing Blog でもアウトプットを見ることができますが、本書ではかなり紙幅を割いて説明がされています。
記事の紹介はここまでで、ここからは自分の話なのですが、自分は結構な割合の労働時間を Glue Work に時間を割いている時期が今まで多かったです。コーディングが嫌いなわけではないし、技術に興味がないわけでもないのですが、どちらかというとコーディング以外の形でプロジェクトやチームに貢献するという機会の方を選択してきたように思います。
Glue Work についての記事は、自分のキャリアについて特定の方向の示唆を与えるものでもないのですが、改めて自分のキャリアというものを考えてみたときに、どういう仕事を日々選択してやるのかというところも重要になってくるな、というのを改めて思わされました。自分のキャリアの観点とは別に、チームの状況という観点からも、これまでと同じ動き方をしていくことがベストではないのではないかというのが最近思い始めていることなので、改めて自分の働き方、動き方について、チームのメンバーやマネージャー、あるいは社外の人たちと話し合ってみたいなと思いました。
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
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
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
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
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
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
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.
