スクラム実践者が知るべき97のこと

89大きく考える

ジェームズ・コプリエン

スクラムガイドで元々説明されているスクラムは、1チームで複雑なプロダクトを開発し、提供し、保守するためのフレームワークである†1。

大組織がアジャイルの分け前にあずかろうとするにつれて、巨象も踊らせられるとうたうスケーリングフレームワークが出てきた。軍隊的な階層組織と同じような意味でよいなら、そのようなフレームワークもうまくいくかもしれない。しかし、階層組織はアジャイルの個人と対話という価値観とは相反する。Scrum@Scaleのチームのチームという階層構造では、それぞれのノードに5つのサブノードが含まれる（ほかのチームや個々の開発者）。625人の組織では、平均の開発者間の距離は7.5ホップになる。スモールワールド理論†2によれば、地球上のすべての人間は最大でも6ホップにすぎない。Scrum@Scaleでは、たった625人で、社会が地球上の80億人に提供しているものよりも劣る接続構造を作ってしまう。

だが、スクラムでの開発がそんなに大きくなる必要はほぼない。スケーリングのよくある言い訳は、小さなグループでは知的能力の限界も小さく、複雑なプロダクトのスコープを扱いきれないという思い込みだ。それでも人の心に限界はない。ほかには生産性を言い訳にする。スクラムの語り手たちが、カイゼンによってベロシティが桁違いに上昇すると話してもだ。より良いプロセスと、より大きな組織のどちらを選ぶ？と聞かれたら、答えは明白だ。Borland QPW†3、Skypeなど、小さなチームでも大きなプロダクトを開発する能力があると証明した例は多い。 ...