少人数のチームの方がソフトウェアの品質は高いという経験則

少人数のチームの方がソフトウェアの品質は高いという経験則の記事があったのでメモ。
この記事は非常に興味深い。

【参考】
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 － Publickey

ソフトウェア開発の世界では、幾つかの有名な経験則がある。
例えば、Conwayの法則「ソフトウェアアーキテクチャはそれを作った組織構造をそのまま反映してしまうので、複雑な組織は複雑なソフトウェアを作る」があるし、ブルックスの法則(人月の法則)「遅れているプロジェクトにメンバーを追加すると、より一層プロジェクトは遅延する」などがある。

(引用開始)
ソフトウェア開発の世界では、次のような法則があると言われている。
コンウェイの法則： 組織の構造が、システムの設計にも大きな影響を与える。
ブルックスの人月の神話： 組織の構造がプロダクトの品質に大きな影響を与える。
しかし組織が実際にどれくらいソフトウェアの品質や構造に影響を与えるかは分かっていなかった。それを研究したものだ。
(引用開始)

マイクロソフトの事例では、少人数のチームの方がソフトウェアの品質は高いという経験則が得られたらしい。
つまり、Conwayの法則、ブルックスの法則はソフトウェア品質にも適用できるわけだ。

上記記事の下記の文章がとても分かりやすい。

(引用開始)
組織構造の縦方向が短い方がソフトウェア品質がいい。
少し分かりやすい例を示す。

1つ目はバグが発生するリスクの低い例。青い色が組織、緑の輪が1つのバイナリ、赤が新機能、星が変更を示す。
この図では、赤い丸の新機能を追加するときに3カ所の変更が行われたことを示している。これが1つの組織の中ですべて行われていれば、バグが発生するリスクは低い。

次はリスクの高いパターン。組織をまたがってバイナリが存在し、新機能も変更部分も散らばっている。これは問題が発生する典型的なパターンだ。

3つ目は、潜在的なリスクを含んでいるパターン。複数の組織によってあるバイナリに対して新機能の追加なしに変更が行われる。こういうときには、お互いの変更に気付かず、いつの間にかバグを抱えてしまうという可能性が高いのだ。
(引用終了)

例えば、4つのチームが一つのシステム(war, jar, dll, exe等)を開発しているとする。
1個のチームで閉じているバイナリモジュールの機能の修正は、バグの影響度が小さい。

4つのチームにまたがるバイナリモジュールに手を加えた場合、他チームへの影響が大きいために、バグの発生リスクが高くなる。
新規機能や機能変更などを一括リリースすれば、必ず本番障害が発生し、問題状況の収拾さえ付かなくなる場合もありうる。
デスマーチプロジェクトそのものだ。

一方、4つのチームにまたがるバイナリモジュールの一部をあるチームが修正した時、その修正が他チームへの影響の考慮が漏れてしまえば、潜在バクになる。
そのような仕様変更が積み重なっていけば、システムの技術的負債は大きくなり、リファクタリングすらできなくなるだろう。

そして、最終的には、バグ修正のコストが大きすぎると判断して、システムの外でデータパッチを当てたり、人が手運用でシステムトラブルを回避するなど、沢山の人手でカバーせざるを得なくなる。
10年以上使い続ける業務システムは、ほとんどが、定期的な手運用のシステムサポート業務でカバーされていて、システム保守費用の方が毎年高くなっている時が多いだろう。

そんな事を思うと、大規模な組織でソフトウェアを作るよりも、少人数のチームで開発するスタイル、つまり、アジャイル開発が現場に浸透しているのは、上記のような経験則を知らなくても、暗黙知として認識しているからだろう。

個人的には、今まで皆が当たり前と信じているソフトウェア開発の常識を、Redmineに蓄積されたチケットデータから分析して評価することができたら面白いだろうなあ、と思ったりする。