Scaling Agile ... ソフトウェア開発をスケールさせる（大規模対応）

Agile開発はどうしても少人数での開発が多い。スタンドアップミーティングができる人数、つまり１ダースが１つの目安。また、ウォーターフォールなら大規模が成功するか、というと、ぼくはウォーターフォールの大規模開発で成功例を見たことがない。本当にソフトウェア開発はスケールさせられるのだろうか、という疑問もある。

ソフトウェア開発をスケールさせるにはどうしたらよいのだろうか。

別のドメインの似た例として、Webのサーバー側のシステムをスケールさせるには、２つの考え方がある。

・scale up ... １マシンのCPUやメモリ、バス性能などをアップさせて、システムのパフォーマンスを上げる。
・scale out ... マシンの数を増やして、システムのパフォーマンスを上げる。

scale up には限界がある。その時点のテクノロジの限界があるから。逆に scale out 作戦が成功するようなアーキテクチャに持っていければ、成功だ。負荷が上がればどんどんマシンを足せばよい。

同じように、ソフトウェア開発チームにも、同じような２つのスケール作戦があるのではないか、というアナロジーに気づいた。

・scale up ... 個人のパワーや個人間のコミュニケーションを上げてチームのパフォーマンスを上げる。
・scale out ... 人の数を増やして、チームのパフォーマンスを上げる。

基本的には、チームは簡単には scale out しない。人を増やしてもコミュニケーションが複雑になるだけでリニアにはチーム性能がでない。また、モチベーションやゴール共有という意味でも人数を増やすことでは限界がある。

では、scale up はどうだろう。例えば、Ruby言語を使ってAgile開発をやる、ということは、よりS/N比の高い言語を使って個人の「脳内」の働きをより高効率にし、さらに、チームの「脳間」コミュニケーションバンド幅を最大に（フェイス・トゥ・フェイスでJITコミュニケーション）することで、scale up しようという作戦なのである。

こう考えると、ソフトウェア開発をスケールさせる、というやりかたのバリエーションと、方向性が見えてくるのでは、と思ってメモしてみた。（この記事はあとで英語にする。）

で、結論としては、そもそも、ソフトウェア開発という「知識創造活動」は原理的に scale out しない。よって scale up 作戦でいく、ということではないか、と考えている。

Agile2008でも、Scaling Agile というのは大きなトピックだ。それでもAgileをスケールさせるには、ぼくは今まで行われていたScrumの階層化（Scrum of Scrum)のような方向ではなく、たとえば、リーンのかんばんを用いたフラットな、チームの繋ぎ方ができなか、と思っている。
http://www.infoq.com/news/2008/01/kenji-hiranabe-agile-kanban