# チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 ## Metadata * Author: [マシュー・スケルトン、マニュエル・パイス、原田騎郎、永瀬美穂、吉羽龍太郎](https://www.amazon.comundefined) * ASIN: B09MS8BML8 * Reference: https://www.amazon.com/dp/B09MS8BML8 * [Kindle link](kindle://book?action=open&asin=B09MS8BML8) ## Highlights 組織は、機械的で線形なシステムではなく、複雑で適応性を持つ有機体として見るべきである。 — location: [380](kindle://book?action=open&asin=B09MS8BML8&location=380) ^ref-40882 --- 高品質でインパクトのあるソフトウェアを提供するというゴールをサポートするため、組織構造は、説明責任をうまく調整しなければいけない」 — location: [406](kindle://book?action=open&asin=B09MS8BML8&location=406) ^ref-10725 --- 人と技術を人間とコンピューター、カーボンとシリコンからなる単一の社会工学的エコシステムと考えるのだ。同時に、チームは内発的に動機づけられ、システムのなかで最高の仕事ができる本物の機会を与えられなければいけないのだ。 — location: [411](kindle://book?action=open&asin=B09MS8BML8&location=411) ^ref-25518 --- 少なくともIT業界においては、プロダクトとチームを中心に据えるという考え方が最近の大きな潮流となっており、ミック・カーステンが著書『Project to Product』で提唱しているような「プロジェクトからプロダクトへ」は重要なマイルストーンの１つになっている。 — location: [452](kindle://book?action=open&asin=B09MS8BML8&location=452) ^ref-41413 --- チームトポロジーのアプローチでは、プレイギングが定義した非公式構造と価値創造構造の重要性を認めている。チームに権限を与え、チームを基本的な構成要素として扱うことで、チーム内の個人は、単なる人の集まりとしてではなくチームとして密接に連携しながら進むようになる。一方で、他のチームとのインタラクションモードを明示的に合意することで、期待するふるまいが明確になり、チーム間の信頼関係が育まれる。 — location: [468](kindle://book?action=open&asin=B09MS8BML8&location=468) ^ref-4527 --- 組織設計における経験則を５つ紹介している［８］。 １．やむを得ない理由があるときに設計する ２．設計判断のために選択肢を用意する ３．適切な時期に設計する ４．整合性が取れていない箇所を探す ５．将来を見据える — location: [490](kindle://book?action=open&asin=B09MS8BML8&location=490) ^ref-43039 --- チームトポロジーでは特に、さまざまなチームが技術や組織の成熟に応じてどう進化するかに目を向けている。 — location: [505](kindle://book?action=open&asin=B09MS8BML8&location=505) ^ref-53468 --- 認知負荷について話すとき、ある瞬間に脳にとどめておける情報の量には誰でも限りがあることは容易に理解できる。チームの場合も同じで、チーム全員の認知容量の合計を超えることはできない。 — location: [554](kindle://book?action=open&asin=B09MS8BML8&location=554) ^ref-1705 --- 全体として、チームトポロジーのアプローチでは、変更フローと稼働中のシステムからのフィードバックを最適化する組織設計を提唱している。チームトポロジーでは、チームの認知負荷を制限し、チーム間のコミュニケーションを明確に設計する必要がある。 — location: [582](kindle://book?action=open&asin=B09MS8BML8&location=582) ^ref-35057 --- コンウェイの法則によれば、チームを編成する前にどんなソフトウェアアーキテクチャーが必要かを理解する必要がある。 — location: [732](kindle://book?action=open&asin=B09MS8BML8&location=732) ^ref-4017 --- さもないと、組織内のコミュニケーションパスとインセンティブがソフトウェアアーキテクチャーを決定づけてしまう。 — location: [733](kindle://book?action=open&asin=B09MS8BML8&location=733) ^ref-10584 --- コンウェイの法則の背後にある同形性を示す証拠が増えていることを考えると、技術リーダーの意見を聞かずにチームの形成、責任、境界について決定を下すというのは、ソフトウェアシステムを構築する組織にとって非常に非効率で、そしておそらく無責任なのだ。 — location: [770](kindle://book?action=open&asin=B09MS8BML8&location=770) ^ref-26898 --- コンウェイの法則は、こういった多対多のコミュニケーションは、速いフローをサポートしない、モノリシックで、こんがらがっていて、結合度が高く、相互依存するシステムを生み出す傾向にあることを示している。コミュニケーションを増やすことは必ずしもよいことではないのだ。 — location: [828](kindle://book?action=open&asin=B09MS8BML8&location=828) ^ref-54180 ---