👻

若手がチームトポロジー読んだ感想

2024/02/12に公開

はじめに

株式会社アトラクタ様の翻訳書籍プレゼントキャンペーンに当選しまして、『チームトポロジー』をいただきました!

https://www.attractor.co.jp/news/book-present-2023-winter/?lp=20231213x

読み終わったので、感想を残しておきます。

※前提
この記事を書いている人間は、新卒4年目。組織を設計したりする立場にないです。

チームトポロジーについて

訳者の吉羽さんの登壇・スライドがわかりやすいです。まずは読む前にこれらで概要を押さえるのがオススメです。
https://slide.meguro.ryuzee.com/slides/109
https://www.youtube.com/watch?v=uJL3M7R8MLc

感想

全体

特に何も考えずキャンペーンに応募・当選しこの書籍を読むことになりました。

本書を読む前に、内容を軽く調べると組織設計に関連した話とわかり、現在4年目と自分が組織を設計したりする立場にはない自分からすると、少し億劫に感じたのが正直なところです。

学びはもちろんありましたが、いつか必要なタイミングで読み直すと効果的と考えてます。

本書はソフトウェアシステムのデリバリーと運用の有効性に関心を持った人のためのものだ。CTO、CIP、CEO、CFOなどのCレベルのリーダー、部門長、ソフトウェアアーキテクト、システムアーキテクト、その他ソフトウェアシステムの構築や運用に関わっていて、もっと効果的にデリバリーや運用をしたい人たちに向けたものである。

チームトポロジーは、安定した早いフローを実現するためのものなので、ソフトウェアシステムのデリバリーと運用に興味がありさえれば、関心を持って読めはずです。

共通言語ができる

タイミーさんの登壇の中で、以下のように述べられています。

チームの進化の実現はCTOやVPofEなど閉じた行為ではないと考えます
共通言語の獲得により全員で組織に向き合えるようになる
https://timee.notion.site/Team-Topologies-Study-98b49ec983c64965a98595456873e6f1

共通言語を獲得することでCTOやマネジメントレイヤーの方に任せる一方ではなく、自分のような現場の1人も組織に向き合う土台を作れると思いました。

特に、書籍の内容として中心に据えられている「4つのチームタイプと3つのインタラクションモード」を知っておくと、テンプレートとして使うことはもちろん、組織構造に関する対話が円滑に進むことでしょう。

コンウェイの法則の話

本の中で、コンウェイの法則の重要性の説明が何度もあります。

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

元々聞いたことのあった言葉ではあるものの、解像度は低い状態でした。

コンウェイの法則を利用した逆コンウェイ戦略をとるために、組織設計とソフトウェア設計は、両方に関して同じだけの知識を持った人たちによってなされる必要があると主張されていて、目から鱗でした。

実際に、組織設計とソフトウェア設計は同じコインの裏表であり、どちらも同じだけの知識を持った人たちによってなされる必要がある

アーキテクトを名乗る人には技術的スキルと社会的スキルの両方が必要であり、人間を理解し社会の枠組みの中で仕事をする必要があるということだ。

認知負荷

速いフローを実現するために、どうやって認知負荷を制限するかについても触れられていました。

その中で3種類の認知負荷の定義が紹介されていて、興味深かったです。

  • 課題内在性負荷
    • 意味)問題領域の本質的なタスクに関連するもの
    • 例)基本的なプログラミングの知識や開発言語に関する知識
  • 課題外在性負荷
    • 意味)タスクが実施される環境に関連するもの
    • 例)テスト環境を動的に起動するためのコマンドの詳細など。
  • 学習関連負荷
    • 意味)学習を進めたり高性能を実現したりする上で、特別な注意が必要なタスクに関連するもの
    • 例)開発対象のドメイン知識や品質向上のための学習など。

研修や雇用・ペアプログラミングなどを行なって課題内在性負荷を最小化しつつ、自動化などによって課題外在性負荷を取り除くことで、付加価値について考えるための学習関連負荷に使えると余力が増える、という旨が書かれており、ぼんやり頭の中にあった事柄が言語化されていてクリアになりました。

エンジニアリングプラクティスが基礎

PART1の最後の「エンジニアリングプラクティスが基礎」という欄が心に残りました。

技術チームは、実績のある継続的デリバリーやテストファースト開発のようなプラクティスに日々投資し、ソフトウェアの運用性とリリース可能性に集中しなければいけない。いくらチームファーストアプローチに投資したとしても、それらの技術がなければ、目標の達成は難しく大きな成果は得られなくなる。

すべてのプラクティスが、早いフローには必須であり、すべてのエンジニアリングチームの継続した努力を必要とするのだ。

本書では、速いフローのために、組織設計の観点でのアプローチが書かれているが、当然技術的なアプローチは必須と再認識しました。

おわりに

いずれ読み返せればと思います。
次は、本の中で何度も言及されていた『LeanとDevOpsの科学』を読みたいです。

Discussion