| « 2008年5月15日 | 2008年5月16日の投稿 |
2008年5月19日 » |
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
| « 2008年5月15日 | 2008年5月16日の投稿 |
2008年5月19日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命