本の概要
- 企業のソフトウェア開発能力を支える、チームの構造の在り方を議論する本
- 同じ会社の方に、欧米のDDD Communityで最近よく言及されると聞いて興味を持った
読書メモ
第一章
基本的な問題意識
- 冒頭で、ソフトウェアを内製している企業が検討の対象としてあげられる
- かつては以下の2つの間に一定のトレードオフが許容されたが今は両方を達成しなければならない
- (1)アプリケーションの安定性
- (2)進化する速度の速さ
- 上記のチャレンジングな要求を達成するためには、安定してパフォーマンスを出し続け、かつ、適応的に進化し続けるチームが求められるが、それらの課題に対し効果的に寄与しない組織管理手法が今も使われている
コミュニケーションをマネジメントする手法
- 著者はソフトウェア開発を効率的に営むためには、コミュニケーションの在り方を最適化することが重要と考えている
- コミュニケーションの在り方を最適化するためには、部門などの組織構成が最適化されている必要があるが、組織図ではその達成は難しい
- 組織図は実際のコミュニケーションのあり方を反映していない
- ピラミッド型組織をイメージしてツリー図を書くが、実際は、組織図に現れない横のコミュニケーションが組織を駆動させている [1]
- また組織図は組織の構造を静的に表現しようとするが、実際の組織におけるコミュニケーションはもっと相互作用により振る舞いを変える動的なものである。そういった側面が組織図では扱うことができない
では、どのようなモデルが必要なのか？
- もっと外部環境の変化に対して適応的に成長し、姿を変え続けるチームを表現できるモデルが欲しい
- 別の言い方をすると、チーム内/チーム間のコミュニケーションによる動的な相互作業を扱えるモデル
コンウェイの法則を活用すると、組織構造とソフトウェアアーキテクチャの関係性を扱うことが可能になる
- コンウェイの法則は1968年にMel Conwayの論文にて提唱された
- Microservice Architectureの流行により、コンウェイの法則の復権(復活)のようなことが現在進行形で起きている
- 著者は、ソフトウェアーキテクチャとチームのアーキテクチャは相互に影響を与え合う不可分な要素と考える
- コンウェイの法則はこれらの問題に対して重要な洞察を与えてくれる
- ThoughworksのJames Lewisは 逆コンウェイ・マヌーバ( Inverse Conway Manoeuvre ) という概念を発案した
認知負荷とコミュニケーション
- 1人の人間が頭の中に保持・展開できる情報の量には限界がある。また頻繁にコンテキストをスイッチするとこれらの能力は短期的に消耗・劣化する。これらの能力を認知負荷と呼ぶ
- 認知負荷は一般に広く知られた現象であるが、チームが処理可能な仕事の総量/キャパシティを計画する際にはなぜか考慮されない
- チームの認知負荷のキャパを超えるまで、種々の複数の異なるコンテキストの仕事がアサインされ続ける。そして最終的にチームが機能不全に陥る
- 上記を防ぐために何ができるのか？
[1] こちらの本でも類似のテーマが扱われています
ワンミッション 米軍発、世界最先端の組織活性化メソッド
