チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング

2025年2月13-14日に行われたDevelopers Summit 2025の登壇資料です。

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. チームトポロジーで紐解く プロダクト開発組織の進化とスケーリング 2025/2/14 Developers Summit fi 株式会社アトラクタ / Certi ed Scrum Trainer (CST) 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー（CST） ▸ X(Twitter): @ryuzee / https://www.ryuzee.com/ 2
3. 自己紹介 3 最新書籍紹介（買ってください!!） 2025/3/26 発売!!
4. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり
5. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング はじめに ▸ プロダクト開発は最初は小さなチームから始まる ▸ プロダクトがうまくいくようになると、開発に関わる人の数は増えていく ▸ 一方で単純に人を増やすだけでは、開発の速度は思ったほど上がらないことがほとんど ▸ 成功を続けるには、顧客に「素早く」「頻繁に」「安定的に」価値を届け続けなければいけない ▸ 安定した速いフロー ▸ そのためには、プロダクト開発組織の構造も状況にあわせて進化させていかなければいけない ▸ そこで使えるのがチームトポロジーの考え方 5
6. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チームトポロジーとは？ ▸ 安定した速いフローを実現するためのもの ▸ 適応型の組織設計モデル ▸ 普遍的な公式ではなくパターン ▸ チームの目的と責任を明確にし、チーム間の相互関係の効果の向上を目指す ▸ 技術、人、ビジネスの変化に継続的に対処できるようにする ▸ 構造は静的なものではなく、状況に応じて変化させていく ▸ 根底にあるのはコンウェイの法則にどう対処するか 6
7. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング コンウェイの法則 “ システムを設計する組織は、 そのコミュニケーション構造をそっくり まねた構造の設計を生み出してしまう メルヴィン・コンウェイ 1968 ” 7
8. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング コンウェイの法則 ▸ 組織設計がソフトウェア設計を決める ▸ 「4つのチームでコンパイラを作成すると、4パスコンパイラになる」 ▸ つまり、職能別組織では、多くのコミュニケーションが必要な複雑なシステムが出来上がってしまう ▸ 「システムのアーキテクチャーと組織のアーキテクチャーが対立する場合、 組織のアーキテクチャーが勝つ」（ルース・マラン） 8
9. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング コンウェイの法則による組織構造→アーキテクチャーの例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p22-23） 9
10. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 10 逆コンウェイ戦略 ▸ コンウェイの法則からは逃れられないことを前提に、それを戦略的に活用した組織設計を目指す ▸ 「組織はチーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現す ▸ = 望ましいアーキテクチャと同型の組織を設計する ▸ すばやく価値を届けることを前提として組織を設計する ▸ 人的資源の効率的な活用よりも、価値の効果的なデリバリーを優先する べ ▸ 「効率より効果」 き」
11. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 逆コンウェイ戦略によるアーキテクチャ→組織構造の例 出典：『チームトポロジー』（マシュー・スケルトン、マニュエル・パイス著、原田騎郎、永瀬美穂、吉羽龍太郎 訳、日本能率協会マネジメントセンター 、2021、p24-25） 11
12. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チームを中心に据える （チームファースト） ▸ プロダクト開発組織の成果とは、顧客にすばやく継続的に価値を届けること ▸ これを組織全体で目指す必要がある ▸ たくさん作ることは目的にはならない ▸ 効率よりも効果を目指す ▸ 組織図やマトリクスに依存した組織構造では、素早いデリバリーやイノベーションは無理 ▸ 権限とスキルを持つチームこそがアジリティの土台となる ▸ チームを基本的な構成要素として扱う ▸ グループが大きくなると、必要な信頼関係が維持できなくなるので、10人くらいまでのチームにする 12
13. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 機能しているチームを長く保つ “ ハイパフォーマンスなチームを解散する のは、単なる破壊行為では済まない。企業 レベルのサイコパスと呼ぶべきものだ アラン・ケリー 『Project Myopia』 ” ※ メンバーを完全に固定しなければいけないという意味ではないので注意 13
14. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チームの認知負荷を考慮する ▸ 人間が脳にとどめておける情報の量には限りがある ▸ 同じことはチームにも言える。チームの責任範囲や担当範囲が広がりすぎると…… ▸ コンテキストスイッチが大きくなる ▸ 優先順位がつけられなくなる ▸ 結果としてモチベーションも低下する ▸ 認知負荷が高いと内発的動機の3要素（ダニエル・ピンク）に影響を及ぼすようになってしまう ▸ 自律・熟達・目的 ▸ ゆえに、チームが扱うソフトウェアの(サブシステムの)サイズを制限する ▸ チームの認知負荷にあわせてソフトウェア境界を選ぶ（後述） 14
15. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 15 4つのチームタイプ ▸ 多くの組織にはさまざまな種類のチームがある ストリームアラインドチーム ▸ チームの役割を無計画に拡張して、誰も全体がわからない ▸ チームの種類を4つに絞ることでこの課題に対処する イネイブリング チーム ▸ ストリームアラインドチーム ▸ プラットフォームチーム ▸ イネイブリングチーム ▸ コンプリケイテッド・サブシステムチーム ▸ チームタイプに応じた目的、役割、責任を担う コンプリケイテッド サブシステムチーム プラットフォームチーム
16. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 16 4つのチームタイプ ストリームアラインドチーム プラットフォームチーム イネイブリングチーム コンプリケイテッド・ サブシステムチーム ビジネスの主な変更フロー（つま りストリーム）に沿って配置するチ ーム インフラやツール、共通サービス などの内部サービス（プラットフォ ーム）を提供するチーム 他のチームが新しい技術やスキ ルを身につけるのを支援するチー ム 名前のとおり複雑なサブシステム やコンポーネントを扱う専門チー ム ‣ 職能横断型で、他のチームを待 ‣ セルフサービスAPI、ツール、サ ‣ 特定の技術や製品ドメインのス ‣ その分野のスペシャリストでな たずにデリバリーできる ‣ 要求探索から本番運用まで、デ リバリーに関わる能力一式を持 っている必要がある ‣ 中心となるチームタイプ ‣ 残りの種類のチームは、すべて ストリームアラインドチームの 負荷を減らすために存在する ービス、サポートなどから構成 される基盤 もしくは 使用が強 制される内部プロダクト ‣ これによってストリームアライ ンドチームは詳細を知る必要が なくなり認知負荷が下がる ‣ サービスが使いやすくて信頼性 が高くなるようにする ペシャリストから構成される ‣ ツール、プラクティス、フレーム ワークの調査や提案、オプショ ンの探索を行う ‣ テクニカルコンサルティングチ ームとも言える（実作業はしな い） ‣ 短期的な支援となるのが普通 ければ理解や変更が難しいよ うな領域を担当する ‣ AI、機械学習、動画処理、数理モ デル、特殊技術、特殊パッケー ジ…… ‣ これによってストリームアライ ンドチームの認知負荷を減らす ‣ 必要なときだけ構成する
17. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 17 3つのインタラクションモード ▸ コミュニケーションや調整に時間をかけるモデルはスケールしない ▸ すべてのチームが他の全チームとやりとりするのは避けなければいけない ▸ チーム間の関係性において、相手とコラボレーションするか、サービス・プロバイダーとして使うかが 判断の分かれ道 ▸ チームがインタラクションする3つの基本的なモード ▸ コラボレーション ▸ X-as-a-Service ▸ ファシリテーション コラボレー ション XaaS ファシリ テーショ ン
18. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 18 3つのインタラクションモード コラボレーションモード 概要 利点 弱点 制約 X-as-a-Serviceモード ファシリテーションモード 一方のチームが他方のチームが提供 するものをサービスとして利用する関 係性 一方のチームが他方のチームが新しい 技術を身につけたり学習したりするた めにファシリテーションする。他のチー ムの障害を取り除く 引き継ぎが少なく、すばやいイノベー ションと探索が可能 オーナーシップが明確。認知負荷を減ら せる ストリームアラインドチームの障害を取 り除きフローを増やす。不足している能 力や機能を検出できる 責任分界点が不明確。認知負荷の増大 を招く。オーバーヘッドによる生産性低 境界やAPIのイノベーションは遅くな る。境界を間違えるとフロー全体に影響 下 を及ぼす 1つのチームが同時にコラボレーション できるのは1チームまで 同時並行で複数のチームとX-as-aServiceモードでインタラクションする 可能性がある 2つのチームが探索を目的として協力 しあう。責任境界が不明確で効率は悪 いが学習は進む 経験豊富なスタッフが必要 同時並行で複数のチームとファシリテ ーションモードでインタラクションする 可能性がある
19. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 4つのチームタイプ、3つのインタラクションモードの利点 ▸ 数種類に類型化することで、共通言語になり、チーム構造の会話がしやすくなる ▸ モデリングのための図形を使って、組織構造を見える化できる ▸ これによって全員が共通理解を持てるようになる 19
20. プロダクト開発組織の構造の変遷
21. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 最初のチーム 仮説検証チーム 変更のフロー ▸ プロダクトの初期は、仮説検証を行う数人の小さなチーム（先遣隊）から始まる ▸ プロダクトの企画、デザイナー、エンジニアなどが含まれる。少人数で何でもやる ▸ まだ他の仕事を兼任していることも多く、少人数なのでプロセスもほとんどない ▸ 小さなものをリリースすることもある ▸ 仮説検証でうまくいかなければピボットしたり終了したりする 21
22. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング プロダクト開発を始める（人が増えてアジャイル開発が始まる） ストリームアラインドチーム 変更のフロー ▸ 仮説検証をさらに進めるべく実際のプロダクト開発に着手する ▸ 人を増やし開発できるようにする。それにあわせて何らかのプロセスと責任を決める ▸ 1チームで要件決め、設計、開発、テスト、リリース、運用まで面倒を見る（1チームでなんでもやる） ▸ 1チームなので、アーキテクチャーはモノリシックになるのが普通（モノリスファースト） ▸ プロダクトがうまくいかないと、このままの体制でどこかで終了することも…… 22
23. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング プロダクトがうまく行き始めると人が増える ストリームアラインドチーム 変更のフロー ▸ 人数が増えるが、扱う仕事の領域や量も増える ▸ 認知負荷が高くなり、開発のパフォーマンスは線形比例では上がらない ▸ オンボーディングに時間がかかる ▸ アジャイル開発のイベントやミーティングに時間がかかるようになる ▸ そこで構造の見直しを検討する 23
24. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 複数チームによるアジャイル開発への進化 ストリームアラインドチーム フィーチャーチーム 変更のフロー ▸ この時点ではモノリスなので、同一コードベース上で開発するフィーチャーチームに分割する ▸ スキルでチーム分割してしまうと依存関係が増え、リードタイムが伸びやすいので避ける ▸ チーム間は作業の調整が必要なので、プランニングやレビュー、レトロスペクティブを共有 ▸ スクラムの場合、LeSSやNexus、Scrum of Scrumsなどのスケーリングパターンの活用（難しい） ▸ 複数チームの成果物を継続的に統合してリリースする。つまりストリームは1つ 24
25. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 25 だが、そのままスケーリングするのは難しい （=大規模アジャイルは難しい） ストリームアラインドチーム 統合チーム フィーチャーチーム 変更のフロー ▸ 全チームが集まってコミュニケーションを行い、足並みを揃えるモデルはスケールしにくい ▸ 例えばプロダクトマネージャーやプロダクトオーナーの負荷が著しく高くなり、単一障害点になる ▸ 開発者自身の扱わなければいけない範囲が増える（認知負荷が高い） ▸ リリースのときに各チームの成果を統合するオーバーヘッドが大きくなる ▸ 何らかの形で、それぞれのチームの依存関係を小さくし、自律的に動けるようにしなければいけない
26. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 26 プロダクトの成長によってアーキテクチャーの見直しが必要にな る。成長の過程で投資が必要だし成長しているので投資できる ドメインやサービスで分離 ストリームアラインドチーム（コア） ストリームアラインドチーム（社内業務系） ストリームアラインドチーム（決済） ストリームアラインドチーム（認証） 変更のフロー ▸ チームを分離し、アーキテクチャを見直すことで、それぞれのチームが独立してリリース可能になる ▸ 例：モノリス→モジュラーモノリス、モノリスからのサービス分離 ▸ それぞれの領域で法的要件やサービスレベル、性能要件が異なっても、対応が容易になる
27. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング ストリームアラインドチームの境界を決める節理面 ▸ ビジネスドメインのコンテキスト境界（いちばん中心的） ▸ 法令・規制遵守 ▸ 変更のリズム ▸ チームの地理的配置 ▸ リスク ▸ パフォーマンス ▸ 技術（他のチームへの依存関係が限定的な場合） ▸ ユーザーペルソナ ▸ ほかにもあるかもしれない 27
28. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 技術による分離 / プラットフォームの抽出 28 これによって各チームはリリースをある程度自由に行えるように なる。開発プロセスも自分たちで決められる ストリームアラインドチーム iOSチーム ストリームアラインドチーム Androidチーム ストリームアラインドチーム Webチーム プラットフォームチーム バックエンドAPIチーム 変更のフロー ▸ 初期の段階ではバックエンドAPIチームはコラボレーションモードでAPIの仕様や範囲を決める ▸ 基本的には、バックエンドAPIチームはAPIをサービスとして提供し、X-as-a-Serviceモードのインタラクション ▸ プロダクトのドメインがある程度安定していないと、バックエンドAPIが安定せずに問題が波及する
29. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 専門性が必要なコンポーネントで分離 29 コンプリケイテッドサブシステムチームは研究開発的な要素も あるため、裁量を持った仕事の仕方が必要になることもある ストリームアラインドチーム 機械学習チーム AIチーム コンプリケイテッド サブシステムチーム コンプリケイテッド サブシステムチーム ストリームアラインドチーム 変更のフロー ▸ 機械学習やAIなど専門性が高いとき、内容が複雑でブラックボックスとして扱ったほうがよいときに、コ ンプリケイテッドサブシステムチームに隠蔽する ▸ ストリームアラインドチームはこのチームの成果物を利用する
30. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 30 社内コンサルティングチーム的な位置づけになる 支援系のチームを分離 ストリームアラインドチーム SREチーム 開発技術チーム イネイブリングチーム イネイブリングチーム ストリームアラインドチーム 変更のフロー ▸ 各チームに必要な知識をトランスファーするイネイブリングチームを用意し、各チームを支援すること で、品質やパフォーマンス（SREであれば信頼性の維持・向上に関すること）の向上につなげる ▸ スキルが身につけば支援は終わるので、チームとの関わりはアドホックなことが多い
31. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 31 プロダクトの進化によって、チーム構造は変化し続けることを前 提にする。これは避けられないものだと考えることが重要 チーム構造は変化し続ける ストリームアラインドチーム コンプリケイテッドサブシステムチーム ストリームアラインドチーム コンプリケイテッドサブシステムチーム ストリームアラインドチーム イネイブリングチーム プラットフォームチーム プラットフォームチーム
32. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング 32 Docker社の事例 https://teamtopologies.com/industry-examples/rebuilding-and-scaling-product-development-at-docker-using-team-topologies
33. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チーム構成を変化させるときに気をつけること ▸ チームのなかにいる人たちの感情を考慮する ▸ チーム構成の設計活動にチームメンバーを入れる ▸ チーム構成を変更する理由を明確にする ▸ チームのミッションを明確にする ▸ 誰がどのチームなのかを決める ▸ チーム構成の変更があったことをアナウンスする ▸ 大シャッフルは危険なやり方 33
34. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チーム構成を変更するときのパターン（メンバーの観点） ▸ チームトポロジーではチームの構造に焦点を当てているが チームのメンバーや文化を考慮して変更しないと失敗する ▸ ダイナミックリチーミング（Dynamic Reteaming）の活用 ▸ チームのメンバーを変更するときの5パターンが定義されている ▸ ワンバイワンパターン ▸ グロウアンドスプリットパターン ▸ アイソレーションパターン ▸ マージパターン ▸ スイッチングパターン 34
35. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング ワンバイワンパターン 35 プロダクト組織の変化の過程でいつも発生する ▸ いちばん基本的かつ頻出のパターン ▸ 既存のチームに1人づつ人を追加する ▸ 全体の構造をいじらないのでリスクは少なく、チームの継続性を保つ ▸ 一方で新しく加わる人のスキルや視点をチームに持ち込む ▸ 新しくチームに加わる人のオンボーディングは重要 ▸ メンターをつけたり、ペアプログラミングをしたりする ▸ 退職やチームからの離脱もこのパターンに含まれる ▸ このときに残すべきチームの文化について検討する
36. ロウアン ス リット ターン 36 特にプロダクトが成長フェーズのときによく発生する ▸ ワンバイワンでチームに人が増えてくると、このパターンを誘発 ▸ チームが大きくなりすぎると、以前より物事の進みや意思決定が遅 くなった、自分に関係ない話が増えたと感じるようになる。チームに 誰がいるのかわからないということも…… ▸ そこで大きなチームを2つかそれ以上のチームに分割する ▸ 分割後のチームはそれぞれ別のミッションを担う ▸ 分割後のチームは依存関係を最小限にする ▸ 当事者のチーム自身が分割を決めるのが望ましい パ プ ▸ 誰がどのチームに行くかも含めて ド グ チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング
37. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング アイソレーションパターン 37 新しいプロダクトの開発や特命プロジェクトで発生する ▸ 新しいアイデアや緊急事態に取り組むときに出現するパターン ▸ 既存のチームから人を選抜して、隔離されたチームを作る ▸ ほかから邪魔されないように場所も移動して隔離する ▸ チームでは既存のプロセスではなく、自由なやり方で仕事を進める ▸ 探索的な仕事なので、自律的に仕事を進められる人を入れる ▸ 役割分担よりも仕事を前に進めるために必要なことをやる ▸ 新しいアイデアがうまくいけば、そのままチームとして継続する ▸ 目的を達成したらチームを解散して、もとのチームに戻ることもある
38. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング マージパターン 38 取り組みの自由度を上げたいとき、スキルを拡張したいときに発 生する ▸ 小さなチームが多数あるときに発生するパターン ▸ 作業領域ごとにチームを1つづつ置くのは制約があるときや、大きな チームのなかで作業の柔軟性を持たせたいときに出現 ▸ それぞれのチームが持っていたスキルを組み合わせることができる ▸ 例えば、ペアプログラミングのペアのバリエーションが増える ▸ 大きくなったチームのなかで、メンバーが自律的にサブチームを動的 に作り変えることもある ▸ チームはそれぞれ違う文化やプロセスを持つので、マージしたときに はキャリブレーション（調整）が必要
39. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング スイッチングパターン 39 メンバーのスキルやキャリア向上を行うときに発生する ▸ 複数チーム間でメンバーを交換するパターン ▸ ほかのチームと知識やスキルを共有、交換したいときに出現 ▸ ペアプログラミングはある意味チーム内のスイッチングパターン ▸ 同じことをずっとやっていると停滞感が生まれるので、個人の成長や 学習のために交換することも多い ▸ リーダーやマネージャーは優秀な人を囲い込みたいと思うかもしれな いが、組織にとってもメンバーにとってもよくない ▸ 組織によっては手を挙げると移動できる仕掛けにしていることも
40. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チーム構造を変えるときはキャリブレーション（調整）を行う ▸ チーム構造を変え人を動かしただけですぐに機能することを期待してはいけない ▸ チームの歴史を共有する ▸ 自分の情報を共有する ▸ 役割を整理する ▸ チームのミッションや仕事の内容を整理する ▸ プロセスや仕事のフローを共有、調整する 40
41. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング チーム構造を変えたあとにレトロスペクティブを行う ▸ チーム構造を変更してしばらくしたら、時間をとって検査する ▸ 対面でのレトロスペクティブやアンケートを活用する ▸ チーム構造の変更が期待した効果を生んでいるかどうかを確認する ▸ フィードバックをもとに、今後のチーム構造の変更をもっとうまく進められるように改善する 41
42. チームトポロジーで紐解くプロダクト開発組織の進化とスケーリング まとめ ▸ 速いフローを実現（維持）するという観点でチーム構造を考える。それに使えるのがチームトポロジー ▸ プロダクトがうまくいくようになると、開発に関わる人の数は増えていく ▸ だが、ずっと同じ構造のままスケーリングすることはできない（大規模アジャイルは難しい） ▸ チーム構造は現在の状況にあわせて変えていかなければいけない ▸ 速いフローを維持するためには、ストリームラインドチームを複数作ることになる ▸ プラットフォームチーム、イネイブリングチーム、コンプリケイテッドサブシステムチームが支える ▸ チーム構造を変更するときは、チームのなかにいる人たちの感情を考慮する ▸ チーム構造を変更するときは、ダイナミックリチーミングの5つのパターンを考慮する ▸ レトロスペクティブを活用して、構造変更を評価し、次回もっとうまくできるように改善する 42

Comment

No comments...