🐡
メモ：チームトポロジー Part1
概要
『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）を読んだメモとポエム。
長くなりそうだったのと、本書が三部構成になっているので部単位で書いていこうかなーと。
- Part2: https://zenn.dev/black_tr1007/articles/e5ae392c0a98a8
- Part3: To Be Continued...
Part1 TL;DR
- コンウェイの法則：システムを設計する組織は、その構造をそっくり真似た構造の設計を生みだしてしまう
- 逆に言えばシステムアーキテクチャとチームインタラクションは同時に設計するとメリットが有る
- チームトポロジーはチームの目的と責任を明確にし、チーム間の相互関係の効果を向上させる
- 組織設計は取りうるソフトウェアの設計を限定する
- 全員が他のすべてとコミュニケーションするように求めるのは混乱のもと
- チーム内のフローがよくなるようなアーキテクチャを選択する
- ダンバー数を踏まえて組織／グループ／チームの人数を制限する
- チームの認知負荷容量にあわせて責任を限定し、明確な境界を作る
- 作業環境はチームの成功に影響する
Chaper 1: 組織図の問題
- 組織図は通常階層型のレポートラインとして設計されるが、実際のコミュニケーションは図のとおりに行われるわけではない
- 組織図のとおりにコミュニケーションパスや責任分界点を考えることは効果的ではない
- 『Organaize for Complexity』（著：ニールズ・プレイギング）で示された3つの組織構造
- 公式の構造（組織図）：コンプライアンス遵守などを円滑にする
- 非公式な構造：個人間の影響力の図
- 価値創造構造：個人やチーム間の能力に基づいた仕事の影響範囲
- チームトポロジーでは価値創造構造を重要視
- チームに権限を与え、チームを基本的な構成要素とする
- チーム内の個人はチームと密接に連携しながら進む
- 他チームとのインタラクションを明示的に合意する
- ふるまいが明確化し、チーム間の信頼関係が育まれる
- コンウェイの法則
- 「システムを設計する組織は、その構造をそっくり真似た構造の設計を生みだしてしまう」
- 価値創造構造とシステムアーキテクチャには強い相関があるという話
- 同形力とも
- 逆コンウェイ戦略
- チームを必須のアーキテクチャ設計に従わせるのではなく
- システムに反映したいアーキテクチャに合うようにチーム構造を変える
- 認知不可とボトルネック
- 個人・チームにキャッシュできる情報には限りがある
- しかし、チームに責任やシステムを割り当てるときにこれを議論することはあまりない
- 認知不可が定量化できないという話もある
- 結果、チームの責任と担当は広がり続け、仕事に熟達する余裕がなく、業務のコンテキストスイッチが膨大になる
- チームトポロジーが目指すもの
- 変更フローとシステムからのフィードバックを最適化する組織設計
- チームトポロジーの提供するもの
- 基本的なチームタイプ
- ストリームアラインド
- プラットフォーム
- イネイブリング
- コンプリケイテッド・サブシステム
- インタラクションモード
- コラボレーション
- X-as-a-Service
- ファシリテーション
- 基本的なチームタイプ
ポエム
「早いフローを実現する上での障害」の図に「数年ごとの苦痛な組織再編」とあって頭が痛くなった。
へーしゃでもう3回くらい経験したが、コミュニケーションパスが大混乱したり、再編のドサクサに紛れてシステムの責任分界が闇に葬られたり、どの部署が何をやってたのかわからなくなったり、そもそも新しい名前が覚えられず定着した旧称でしか会話が成り立たなかったり・・・。
Chapter 2: コンウェイの法則が重要な理由
- 「システムアーキテクチャと組織のアーキテクチャが対立する場合、組織のアーキテクチャが勝つ」（ルース・マラン）
- 組織はリアルな現場でのコミュニケーションと一致／近似した設計を生み出すように制約される
- これに内製・外注の差はない
- 例えば
- 職能型サイロ構成の組織でE2Eのフローに適したシステムは生まれない
- 地域ごとの販売チャネルベースの組織が全世界向けに展開できる効果的なアーキテクチャは作り出せない
- コンウェイの法則を逆手に取る
- 組織内のコミュニケーションパスが組織の考案するソリューションを限定する
- 逆に言えば、ある設計を使わせたくなければそうならないように、ある設計を採用させたければそのように、組織構成を変えれば良い
- ただし、これはあくまで可能性を高めるだけでもある
- 組織設計にあたって
- 意思決定者は「エンジニアリングチームの形成と配置はシステムアーキテクチャに強い影響を与える」ことを受け入れる
- 人事部門はソフトウェアシステムについてどの程度知っているか
- 予算配分などを決める人たちは自分たちの決定がシステムの生存可能性に与える影響を知っているか
- 技術リーダーの意見を聞かずに決定を下すのは非効率で無責任である
- 不必要なコミュニケーションについて
- コミュニケーションは全て歓迎するべきというわけではない
- 論理的にはコミュニケーションが発生しないパス・内容の場合には何かが間違っている可能性がある
- 多対多のコミュニケーションが求められる場合組織設計上の問題がある
- 全員がチャットの全メッセージを見るべき
- 大規模なスタンドアップミーティングに全員出席するべき
- 意思決定のために全員が会議に出るべき
- など
- ツールの利用
- 組織全体で1つのツールを選択すると不必要なコンフリクトが発生する
- 独立したチームでは個々にツールを選択する
- コラボレーションするチームでは共有ツールを
- 軽率にコンウェイの法則を適用するのは微妙
- 異なるコンポーネントのチームがたくさんできる
- 一般的にはストリームアラインドチームが好まれる
- 縄張りづくりや人員削減のための組織再編
- 組織構造はプロダクトのアーキテクチャを見越したものであるべき
- チームファーストのアプローチを採用しよう
- 管理の利便性や人員削減のための定期的な組織再編はソフトウェアを効果的に構築・運用する能力を奪う
ポエム
「大企業で働いたことがあるなら、モノリシックな共有データベースがビジネス全体を支えている例に遭遇したことがあるだろう」という一文が最初の方にある。
初期配属の子会社はこれが当たり前に横行していたし、何ならトップがそれに集約させるように働きかけていたりした。
当時はそれが効率的だと思っていたが、異なるビジネスロジックを一つの管理システム・DBに集約させる作業は大変だったらしく、結局私の在籍中には解消しなかった記憶がある。
親会社も同じような状況だったし、傍から見てビジネス上の課題を解決してないシステム開発している部署は誇らしげにリリースノートを書いており、本書の「職能型サイロの組織」の課題ってこういうところなのかなぁなどと思ってしまった。
Chapter 3: チームファースト思考
- 「チームが偉業を成し遂げるのは、単にそれぞれの資質が優れているからだけでなく、 メンバーがまとまって1つの生命体と化すからだ」（スタンリー・マクリスタル）
- スタープレーヤーよりもチームとしての団結力の話かな
- チームの人数
- 本書ではチーム＝5～9人の安定したグループ
- Amazonのピザ2枚ルール
- お互いのことを詳しく知って親密な関係を築けるのは5人程度
- ダンバー数
- チームサイズの限界とダンバー数
- ダンバー数
- 5人：親密な関係 or ワーキングメモリーを保持できる人数
- 15人：深く信頼できる人数
- 50人：相互信頼できる人数
- 150人：他人の能力を覚えていられる人数
- ダンバー数の人数については諸説ある
- 共通しているのは、組織の中で効果的に働けるグループの数には限界があるということ
- チームのプラクティスがスケールした瞬間に活きなくなることもしばしば
- ダンバー数
- 長続きするチームを作る
- チームが軌道に乗るには2週間から3ヶ月以上かかる
- 例えば半年のプロジェクトを終えたチームを解散したり人を増やすのは非効率的
- 人月の神話の頃から言われている
- 高信頼な組織（～150人）では人が年に1回程度移っても大きく影響しない
- Pivotalの取り組みなど
- チームが長続きする≒チームがソフトウェアのオーナーシップを獲得する
- ソフトウェアの保守や生存可能性について考えられる
- オーナーシップはあくまで世話役であり、専有や縄張りではない
- 世話役が複数いるソフトウェアは誰もオーナーシップを発揮しない
- チームファースト思考を持つ
- メンバーはチームファーストのマインドセットを持つべき
- デリバリーの単位、評価や報酬もチーム単位が望ましい
- 『Out of the Crisis』（著：エドワード・デミング）
- マネジメントにとって重要な14項目
- 年次個人評価の廃止
- 目標設定によるマネジメントの廃止
- 認知不負荷の定義
- 『ワーキングメモリで利用される心理的労力の総量』（著：ジョン・スウェラー）
- 課題内在性負荷：問題領域の本質的なタスクに関連するもの
- 実装方法やドメインモデルなど
- 課題外在性負荷：タスクが実施される環境に関連するもの
- テスト環境の状態や環境構築の方法など
- 学習関連不可：特別な注意が必要なタスクに関連するもの
- ビジネスドメインや特定のアルゴリズムなど
- 認知不可のマネジメント
- 基本的には課題内在性負荷と課題外在性負荷を下げていく
- 自動化、研修、XXX Driven系の実践など？
- 付加価値のための学習関連不可を重視
- 基本的には課題内在性負荷と課題外在性負荷を下げていく
- チームが扱うドメインの種類の制限
- ドメインの種類をシンプル・煩雑・複雑に分類
- ドメインを単一のチームにアサイン
- ドメインがチームに対して大きかったらサブドメインに分割
- サブドメイン単位でチームにアサインする
- 単一のチームがシンプルなドメインを数個扱う
- ルーティン化によるモチベ＝ションの低下に注意
- 複雑なドメインをアサインしたチームに他のドメインはアサインしない
- 例えばシンプルなドメインをアサインすると、そっちばかりやって複雑なドメインが進まなくなりがち
- 集中させよう
- 煩雑なドメインを単一チームに2個アサインしない
- チームがドメイン単位で分裂しやすくなる
- 初めからチームを分割して1個ずつアサインするべき
- チームAPIを設計する
- チーム間のコミュニケーションネットワークを作る手段
- チームが他のチームとコラボレーションするのに必要なあらゆるものをドキュメント化する
- ソフトウェアの外部仕様
- バージョン管理
- ソフトウェアのHow to
- チーム内プラクティス
- コミュニケーション方法
- バックログ
- その他必要なものはなんでも
- APIなので当然ユーザビリティも考慮するし、テストと改良が必要
- オフィススペースの話
- 完全オープン、個人ワークスペースだけなど極端に振るのはよくない
- コラボレーションする時、集中して活動する時などチームの状況で必要な環境は変わる
- いいバランスは難しいが、ここを疎かにしてはいけない
- 完全オープン、個人ワークスペースだけなど極端に振るのはよくない
- 基礎になるのはエンジニアリングのプラクティス
- CI/CDやTDDといった技術的な素養がなければチームファーストはワークしない
- 仮説駆動とフィードバックサイクルでプロダクトが進む仕組みが先ずは重要
- エンジニアリングチームはそこに対して継続的な努力をする
ポエム
チームAPIの考え方はすごくいいなと思った。
隣のチームとのやり取りはチケットシステムで行っているが、そのチケットのテンプレートが大量にあり、どれを利用すれば良いのかわからないことも増えてきたなということを思い出してしまった。
チームAPIに限らずチームWikiを作成することは多くのチームで実践していると思うが、情報の陳腐化を防ぐ良い方法はないものだろうか・・・。
評価の方法を個人主義からチームの成果ベースにという話も非常に納得がいく。
役職が上がると「他人を巻き込んでムーブメントを起こす」ことが求められがちだが、これが横行すると手柄の取り合いが起きたり、漁夫狙いが増えたり、局所最適化ばかりが起きたりといいことがない（実体験）。
チームやプロダクトの成果に応じてその単位で評価していくというのはプロダクト／サービス自体を良くしていくムーブメントを起こしやすくなり、会社の成長にもつながっていくのかなと思った。
Discussion