最近、ソフトウェアシステムのモデリングとしてドメイン駆動設計（DDD）、開発手法のフレームワークとしてスクラムの人気があります。
Web上でもこれらの情報は多く、またこれらの組み合わせについても議論されているので、難しいという話はあるものの、概ね受け入れられているのだと思います。
それでは、これらを実践する開発チームの組織構造はどうなるべきでしょうか？
コンウェイの法則
開発チームの組織の構造と、ソフトウェアシステムのアーキテクチャの関係を示す法則があります。それがコンウェイの法則です。
コンウェイの法則とは、ソフトウェアシステムのアーキテクチャは開発チームの組織とよく似る、というものです。
引用元：https://bliki-ja.github.io/ConwaysLaw/
この法則に則ると、開発チームの組織、ソフトウェアシステムのアーキテクチャ、ビジネスドメイン、そしてスクラムチームと開発するプロダクトの関係は以下のような図になるかと思います。
逆コンウェイ作戦
開発チームが分割されるほど規模の大きいプロダクトにおいて、スクラムでDDDをうまく達成していくには、チームの組織構造まで含めて設計する必要がありそうです。
コンウェイの法則に基づいて、このような最適なアーキテクチャに合わせて組織構造を変えていく戦略を、逆コンウェイ作戦と呼びます。このようにみていくと逆コンウェイ作戦を取る場合、DDDによって見いだされたビジネスドメインに基づいて、チームすらフィードバックループの中でうまく組み変えていく必要があるのかもしれません。
認知負荷
チームの組織構造を変えると言っても、頻繁に変更されていると、チームのパフォーマンスは低下してしまいます。
ここで、チームのパフォーマンスを考える際に、影響を与える一つとして認知負荷があります。認知負荷とは、「ワーキングメモリで利用される心理的労力の総量（つまり負荷）」のことで、内在性、外在性、学習関連の3つがあるとされています。
各認知負荷ともに、チーム構成の頻繁な変更により大きくなると考えられます。
特に、学習関連負荷に含まれるビジネスドメインについての負荷は、DDDに応じたビジネスドメインのコンテキスト境界に合わせたチームを考えると、それらを頻繁に移動することが負荷を高め、それが一定以上高くなりすぎてしまうと、パフォーマンスに影響が出る可能性が高いといえるかと思います。
信頼関係
認知負荷以外で、チームのパフォーマンスに悪影響を与えると想定されるのが、信頼関係です。
チームメンバー間の信頼関係の構築が適切な判断、デリバリーの安全性や速度に影響するとされています。
しかし、一般的にダンバー数*1と呼ばれるグループにおける認知と信頼の上限数が知られています。これによると、1人の人間が信頼できる人間の数は100人から250人程度であること、そのうちお互いを詳しく知って親密な関係を築けるのは5人程度、とされています。
このような点から、チーム内の構成が頻繁に変わることは抑えつつ、ドメイン、アーキテクチャにあったチームの組織構造が変わっていく方法を考えていく必要があるでしょう。
まとめ
今回は、DDD、スクラム、コンウェイの法則を通して、開発チームの組織構造をどのように考えるべきかを簡単に考察しました。
チームの組織構造が単に外部から与えられるものとせず、開発チームから適切なチームの組織構造を生み出せると良さそうですね。
参考
補足：コンポーネントチームとフィーチャーチーム
書き終えてから少しして、「ある種のコンポーネントチームを推奨しているような書き方になったのではないか」という風に感じ、補足を書き足すことにしました。
今回の図において、1チーム1ドメインという描きかたになってしまいましたが、1チーム複数のビジネスドメインや、複数チームが同一のビジネスドメインを担当することは特に問題ないと思っています。
一方でやはり大規模化したシステムにおいて、1チームがシステムが関わる全ビジネスドメインを担当するのは現実的ではないように思います。
どうしても、チームの認知における現実のビジネスドメイン知識に対する限界が存在し、システムの関わるすべてのビジネスドメインを担当することが現実的でないことを想定して今回の記事を書きました。ビジネスドメインに縛られずに各ビジネスドメインを担当していけるチームが構築できるなら、それが良いと思いますし、難しい場合には、今回のようなことを踏まえて、チームの構成を考える必要があるかと思います。
もちろん、今回のスクラムチームのイメージは、ビジネスドメインに対して必要なソリューションを提供できる、フィーチャーチームを想定しています。
どのような組織構造が良いかは、開発するプロダクト、企業文化やチームメンバーの習熟度など様々なものに影響されると思います。これが答えというよりも、最適なチーム構成を自分たちで見つけていくのが大切で、今回の記事はその参考の1つになればと思います。
