PARTⅠ デリバリーの手段としてのチーム
KEY TAKEWAYS 要点
Chapter 1
・コンウェイの法則では、ソフトウェアアーキテクチャーとチームインタラクションを同時に設計する利点を説いている。両者に働く力は同じものだからだ
・チームトポロジーはチームの目的と責任を明確にし、チーム間の相互関係の効果を向上させる
・チームトポロジーでは、戦略適応性の実現のために組織を調整しつつソフトウェアシステムの構築においては人間的なアプローチを利用する
過去数十年にわたって、ビジネスを構成するための新しいアプローチがたくさん登場した。それらは依然として組織を静的なものとして見ていさて、組織を再編したあとに起こる現実のふるまいや構造は考慮に入れていなかった。たとえば、1990年代に登場しそこから数十年でかなり普及した「マトリクスマネジメント」は、個人にビジネスマネジャーとファンクショナルマネジャーの双方に報告させることで、複雑で、不確実性が高くさて、高度なスキルが必要な仕事に対応しようとした。純粋な職能型組織のチーム構造と比べると、ビジネス価値に焦点を当てているとはいえ、これもまた静的な世界観であり、ビジネスや技術の領域が急激に進化するにつれ、時代遅れになっていく。
Chapter 2
・組織はそのコミュニケーションパスを反映した設計を作り出す
・組織設計はソリューション探索の制約になり、取りうるソフトウェア設計を限定する
・全員が他のすべての人とコミュニケーションするよう求めるのは、混乱のもとである
・チーム内のフローがよくなるようなソフトウェアアーキテクチャーを選択せよ
・明瞭なチームインタラクションだけにコミュニケーションバスを限定することで、モジュール化した疎結合なシステムが生まれる
コンウェイの法則の背後にある同形性を示す証拠が増えていることを考えると、技術リーダーの意見を聞かずにチームの形成、責任、境界について決定を下すというのは、ソフトウェアシステムを構築する組織にとって非常に非効率で、そしておそらく無責任なのだ。
実際に、組織設計とソフトウェア設計は同じコインの裏表であり、どちらも同じだけの知識を持った人たちによってなされる必要がある。アラン・ケリーのソフトウェアアーキテクトの役割についての見解は、この考えをさらに発展させたものだ。
これまで以上に確信するようになったことがある。アーキテクトを名乗る人には技術的スキルと社会的スキルの両方が必要であり、人間を理解し社会の枠組みのなかで仕事をする必要があるということだ。同時に、彼らには純粋な技術にとどまらない広範な権限が必要だ。組織構造や人事問題についても発言権を持つ、つまりマネジャーになる必要があるのだ。
基本的に、組織設計にはエンジニアを巻き込む必要がある。というのも彼らは、APIインターフェイス、抽象化、カプセル化といった重要なソフトウェア設計の概念を理解しているからだ。ナオミ・スタンフォードはこのように付け加える。
「部署や課、システム、ビジネスプロセスといったものは、設計の一部としてより広い組織とのインターフェイスや境界を決める場合に限り、独立して設計できる」
Chapter 3
・チームはソフトウェアデリバリーにおける最も効果的な手段である。個人ではない
・ダンバー数を踏まえて、組織のグループのなかのチーム数を制限する
・チームの認知負荷の許容量に合わせて、責任を限定する
・チームごとに明確な責任の境界を作る
・チームの成功の助けとなるよう作業環境を変える
PART Ⅱ フローを機能させるチームトポロジー
KEY TAKEWAYS 要点
Chapter 4
・その場しのぎや頻繁なチーム設計の変更はソフトウェアのデリバリーを遅くする
・唯一絶対のトポロジーはないが、どの組織にとっても不適切なトボロジーはある
・どのトポロジーにするかを検討する際は、技術面や文化面での成熟度、組織の規模、技術面での規律といった観点が欠かせない
・特に、フィーチャーチームやプロダクトチームのパターンは強力だが、それを支える環境がある場合のみ機能する
・チームの責任を分割することでサイロを壊し、他のチームの能力を高める
Chapter 5
・4つの基本的なチームタイプによって、現代のソフトウェアチーム間のインタラクションは単純化できる
・業界におけるよくあるチームを基本的なチームタイプにマッピングすることで、オーナーシップの不明瞭さや過負荷または低負荷なチームを取り除き、組織を成功に導ける
・中心となるチームタイプは、ストリームアラインドチームだ。その他のチームタイプはすべてストリームアラインドチームを支援する
・その他のチームタイプとして、イネイプリングチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームがある
・トポロジーは大規模になると、しばしばフラクタル(自己相似)な形となる。すなわちチームから構成されるチームだ
ストリームアラインドチームが備える能力
一般的に、ストリームアラインドチームは初期の要求探索の段階から本番運用まで作業を進めるのに必要な能力一式を備えている必要がある。そこのような能力には以下のようなものが含まれる(これに限らない)。
・アプリケーションセキュリティ
・事業成長性分析と運用継続性分析
・設計とアーキテクチャー
・開発とコーディング
・インフラストラクチャーと運用性
・メトリクスとモニタリング
・プロダクトマネジメントとオーナーシップ
・テストとQA
・ユーザーエクスペリエンス (UX)
Chapter 6
・チームファーストのアプローチを活用して、ソフトウェア境界を選択する
・ソフトウェアのデリバリーチェーンにおいて、隠れモノリスや結合に気をつける
・ビジネスドメインで境界づけられたコンテキストを踏まえたソフトウェア境界を利用する
・必要に応じて別のソフトウェア境界を検討する
PART Ⅲ イノベーションと高速なデリバリーのためにチームインタラクションを進化させる
KEY TAKEWAYS 要点
Chapter 7
・ソフトウェアデリバリーを強化するには、いずれかのチームインタラクションモードを選択する
・チームインタラクションモードにはコラボレーション、X-as-a- Service、ファシリテーションの3種類があり、他のチームにサービスを提供したり、そのサービスを進化させたりする
・コラボレーションはイノベーションを強力に推進するが、フローを低下させる可能性がある
・X-as-a-Serviceは他のチームがすばやくデリバリーするのを助けるが、それは境界が適切な場合に限られる
・ファシリテーションは複数チームをまたぐ問題の発生を回避したり、問題を見つけたりするのに役立つ
Chapter 8
・戦略的優位性の追求のために、異なるトポロジーを同時に活用する
・新しいアプローチの導入を加速するために、チームタイプやチームインタラクションを変える
・チームトポロジーを活用して、探索、開発、終了フェーズを区別する
・さまざまなニーズに対応するために、複数のチームタイプが同時に存在することを想定しておく
・組織変更のトリガーを認識しておく
・運用は、自律操舵のための高精度な入力センサーとして扱う
Chapter 9
・チームファーストのアプローチとコンウェイの法則、4つの基本的なチームタイプ、チームインタラクション、トポロジーの進化、組 織的センシングを組み合わせる
・さあ始めよう。 まずはチームから始めて、ストリームを特定し、 最 低限のプラットフォームを明らかにし、 能力ギャップを見極め、チームインタラクションを実践しよう
■4つのチームタイプと3つのインタラクションモード
4つの基本的なチームタイプは以下のとおりだ。
・ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデリバリーする能力を持つ
・プラットフォームチーム：下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。プラットフォームは、直接使うと複雑な技術をシンプルにし、利用するチームの認知負荷を減らす
・イネイブリングチーム：転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける
・コンプリケイテッド・サブシステムチーム：普通のストリームアラインドチーム、プラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。本当に必要な場合にだけ編成される
速いフローで効果的なソフトウェアのデリバリーを行うのに必要なのは、これらのチームの組み合わせだけだ。だが、効果的なソフトウェアデリバリーとは何なのかを理解し、それを実現していくには、4つの基本的なチームタイプ間のインタラクションモードも極めて重要である。
・コラボレーションモード： 特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。学習のペースを加速する上で、このオーバーヘッドには価値がある
・X-as-a-Serviceモード：あるチームが、別のチームが提供する何かを利用する(API、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
・ファシリテーションモード：あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする
