チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 読書メモ
https://scrapbox.io/files/66b736137d96ee001dc701ec.png
/emoji/tea.icon ：自分の解釈したポイントのアイコン
#読書メモ は内容をそのまま書くのではなくメモをとりながら読んで、考えたことを記録するもの 少し読んでみて難しかったので、まず次の資料を参考にさせていただいた
時代に合わせて組織構造も変化していく必要が出てきた
FourKeys
素早く頻繁に安定的に、問題があればすぐ直す
「速いフロー」を阻害する要因は複数ある。
コンウェイの法則を無視、他
チームトポロジーとは、その速いフローを実現するためのもの
位相幾何学（トポロジー）とは、図形をゴムのようなものでできていると考え、グニャグニャと連続的に変形できるものは同じと思う、とても柔らかい幾何学のことです。
/emoji/tea.icon 柔軟に適応できる、チームの構造のパターン（と、理解した）
チームトポロジーの中心
コンウェイの法則
逆コンウェイ戦略
チームファースト
チーム間の情報共有と連携=ベストではない
チームの疎結合
/emoji/tea.icon なるほど、そう言われるとわかる
チームAPI
チームの使用する機能を使用する際はインターフェースを使用する
Amazonの例
一般の人が使うのと同じAPI使ってるらしい
Amazonの例は極端だが、チームの周りを取り囲むものをAPIとして定義する考え方
/emoji/tea.icon GET: /このチームの仕事のやり方
Response {must: "これこれをこうする"}
4つのチームタイプ
ストリームアラインド
一番中心となるチームタイプらしい
/emoji/tea.icon こっちがいわゆる普通のドメインごとのチームか？
イネイブリング
それぞれのチーム？
/emoji/tea.icon それぞれのスキルとかを支援してくれるチームっぽい
実作業はしないらしい
コンプリケイティド・サブシステム
もとREチーム？
プラットフォームチーム
うちでいうSRE
3つのインタラクションモード
インタラクションとは英語の「 inter（相互に）」と「action（作用）」を合成したもので、その基本は「人間が何かアクション(操作や行動)をした時、そのアクションが一方通行にならず、相手側のシステムなり機器がそのアクションに対応したリアクションをする」ということです。
コラボレーション
X as a Service
ファシリーテーション
チーム同士の関わり方のことっぽいな
/emoji/tea.icon ここまで読んでチーム構成の図がスッと理解できた
組織的センシング
チーム構造を変えていく
トポロジー進化
タイミングを見て変えていく
本書に戻ってきた
Step1
組織のコミュニケーション構造
コミュニケーションの取り方はチームだけではなく、仕事を終わらせる上で必要な人と連絡とる
コミュニケーションは必然的に複雑になる
/emoji/tea.icon 組織図とコミュニケーションは連動するものではない（組織図以上のコミュニケーションが発生する）
P6 図1.1がまさにそう
認知負荷
色々横断で知っておいたほうが良いことはあるが、認知負荷も考慮すべき
Step2
組織の構造とアーキテクチャの構造は密接に関わってしまう
/emoji/tea.icon 個人のマネジメント、組織の開発体制とかを見据えていくなら『LeanとDevOpsの科学』も読みたい
/emoji/tea.icon 逆コンウェイの弱点は？みたいな問いにも答えられるようにしたい。自分の解
例えば、パッと思いつくのはDBだけを管理するエンジニアはそんなにいない、人が多く必要になる
それはでも仕事があれば課題でもない気がする
チームごとに技術選定がバラバラになってサイロ化する可能性はあるかな
知見の共有とかがしづらそう