なぜ小さなチームが重要なのか？システムの品質面からの考察

システム全体の品質は、そのシステムを構成する各要素の品質の積で表現される。

システムは一つでも欠陥があると全体として欠陥があるとみなされる。なので、例えば90%の信頼性のモジュールと90%の信頼性のモジュールを組み合わせたシステムを作ると、両方において問題が発生していない確率は81%となり全体としての信頼性も81%となる。

このようなパターンはシステムとモジュールの関係だけに当てはまるわけではなく、組織やプロセスにおいても仕組み（システム）である以上同じように当てはめることができる。一人がミスをすればお客様からの信頼を失うってしまうことは、個人という構成要素が会社というシステム全体の品質を左右しているといえるし、生産工程の中で一行程で問題が発生した場合に全行程が止まってしまうことも同様である。

では、システム（仕組み）の品質を上げるためにはどうすればよいのか？

各要素の品質をあげることができれば、それに超したことはない。しかしコストと品質の関係は逓減関係にあるため、品質を60%から61%へ上げるのはそれほどコストがかからなくても、98%から99%へ上げるのにはより多くのコストがかかる。そのため、各要素の品質を上げるのは次第にコストに見合わなくなってくる。

それを打開する方法の一つが”冗長化”をすることだろう。一人がミスをしてもカバーできるようにその人の仕事をチェックする人を設けておけば事故を未然に防げるし、あるサーバが止まっても大丈夫なように複数台のサーバを事前に準備しておくことでサービス全体が止まるという事態を避けることができる。冗長化の場合、例えば90%の信頼性の部品と90%の信頼性の部品を組み合わせた場合、両方に同時に問題が発生する確率は1%なので結果として99%の信頼性を担保できるようになる。

とはいえ冗長化もコストはかかる。そのコスト次第では割にあわなくなってくる。他に解決方法はあるのだろうか。それが”構成要素を少なくする”というアプローチだ。90%の品質の要素が3つあった場合、2つに減らすことができれば、それだけでも10%近い品質向上につながる。要素が減ることにより品質を上げつつコストも減らすことができる。ただ賢明なみなさんはお分かりかと思うが、単純に構成要素を減らすと全体が成り立たなくなるため、要素が少なくても成り立つような仕組みを再デザインすることが重要となる。

普通の感覚では大きな方がよしとされがちなので「小さなチームを目指します」といってもあまりピンとこない人も多い。ただ、システムの世界においては小は大より優位性がある。小さなままでいることで品質を効率的に高めることができるため、極力小さくとどまれるように工夫をしなければならない。チームを小さく保つこと、ソフトウェアを小さく保つこと、ユーザインターフェースを小さく保つこと、なぜそういうことが大切なのかを今までうまく説明できていなかったので改めて整理をしてみた。