パターン1:組織の規模を決める    

 

図1 我々が研究した多くの組織での役割の数は、著しく近い値を示している。これは、プロセスごとの役割(ノード)の分布のヒストグラムである。これは、スタッフのレベル(人の数、役割の数ではない)ではないが、組織の規模を決めるガイドラインになる。

問題:

組織はどのくらいの大きさであるべきか?

コンテキスト:

コスト競争力があり、世の中で一番短いと思われるスケジュールに適合するように、ソフトウエア組織を作ろうとしている。最終製品の最初のリリースは多分25,000行を超えるコードになりそうである。

開発組織は、スポンサーとなる企業あるいは会社のような大きな組織の中の一部として組み込まれる(論理的根拠を参照)。

これは、ソフトウエアを作る組織に対してのみ適用される。例えば、既存のソフトウエアを組み合わせるような仕事をする組織には直接的には適用できないであろう。

影響する事柄:

大きすぎて、大幅に縮小しなければならなくなった。

大きな組織は舵をとるのが難しい船である。

小さすぎて、開発に必要な組織としての最小人数にも満たない。

小さすぎる組織は、不適切な慣性を持つており、不安定になりがちである。

規模は提供物に非線形的に影響する。情報交換のオーバーヘッドは規模の二乗に比例する。これは、組織の結合力は規模の二乗に反比例するのに対し、“馬力”だけはリニアに増加することを意味する。

新しい人は、組織に同化してしまった元からいる人に比べて、組織の中の他の人と非常に密接に接触し、組織のより広い範囲の人と接触する。

解決策:

デフォルトとして10人を選びなさい。適切に選ばれた教育を受けた人の小さなチームは、31ケ月で1,500KSLOC、15ケ月で200KLOC、8ケ月で60KSLOCのソフトウエアを開発できることが経験上わかっている。開発の後の方の工程で人を増やしてはならない。最終期限を、完成日から計算しなおした日に合わせるように試みなさい。

結果として生じるコンテキスト:

ほとんど全員が“共通の知識”を持つことができる組織になる。我々は、プロジェクトのほとんどの役割は、6つから7つの役割となら相互関係を維持することができることを経験的に発見した。10人なら、全員の間での情報交換を管理することができる(完全に結合されたネットワークは必要でないかもしれない)。一方では、10人というのは適切な“組織としての開発に必要な最小人数”である。

このパターンは、組織の成長を押さえるのに役立つ段階的な補充見習いのパターンと密接に関係している。またプロトタイプとも相互間系がある。

論理的根拠:

組織を小さく保つことは、すべての人がプロジェクトがどのように動いているのかを知ることを可能にする。うまくやっているプロジェクトは適合するプロセスを持つている。プロセスがうまく適合するのは、広く行きわたった“やったことが報われるという風土”がある場合のみである。“やったことが報われる風土”のために必要になる対話は、小さな組織にのみ生じる。Tom DeMarcoは、プロセスから利益を得る人はすべて、プロセスでの仕事とプロセスの意思決定に係わっていなければならないと注意している。

最初に10人いるのは多分多すぎるが、後から人を増やすことによる出費とオーバーヘッドを避ける。

このパターンは大きなプロジェクトのためのものである。25KSLOCを超えるようなプロジェクトでも、まれには1人でやってしまうこともできる(ソロ名音楽家のパターン参照)。

それぞれの管理スタイル(リーダーシップ主導、マネージャー主導)は、組織のタイプ(民主制、共和制、寡頭制)によって成功したり失敗したりする。リーダーシップ主導の管理スタイルは、これらの組織がうまく働く助けになる。すなわち、プロジェクトメンバーは適切な管理スタイルによってうまく表されていると感じているのでので、民主的であることを強いる必要性はあまり感じられない。[これは、管理スタイルについての新しいパターンかもしれない。]

1つのチームの方がサブチームの集まりよりもいい。1つのチームが、組織の責任が大きいと悩んで、小さなサブチームへ分裂するのが早ければ早いほど、企業全体としての効率は悪くなる。

多くのソフトウエア開発文化は、1人のテクニカルマネージャーが面倒をみるグループの大きさはここまで、という数字を持つている。多くの人を追加することは、グループを分割することになり、生産性以外は同等であっても、生産性を大いに落とすかもしれない。

さらなる研究が、このパターンとAlexanderの"The Distribution of Towns" [Alexander 2]や他のパターンの間の関係を評価するかもしれない。ここでは、我々は、社交的な組織は小さくなければならない、と規定する。それは、''Subculture Boundary'' [Alexander 13]と''Identifiable Neighborhood'' [Alexander 14]のパターンを反映している。Alexanderは、人間が持つ外部から入ってきたものを嫌うという傾向を維持しながら、環境を維持することと大きな町が供給することができる規模の経済とのバランスをとるという壮大なアーキテクチャ的な状況を強調している。ここでのパターンによって作られたような小さな組織は隔離された状態の中にあるのはまれで、より広い支援組織の状況の中に存在する。この大きな組織への関係は、パトロンのパターンを思い起こす。

開発の後の方の工程で人を増やすということについては、たくさんの神話がある。あるマネージャーは、「あるプロジェクトで、顧客との契約を満足するために新しい人で10人から20人へ人を増やした。新しく入ってきた人の組織への“吸収”のために、3ケ月も 遅れてしまった。」と書いている。