スクラムは境界を生み出す

@sakaba37さんから言われてハッと気づいたこと。
スクラムはあえて境界を作り出している、と。

「More Effective Agile」で良く出る言葉は、「スクラムチームはブラックボックスとして扱える」ことだ。
チームをブラックボックスとして扱える利点は、2つある。
１つは、外部のプロジェクトマネージャはチームのマイクロマネジメントが不要で、インプットとアウトプットの評価だけでチームをコントロールできる点だ。
これはスクラムチームだからこそ実現できる。

もう一つは、疎結合なスクラムチームを組合せることで、大規模なソフトウェア開発にもスクラムを適用しやすくなる点だ。
スクラムチームは、コンウェイの法則「アーキテクチャは組織構造に従う」の呪縛から逃れられる。

実際、スクラムチームはチーム単体でアウトプットの増分を定期的にデリバリーできる能力を持ち、他のチームに依存する必要性はない。
よって、スクラムチームを一つのコンポーネントに対応付けることで、大規模なソフトウェアを組み立てることが出きる。
昨今、クラウド上の開発が主流になることで、マイクロサービスのアーキテクチャが流行しているが、その理由も、スクラムチームがマイクロサービスと相性がいいためだろう。

よくある駄目な例は、大規模なソフトウェアを開発するチーム構成を、データベースチーム、インフラチーム、アプリチーム、フロントチームのような機能別組織で分割してしまうことだ。
すると、1つの機能を作るために、数多くのチームに依存せざるを得ず、その分、複雑な組織構造を盛り込んだソフトウェアを作り込んでしまう。

これはオブジェクト指向設計と同じ発想で、疎結合なコンポーネントを組合せることで、各コンポーネントは互いにメッセージパッシングし合い、変な副作用を起こさずに大規模なソフトウェアを組み立てることができる。
同様に、疎結合なスクラムチームは、互いにコミュニケーションを取り合うが、変な副作用を起こさずに、大規模なソフトウェアを開発できる基盤をもたらす。

つまり、スクラムチームは専門性を発揮できるチームであり、チーム単体で諸問題を解決できる能力も持つので、そういうチーム設計が可能になるわけだ。
たぶん、Lessはそういう発想で組み立てられているのでは、と想像している。
だから、Lessは暗黙知を重んじる日本人好みなのだろう、と。