はじめに
”チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計” を読んだ。
要約
この本は、主に DevOps の観点で、ソフトウェアの高速なデリバリーと運用を実現するために、どのようなチームや組織を作るのが良いか、実践的で段階的な組織設計のモデルについて書かれている。
個人ではなく、"チーム"がソフトウェアをデリバリーしていくにあたっての最も重要な単位と考え、チームが最大限にパフォーマンスを発揮するために、チームの人数やその責任の範囲に基づいたチームデザインとして、4つの基本的なチームのタイプや、そのチーム間のコミュニケーション方法に関する３つのパターンが紹介されている。
内容の構成としては、3つのPartからなる。 Part1 ではコンウェイの法則についての考察、組織構造がシステム設計に与える影響・制約、これをどう活かすか、といったことについて述べられている。Part2 では、実際に採用されているチーム構成におけるアンチパターンや成功パターン、それを踏まえての 4 つの基本的なチームタイプについて紹介されている。Part3 ではソフトウェアのデリバリー高速化するための 3 つのコミュニケーションパターンについて述べられ、現在の環境下でどのようなアプローチをしていくのが良いか、といった感じのことが書かれている。
読書メモ
### コンウェイの法則と逆コンウェイ戦略 メルヴィン・コンウェイという方によって生み出された「システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう」という法則。 例えば、職能別な縦割り組織だと、複雑なアーキテクチャで組織間のコミュニケーションが多く必要なシステムになってしまう、ということ。 それを踏まえて、「チーム構造と組織構造を進化させて、望ましいアーキテクチャを実現すべきだ」というのが逆コンウェイ戦略。 ### チームファースト チームトポロジーでは近年のソフトウェア開発において、ソフトウェアを開発して進化させていくには個人では継続不可能として、「チーム」に注目している。 チームの認知不可を軽減させ、チームやチーム連携のパフォーマンスを最大化させることを目指している。 ### チームAPI ITにおける API (ソフトウェアコンポーネント同士が互いに情報をやりとりするのに使用するインタフェース仕様)を、チームに対して置き換えた表現。 他のチームとのやりとりのために必要なあらゆることを決める。 例えば以下の様なものが挙げられていた。 * コード: チームが開発しているシステムのエンドポイントやライブラリ、UI など * バージョン管理 * Wiki/ドキュメンテーション: チームがオーナーシップをもつソフトウェアのHowTo * プラクティス: チームが好む働き方 * コミュニケーション: チームへのアプローチ方法。チャットツールやオンライン会議ツールなど。 * 仕事に関する情報: チームが取り組んでいること * その他: このチームが他のチームとやりとりするために必要なものはなんでも チームは継続的にチームの API を定義して公開し、テストして進化させ、API を利用するユーザーの目的に合っているように振る舞う必要がある、とのこと。 ### 4つの基本的なチームタイプ * ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ * プラットフォームチーム：下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす * イネイブリングチーム：転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける * コンプリケイテッド・サブシステムチーム：普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成 ### 3つのインタラクションモード * コラボレーションモード：特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある * X-as-a-Serviceモード：あるチームが、別のチームが提供する何かを利用する（API、ツール、ソフトウェア製品全体など）。コラボレーションは最小限になっている * ファシリテーションモード：あるチーム（通常はイネイブリングチーム）が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする
