感情タグBEST3
Posted by ブクログ
近年のソフトウェア開発における組織のあるべき姿をシンプルに解説した良書。
4つのチームと3つのインタラクションモードという切り分け方は、実際の業務においても納得感があった。
一方で、このプラクティスを適用できる段階・できない段階の組織というものはそれぞれありそう。
本書に登場する単語は独特なものばかりで、概念を知らない人には伝わりづらい部分がある。
とはいえ、難解な概念は少なく、昨今の組織戦略の文脈では多く登場するのもあって、理解と咀嚼に時間を割く価値はあるなと感じた。
コミュニケーションパスの制限による開発速度の向上は実感としても感じるものがあるが、チーム間のコミュニケーションによって生まれていた何らかが生まれづらくなる懸念があるのではないかと感じた。
そういった部分を俯瞰的に見る役目はイネイブリングチームか、あるいはEM的な立場の人になるんだろうか。
Posted by ブクログ
これまで縦、横、マトリックス、プロジェクト、タスクフォースのような従来の組織パターンでしか考えることが出来なかったソフトウェア開発組織について、コンウェイの法則を踏まえた現代のソフトウェア開発に適応するための新しいチームタイプを定義し、それらをどのように組成し、どうコミュニケーションさせるとよいかを説明した書籍。組成時の設計だけでなく、どのように変化させたら良いかを考えるための良い参考書。
Posted by ブクログ
組織構造とプロダクトが連動するのは別の本で「コンウェイの法則」に出会って知っていてが、より組織構造をどのようにすればよいのかのヒントになる。
IT業界の話ではあるけどもこれはどれぐらい他の組織にも応用できるのかも気になった。
また、「コンウェイの法則」が言われてからこんなにも時間が経ってから組織構造に注目があるのかが不思議である。これまでは組織よりも個人の生産性が高ければなんとかなっていたのかな。
Posted by ブクログ
# 多方面からプロダクトに立ち向かうための、戦略的組織論
## 面白かったところ
- 組織とソフトウェアアーキテクチャは密接に関わり合っており、人こそがソフトウェアであり組織を良くも悪くもすることがわかった
- 自分が管轄外のプロダクトには適切な境界線（interface）を切って、異なる概念を持ち込まない・持ち込ませない制約があるとイイことを改めて学べた点
## 微妙だったところ
- 引用がとても多く、著者自身の熱い思いがあまりなかった点。チームトポロジーのフレームワークはすごいしやってみる価値はあるんだけど、イマイチ引き込まれれる何かがなかった。
## 感想
現場での課題図書として上がっていた一冊。なにもないところから著者の真意を汲み取ることは難しいだろうなとは思いつつ、現場での組織構成を擬えて見るとかなりイメージが進んだ。
人間一人の認知負荷にも限界があり、チームのそれにも限界がある。この前提を踏まえたうえで、自チームで担当すること・しないことのドメイン境界を切ってinterfaceでハーネスをかける。
「〇〇チームは▲▲機能の担当」という境界を Package by Featureで区切る。多機能とやり取りするときは必ずInterfaceを切って、他チームとコミュニケーションを図る。
なるほど。今やっている僕らの軌跡はこの本からやってきたんだと腑に落ちた。
Posted by ブクログ
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
エンジニア、コンサルタントのマシュー・スケルトン氏、マニュエル・パイス氏の著書です。ソフトウェアの開発、運用組織に関する書籍になります。
【本書で学べること・考えること】
- コンウェイの法則
- 一般的な組織構造がソフトウェアに与える影響
- 組織図とコミュニケーションギャップ
- 認知負荷
- 逆コンウェイ戦略
- チームファースト思考
- チームのアンチパターン
- 4つの基本的なチームタイプ
- 3つのチームインタラクションモード
- 組織構造のプラクティス
読んでみての感想です。
この本のベースは、「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というコンウェイの法則をベースにしています。
組織構造をあるべきアーキテクチャに合わせて変化させることで、ソフトウェアのアーキテクチャを最適化するという思想です。
コンウェイの法則、言われてみればですが目から鱗です。
基本となるストリームアラインドチーム（DevOps）を中心に基盤を支えるプラットフォームチーム、補助するイネイブリングチーム、専門的なサブシステムを提供するコンプリケイテッド・サブシステムチームという4つの基本的なチームが、コラボレーション、X-as-a-Service、ファシリテーションの3つのインタラクションので関わり合う構造のプラクティスを紹介しています。
自社サービスの会社ではない場合、完全に適用することはできないですが、組織の構造、認知負荷、チームの定義、タックマンモデルなど、チームに関する知見は大いに参考になると思います。
マネージャーやマネージメントを目指す方には、是非、一読してほしい良書です。
Posted by ブクログ
こう、スッキリと概念を示してくれているのは、ここをスタートポイントにいろいろ考えを巡らせることのできるタイプの良書だと思う。
コンウェイの法則を再認識させてくれたことと、チーム間の関係も動的に変化させていくものだという視点が特によかった。
ただ、この本に書かれているのは設計指針なので、コンテキストに合わせた実装は自分たちで考える必要がある。わかっていてもそこがしんどいところだと思う。ショートカットはなくて、泥臭く取り組むしか無いのだよ、っていうことですね。
Posted by ブクログ
カタカナ語と抽象的な概念が多くやや掴みにくさはある。コンウェイの法則は、ソフトウェアと開発チームの関係性を指し示す概念で真を食っていると感じる。
セントラル方のアナリティクス組織に置き換えた時に3つのコラボレーション全てが当てはまるので、組織を最適化させる際には切り分けて考える必要がありそう。
① コラボレーション
② X as a Services
③ ファシリテーション
↓
①例：ビジネスパートナー活動・レポート作成
②例：tableauダッシュボード提供（作成ではなく
③例：セルフBI活動
Posted by ブクログ
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、ツール、ソフトウェア製品全体など)。コラボレーションは最小限になっている
・ファシリテーションモード：あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする
Posted by ブクログ
やや難解。日本語は不自然でないがすんなり入ってきにくい。また日を改めて読み直してみる。
“いまどき”の組織編成のあり方として明確な指針を示していると感じる。将来に通用するかは分からないが、いまはこれがベストだろう。
事前の知識を必要としていて解説が平易でないところも多いうえ、組織を編成する責任者とか所属チームを拡張する一端を担うような人でないと使いどころが無さそう。組織のビジョンをこの書籍で共有することは難しい。
