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

感想・レビュー・書評

• 

  スタヰルさんの感想

  フォロー

  2023年12月23日

  # 多方面からプロダクトに立ち向かうための、戦略的組織論
  
  ## 面白かったところ
  
  - 組織とソフトウェアアーキテクチャは密接に関わり合っており、人こそがソフトウェアであり組織を良くも悪くもすることがわかった
  - 自分が管轄外のプロダクトには適切な境界線（interface）を切って、異なる概念を持ち込まない・持ち込ませない制約があるとイイことを改めて学べた点
  
  ## 微妙だったところ
  
  - 引用がとても多く、著者自身の熱い思いがあまりなかった点。チームトポロジーのフレームワークはすごいしやってみる価値はあるんだけど、イマイチ引き込まれれる何かがなかった。
  
  ## 感想
  
  現場での課題図書として上がっていた一冊。なにもないところから著者の真意を汲み取ることは難しいだろうなとは思いつつ、現場での組織構成を擬えて見るとかなりイメージが進んだ。
  
  人間一人の認知負荷にも限界があり、チームのそれにも限界がある。この前提を踏まえたうえで、自チームで担当すること・しないことのドメイン境界を切ってinterfaceでハーネスをかける。
  
  「〇〇チームは▲▲機能の担当」という境界を　Package by Featureで区切る。多機能とやり取りするときは必ずInterfaceを切って、他チームとコミュニケーションを図る。
  
  なるほど。今やっている僕らの軌跡はこの本からやってきたんだと腑に落ちた。

  5

  詳細をみる
  コメント0件をすべて表示
• 

  げんえいさんの感想

  フォロー

  2021年12月9日

  組織構造とプロダクトが連動するのは別の本で「コンウェイの法則」に出会って知っていてが、より組織構造をどのようにすればよいのかのヒントになる。
  IT業界の話ではあるけどもこれはどれぐらい他の組織にも応用できるのかも気になった。
  また、「コンウェイの法則」が言われてからこんなにも時間が経ってから組織構造に注目があるのかが不思議である。これまでは組織よりも個人の生産性が高ければなんとかなっていたのかな。

  1

  詳細をみる
  コメント0件をすべて表示
• 

  miyazaghiさんの感想

  フォロー

  2024年1月22日

  カタカナ語と抽象的な概念が多くやや掴みにくさはある。コンウェイの法則は、ソフトウェアと開発チームの関係性を指し示す概念で真を食っていると感じる。
  
  セントラル方のアナリティクス組織に置き換えた時に3つのコラボレーション全てが当てはまるので、組織を最適化させる際には切り分けて考える必要がありそう。
  
  ① コラボレーション
  ② X as a Services
  ③ ファシリテーション
  ↓
  ①例：ビジネスパートナー活動・レポート作成
  ②例：tableauダッシュボード提供（作成ではなく
  ③例：セルフBI活動

  0

  詳細をみる
  コメント0件をすべて表示
• 

  ゆぺこさんの感想

  フォロー

  2023年9月11日

  ITエンジニア本大賞より (https://www.shoeisha.co.jp/campaign/award)

  0

  詳細をみる
  コメント0件をすべて表示
• 

  T.Horiさんの感想

  フォロー

  2023年8月7日

  近年のソフトウェア開発における組織のあるべき姿をシンプルに解説した良書。
  4つのチームと3つのインタラクションモードという切り分け方は、実際の業務においても納得感があった。
  一方で、このプラクティスを適用できる段階・できない段階の組織というものはそれぞれありそう。
  本書に登場する単語は独特なものばかりで、概念を知らない人には伝わりづらい部分がある。
  とはいえ、難解な概念は少なく、昨今の組織戦略の文脈では多く登場するのもあって、理解と咀嚼に時間を割く価値はあるなと感じた。
  
  コミュニケーションパスの制限による開発速度の向上は実感としても感じるものがあるが、チーム間のコミュニケーションによって生まれていた何らかが生まれづらくなる懸念があるのではないかと感じた。
  そういった部分を俯瞰的に見る役目はイネイブリングチームか、あるいはEM的な立場の人になるんだろうか。

  0

  詳細をみる
  コメント0件をすべて表示
• 

  さとうさんの感想

  フォロー

  2023年7月14日

  非常に引用数の多い書籍
  今の自分では有効活用できないなと感じたが、改めて読み直したい一冊

  0

  詳細をみる
  コメント0件をすべて表示
• 

  japapizzaさんの感想

  フォロー

  2023年3月4日

  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、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
  ・ファシリテーションモード：あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする

  0

  詳細をみる
  コメント0件をすべて表示
• 

  会津大学情報センター（附属図書館）さんの感想

  フォロー

  2023年2月1日

  [ITエンジニア本大賞] 2023年特別賞

  0

  詳細をみる
  コメント0件をすべて表示
• 

  kyosawaさんの感想

  フォロー

  2022年10月20日

  詳細はkobo上のラインマーカー参照
  
  ・組織のコミュニケーション構造
  　チームトポロジーでは、チームが新しい状況に素早く対応し、ソフトウェアを高速化つ安全にデリバリーするのに役立つ動的なチーム構造とインタラクションモードをいかにして実現するかに焦点を当てている。現時点では、これがあなたにとって最大のボトルネックではないかもしれない。だが、いずれは、コミュニケーション不足や不適切なプロセスによって硬直したチーム構造がデリバリーを遅くするという問題に直面する。
  
  　組織図が仕事の終わらせ方やチーム間のやりとりを忠実に表したものだと考えてしまうと、仕事の割り当てや責任について効果的な判断ができなくなる。ソフトウェアアーキテクチャーのドキュメントが、実際のソフトウェア開発が始まるとすぐに陳腐化するのと同じように、組織図も常に現実と一致していないのだ。
  
  　組織図やマトリクスマネジメントのような単一で静的な組織構造を利用していては、現代のソフトウェアシステムで効果的なアウトカムを生み出せないことが徐々に明らかになってきている。必要なのは単一の構造ではない。チームの成長やチーム間のインタラクションを考慮に入れた、現在の状況に適応可能なモデルが必要なのだ。チームトポトジーでは、あらゆる種類の組織で、チーム・プロセス・技術の整合性を保つための(再)進化的なアプローチを提供する。
  
  ・チームトポトジー：チームについての新しい考え方
  　チームトポトジーのアプローチでは、組織設計において適応型モデルを重視し、チーム間の相互関係に積極的に優先順位をつける。それによって、ソフトウェアの比重が高い現代の企業が、ビジネスや技術の観点で戦略変更が必要になったことを感知するための、特定の技術に依存しない重要なメカニズムを提供する。最終的なゴールは、顧客のニーズに合うソフトウェアをチームがより簡単に構築・実行し、オーナーシップを持てるようにすることである。
  
  　また、チームトポロジーでは、ソフトウェアシステムの設計と構築において人間的なアプローチも重視している。チームをソフトウェアデリバリーにおける不可分な要素と捉え、チームの認知容量には尊重すべき上限があることを認めている。チームトポトジーは、コンウェイの法則を確たる土台とした動的なチーム設計を活用しており、ソリューション探索のための戦略的ツールになっている。
  
  ・図1.2 速いフローを実現する上での障害
  - コンウェイの法則への対抗
  - チームにとって大きすぎるソフトウェア
  - 組織設計の選択による混乱
  - チームが引っ張りだこ
  - 数年ごとの苦痛な組織再編
  - ブロックされているフロー
  - 不測の事態の多発
  - モチベーションの低いチーム
  
  ・コンウェイの法則を理解する
  　正式な指揮命令系統かどうかに関係なく、組織内のコミュニケーションパスが、組織が考案できるソリューションの種類を事実上限定する。だが私たちは、戦略的優位のためにこれを利用しても良いのだ。ある種の設計(たとえば、技術的な内部に焦点を当てすぎたもの)を使わせたくないなら、そうならないように組織を再編すればよい。
  
  同じように、組織にある種の設計(たとえば、フローに適したもの)を発見し使わせたければ、そうなるように組織を再編すれば良い。もちろん、私たちが望む設計を組織が見つけて利用する保証はないが、少なくともコミュニケーションパスを形成することによってその可能性は高められる。
  
  ・逆コンウェイ戦略
  　組織がフローに最適化された効果的なソフトウェアシステムを構築する可能性を高めるには、逆コンウェイ戦略を選択し、ソフトウェアが完成するより前にチーム間の相互のコミュニケーションを再構成するとよい。初めは反発を受けるかもしれないが、マネジメントの十分な意志とチームの意識があればこのアプローチはうまくいく。
  
  ・図2.4 独立サービスとデータストアを持つマイクロサービスアーキテクチャーのためのチーム設計
  コンウェイの法則の背後にある同形力を未然に防ぐ組織設計で、4つの独立したマイクロサービスを持つソフトウェアアーキテクチャーを作りやすくする。この図も基本的には図2.3の図を90度回転させただけである。
  
  ・組織設計には技術的専門知識が必要だ
  　コンウェイの法則の背後にある同形性を示す証拠が増えていることを考えると、技術リーダーの意見を聞かずにチームの形成、責任、境界について決定を下すというのは、ソフトウェアシステムを構築する組織にとって非常に非効率で、そしておそらく無責任なのだ。
  
  　これまで以上に確信するようになったことがある。アーキテクトを名乗る人には技術的スキルと社会的スキルの両方が必要であり、人間を理解し社会の枠組みの中で仕事をする必要があるということだ。彼らには純粋な技術にとどまらない広範な権限が必要だ。組織構造や人事問題についても発言権を持つ、つまりマネジャーになる必要があるのだ。
  
  ・不必要なコミュニケーションを制限する
  　コンウェイの法則の示す重要な点は、すべてのコミュニケーションとコラボレーションが良いとは限らないということだ。したがって「チームインターフェイス」を定義し、どんな仕事には強力なコラボレーションが必要で、どんな仕事には必要ないのかという期待値を設定することが重要になる。多くの組織はいつでもコミュニケーションは多い方が良いと考えるが、実際にはそうではない。
  
  　必要とされるのは、特定のチーム間における集中的なコミュニケーションだ。予期せぬコミュニケーションを探し、その原因に取り組むことが重要なのだ。マヌエル・ソーサらが2004年に航空機製造産業を対象に行った研究でも明らかになったように、「マネジャーは、モジュラーシステム全体で、設計インターフェイスが定まっていない原因や、予期せぬチームインタラクションの原因を理解することに努めるべきだ」ということだ。
  
  ・長続きする小さなチームを標準とする
  　本書では、「チーム」は明確な意味を持って使われる。チームとは、5人から9人のメンバーからなる安定したグループで、共有されたゴールのために働く単位のことだ。私たちは、チームをソフトウェアの提供が可能な組織内で最小の単位として捉えている。
  
  　チームサイズの限界とダンバー数の関係は、チーム・部門・仕事のストリームの数、ビジネスラインの数などでも同じだ。人類学における研究でも、人が深い関係を結べる人の数には7という明確な限界があることがわかっている。
  - およそ5人：人が親密な関係、もしくはワーキングメモリーを保持できる人数の限界
  - およそ15人：人が深く信頼できる人数の限界
  - およそ50人：人が相互信頼できる人数の限界
  - およそ150人：人が他の人の能力を覚えていられる限界
  
  　チームを作って、そのチームが効果的に働けるようになるには時間がかかる。チームが一体として働けるようになるには、2週間から3ヶ月以上かかるのが一般的だ。
  〜中略〜
  フレデリック・ブルックスが、この業界では古典とされる「人月の神話」で指摘し、ブルックスの法則として知られるようになった通り、チームに新しい人を追加してもすぐにキャパシティが増えるわけではない。
  
  　ベストなやり方は、アラン・ケリーが2008年の著書「Project Myopia」で示したように、チームを安定させ「チームに仕事が流れ込む」ようにすることだ。チームは安定している必要があるが、固定してはいけない。必要な時に時々変えるのだ。
  　高信頼な組織では、人が年に1回チームを移っても、チームのパフォーマンスに大きな問題が出ることはない。例えば、クラウドソフトウェアを専門とするPivotalでは、「エンジニアは9ヶ月から12ヶ月毎に他のチームに移っている」。
  
  ・適切な境界が認知負荷を下げる
  　チームが担当するソフトウェアサブシステムやドメインのサイズを拡大したい場合は、チームの認知容量を最大化できるように課題内在性負荷および課題外在性負荷を削減し、チームが働くエコシステムを調整する。
  
  ・「チームAPI」を設計して、チームインタラクションを促す
  　チームや人がお互いにコミュニケーションしながら学ぶための時間と場所を明示的に確保しておくことで、組織では、効果的なチームインタラクションを促す学習と信頼関係のリズムが作れるようになる。チームが信頼関係を築き新しいことを学ぶのを助けるには、2つのことが必須になる。
  　1. 意識して設計された物理環境および仮想環境
  　2. ギルド活動のためにデスクから離れる時間。コミュニティオブプラクティス(自主的に定期的に集まって興味のあるドメインについて一緒に学んだり、内部の技術カンファレンスを開いたりして、知識を共有するグループ)
  
  ・成功しているチームのパターン
  　フィーチャーチームとは、職能横断型かつコンポーネント横断型のチームのことで、顧客向けの機能のアイデア検討から構築までを一貫して行い、顧客に提供し、理想的には使用状況やパフォーマンスを監視できるチームを指す。
  
  　プロダクトチームの目的や特徴はフィーチャーチームと同じだが、1つかそれ以上のプロダクトの機能全体を担当するという点が異なる。プロダクトチームは、自分達の成果をエンドユーザーに提供する上で、インフラストラクチャー、プラットフォーム、テスト環境、ビルドシステム、デリバリーパイプラインなどに依存する。
  〜中略〜
  　チームが自律的でいるのに重要なのは、外部への依存関係をノンブロッキングにすることだ。すなわち、新機能はできているのに、外部の何かを待っているということがないようにする。
  
  ・トポロジーを選択する場合に考慮すること
  　ここまで見てきた例の全てで、チームの能力(もしくは能力不足)とそれがチーム間の依存関係をどう引き起こすかについて考える重要性を訴えている。仕事が多くなったときに単にチームを複製したり人を追加したりするのではなく、より多くのメリットを享受するにはどの依存関係を取り除くべきか、どの依存関係は明示的に受け入れるかを考えることが重要なのだ。
  
  ・4つの基本的なチームタイプ
  　適切なチームが配置されているだろうか？チームの自立と他のチームからのサポートはバランスが取れているだろうか？チームの種類を以下の4つの基本的なチームタイプにまで減らしてしまえば、そのような質問に答えるのは簡単になる。
  - ストリームアラインドチーム
  - イネイブリングチーム
  - コンプリケイテッド・サブシステムチーム
  - プラットフォームチーム
  
  ちょっと注意すれば、モダンなソフトウェアシステムの開発と運用に必要なのはたった4つのチームタイプであることがわかる。効果的なソフトウェア境界とチームインタラクションがあれば、これら4つのチームタイプに制限することで、効果的な組織設計をする上での強力なテンプレートになる(図5.1)。
  
  ・ストリームアラインドチーム
  　ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザペルソナの1つのような場合もあるだろう。さらに、なるべきそのチームだけで素早く安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ないということだ。
  
  　ストリームアラインドチームは、組織で根幹となるチームタイプで、残りの基本的なチームタイプの目的は、ストリームアラインドチームの負荷を減らすことにある。
  
  本章の後半で見ていくが、例えばイネイブリングチームのミッションは、ストリームアラインドチームが欠いている能力を素早く獲得するのを助けることにある。調査や試験の作業を行い、役に立つプラクティスを準備するのだ。
  
  プラットフォームチームのミッションは、下位の詳細な知識(プロビジョニング、監視、デプロイなど)を引き取り、使いやすいサービスを提供することでストリームアラインドチームの認知負荷を減らすことだ。
  
  ・イネイブリングチーム
  　イネイブリングチームは、特定のテクニカル(プロダクト)ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。
  
  イネイブリングチームの最終的なゴールは、ストリームアラインドチームへのソリューションの提供ではない。ストリームアラインドチームの課題に注力することで、ストリームアラインドチームの自律性を高めることである。イネイブリングチームがうまく機能すれば、ストリームアラインドチームは、イネイブリングチームからの支援を数週間から数ヶ月で必要としなくなるはずだ。イネイブリングチームへの継続的な依存関係は作るべきではない。
  
  ・プラットフォームチーム
  　プラットフォームチームの目的は、ストリームアラインドチームが自律的に仕事を届けられるようにすることである。ストリームアラインドチームは本番環境のアプリケーションの開発、運用、修正を含む全体のオーナーシップを持つ。プラットフォームチームは、内部サービスを提供することで、ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる。
  
  　プラットフォームチームは、少数のサービスを高い品質で提供することに集中するのが現実的だ。多数のサービスを提供していても、品質やレジリエンスの問題だらけでは話にならない。投入する労力と品質のバランスを常に保たなければいけない。
  
  ・サポートチームを変換する
  　サポートにフォーカスするチームは、同じ変更のストリームに沿っているチームのトライブやファミリーの中に配置される。この状況では、サポートを提供するチームは、サービス全体のユーザーエクスペリエンスを認識するようになり、ITやソフトウエアの範囲を超えたエンドツーエンドのトランザクションのモニタリングを追加したりするようにもなる。このようなチームを「サービスエクスペリエンスチーム」と改名した組織もある。エンドツーエンドのユーザエクスペリエンスは単なるITシステムの範囲を大きく超えるものになるからだ(図5.4)。
  
  ・ソフトウェアの境界、または「節理面」
  　節理面は、ソフトウェアシステムを簡単に複数に分割できる自然な継ぎ目のことだ。このようなソフトウェアの分割は、特にモノリシックなソフトウェアで役に立つ。モノリスという言葉はギリシャ語から来ていて、「1つの石」を意味する。伝統的な石工は、石を特定の角度で叩き、自然の節理面を利用して岩をきれいな断面で分割していく。ソフトウェアでも同じような節理面を探せば、ソフトウェアの境界となるような自然な分割点が見つかるはずだ。
  
  　通常は、ビジネスドメインの違いとソフトウェアの境界を合わせるのが最善だ。モノリスは技術的な観点で見ても問題が多い。特に、時間とともに構築やテキスト、問題の修正にだんだん時間がかかるようになり、価値をデリバリーする速度が遅くなっていく点が問題だ。
  
  　一般的でもある技術主導での分割は、往々にして更なる制約を生み出し、フローを改善するどころかフローを低下させる。技術主導で分割すると、全体的な視点ではそれぞれのチームの作業の透明性は低くなり、チーム内のコミュニケーションと比べてチーム間のコミュニケーションは遅くなる。その上、プロダクトの依存関係が残り続けるため、チームの自律性が低くなるのだ。
  
  ・3つのチームインタラクションモード
  　ソフトウェアシステムのためのチームトポロジーモデルをいつどのように適用するかを理解するには、チームファーストの力学とコンウェイの法則を考慮した上で、チームがインタラクションする3つの基本的なモードを定義し、理解することが必要だ。
  - コラボレーション：他のチームと密接に協力して作業すること
  - X-as-a-Service：最小限のコラボレーションで何かを利用または提供すること
  - ファシリテーション：障害を取り除くために他のチームを支援したり、支援を受けたりすること
  
  ・表7.1 コラボレーションモードの強みと弱み
  典型的な使用法：
  - コンプリケイテッド・サブシステムチームと共同作業する、ストリームアラインドチーム
  - プラットフォームチームと共同作業する、ストリームアラインドチーム
  - プラットフォームチームと共同作業する、コンプリケイテッド・サブシステムチーム
  
  ・表7.2 X-as-a-Serviceモードの強みと弱み
  典型的な使用法：
  - プラットフォームチームのPlatform as a Serviceを使用する、ストリームアラインドチームとコンプリケイテッド・サブシステムチーム
  - コンプリケイテッド・サブシステムチームの提供するコンポーネントやライブラリを使用する、ストリームアラインドチームとコンプリケイテッド・サブシステムチーム
  
  ・表7.3 ファシリテーションモードの強みと弱み
  - ストリームアラインドチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチームを支援するイネイブリングチーム
  - ストリームアラインドチームを支援するストリームアラインドチーム、コンプリケイテッド・サブシステムチーム、プラットフォームチーム
  
  ・表7.4 基本的なチームタイプのチームインタラクションモード
  - プラットフォームチームは「X-as-a-Service」が典型的で、「コラボレーション」は偶発的
  
  ・表7.5　4つの基本的なチームタイプのためのインタラクションモードの基本形
  - ストリームアラインドチームは「X-as-a-Service」または「コラボレーション」を使用する
  - イネイブリングチームは「ファシリテーション」を使用する
  - プラットフォームチームはプラットフォームチームを利用するチームのために「X-as-a-Service」を使用する
  
  　例2. プラットフォームチームは、新しい技術的アプローチを評価するためにストリームアラインドチームとは密接にコラボレーションすることを期待されているが、他のチームからのインタラクションはほとんどない。
  
  プラットフォームチームには、ストリームアラインドチームとの重要なコミュニケーションが期待されている。これは彼らが新しいコラボレーションモードを使用して、新しい技術的ソリューションを共に探していくことになっているからだ。この例では、チーム間コミュニケーションの不在が、ストリームアラインドチームに何か問題が起きていることを示唆している。
  
  彼らはこの時点でコラボレーションモードを採用することの価値を理解しているのだろうか？このコラボレーションを実施するのに十分なスキルを持っているのだろうか？それとも別のチームの方が適してはいないか？チームが橋を橋を架けようとしている境界は、あまりにも大掛かりではないか？
  
  ・チームトポロジーの絶え間ない進化
  　密接なコラボレーションから限定的なコラボレーション、そしてX-as-a-Serviceに至るまでのチームトポロジーの進化を図8.6に示す。
  
  探索によって技術やプロダクトへの理解が深まるにつれて、初期の密接なコラボレーションは発展し、コラボレーションする対象の数を減らす。さらにプロダクト境界やサービス境界が確立されると、X-as-a-Serviceへと発展していく。
  
  ・図8.7 企業におけるチームトポロジー
  　チーム1はプラットフォームチームとのコラボレーションを続け、新しいパターンや新しい技術の使い方を発見している。この探索活動によって、チーム2は最終的にプラットフォームとの間にX-as-a-Serviceの関係を導入できる。その後、チーム3より先は最新バージョンのプラットフォームを導入し、プラットフォームチームと密接にコラボレーションすることなくサービスとして利用する。
  
  　組織におけるチームトポロジーは、数ヶ月にわたってゆっくりと変化する。毎日や毎週ではない。数ヶ月かけて、インタラクションモードに変化を促し、それに付随してソフトウェアアーキテクチャーにも変化が起こることを期待すべきなのだ。
  
  ・チームトポロジー進化のきっかけ
  　組織内のチームトポロジーを再設計するきっかけになる状況はいくつかある。これらを知って学べば、組織は自らの義務を理解し、適応と進化を続けられるようになるだろう。
  - 1チームで扱うにはソフトウェアが大きくなりすぎている
  - デリバリーのリズムが遅くなり始めている
  - 複数の業務サービスが大量の下位のサービス群に依存している
  
  ・自律操舵設計と開発
  　では、組織はどんなものを感知すべきなのだろうか？組織が答えを見つけるには、これらの質問が役立つかもしれない
  
  　どうすれば、チームが機能のコーディングを終えた後も、長期間ソフトウェアを継続的にケアできるだろうか？ケアの継続性を向上するための最も重要な変更点の1つは、「保守」または「通常業務」(BAU)チームを作らないことだ。
  
  ・図8.10 新規サービスとBAUのチームをペアにする
  　旧システムを保守するためのサイバネティックなアプローチでは、新規サービスと旧システムを開発し実行する単一もしくはペアのストリームアラインドチームがある。これによって、チームは新しいテレメトリを旧システムに取り込み、両システムからのセンシングの精度を高められる。
  
  　最前線の運用システムから高精度な情報を生成し受信するには、高いスキルと意識を持った人材が必要だ。つまり過去の多くのIT運用チームとは対照的に、IT運用部門の人材に求められているのは、問題を素早く正確に認識して選別し、新機能の構築にあたる仲間に正確で有益な情報を提供することである。

  0

  詳細をみる
  コメント0件をすべて表示
• 

  かばおさんの感想

  フォロー

  2022年8月25日

  少し前に話題になって積読していたのですが、組織単位の課題発見をするヒントになるかと思い、読みました。チートポ。論旨としては、「チーム内外のコミュニケーションを最適化するように組織構造をつくり、逆コンウェイの法則によって設計もいいかんじにしよう」みたいなかんじ。組織構造として、ロールごとに4つのチームタイプを紹介しています。この手のエンジニアリング組織本は、論理の積み上げではなくて実情の課題をとく方策を提案するせいか、自分にはあまりうまく読めないです。結局、解こうとしている課題があまりわからないまま目が滑って途中で読むのをやめました。認知負荷を軽減するという視点は参考になりました。

  0

  詳細をみる
  コメント0件をすべて表示